VHDL 2008 simplified conditions

[Jerry]

Hi all:

I was attracted to simplified conditions, but they don't cross to mixed std_logic / boolean such as this:

elsif run_tx and (rd_idx < wr_idx) then

Where run_tx is std_logic and rd/wr_idx are natural. This will not work? I was hoping to get away with mixing the convenience of bool / std_logic. That should probably be an extension.

I had to put in "run_tx = '1'" to resolve to bool / bool.

Vsim does not complain about the pure std_logic expression simplification that involves all std_logic, for instance this is fine:

>> if not rd_msg_lst and RD_MSG_i then

Where rd_msg_lst and RD_MSG_i are std_logic (obvious edge detection).


So, not possible to mix bool / std_logic, right? I hope that's only "as of yet".

Thanks in advance for the comments,
Jerry

 

Am Freitag, 25. März 2016 19:39:32 UTC+1 schrieb JerryO:

Hi all:

I was attracted to simplified conditions, but they don't cross to mixed std_logic / boolean such as this:

elsif run_tx and (rd_idx < wr_idx) then


Where run_tx is std_logic and rd/wr_idx are natural. This will not work? I was hoping to get away with mixing the convenience of bool / std_logic. That should probably be an extension.

I had to put in "run_tx = '1'" to resolve to bool / bool.

Vsim does not complain about the pure std_logic expression simplification that involves all std_logic, for instance this is fine:

if not rd_msg_lst and RD_MSG_i then

Where rd_msg_lst and RD_MSG_i are std_logic (obvious edge detection).


So, not possible to mix bool / std_logic, right? I hope that's only "as of yet".

Thanks in advance for the comments,
Jerry

Hi Jerry,

the simplification is done by implicitly assuming that you used the new "??" operator, which does std_ulogic/bit to boolean conversion. This works fine for me as long as you have only std_ulogic/bit types in the expression. If you mix boolean and std_ulogic/bit things may not be so clear and i don't know if the operator precedences are good enough to assume the correct place for the "??"-operator. I'm using modelsim and the following two expressions work, with variables logic as std_ulogic and bool as boolean:

if bool and (?? logic) then ...
if (?? logic) and bool then ...

If i don't use the brackets it fails for me.
However if this behaviour is so important to you, you could always overload the operators, e.g. for "and":

function "and" (l : std_ulogic; b : boolean) return boolean is
begin
return (?? l) and b;
end function;

function "and" (b: boolean; l : std_ulogic) return boolean is
begin
return l and b;
end function;

Cheers,
Ralf

 

On Tuesday, May 3, 2016 at 8:46:09 PM UTC+12, ralf.h...@gmail.com wrote:

However if this behaviour is so important to you, you could always overload the operators, e.g. for "and":

function "and" (l : std_ulogic; b : boolean) return boolean is
begin
return (?? l) and b;
end function;

function "and" (b: boolean; l : std_ulogic) return boolean is
begin
return l and b;
end function;

This is actually illegal in VHDL (IEEE Std 1076-2008) (error in the second function aside).

9.2.2 Logic operators para 2:

For the binary operators and, or, nand, nor, xor, and xnor, the operands shall both be of the same base type, or one operand shall be of a scalar type and the other operand shall be a one-dimensional array whose element type is the scalar type. The result type is the same as the base type of the operands if both operands are scalars of the same base type or both operands are arrays, or the same as the base type of the array operand if one operand is a scalar and the other operand is an array.

Your scalar types do not have the same base type.

1.3 Structure and terminology of this standard, 1.3.1 General, para 4:

In this document, the word shall is used to indicate a mandatory requirement. The word should is used to indicate a recommendation. The word may is used to indicate a permissible action. The word can is used for statements of possibility and capability.

The consequence is that your functions should not be interpreted as overloaded operators (no use of infix notation).

I don't have access to a wide number of VHDL implementations but have found two so far that do not catch as errors functions with different base types when used as overloaded binary operators in expressions. As I recall this semantic rule was new to -1993.

 

[rickman]

On 5/5/2016 5:22 PM, diogratia@gmail.com wrote:

On Tuesday, May 3, 2016 at 8:46:09 PM UTC+12, ralf.h...@gmail.com
wrote:

However if this behaviour is so important to you, you could always
overload the operators, e.g. for "and":

function "and" (l : std_ulogic; b : boolean) return boolean is
begin return (?? l) and b; end function;

function "and" (b: boolean; l : std_ulogic) return boolean is
begin return l and b; end function;


This is actually illegal in VHDL (IEEE Std 1076-2008) (error in the
second function aside).

9.2.2 Logic operators para 2:

For the binary operators and, or, nand, nor, xor, and xnor, the
operands shall both be of the same base type, or one operand shall be
of a scalar type and the other operand shall be a one-dimensional
array whose element type is the scalar type. The result type is the
same as the base type of the operands if both operands are scalars of
the same base type or both operands are arrays, or the same as the
base type of the array operand if one operand is a scalar and the
other operand is an array.

Your scalar types do not have the same base type.

Does this apply to other than the built-in operators in VHDL?

1.3 Structure and terminology of this standard, 1.3.1 General, para
4:

In this document, the word shall is used to indicate a mandatory
requirement. The word should is used to indicate a recommendation.
The word may is used to indicate a permissible action. The word can
is used for statements of possibility and capability.

The consequence is that your functions should not be interpreted as
overloaded operators (no use of infix notation).

I don't have access to a wide number of VHDL implementations but have
found two so far that do not catch as errors functions with different
base types when used as overloaded binary operators in expressions.
As I recall this semantic rule was new to -1993.

I think you are misinterpreting the standard. If the standard has a
restriction, it would be based on some reason, some problem that would
be created if you don't stick to that restriction. What would be the
reason this restriction would apply to user defined logic operators? I
don't have the standard here to consult, so I can't see the context of
9.2.2.

--

Rick C

 

Am Freitag, 6. Mai 2016 04:10:16 UTC+2 schrieb rickman:

On 5/5/2016 5:22 PM, diog...@gmail.com wrote:
On Tuesday, May 3, 2016 at 8:46:09 PM UTC+12, ralf.h...@gmail.com
wrote:

However if this behaviour is so important to you, you could always
overload the operators, e.g. for "and":

function "and" (l : std_ulogic; b : boolean) return boolean is
begin return (?? l) and b; end function;

function "and" (b: boolean; l : std_ulogic) return boolean is
begin return l and b; end function;


This is actually illegal in VHDL (IEEE Std 1076-2008) (error in the
second function aside).

There is no error in the second function, it uses the overloaded first function, which is, as you proved by misreading it, probably not a good case of code re-use.

9.2.2 Logic operators para 2:

For the binary operators and, or, nand, nor, xor, and xnor, the
operands shall both be of the same base type, or one operand shall be
of a scalar type and the other operand shall be a one-dimensional
array whose element type is the scalar type. The result type is the
same as the base type of the operands if both operands are scalars of
the same base type or both operands are arrays, or the same as the
base type of the array operand if one operand is a scalar and the
other operand is an array.

Your scalar types do not have the same base type.

Does this apply to other than the built-in operators in VHDL?


1.3 Structure and terminology of this standard, 1.3.1 General, para
4:

In this document, the word shall is used to indicate a mandatory
requirement. The word should is used to indicate a recommendation.
The word may is used to indicate a permissible action. The word can
is used for statements of possibility and capability.

The consequence is that your functions should not be interpreted as
overloaded operators (no use of infix notation).

I don't have access to a wide number of VHDL implementations but have
found two so far that do not catch as errors functions with different
base types when used as overloaded binary operators in expressions.
As I recall this semantic rule was new to -1993.

I think you are misinterpreting the standard. If the standard has a
restriction, it would be based on some reason, some problem that would
be created if you don't stick to that restriction. What would be the
reason this restriction would apply to user defined logic operators? I
don't have the standard here to consult, so I can't see the context of
9.2.2.

I don't have the context either, as i don't have access to the 2008 standard, but i agree with Rick here. I would be puzzled to learn that this section also applies to overloaded operators. The only thing i found close to this section in the 1993 standard states basically the same, but with restriction to types bit and boolean (7.2.1). Back then, from your point of view, the extension of ieee.std_logic_1164 to apply logical operators (and, or , ....) on std_ulogic must be wrong as well.

Ralf

 

On Friday, May 6, 2016 at 10:04:04 PM UTC+12, Ralf wrote:

I don't have the context either, as i don't have access to the 2008 standard, but i agree with Rick here. I would be puzzled to learn that this section also applies to overloaded operators. The only thing i found close to this section in the 1993 standard states basically the same, but with restriction to types bit and boolean (7.2.1). Back then, from your point of view, the extension of ieee.std_logic_1164 to apply logical operators (and, or , ...) on std_ulogic must be wrong as well.

Your conclusions "with restriction to types bit and boolean" and "Back then, from your point of view, the extension of ieee.std_logic_1164 to apply logical operators (and, or , ...) on std_ulogic must be wrong as well" don't appear supported by my statements, the standard (-1993 or -2008) nor history.

The very first VHDL Issue was on this subject, and the result was as I conveyed:

VASG-ISAC Analysis & Rationale
------------------------------
This is a problem. The solution is relatively straightforward.

The paragraph starting "The following logical operators ..." needs to be
rewritten to explicitly state that both operands of a binary logical operator
must be of the same type.

For example:

The logical operators _and_, _or_, _nand_, _nor_, _xor_, and _not_ are
defined for predefined types BIT and BOOLEAN. They are also defined for any
one-dimensional array type whose element type is BIT or BOOLEAN. For
the binary operators _and_, _or_, _nand_, _nor_, and _xor_ the operands
must both be of the same type. Furthermore, in the case of the one-dimensional
arrays they must be arrays of the same length, the operation is performed
on matching elements of the arrays, and the result is an array with the
same index range as the left operand. For the unary operator _not_, the
operation is performed on each element of the operand, and the result is
an array with the same index range as the operand.
--

You could note that the predefined operators found in package standard don't require the restriction on both operands having the same base type. They're defined that way and not frangible.

The ghdl author and I were exchanging email on this overnight, he related there was an Issue Report (IR), so I searched through my archive then located a Wayback Machine URL to share (eda.org no longer available).

See:

http://web.archive.org/web/20110927064548/http://eda.org/isac/IRs-VHDL-87/IR0001.txt

This can also be found in IEEE Std 1076_int-991 (IEEE Standards Interpretations, IEEE Std 1076-1987). Document page 15.

I used to correspond with IR-0001's author on the -1993 standard but this predates my involvement.

A bit more from the -2008 standard:

9.2.2 Logical operators

The binary logical operators and, or, nand, nor, xor, and xnor, and the unary logical operator not are defined for predefined types BIT and BOOLEAN. They are also defined for any one-dimensional array type whose element type is BIT or BOOLEAN.

For the binary operators and, or, nand, nor, xor, and xnor, the operands shall both be of the same base type, or one operand shall be of a scalar type and the other operand shall be a one-dimensional array whose element type is the scalar type. The result type is the same as the base type of the operands if both operands are scalars of the same base type or both operands are arrays, or the same as the base type of the array operand if one operand is a scalar and the other operand is an array.
--

Notice the paragraph separator as in the original, eliminating any possible misinterpretation of predefined operators for BIT or BOOLEAN as a restriction on the second paragraph. I may get around to looking through the history of that paragraph separator, it means looking for Language Change Specifications (LCSs) for -2008, and the history isn't completely available.

The second function has an error in it, it depends on an illegal operator overload.

Regards,

 

[Ralf]

Am Samstag, 7. Mai 2016 09:14:44 UTC+2 schrieb diog...@gmail.com:

On Friday, May 6, 2016 at 10:04:04 PM UTC+12, Ralf wrote:

I don't have the context either, as i don't have access to the 2008 standard, but i agree with Rick here. I would be puzzled to learn that this section also applies to overloaded operators. The only thing i found close to this section in the 1993 standard states basically the same, but with restriction to types bit and boolean (7.2.1). Back then, from your point of view, the extension of ieee.std_logic_1164 to apply logical operators (and, or , ...) on std_ulogic must be wrong as well.

Your conclusions "with restriction to types bit and boolean" and "Back then, from your point of view, the extension of ieee.std_logic_1164 to apply logical operators (and, or , ...) on std_ulogic must be wrong as well" don't appear supported by my statements, the standard (-1993 or -2008) nor history.

The very first VHDL Issue was on this subject, and the result was as I conveyed:

VASG-ISAC Analysis & Rationale
------------------------------
This is a problem. The solution is relatively straightforward.

The paragraph starting "The following logical operators ..." needs to be
rewritten to explicitly state that both operands of a binary logical operator
must be of the same type.

For example:

The logical operators _and_, _or_, _nand_, _nor_, _xor_, and _not_ are
defined for predefined types BIT and BOOLEAN. They are also defined for any
one-dimensional array type whose element type is BIT or BOOLEAN. For
the binary operators _and_, _or_, _nand_, _nor_, and _xor_ the operands
must both be of the same type. Furthermore, in the case of the one-dimensional
arrays they must be arrays of the same length, the operation is performed
on matching elements of the arrays, and the result is an array with the
same index range as the left operand. For the unary operator _not_, the
operation is performed on each element of the operand, and the result is
an array with the same index range as the operand.
--

You could note that the predefined operators found in package standard don't require the restriction on both operands having the same base type. They're defined that way and not frangible.

The ghdl author and I were exchanging email on this overnight, he related there was an Issue Report (IR), so I searched through my archive then located a Wayback Machine URL to share (eda.org no longer available).

See:

http://web.archive.org/web/20110927064548/http://eda.org/isac/IRs-VHDL-87/IR0001.txt

Thank you, that link is very interesting.

This can also be found in IEEE Std 1076_int-991 (IEEE Standards Interpretations, IEEE Std 1076-1987). Document page 15.

I don't have access to this document.

I used to correspond with IR-0001's author on the -1993 standard but this predates my involvement.

A bit more from the -2008 standard:

9.2.2 Logical operators

The binary logical operators and, or, nand, nor, xor, and xnor, and the unary logical operator not are defined for predefined types BIT and BOOLEAN. They are also defined for any one-dimensional array type whose element type is BIT or BOOLEAN.

For the binary operators and, or, nand, nor, xor, and xnor, the operands shall both be of the same base type, or one operand shall be of a scalar type and the other operand shall be a one-dimensional array whose element type is the scalar type. The result type is the same as the base type of the operands if both operands are scalars of the same base type or both operands are arrays, or the same as the base type of the array operand if one operand is a scalar and the other operand is an array.
--

Notice the paragraph separator as in the original, eliminating any possible misinterpretation of predefined operators for BIT or BOOLEAN as a restriction on the second paragraph. I may get around to looking through the history of that paragraph separator, it means looking for Language Change Specifications (LCSs) for -2008, and the history isn't completely available.

This is interesting, since this separation is not present in my version of the 1993 standard.

The second function has an error in it, it depends on an illegal operator overload.

No, in that case the error is in the first function. However, i don't want to argue about this. It doesn't solve anything.

Regards,

The question still remains: Can I divert from the standard when overloading operators?
In case of 1993 it can be expanded on: Can i use other types than BIT and BOOLEAN?

I think we have a different view of the standard, that might be because you know much more about the details. Still, i don't see where the standard states that i can't overload operators like i did in those two functions.
The paragraph separator is only a weak indicator for me. It should be mentionend in the section, which states how to overload operators. E.g. a paragraph that states how an implementation has to treat overloaded operators, if they don't adhere to the standard.

Another example of operator overloading that i use is the extension of 1993 VHDL with the operator:
"and" (std_logic_vector; std_logic) return std_logic_vector;

This was introduced in some later standard and, if i understand you correctly, is forbidden in the 1993 version.

I argue that this overloaded function is perfectly fine, but if i'm wrong i'm glad that the tools i use are not so stiff on their implementation of the standard.

Regards,
Ralf

 

On Monday, May 9, 2016 at 11:21:44 PM UTC+12, Ralf wrote:

> The question still remains: Can I divert from the standard when overloading operators?

Now there's the sixty four dollar question. Before I let you off the hook:

> In case of 1993 it can be expanded on: Can i use other types than BIT and BOOLEAN?

The semantic restriction only requires both operands be the same type. How is that restrictive to predefined types?

I think we have a different view of the standard, that might be because you know much more about the details. Still, i don't see where the standard states that i can't overload operators like i did in those two functions.

I think we have different views of what a standard is. Illegal is a term defined in the standard.

The IEEE will tell you a standard is an agreement by interested parties (for Design Automation primarily vendors) on how something is defined or functions to insure interoperability and reliability.

And what that tells us is that the purpose to which VHDL is used has changed (I'll explain this further down).

> The paragraph separator is only a weak indicator for me. It should be mentionend in the section, which states how to overload operators. E.g. a paragraph that states how an implementation has to treat overloaded operators, if they don't adhere to the standard.

Here's the shocker. If you look in the -2008 standard 16.3 package standard you'll find predefined operators for BOOLEAN (and BOOLEAN_VECTOR) as well as BIT (and BIT_VECTOR) violating the semantic rule in 9.2.2 paragraph 2.

You'll also find 9.2.2 doesn't describe these mixed argument binary logic operators - at all. There's also no public document trail (and I have a good portion of all the LCSs).

These and the changes you mentioned one of in the -2008 version of package std_logic_1164 have no visible documentation trail and are contrary to to 9..2.2.

Add to that that the VHDL standard revision passed a vote, was required to answer all questions (objections) and is inconsistent.

Another example of operator overloading that i use is the extension of 1993 VHDL with the operator:
"and" (std_logic_vector; std_logic) return std_logic_vector;

This was introduced in some later standard and, if i understand you correctly, is forbidden in the 1993 version.

The -2008 revision of the standard, package std_logic_1164 among others were made part of the VHDL standard.

I argue that this overloaded function is perfectly fine, but if i'm wrong i'm glad that the tools i use are not so stiff on their implementation of the standard.

It's not consistent with 9.2.2. I'll state categorically that there has never been a VHDL implementation started and solely consistent with the -2008 standard and that no VHDL implementation is fully compliant with that version.

Now for the difference in purpose for VHDL which was originally sponsored by the DoD as a formal notation for use in formal design descriptions for formal proofs.

That's not the case today. A syntactically and semantically valid functionally verified and implementation proven is not accepted as a formal proof of correctness. (And no other HDL has been either). The same methodology used to make the C programming language acceptable to the NSA for code controlling type I crypto implementations is used for all HDLs. A language subset is defined that is considered formally provable. VHDL has most of that (historically) built in to the language definition. Things like pure versus impure for functions.

You'll find that extends to synthesis with things like restrictions on constructs (no while loops, which depend on abstracts).

And what's happened in the intervening years (-2000, -2002, -2008 revisions) is sort of like the Europe English joke (http://www.ahajokes.com/eng011.html). There's been a slow and steady transformation of VHDL into an HDL like the others, currently there are attempts to add features found in SystemVerilog (and having been tried before and failed in the marketplace, see the failed P1551 (Standard for VHDL Electronic Digital System and Interface Design) effort based on VHDL+).

And what we have today is an inconsistency in the standard where this semantic rule is contradicted by poorly documented changes.

So the question is if the standard is meant primarily for language implementers and is inconsistent does it serve it's purpose?

Imagine someone were to implement a VHDL tool solely from the standard and actually used the semantic rule in 9.2.2. They'd have (theoretically) a standard compliant tool that isn't interoperable with another VHDL tool (I haven't seen any proof anyone actually conforms to the rule (With it's shall, like must in -1993).

And for this particular point all implementation vary from the standard.

Which is good, there's no more Sense of the VASG, or Interpretations - the DASC has no method to make variances from the standard, that's what revisions are for. The bad news is no one has really noticed, and there have been no new VHDL tool starts no derived from earlier standard revision compliant tools.

There is good news. Some of the more useful features found in the -2008 revision are actually being adopted, albeit not so much supported by synthesis vendors. VHDL may still be one of the most concisely defined 'languages' ever and has roots earlier than it's 1983 DoD start.

And if you have strong feelings on the standard they could always use a hand with the P1076 VASG effort, it's open to individual contributors.

Cheers.