Generic in CASE choice ?!?

[Thorsten Bunte]

Hello,

is it allowed to use a generic within a choice line of a CASE statement?

case "signal"
when "constant" =>
....
when "constant" to "constant" + "generic_value" =>
....
when others =>
....
end case;

ModelSIM (PE 6.0b) gives me the warning:

** Warning: ../SRC/RTL/arch_ADRDEC.vhd(1977): Case choice must be a locally
static expression.

Best regards,

Thorsten

 

[Taras_96]

Hi

I've got a similar question, so I'll post it here, and maybe two birds
can be killed with one stone.

I have a bunch of constants:

constant NU_OPERATIONS : unsigned := "011";
constant FINAL_STATE : unsigned := NU_OPERATIONS + 1;
constant FIRST_STATE : unsigned := FINAL_STATE + 1;
constant INIT_STATE : unsigned := FIRST_STATE + 1;

I can not use FINAL_STATE or FIRST_STATE in any case expressions,
because I get a "Choice FIRST_STATE is not a locally static
expression."

I've read a number of bulletin board posts on the topic, but am still a
bit confused. Are the expressions not locally static because the
compiler need not evaluate the right hand side of the expressions
(doesn't have to add '1')?

"Unfortunately, the value of constant c_CS0Part is not
locally static as aggregates are not locally static (i.e. the
compiler doesn't have to evaluate the aggregate
expression at compile time)." -
http://groups-beta.google.com/group/comp.lang.vhdl/browse_frm/thread/fc782d64937988a3/89c9cac9fcf2c025?q=%22Unfortunately,+the+value+of+constant%22&rnum=1#89c9cac9fcf2c025

Furthermore, if I was to make NU_OPERATIONS a global constant, what
hope would there be in using it in a CASE statement?

These restrictions to me seem to be quite uneccesary, especially when
considering that constants are often defined with relation to other
constants, and are used globally - am I doomed to using an ugly if/else
statement?

Thanks

Taras

 

[Andy Peters]

Taras_96 wrote:

I have a bunch of constants:

constant NU_OPERATIONS : unsigned := "011";
constant FINAL_STATE : unsigned := NU_OPERATIONS + 1;
constant FIRST_STATE : unsigned := FINAL_STATE + 1;
constant INIT_STATE : unsigned := FIRST_STATE + 1;

I can not use FINAL_STATE or FIRST_STATE in any case expressions,
because I get a "Choice FIRST_STATE is not a locally static
expression."

I've read a number of bulletin board posts on the topic, but am still
a
bit confused. Are the expressions not locally static because the
compiler need not evaluate the right hand side of the expressions
(doesn't have to add '1')?

"Unfortunately, the value of constant c_CS0Part is not
locally static as aggregates are not locally static (i.e. the
compiler doesn't have to evaluate the aggregate
expression at compile time)." -

http://groups-beta.google.com/group/comp.lang.vhdl/browse_frm/thread/fc782d64937988a3/89c9cac9fcf2c025?q=%22Unfortunately,+the+value+of+constant%22&rnum=1#89c9cac9fcf2c025

Furthermore, if I was to make NU_OPERATIONS a global constant, what
hope would there be in using it in a CASE statement?

These restrictions to me seem to be quite uneccesary, especially when
considering that constants are often defined with relation to other
constants, and are used globally - am I doomed to using an ugly
if/else
statement?

I think it is kind of odd that a constant plus a constant, evaluated at
compile time, isn't considered locally static; however, I think a
better solution to your problem is to simply use an enumerated type for
your case constants. this is actually the standard way of specifying
the states in a state machine, which I gather is your goal.

-a

 

[Taras_96]

Hi

There are two problems with this approach for my particular problem.

(1) The first 'n' states will correspond to doing a particular
operation, while the remaining few states will correspond to setting up
and winding down the operations. 'n' must be parametisable, will be a
global consant, and can be a value of up to 2048, so assigning names to
the first 2048 states of the state machine in the type declaration
would be unecessary, if in fact, you could do it without typing out
2048 words. Secondly, it IS preferable that the remaining few states
ARE named (in my example FIRST, INIT, and LAST).

(2) Secondly, the encoding of the states must be in binary, and must
follow the order of the type declaration (ie: the first 'n' states mus
be encoded in binary from 0 -> n-1, FIRST state must be encoded n, LAST
state must be encoded n+1, and INIT state must be encoded n+2). The
encoding is specified in a string:

attribute ENUM_ENCODING of STATE_TYPE: type is "00 01 10 11"

The contents of my string must both be parametisable and have up to
around 2050 entries. Obviously just writing the string out like above
is not possible. I have looked at a number of encodings that Xilinx
provides, and binary seems to be the most promising. However, if
binary encoding is used, does Xilinx assign '0' to the first item in
the enumeration, '1' to the second item in the enumeration, '2' to the
third item in the enumeration, or does it assign binary values to the
state in some random order to optimise feedback logic? Does anyone
have any other ideas as to how to get around this problem?

Regards

Taras