Is my code good?

Discussion in 'VHDL' started by bxbxb3, Feb 25, 2005.

  1. bxbxb3

    bxbxb3 Guest

    Hi,
    I have a doubt whether the following coding style is a good one or not.

    process(clock)
    begin
    if(clock'event and clock='1') then
    case state is
    when START_RD=>

    when NEXT1=>

    when FINAL=>
    o_Frame_SaComapact1_Rt <= i_myMacAddress;
    end case;
    end if;
    end process;


    Two of the case statements have nothing to do in that state. Will this
    infer a latch? Is it better to use a "if" statement instead?
    Thanks in advance.
    bxbxb3, Feb 25, 2005
    #1
    1. Advertising

  2. bxbxb3 wrote:
    > Hi,
    > I have a doubt whether the following coding style is a good one or not.
    >
    > process(clock)
    > begin
    > if(clock'event and clock='1') then
    > case state is
    > when START_RD=>
    >
    > when NEXT1=>
    >
    > when FINAL=>
    > o_Frame_SaComapact1_Rt <= i_myMacAddress;
    > end case;
    > end if;
    > end process;
    >
    >
    > Two of the case statements have nothing to do in that state. Will this
    > infer a latch?


    No, it will infer a flip-flop because that's what you describe in your
    process ("if(clock'event and clock='1')").

    > Is it better to use a "if" statement instead?


    Depends whether this is the only decoding you do with 'state'. In
    general, I do like to use case statements with enumeration types.

    If the code is not going to be synthesized, I _never_ use a "when
    others" choice. Reason: if you later expand (add members) to you
    enumeration type and you forget to modify your case statement, the code
    will fail already at compilation time, because case choices must be
    complete.

    For synthesis this is different: the state variable/signal will be
    mapped to a vector, giving 2**n possible states. So here you _must_ use
    a "when others" choice, to prevent hang-up situations if the state
    vector ever gets one of those unused states.

    Paul.
    Paul Uiterlinden, Feb 25, 2005
    #2
    1. Advertising

  3. > For synthesis this is different: the state variable/signal will be
    > mapped to a vector, giving 2**n possible states. So here you _must_ use
    > a "when others" choice, to prevent hang-up situations if the state
    > vector ever gets one of those unused states.
    >
    > Paul.


    Hi,

    I am not convinced that synthesis programs generate fail-safe FSMs
    only because of the "when others" clause. Please refer to the
    application note "Designing Safe VHDL State Machines with Synplify".

    /Peter
    Peter Hermansson, Feb 25, 2005
    #3
  4. bxbxb3

    Eric Smith Guest

    Paul Uiterlinden <> writes:
    > For synthesis this is different: the state variable/signal will be
    > mapped to a vector, giving 2**n possible states. So here you _must_
    > use a "when others" choice, to prevent hang-up situations if the state
    > vector ever gets one of those unused states.


    Note that VHDL semantics only define "when others" to affect the other
    legal values of the type. For instance, if you have an enumeration with
    three values, FOO, BAR, and BAZ, which will synthesize to a two bit
    vector, a "when others" clause does not cover the fourth possible state
    of the vector.

    A synthesis tool may choose to expand the meaning to encompass the
    illegal values, but the VHDL LRM does not guarantee this, so you have to
    determine it for the specific synthesis tool.

    Eric
    Eric Smith, Feb 27, 2005
    #4
  5. Eric Smith wrote:

    > Paul Uiterlinden <> writes:
    >> For synthesis this is different: the state variable/signal will be
    >> mapped to a vector, giving 2**n possible states. So here you _must_
    >> use a "when others" choice, to prevent hang-up situations if the state
    >> vector ever gets one of those unused states.

    >
    > Note that VHDL semantics only define "when others" to affect the other
    > legal values of the type. For instance, if you have an enumeration with
    > three values, FOO, BAR, and BAZ, which will synthesize to a two bit
    > vector, a "when others" clause does not cover the fourth possible state
    > of the vector.


    You should allways expand your enumerations to 2**n states (foo, bar, baz,
    unused) to avoid this problem.
    BTW when using synplify, you should replace each enumeration type with
    constant declarations, if you like to have a determistic result, that
    didn't mess up you equivalence check.

    bye Thomas

    --
    Emailantworten bitte an thomas[at]obige_domain.
    Usenet_10 ist für Viren und Spam reserviert
    Thomas Stanka, Feb 28, 2005
    #5
  6. Peter Hermansson wrote:
    >
    > I am not convinced that synthesis programs generate fail-safe FSMs
    > only because of the "when others" clause. Please refer to the
    > application note "Designing Safe VHDL State Machines with Synplify".


    Thanks for the pointer. Interesting stuff.

    When I wrote my message, I had Synopsys design_compiler in mind. There
    the "when others" does work.

    Paul.
    Paul Uiterlinden, Feb 28, 2005
    #6
  7. bxbxb3

    Eric Smith Guest

    I wrote:
    > Note that VHDL semantics only define "when others" to affect the other
    > legal values of the type. For instance, if you have an enumeration with
    > three values, FOO, BAR, and BAZ, which will synthesize to a two bit
    > vector, a "when others" clause does not cover the fourth possible state
    > of the vector.


    Thomas Stanka <> writes:
    > You should allways expand your enumerations to 2**n states (foo, bar, baz,
    > unused) to avoid this problem.


    Agreed, this is the best approach to avoid dependence on characteristics
    of a specific synthesizer. Then the "when others" clause can be used
    with predictable results.
    Eric Smith, Feb 28, 2005
    #7
    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. sikka noel
    Replies:
    8
    Views:
    413
    Mike Wahler
    Aug 5, 2003
  2. vlsidesign
    Replies:
    26
    Views:
    951
    Keith Thompson
    Jan 2, 2007
  3. Cliff  Martin
    Replies:
    1
    Views:
    3,022
    Larry Smith
    Jan 31, 2007
  4. SM
    Replies:
    9
    Views:
    491
  5. Casey Hawthorne
    Replies:
    18
    Views:
    603
    Beej Jorgensen
    Nov 6, 2009
Loading...

Share This Page