Generic in CASE choice ?!?

Discussion in 'VHDL' started by Thorsten Bunte, Apr 28, 2005.

  1. 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
     
    Thorsten Bunte, Apr 28, 2005
    #1
    1. Advertising

  2. Thorsten Bunte

    Taras_96 Guest

    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...he value of constant"&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
     
    Taras_96, Apr 28, 2005
    #2
    1. Advertising

  3. Thorsten Bunte

    Andy Peters Guest

    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...he value of constant"&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
     
    Andy Peters, Apr 28, 2005
    #3
  4. Mike Treseler, Apr 28, 2005
    #4
  5. Thorsten Bunte

    Taras_96 Guest

    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
     
    Taras_96, Apr 29, 2005
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jan

    choice in a case satement

    jan, Dec 3, 2003, in forum: VHDL
    Replies:
    2
    Views:
    517
    Nicolas Matringe
    Dec 4, 2003
  2. Manfred Balik
    Replies:
    3
    Views:
    4,316
    Brian Drummond
    Apr 30, 2005
  3. Kenneth Johansson
    Replies:
    9
    Views:
    8,854
    Mike Treseler
    May 9, 2005
  4. Mickey Segal
    Replies:
    0
    Views:
    899
    Mickey Segal
    Feb 2, 2004
  5. miles.jg
    Replies:
    16
    Views:
    885
    Alf P. Steinbach
    Nov 14, 2007
Loading...

Share This Page