Related
I have this definition:
subtype sample_t is signed(SAMPLE_WIDTH-1 downto 0);
Now in the code I want to set a signal to the maximum value of sample_t divided by 2:
signal max_sample : sample_t;
max_sample <= to_signed(max_sample'<some attribute>/2,max_sample'LENGTH);
I've looked at attributes sample_t'HIGH and sample_t'RIGHT but these seem to return the highest subscript of the array.
From this list: https://www.csee.umbc.edu/portal/help/VHDL/attribute.html
T'HIGH is the highest value of type T.
A'HIGH is the highest subscript of array A or constrained array type.
How to use the first definition on sample_t?
One of the commenters suggestions:
max_sample <= (max_sample'LEFT => '0', others => '1');
works. But this:
max_sample <= (max_sample'LEFT => '0', others => '1')/2;
fails with "OTHERS is illegal aggregate choice for unconstrained target".
why this error?
In VHDL, signed is an array type, not an integer. The core language only knows that it is a collection of std_logic objects. It's interpretation as a number is only by convention introduced by the numeric_std library functions defining the operators and type casts for signed. As such, integer specific attributes aren't going to work on an array type.
The reason why your last attempt at division fails is that the aggregate expression forming the dividend doesn't yet have a fully determined range due to the others. The aggregate is still just an intermediate temporary and can't pick up its length from max_sample. That prevents the division operator from compiling.
It will compile if you use a fully constrained range:
max_sample <= (max_sample'high => '0', max_sample'high-1 downto max_sample'low => '1') / 2;
Or if you use a qualified expression:
max_sample <= sample_t'(max_sample'high => '0', others => '1') / 2;
An alternate solution is just to subtype integer instead of using signed. Then you can use it in a more integery way:
constant SAMPLE_T_MAX : integer := 2**(SAMPLE_WIDTH-1)-1;
subtype sample_t is integer range -SAMPLE_T_MAX-1 to SAMPLE_T_MAX;
max_sample <= sample_t'high; -- Assuming that the "divide by 2" was just to avoid the sign bit
This will not work if sample_t_max exceeds the largest integer size your tooling supports which is still typically 32-bits including the sign. Also, for practical reasons, it is best not to use integer types for signals that will be exposed on the top level port after synthesis.
Otherwise you have to work within the limitations of using array types for numerics. Your options are to resort to bit twiddling as above or just directly compute the max value similarly to the integer subtype:
constant SAMPLE_T_MAX : integer := 2**(sample_t'length-1)-1;
max_sample <= to_signed(SAMPLE_T_MAX, max_sample'length);
The accepted answer from Kevin Thibedeau could not be readily reconciled with the actual question (why this error?). The answer can be explained in terms of the VHDL standard.
First a Minimum, Complete, and Verifiable example can be constructed for the question:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity foo is
end entity;
architecture fum of foo is
constant SAMPLE_WIDTH: natural := 42; -- pick a number
subtype sample_t is signed(SAMPLE_WIDTH-1 downto 0);
signal max_sample : sample_t;
begin
-- max_sample <= (max_sample'LEFT => '0', others => '1'); -- analyzes
max_sample <= (max_sample'LEFT => '0', others => '1')/2; -- Doesn't analyze
end architecture;
Because we're dealing with semantic rules during analysis (compile) the example doesn't have to do anything besides replicate the error. Error messages aren't standardized in VHDL and will vary by implementation.
The semantics for using an others choice in an aggregate:
IEEE Std 1076-2008 9.3 Aggregates, 9.3.3 Array aggregates, para 7 (in part):
The index range of an array aggregate that has an others choice shall be determinable from the context. That is, an array aggregate with an others choice shall appear only in one of the following contexts:
...
e) As a value expression in an assignment statement, where the target is a declared object (or member thereof), and either the subtype of the target is a fully constrained array subtype or the target is a slice name
This is why the first example (commented out) analyzes. sample_t is a fully constrained subtype, see 5. Types, 5.1 General the definition of fully constrained, para 6 (in part):
A composite subtype is said to be fully constrained if:
-- It is an array subtype with an index constraint and the element subtype either is not a composite subtype or is a fully constrained composite type, or
...
Where the sample_t element base type is std_ulogic and the subtype has an index constraint.
Back to the second example.
We don't satisfy rule e), the aggregate isn't a value expression for the assignment statement, it's an operand for the division operator defined by the "/" function for overload in IEEE package numeric_std:
-- Id: A.25
function "/" (L : UNRESOLVED_SIGNED; R : INTEGER) return UNRESOLVED_SIGNED;
-- Result subtype: UNRESOLVED_SIGNED(L'LENGTH-1 downto 0)
-- Result: Divides an UNRESOLVED_SIGNED vector, L, by an INTEGER, R.
-- If NO_OF_BITS(R) > L'LENGTH, result is truncated to L'LENGTH.
(For earlier revisions of numeric_std the parameter and result types would be SIGNED instead of UNRESOLVED_SIGNED, -2008 formally defines how resolution functions of composite types drivers are defined.)
Because the rules of 9.3.3 paragraph 7 are inclusive instead of exclusive we
need to find a rule that allows us to use the aggregate, and one is readily identified:
i) As the operand of a qualified expression whose type mark denotes a fully constrained array subtype
We can use a qualified expression:
max_sample <= sample_t'(max_sample'LEFT => '0', others => '1')/2;
And this analyzes (compiles) successfully.
To clarify the value expression being assigned to max_sample is the result of division by 2 which uses an operator overload and who's function does not return a constrained subtype. (UNRESOLVED_SIGNED or SIGNED is not constrained).
The reason why there are inclusive rules is to allow the code for associating values with elements of an aggregate to be determined at analysis time (compile time). You'd find by examining previous revisions of the VHDL standard that the list of inclusive rules has been expanded.
The answer to your question with respect to the second example:
max_sample <= (max_sample'LEFT => '0', others => '1')/2;
is that the elements of the aggregate can't be identified without knowing the subtype from context.
If you were to look at the output of the parser producing an abstract syntax tree used for semantic analysis the right hand side expression in the assignment statement can be expressed hierarchically. (11.6 Concurrent signal assignment statements, the waveform is comprised of one or more waveform elements, see 10.5.2 Simple signal assignments, 10.5.2.1 General, a waveform element can contain a value expression, see 10.5.2.2 Executing a simple assignment statement, 9. Expressions, 9.1 General the BNF.)
Using inclusive rules alleviates the need of traversing the expression hierarchy and calculating the subtype of the aggregate (an operand) during analysis and would require semantic characterization of the "/" function not required by the standard. You can also construct cases where the subtype can't be readily ascertained by characterization at analysis time. The result is the rules found in 9.3.3 Array aggregates paragraph 7.
The qualified expression provides the subtype directly.
I want to know if it is possible to convert a enum type, like FSM states to std_logic_vector or integer. I'm doing a testbench with OSVVM for a FSM and I want to use the scoreboard package to automatically compare the expected state with the actual one.
Thanks!
To convert to integer, use:
IntVal := StateType'POS(State) ;
From there, it is easy to convert to std_logic_vector, but I prefer to work with integers when possible as they are smaller in storage than std_logic_vector. For verification, it will be easier if you start to think more about integers when the value is less than 32 bits.
If you need it as std_logic_vector, using only numeric_std you can:
Slv8Val := std_logic_vector(to_unsigned(IntVal, Slv8Val'length)) ;
For verification, I liberally use numeric_std_unsigned, so the conversion is a easier:
Slv8Val := to_slv(IntVal, Slv8Val'length) ;
In the event you have an integer and want to convert it back to a enumerated value, you can use 'VAL.
State := StateType'VAL(IntVal) ;
In OSVVM, we use records with resolved values to create a transaction interface. We have a resoled types for integers (osvvm.ResolutionPkg.integer_max). We transfer enumerated values through the record using 'POS (as we put it in) and 'VAL (as we get it out).
Note don't confuse 'VAL with 'VALUE. 'VALUE converts a string to a value - opposite to 'IMAGE.
You of course learn all of this in SynthWorks' OSVVM class :).
Maybe like this...
function my_func(inp : t_my_enum) return integer is
begin
case inp is
when stateA =>
return 1;
when stateB =>
return 2;
when others =>
return 0;
end case;
end function my_func;
... <= my_func(stateB);`
The configuration below
reg [3:0] myreg;
always#(...) begin
...
if(myreg) begin <events> end ...
end
How reference to "myreg" in condition without referring specific bit and logical operation between bits in packed array will be handled?
Edit: Would you please provide where this behavior you explained is documented? As this semantic structure is allowed, I guess there should be some documentation about it... Thank you!
Edit 1: Thanks for all your answers so far. Let's refocus on the following two points:
Why you believe logical value of (myreg) is reduction OR (not AND for example) - is there standard guideline? Let's turn off common sense and our feeling of "right" and "wrong" - these are not the matters we can base our conclusions on in mathematics/cybernetics.
is it true that "it may behave differently with another simulator" - or in the real life?
This strikes me because (a) I can not find document which states that it MUST be a reduction OR, and (b) that Quartus (which I use) does not give any warning or error for the syntax above.
Yes, #Morgan is correct Xillinx ISE and Questasim is doing same, When I synthesis the following code.
module aa( input clk,
input rst_n,
input [4:0] my_reg,
output reg chk
);
always # (posedge clk or negedge rst_n)
begin
if (!rst_n) begin
chk <= 1'bz;
end else begin
if (my_reg) begin
chk <= 1'b1;
end
else begin
chk <= 1'b0;
end
end
end
endmodule
You can see here schematic view,
Verilog should behave like this:
myreg | result | comment
------|--------|--------
0000 | 1'b0 | FALSE - all bit bits are zero
0010 | 1'b1 | TRUE - at least one bit is one
001X | 1'b1 | TRUE - at least one bit is one
000X | 1'bX | FALSE - we don't know whether all bits are zero or not
and if interprets 1'bX as FALSE
From this EDA Playground example VCS 2014.2 is interpreting :
if (myreg) begin
...
as an OR bit reduction of myreg ie:
if ( |myreg == 1'b1) begin
...
As Greg found the relevant (SystemVerilog IEEE 1800-2012 Standard) section of the LRM is Section 12.4
it evaluates to false (that is, has a zero value or the value is x or z),
The code supplied if (myreg) is valid but given x's or z's will evaluate to false rather than propagating x's you may find a difference between RTL and gate level simulations if you use un-initialised registers, the initial x's will evaluate to false rather than potentially being 1 and evaluating to true.
if(myreg) is the same as if(myreg != 0) according to IEEE Std 1800-2012 § 12.4 Conditional if–else statement
The conditional statement (or if–else statement) is used to make a
decision about whether a statement is executed. Formally, the syntax
is given in Syntax 12-2.
conditional_statement ::= // from A.6.6
[ unique_priority ] if ( cond_predicate ) statement_or_null
{ else if ( cond_predicate ) statement_or_null }
[ else statement_or_null ]
unique_priority ::= unique | unique0 | priority
cond_predicate ::= expression_or_cond_pattern { &&& expression_or_cond_pattern }
expression_or_cond_pattern ::= expression | cond_pattern
cond_pattern ::= expression matches pattern
Syntax 12-2—Syntax for if–else statement (excerpt from Annex A)
If the cond_predicate expression evaluates to true (that is, has a nonzero known value), the first statement shall be executed. If it evaluates to false (that is, has a zero value or the value is x or z), the first statement shall not execute. If there is an else statement and the cond_predicate expression is false, the else statement shall be executed. Because the numeric value of the if expression is tested for being zero, certain shortcuts are possible. For example, the following two statements
express the same logic:
if(expression)
if(expression != 0)
Note the LRM is checking if the expression is a nonzero value. It is not constraining the width or even considering if it is a signed type. Negative numbers would be be true, only zero is false.
Synthesizers may do bit-wise compression which is equivalent logic as comparing to zero.
In order to catch more bugs in simulation, it is an advantage to get a warning
if std_logic with 'X' is used in = compare.
When using the ieee.std_logic_1164 package, the std_logic compare function
= does not warn about 'X' in either of the operands. So the ´if´ branch in
the code below is taken when sl_i is '1', but the else branch is taken
when sl_i is either of '0', 'X', etc.:
if sl_i = '1' then
sl_o <= '1';
else -- sl_i in "UX0ZWLH-"
sl_o <= '0';
end if;
So for example an 'X' or 'U', due to use of some unknown or uninitialized
value, is silently ignored during simulation. However, if a warning was given,
it would improve the possibility of finding bugs in simulation, like when the
ieee.numeric_std package warns about metavalue ('X' etc.) in compare with
=.
? Is there any standard VHDL way to get warning for metavalues in std_logic
at compare with = ?
One possibility, is to make a package where the implicit = for std_logic is
redefined, and then use this package with .all so the = is replaced. Such
package with may look like:
library ieee;
use ieee.std_logic_1164.std_logic;
package std_logic_warning is
function "="(l, r : std_logic) return boolean;
end package;
library ieee;
use ieee.std_logic_1164.is_x;
use ieee.std_logic_1164; -- For access to "=" using std_logic_1164."="
package body std_logic_warning is
function "="(l, r : std_logic) return boolean is
begin
assert not (is_x(l) or is_x(r))
report "std_logic_warning.""="": metavalue detected"
severity WARNING;
return std_logic_1164."="(l, r);
end function;
end package body;
? Will such a redefine be VHDL standard compliant, and is it likely to work
with the tools in general ?
As Jim Lewis points out with reference to ISAC
IR2058 the idea of
overriding the implicit = may not work in general for tool when using
VHDL-2003. VHDL-2008 should fix this.
Note that above question and suggestion has been edited based on David Koontz
previous comments.
Depending on which language revision you are using, you may experience portability problems. I suggest you avoid them by using VHDL-2008, which removes a number of issues.
Prior to VHDL-2008, some tools did not allow explicit operators to overload implicit operators. Prior to VHDL-2008, tools interpreted the reference to "ieee.std_logic_1164.std_logic" differently. See ISAC IR2058 for a discussion: http://www.eda.org/isac/IRs-VHDL-2002/IR2058.txt. Even with the implementation of IR2058, my interpretation is that is_x will not be included in your reference to std_logic as only overloaded operators are included and not all functions - so if that works it is probably not portable between tools.
Hence, I would use VHDL-2008 and the following code. I replaced the reference to ieee.std_logic_1164."=" with one to ieee.numeric_std.std_match, as it is not clear to me if you can still reference an implicit operator once an explicit operator is visible to replace it - even if it is legal, I would expect this to be a fringe case that may break tools (make sure to report the bugs). Use of std_match also has the benefit of correctly handling an 'L' or 'H'.
library ieee;
use ieee.std_logic_1164.all;
package std_logic_warning is
function "="(l, r : std_logic) return boolean;
end package;
package body std_logic_warning is
function "="(l, r : std_logic) return boolean is
begin
assert not (is_x(l) or is_x(r))
report "std_logic_warning.""="": metavalue detected"
severity WARNING;
return ieee.numeric_std.std_match(l, r);
end function;
end package body;
If you don't like the behavior of std_match, you can use std_match as a template to create the functionality, however, I don't recommend this as synthesis tools may not like it.
While you could use the modified "=", as a counter suggestion, there are two sources of X, external from other designs and internal from uninitialized registers. I don't worry about uninitialized registers as I am rigorous about my resets. Hence, at the core level, I may (depending on my confidence of others or the testbench), use the assert statement directly on core inputs.
assert not is_x(core_input_1)
report "meta value detected on core_input_1" severity ERROR ;
There are a couple things wrong with this scenario.
There isn't an explicit std_logic_1164."=" defined. Equality and inequality operators are implicitly declared for all types.
IEEE Std 1076-1993 Section 3 Types, Para 2:
...The set of operations of a type includes the explicitly declared
subprograms that have a parameter or result of the type. The remaining
operations of a type are the basic operations and the predefined
operators (see 7.2). These operations are each implicitly declared for
a given type declaration immediately after the type declaration and
before the next explicit declaration, if any.
The extended name should be ieee.std_logic_1164."=".
A relational operator in an expression is given as an operator symbol, so no extended name with left and right arguments. A function call to the equality operator function you've declared can be an extended name.
As long as the "=" operator being declared in the package declaration isn't used elsewhere in the package body you could use a context clause before the package body:
library ieee;
use ieee.std_logic_1164."=";
and
return l = r;
Also the equality operator is rigidly defined.
IEEE Std 1076-1993, 7.2.2 Relational operators, Para 4:
... Two scalar values of the same type are equal if and only if the values are the same.
So, no equality returns FALSE just because they are meta values. It's illegal to redefine what 'equal' means.
And ya, I know of one tool that will let you analyze this or something close, but it'll fail when using the operator. Even if it worked it would not be portable (while still being illegal, immoral and likely bad for the waistline).
This code crashes in ghdl, it was an attempt to avoid using the -fexplicit flag artificially changing the precedence of overloaded operators, which isn't -2008 standard compliant:
library ieee;
use ieee.std_logic_1164.std_logic;
use ieee.std_logic_1164.to_x01;
use ieee.std_logic_1164.is_x;
package std_logic_warning is
function "="(l, r : std_logic) return boolean;
end package;
package body std_logic_warning is
use ieee.std_logic_1164."=";
function "="(l, r : std_logic) return boolean is
begin
if is_x(l) or is_x(r) then
report "std_logic_warning.""="": metavalue detected, returning FALSE"
severity WARNING;
return FALSE;
end if;
return l = r; -- std_logic_1164."="(l, r);
end function;
end package body;
library ieee;
use ieee.std_logic_1164.std_ulogic;
use ieee.std_logic_1164.std_logic;
-- use ieee.std_logic_1164.all;
use work.std_logic_warning.all;
entity warning_test is
end entity;
architecture foo of warning_test is
signal a: std_logic;
signal b: std_logic;
begin
UNLABELLED:
process
begin
wait for 1 ns;
a <= 'X';
wait for 1 ns;
b <= '1';
wait for 1 ns;
a <= '0';
wait for 1 ns;
b <= '0';
wait;
end process;
MONITOR:
process (a,b)
begin
assert a = b
report "a = b " & "( " & std_logic'image(a)
& "=" & std_logic'image(b) & " )"
severity NOTE;
end process;
end architecture;
ghdl -r warning_test
std_logic_warning.vhdl:17:7:#0ms:(report warning):
std_logic_warning."=": metavalue detected, returning FALSE
std_logic_warning.vhdl:57:9:#0ms:(assertion note): a = b ( 'U'='U' )
std_logic_warning.vhdl:17:7:#1ns:(report warning):
std_logic_warning."=": metavalue detected, returning FALSE
std_logic_warning.vhdl:57:9:#1ns:(assertion note): a = b ( 'X'='U' )
std_logic_warning.vhdl:17:7:#2ns:(report warning):
std_logic_warning."=": metavalue detected, returning FALSE
std_logic_warning.vhdl:57:9:#2ns:(assertion note): a = b ( 'X'='1' )
ghdl: exec error
I'd suspect the issue has something to do with stack allocation, determined by trying concurrent assertions instead of the monitor process (which output more before crashing).
What it does show before bombing out is that 'U'='U' is a valid equality comparison according to the LRM and your `"=" operator say it isn't.
You could note your equality operator "=" is declared in the package declaration while the use clause is in effect in the package body. There should be no IR2058 conflict noted by Jim in his answer. That use clause (in the package body) isn't visible to where your overload function is visible.
To use your declaration in the test bench the order of use clauses was carefully crafted:
library ieee;
use ieee.std_logic_1164.std_ulogic;
use ieee.std_logic_1164.std_logic;
-- use ieee.std_logic_1164.all;
use work.std_logic_warning.all;
This also side steps the use of the Modelsim or ghdl overload rule evasion (-fexplicit as a command line argument in ghdl).
Unfortunately this demonstrates how complex VHDL is more than anything else
An acquaintance pointed out there was recursion in the function call so I proved that was the case by changing the function name (and changing the assertion condition expression).
ghdl -a test.vhdl
ghdl -e warning_test
ghdl -r warning_test
test.vhdl:16:7:#0ms:(report warning): std_logic_warning."=": metavalue detected, returning FALSE
test.vhdl:56:9:#0ms:(assertion note): a = b ( 'U'='U' )
test.vhdl:16:7:#1ns:(report warning): std_logic_warning."=": metavalue detected, returning FALSE
test.vhdl:56:9:#1ns:(assertion note): a = b ( 'X'='U' )
test.vhdl:16:7:#2ns:(report warning): std_logic_warning."=": metavalue detected, returning FALSE
test.vhdl:56:9:#2ns:(assertion note): a = b ( 'X'='1' )
test.vhdl:56:9:#3ns:(assertion note): a = b ( '0'='1' )
The recursion revolves around the function return expression "=".
commenting out the use clause in the package body yields:
-- use ieee.std_logic_1164."=";
ghdl -a test.vhdl
test.vhdl:20:14: no function declarations for operator "="
ghdl: compilation error
Which says the use clause is necessary, and that's expected:
IEEE Std 1076-1993 Section 3 Types, Para 2:
...The set of operations of a type includes the explicitly declared
subprograms that have a parameter or result of the type. The remaining
operations of a type are the basic operations and the predefined
operators (see 7.2). These operations are each implicitly declared for
a given type declaration immediately after the type declaration and
before the next explicit declaration, if any.
So is the issue overload resolution? (No it's visibility).
10.5 The context of overload resolution:
Overloading is defined for names, subprograms, and enumeration
literals.
For overloaded entities, overload resolution determines the actual
meaning that an occurrence of an identifier or a character literal has
whenever the visibility rules have determined that more than one
meaning is acceptable at the place of this occurrence; overload
resolution likewise determines the actual meaning of an occurrence of
an operator or basic operation (see the introduction to Section 3).
We've first got to determine if both declarations of the function "=" are visible.
10.4 Use clauses, para 3:
Each selected name in a use clause identifies one or more declarations
that will potentially become directly visible. If the suffix of the
selected name is a simple name, character literal, or operator symbol,
then the selected name identifies only the declaration(s) of that
simple name, character literal, or operator symbol contained within
the package or library denoted by the prefix of the selected name.
10.4 Use clauses, para 4:
For each use clause, there is a certain region of text called the
scope of the use clause. This region starts immediately after the use
clause. If a use clause is a declarative item of some declarative
region, the scope of the clause extends to the end of the declarative
region. If a use clause occurs within the context clause of a design
unit, the scope of the use clause extends to the end of the
declarative region associated with the design unit. The scope of a use
clause may additionally extend into a configuration declaration(see
10.2 ).
And about here we note that this use clause is within the package body, and it's effect doesn't extend anywhere else. We also know that the declared function (originally also "=" is directly visible (i.e. not by selection) from the package declaration.
10.4 Use clauses, para 5:
In order to determine which declarations are made directly visible at
a given place by use clauses, consider the set of declarations
identified by all use clauses whose scopes enclose this place. Any
declaration in this set is a potentially visible declaration. A
potentially visible declaration is actually made directly visible
except in the following two cases:
a. A potentially visible declaration is not made directly visible if
the place considered is within the immediate scope of a homograph of
the declaration.
b. Potentially visible declarations that have the same designator are
not made directly visible unless each of them is either an enumeration
literal specification or the declaration of a subprogram (either by a
subprogram declaration or by an implicit declaration).
And There is a homograph, the function declaration in the package declaration.
From Appendix B Glossary:
B.117 homograph: A reflexive property of two declarations. Each of two declarations is said to be a homograph of the other if both declarations have the same identifier and overloading is allowed for at most one of the two. If overloading is allowed for both declarations, then each of the two is a homograph of the other if they have the same identifier, operator symbol, or character literal, as well as the same parameter and result type profile.(§ 1.3.1 , § 10.3 )
B.119 immediate scope: A property of a declaration with respect to the declarative region within which the declaration immediately occurs. The immediate scope of the declaration extends from the beginning of the declaration to the end of the declarative region. (§ 10.2 )
So the issue revolves around immediate scope in 10.4, a. And b tells us that if both are subprogram declarations they are both visible inside the subprogram body.
And we get down to the NOTES:
1--These rules guarantee that a declaration that is made directly
visible by a use clause cannot hide an otherwise directly visible
declaration.
The use clause declaration that would become potentially visible is with in the immediate scope of the subprogram declaration found in the package declaration.
And if it weren't:
10.5 The context of overload resolution, para 3:
At such a place, all visible declarations are considered. The
occurrence is only legal if there is exactly one interpretation of
each constituent of the innermost complete context; a complete context
is either a declaration, a specification, or a statement.
Not being legal is synonymous with error. We'd have gotten an error.
So the moral here is that VHDL can be complex especially when you're trying to game it. And what I was trying to do resulted in legal code that didn't do what was intended, and didn't generate and error until out of stack space at run time, a catch-22.
The displayed code can be made to function with the following change:
Remove the use clause in the package body:
-- use ieee.std_logic_1164."=";
Restore EquipDev's return statement:
return l = r; -- std_logic_1164."="(l, r);
becomes
return std_logic_1164."="(l, r);
again. (Undoing my error).
This gives:
ghdl -a std_logic_warning.vhdl
ghdl -e warning_test
ghdl -r warning_test
std_logic_warning.vhdl:17:7:#0ms:(report warning): std_logic_warning."=": metavalue detected, returning FALSE
std_logic_warning.vhdl:58:9:#0ms:(assertion note): a = b ( 'U'='U' )
std_logic_warning.vhdl:17:7:#1ns:(report warning): std_logic_warning."=": metavalue detected, returning FALSE
std_logic_warning.vhdl:58:9:#1ns:(assertion note): a = b ( 'X'='U' )
std_logic_warning.vhdl:17:7:#2ns:(report warning): std_logic_warning."=": metavalue detected, returning FALSE
std_logic_warning.vhdl:58:9:#2ns:(assertion note): a = b ( 'X'='1' )
std_logic_warning.vhdl:58:9:#3ns:(assertion note): a = b ( '0'='1' )
Which appears to be the correct result, because when b is assigned to '0' at 4 ns the assertion test won't trigger for either the function or monitor process.
Recap
Is it possible to replace the relational operator "=" for std_logic?
Yes, But it may not be practical. Notice that there are use clauses for all the package std_logic_1164 names used except "=". In -2008 you can declare contexts where you could construct such a context clause once and invoke it. Or otherwise you could fill the package declaration with use clauses.
And the entire point of this exercise was to show that the adopted definition of "=" wasn't valid for meta values and is not standard compliant. (The 7.2.2 para 4 quote above).
And as Jim points out assertion test monitors can take the place of any usefulness redefining "=" may have.
I recall that in Verilog it can be valid to use a constant in the expression of a case statement, but is it also valid in VHDL?
// Verilog example
case(1'b1)
A[2]: Y<=2'b11;
A[1]: Y<=2'b10;
A[0]: Y<=2'b01;
default:Y<=2'b00;
endcase
The following code is not exactly parallel to your example, but it may be useful:
This compiles:
process
constant S : std_logic := '1';
begin
case S is
when '0' =>
when '1' =>
when others =>
end case;
end process;
So does this:
process
begin
case std_logic'('1') is
when '0' =>
when '1' =>
when others =>
end case;
end process;
This does not:
process
begin
case '1' is
when '0' =>
when '1' =>
when others =>
end case;
end process;
'1' is ambiguous (std_logic / character).
Now, what you're actually doing is a bit different, and I'm not sure what your intent is. You seem to want to determine the highest bit that is set. In VHDL, your construct would only be valid syntactically if A is also constant (case choices need to be locally static), in which case there are much easier ways to accomplish this (e.g. a for loop). There's the problem of mutual exclusion, though - in general, case choices are bound to overlap, and I would think that should be illegal (though ModelSim didn't complain when I tried it - synthesis tools may be another story). I would say it's definitely not a great idea either way.
No you can't express the case statement as a VHDL case statement
Unlike Verilog, IEEE Std 1364-2005 9.5 Case statement para 4:
The case expression and the case item expression can be computed at
run time; neither expression is required to be a constant expression.
In IEEE Std 1076-1993 8.8 Case statement, para 8 (also representative of -2008):
The simple expression and discrete ranges given as choices in a case
statement must be locally static. A choice defined by a discrete range
stands for all values in the corresponding range. The choice others is
only allowed for the last alternative and as its only choice; it
stands for all values(possibly none) not given in the choices of
previous alternatives. An element simple name (see 7.3.2 ) is not
allowed as a choice of a case statement alternative.
From the glossary:
locally static expression: An expression that can be evaluated during the analysis of the design unit in which it appears.
analysis: The syntactic and semantic analysis of source code in a VHDL design file and the insertion of intermediate form representations of design units into a design library.
(A fancy way of telling us compile time as opposed to elaboration (linking and loading). VHDL's definitions also embrace interpretive implementation.)
The definition of a locally static expression requires A to be declared as a constant and in the VHDL LRM -1993 version a slice name or index name isn't locally static (See IEEE Std 1076-1993, 7.4.1 Locally static primaries para 1, 7.4.2 Globally static primaries, r. - globally static means at elaboration time). This is changed in the IEEE Std 1076-2008 for static index expressions or static index ranges (See IEEE Std 1076-2008, 9.4.2, n. and o.). It's likely synthesis vendors tools lag, even if you can simulate it, you likely can't synthesis it today.
There's also the issue of multiple choices with the same value. See IEEE Std 1076-1993 8.8 Case statement, para 3 (also representative of -2008 for this issue):
The expression must be of a discrete type, or of a one-dimensional
array type whose element base type is a character type. This type must
be determinable independently of the context in which the expression
occurs, but using the fact that the expression must be of a discrete
type or a one-dimensional character array type. Each choice in a case
statement alternative must be of the same type as the expression; the
list of choices specifies for which values of the expression the
alternative is chosen.
Where the expressions std_logic'('1') or S have a base type of std_ulogic. And this eliminates choices that are not of the base type of std_logic (std_ulogic - 'U', 'X', '0', '1', 'Z', 'W', 'L', 'H', '-', See IEEE Std 1076-2008 16.7 Standard multivalue logic package and Annex A footnote 15 which provides a link to the source for package std_logic_1164).
Notice fru1tbat showed choices '0', '1' and others, evaluation of the expressions A(2), A(1) or A(0) returns a std_ulogic subtype and would give you multiple choices representing the same value ('1'). See IEEE Std 1076-1993, 8.8 para 7:
For other forms of expression, each value of the (base) type of the
expression must be represented once and only once in the set of
choices, and no other value is allowed.
So the case statement isn't directly expressible in VHDL, we're only interested in cases where A(2), A(1) and A(0) are '1' and only one choice is allowed. Instead we can use a conditional signal assignment statement:
library ieee;
use ieee.std_logic_1164.all;
entity constexp is
end entity;
architecture foo of constexp is
signal A: std_logic_vector (2 downto 0) := "001";
signal Y: std_logic_vector (1 downto 0);
begin
COND: -- Conditional Signal Assignment statement
Y <= "11" when A(2) = '1' else
"10" when A(1) = '1' else
"01" when A(0) = '1' else
"00";
end architecture;
(And this design specification analyzes, elaborates and simulates.)
A conditional signal assignment is a concurrent statement in the 1076-1993 standard (See 9.5.1 Conditional signal assignments) while a conditional signal assignment can be used as a sequential statement as well in the 1076-2008 standard (See 11.6 Concurrent signal assignment statements and 10.5.3 Conditional signal assignment). Today it's likely synthesis vendors would be -1993 compliant.
And by definition any of the constructs here can be devolved into if statements which are sequential statements.