In vhdl I can define my own enumeration type and create a signal of this type:
type tp is (red,green,blue,yellow);
signal sg: tp := red;
But now I want a for loop to run over all of these states. Something like
for i in sg'min to sg'max loop
<something>
end loop;
In c++ there are iterators for this purpose. But in VHDL all I can find is sg'pos that converts the signal to a number that I can increment. But I cannot seem to find a way to convert the number back to a signal.
This is what you need:
for i in tp'left to tp'right loop
<something>
end loop;
`left and `right are called type attributes. They are useful in your testbench, but not recommended for your design. This is because you the synthesiser may change the order of the enumerations, which might cause you problems.
You can specify the type of the loop parameter where the discrete range is a range of values of a specified scalar type:
entity enum is
end entity;
architecture enum_range of enum is
type tp is (red,green,blue,yellow);
signal sg: tp := red;
begin
process (sg)
begin
for i in tp range red to yellow loop
if sg = i then
report "sg = " & tp'image(sg);
end if;
end loop;
end process;
end architecture;
This produces:
enum.vhdl:12:17:#0ms:(report note): sg = red
TL;DR explanation
IEEE Std 1076-2008 10.10 Loop statement
iteration_scheme ::=
while condition
| for loop_parameter_specification
parameter_specification ::=
identifier in discrete_range
and
For a loop statement with a for iteration scheme, the loop parameter specification is the declaration of the loop parameter with the given identifier. The loop parameter is an object whose type is the base type of the discrete range. Within the sequence of statements, the loop parameter is a constant. Hence, a loop parameter is not allowed as the target of an assignment statement. Similarly, the loop parameter shall not be given as an actual corresponding to a formal of mode out or inout in an association list.
For the execution of a loop with a for iteration scheme, the discrete range is first evaluated. If the discrete range is a null range, the iteration scheme is said to be complete and the execution of the loop statement is therefore complete; otherwise, the sequence of statements is executed once for each value of the discrete range (subject to the loop not being left as a consequence of the execution of a next statement, an exit statement, or a return statement), after which the iteration scheme is said to be complete. Prior to each such iteration, the corresponding value of the discrete range is assigned to the loop parameter. These values are assigned in left-to-right order.
5.3.2 Array types, 5.3.2.1 General
discrete_range ::= discrete_subtype_indication | range
5.3.2.2 Subtype indications
subtype_indication ::=
[ resolution_indication ] type_mark [ constraint ]
constraint ::=
range_constraint
| array_constraint
| record_constraint
5.2 Scalar types 5.2.1 General
range_constraint ::= range range
range ::= range_attribute_name
| simple_expression direction simple_expression
direction ::= to | downto
It helps to understand how defining a range as the discrete range works. Without specifying a subtype indication in the discrete range the type is derived from the simple expressions in the range. The type of a numeric literal (9.3.2 Literals) is universal_integer convertible to type integer. The type can also be supplied by attribute as Matthew Taylor shows. Only dipping a toe in simple_expression (9.1) term -> factor -> primary, a primary can be a name (attribute name, 8.6) or a literal.
BNF other than found in Annex C (informative) Syntax summary, is normative.
Related
For this VHDL design description:
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
entity four_bit_counter is
port (
count_out : out unsigned (3 downto 0);
clk : in std_logic;
enable:in std_logic;
reset: in std_logic) ;
end four_bit_counter;
architecture arc of four_bit_counter is
signal count : unsigned (3 downto 0);
begin
process (clk, reset, enable)
begin
if (reset = '1') then
count <= "0000";
elsif (clk' event and clk = '1') then
if (enable = '1') then
if (count="1010") then
count<="0000";
else
count <= count +1;
end if;
end ;
end if;
end process;
count_out <= count;
end arc;
I have the error
Error (10327): VHDL error at four_bit_counter.vhd(22): can't determine definition of operator ""="" -- found 2 possible definitions
and I don't know how to fix this.
The two possible definitions are both from package std_logic_arith
function "="(L: UNSIGNED; R: UNSIGNED) return BOOLEAN;
function "="(L: SIGNED; R: UNSIGNED) return BOOLEAN;
The ambiguity comes from overload resolution for the equality operator due to the package providing the second definition and how the type of the right operand a string literal is determined.
See IEEE Std 1076-2008 9.3.2 Literals:
String and bit string literals are representations of one-dimensional arrays of characters. The type of a string or bit string literal shall be determinable solely from the context in which the literal appears, excluding the literal itself but using the fact that the type of the literal shall be a one-dimensional array of a character type. The lexical structure of string and bit string literals is defined in Clause 15.
Here the context is the equality operator, where 12.5 The context of overload resolution specifies the error:
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 5.1).
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. ...
Overloads for operators are provided by function declarations (
4.5.2 Operator overloading). For a binary operator the left operand is association with the first function parameter and the right parameter is associated with the second parameter. The return value is a Boolean (again from context, it's an if statement's condition which is a Boolean expression).
The type of the right operand can't be determined from context.
There are several possible solutions
Use the IEEE's numeric_std package instead where functions implementing operators don't have both signed and unsigned operands. Package numeric_std is incorporated into the standard's -2008 revision leading to package std_logic_arith's eventual deprecation.
Use a qualified expression (9.3.5) to specifically state the type of the operand.
if count = unsigned'("1010") then
(the redundant parentheses around the condition have been removed for clarity)
Rely on an abstract literal (15.5) where the ambiguity doesn't exist. This can either be of the form of a decimal literal (15.5.2) or based literal (15.5.3).
Use a function call to the overloaded operator's declaration with a selected name noting that named association can't be used for operator overloads.
Define an object (here a constant) with that value provided by a value expression. The type is inherent in an object declaration.
I have a record type(REC) which contains an element of type VECTOR which is an unconstrained 2d array of STD_LOGIC:
package TEST is
type VECTOR is array (NATURAL range <>, NATURAL range <>) of STD_LOGIC;
type REC is record
data : VECTOR;
end record REC;
function con(
a : REC;
b : REC)
return REC;
end package TEST;
When declaring the body of the con function I want to specify the size of the REC.data array like so:
package body TEST is
function con(
a : REC;
b : REC)
return REC is variable r : REC(
data(a.data'length(1) + b.data'length(1) - 1 downto 0, a.data'length(2) - 1 downto 0));
begin
-- . . . do things
end function con;
end package body TEST;
but in the line where I attempt to set the size of data it Vivado throws the following error:
Sliced name is allowed only on single-dimensional arrays
Does this mean I cannot have an unconstrained 2d arraign in a record or is there a different method for defining the size of it in the con function ?
---- EDIT ----
Since I now understand that it is not possible to use 2d arrays in this context what method should I use to create a function which:
Takes two 2d arrays (or arrays of arrays) of size [x][y] and [z][y] as inputs
Outputs an array of size [x+z][y]
With both input arrays being unconstrained and the output array being constrained to size [x+z][y]
And all arrays (input and return) be a record type
user1155120 I don't think I fully understand what you are trying to say. Are you saying my code is not
a minimal reproducible example, because except for me forgetting to include the STD_LOGIC library
the code reproduces the problem when I paste it into Vivado, and it is about as minimal as I can get it.
Or are you saying that the code you linked as this works works for you, because at least in my
Vivado it still throws the same error ? – Mercury 4 hours ago
The original comment was meant for Tricky. There's a missing return statement in the function con which would prevent use in an example.
It isn't clear if record constraints (a -2008 feature) are supported in Vivado Simulator. In Vivado Synthesis Guide UG901 2020.1 we see all sorts of wonderful uses of record types from everything to inferring ram to record elements of record types. Xilinx has been busy.
It'd seems odd if unconstrained elements in record type declarations were supported but not record constraints (they're pretty much a package deal, pun aside). Note the comment called it a -2008 feature.
A record constraint is limited to supply the constraint of an element or subelement that is of an unconstrained type (typically arrays). VHDL has always been capable of supplying multi-dimensional array constraints. The language of the standard is particular based on the flexibility of the syntax.
This code is VHDL -2008 compliant and provides your record constraint:
library ieee; -- ADDED for MCVe
use ieee.std_logic_1164.all; -- ADDED
package TEST is
type VECTOR is array (NATURAL range <>, NATURAL range <>) of STD_LOGIC;
type REC is record
data: VECTOR;
end record REC;
function con (a: REC; b: REC) return REC;
end package TEST;
package body TEST is
function con (a: REC; b: REC) return REC is
variable r:
REC ( -- record constraint:
data (
natural range a.data'length(1) + b.data'length(1) - 1 downto 0,
natural range a.data'length(2) - 1 downto 0
)
);
begin
-- . . . do things
return r; -- ADDED required return statement
end function con;
end package body TEST;
You'll note the changes to the record constraint from yours is the addition of natural range before each range of the element data constraint.
From IEEE Std 1076-2008 5.3.3 Record types:
record_constraint ::=
( record_element_constraint { , record_element_constraint } )
record_element_constraint ::= record_element_simple_name element_constraint
From 6.3 Subtype declarations:
element_constraint ::=
array_constraint
| record_constraint
Here the element data is an array so an array_constraint is appropriate.
From 5.3.2 Array types, 5.3.2.1:
array_constraint ::=
index_constraint [ array_element_constraint ]
| ( open ) [ array_element_constraint ]
Because element data array elements are scalar (enumeration type STD_LOGIC) we follow index_constraint.
index_constraint ::= ( discrete_range { , discrete_range } )
discrete_range ::= discrete_subtype_indication | range
The code shown above uses a discrete subtype indication for the index ranges of the element data dimensions and successfully analyzes (compiles).
From 5.2.2 Scalar types, 5.2.2.1:
range ::=
range_attribute_name
| simple_expression direction simple_expression
direction ::= to | downto
The constraint in the question uses a range with simple expressions and direction.
So why did it produce the error message about multi-dimensional slices?
In 9. Expressions, 9.1 the BNF, simple_expression -> term -> factor -> primary -> name.
In 8. Names, 8.1 name -> slice_name, only multi-dimensional slices are not allowed semantically in 8.5 Slice names who's BNF tells us it's syntactically valid:
slice_name ::= prefix ( discrete_range )
The prefix of a slice shall be appropriate for a one-dimensional array object. The base type of this array type is the type of the slice.
and semantically the prefix data is not appropriate for a one-dimensional array object.
These comments provide bit more context for the problem although it isn't clear which version the record constraint you used in the reported eventual success:
#Mercury when you add a (VHDL) file to Vivado, it's by default set to use VHDL 93, but not 2008. Go
to the property Window and change the file type from VHDL to VHDL 2008. I'm not sure why it
prints the wrong error message in your case. (Vivado likes to confuse users with wrong error messages
...). Anyhow, it should have reported your feature is only supported in 2008 mode. – Paebbels 3 hours
ago
#Paebbels Thank you, that fixed the problem, maybe add it as a sub note to your response so I can
mark it as accepted answer. You just saved me hours of frustration. And I'm already getting familiar with
Vivado's shenanigans, my Favorit one of which is "ERROR close to ..." which has to be one of the most
useless error messages I have experience in a long time :) – Mercury 3 hours ago
As far as detecting -2008 source, there are no -1993 syntax errors and no -2008 new reserved word, delimiters, separators or graphics characters in either the primary unit or the secondary.
That leaves you at the mercy of semantic analysis which failed. You could also note the unconstrained record element wasn't reported during analysis of the package declaration. It occurred during evaluation of the variable r. All declared objects are required to be constrained. VHDL doesn't have a recital of all features, semantics can be restrictive as well. It's legal in places to have unconstrained elements and objects.
Associating semantics rules found in the text of the standard with an textual element of the particular declaration or statement can be tough and the squeaky wheel gets the lubricant. Record constraints are relatively new to VHDL implementations.
The problem appears to have been one of tool familiarity.
This is the definition of row and column merges from PoC's vectors package, see lines starting at 359:
function slm_merge_rows(slm1 : T_SLM; slm2 : T_SLM) return T_SLM is
constant ROWS : positive := slm1'length(1) + slm2'length(1);
constant COLUMNS : positive := slm1'length(2);
variable slm : T_SLM(ROWS - 1 downto 0, COLUMNS - 1 downto 0);
begin
for i in slm1'range(1) loop
for j in slm1'low(2) to slm1'high(2) loop -- WORKAROUND: Xilinx iSIM work-around, because 'range(2) evaluates to 'range(1); see work-around notes at T_SLM type declaration
slm(i, j) := slm1(i, j);
end loop;
end loop;
for i in slm2'range(1) loop
for j in slm2'low(2) to slm2'high(2) loop -- WORKAROUND: Xilinx iSIM work-around, because 'range(2) evaluates to 'range(1); see work-around notes at T_SLM type declaration
slm(slm1'length(1) + i, j) := slm2(i, j);
end loop;
end loop;
return slm;
end function;
function slm_merge_cols(slm1 : T_SLM; slm2 : T_SLM) return T_SLM is
constant ROWS : positive := slm1'length(1);
constant COLUMNS : positive := slm1'length(2) + slm2'length(2);
variable slm : T_SLM(ROWS - 1 downto 0, COLUMNS - 1 downto 0);
begin
for i in slm1'range(1) loop
for j in slm1'low(2) to slm1'high(2) loop -- WORKAROUND: Xilinx iSIM work-around, because 'range(2) evaluates to 'range(1); see work-around notes at T_SLM type declaration
slm(i, j) := slm1(i, j);
end loop;
for j in slm2'low(2) to slm2'high(2) loop -- WORKAROUND: Xilinx iSIM work-around, because 'range(2) evaluates to 'range(1); see work-around notes at T_SLM type declaration
slm(i, slm1'length(2) + j) := slm2(i, j);
end loop;
end loop;
return slm;
end function;
The definition of T_SLM is:
type T_SLM is array(natural range <>, natural range <>) of std_logic;
Currently, I see no problem in nesting this code in another layer like your unconstrained record.
Edit:
Thie code above requires VHDL 2008 to be enabled in Vivado.
When VHDL files are added to Vivado, it's by default set to use VHDL 93, but not 2008. Go to the property Window and change the file type from VHDL to VHDL 2008``.
The printed error message is misleading and points to a false feature being used. The correct message should be it's a VHDL-2008 feature, please enable it.
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.
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.
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.