"when others" clause and synthesis

Discussion in 'VHDL' started by Calvin C, Dec 5, 2009.

  1. Calvin C

    Calvin C Guest

    Hi all,

    VHDL "when others" clause is to cover unused states in a state
    machine:

    i.e.

    ....
    when state0 =>

    when state1 =>
    ...
    when state8 =>

    when others =>
    (back to state0)

    We use one-hot for our 9-state state machine and use synopsys DC for
    the synthesis. The synthesized netlist shows 9 FFs as expected for the
    state machine.

    We next load the netlist into modelsim and use command "force -fixed
    reg2/d 1 time1 -cancel time2" to apply a short pulse '1' to input D of
    FF#2, to be captured by one clock edge when FF#2 output, reg2/q is at
    '0'.

    We'd expect the state machine to be able to go back to state0 shortly
    after that "induced noise" incident as instructed in "when others"
    clause.

    The state machine however hangs up!!!

    What could the problem be ?

    Thanks,

    Calvin
    Calvin C, Dec 5, 2009
    #1
    1. Advertising

  2. Calvin C

    KJ Guest

    On Dec 5, 3:33 pm, Calvin C <> wrote:
    > Hi all,
    >
    > VHDL "when others" clause is to cover unused states in a state
    > machine:
    >
    > i.e.
    >
    > ...
    >     when state0 =>
    >
    >     when state1 =>
    >          ...
    >     when state8 =>
    >
    >     when others =>
    >     (back to state0)
    >
    > We use one-hot for our 9-state state machine and use synopsys DC for
    > the synthesis. The synthesized netlist shows 9 FFs as expected for the
    > state machine.
    >
    > We next load the netlist into modelsim and use command "force -fixed
    > reg2/d 1 time1 -cancel time2" to apply a short pulse '1' to input D of
    > FF#2, to be captured by one clock edge when FF#2 output, reg2/q is at
    > '0'.
    >
    > We'd expect the state machine to be able to go back to state0 shortly
    > after that "induced noise" incident as instructed in "when others"
    > clause.
    >
    > The state machine however hangs up!!!
    >
    > What could the problem be ?
    >
    > Thanks,
    >
    > Calvin


    On Dec 5, 3:33 pm, Calvin C <> wrote:
    > Hi all,
    >
    > VHDL "when others" clause is to cover unused states in a state
    > machine:
    >
    > i.e.
    >
    > ...
    > when state0 =>
    >
    > when state1 =>
    > ...
    > when state8 =>
    >
    > when others =>
    > (back to state0)
    >
    > We use one-hot for our 9-state state machine and use synopsys DC for
    > the synthesis. The synthesized netlist shows 9 FFs as expected for the
    > state machine.
    >
    > We next load the netlist into modelsim and use command "force -fixed
    > reg2/d 1 time1 -cancel time2" to apply a short pulse '1' to input D of
    > FF#2, to be captured by one clock edge when FF#2 output, reg2/q is at
    > '0'.
    >
    > We'd expect the state machine to be able to go back to state0 shortly
    > after that "induced noise" incident as instructed in "when others"
    > clause.
    >
    > The state machine however hangs up!!!
    >
    > What could the problem be ?
    >


    I don't know specifically about Synopsys but with other synthesis
    tools, the default synthesis result for the 'when others' branch is
    only to cover the synthesizable states that have not already been
    explicitly specified.

    So if you have 'when state0 => ' ... 'when state8 =>' branches then,
    from the synthesizer's perspective, you've covered every path so the
    'when others =>' branch is redundant, unreachable code so it does not
    get synthesized.

    Synopsys may have some synthesis option that overrides this behavior.
    In Quartus the option is called 'Safe state machines' which is defined
    as "Tells the compiler to implement state machines that can recover
    gracefully from an illegal state.", the options being "Off" (which is
    the default) and "On". Check to see if Synopsys has something
    similar.

    Implementing state machines that recover from illegal states AND are
    one hot encoded tends to result in a lot of extra logic. In your
    case, you've got 2^9 - 9 (503) illegal states that need to be
    covered...that's a bit of baggage for 9 valid states.

    In fact, the system level requirements that would drive one to have to
    implement the 'when others' branch are usually the same ones that
    would drive one away from even wanting a one hot state machine because
    of the huge number of states. If you're explicitly saying you have to
    have one hot encoding, you might want to re-think why you think you
    need to have the 'when others' logic. Alternatively, if you have
    valid reasons for why you need to have the 'when others' logic, you
    should re-think your need for one hot and instead look to binary or
    gray code instead.

    Kevin Jennings
    KJ, Dec 5, 2009
    #2
    1. Advertising

  3. KJ wrote:

    > Implementing state machines that recover from illegal states AND are
    > one hot encoded tends to result in a lot of extra logic. In your
    > case, you've got 2^9 - 9 (503) illegal states that need to be
    > covered...that's a bit of baggage for 9 valid states.


    That's to much. In a one-hot encoded FSM it is sufficient to detect whether
    two registers are set, of the 9 storing the state. This will cover all
    illegal states.

    Tom
    Thomas Reinemann, Dec 7, 2009
    #3
  4. Calvin C

    Andy Guest

    Per the language description, if you only described nine states for
    the state machine to handle, the hardware implementation does exactly
    that. Per your description, there are no "others" to handle. The
    reachability analysis done by most synthesis tools condludes that your
    "when others" condition is unreachable, and therefore it need not be
    implemented.

    If you want all possible states to be handled, you need to define
    those states.

    Getting past the reachability analysis can be a bit trickier. If the
    state variable is never assigned a specific value, then the
    reachability analysis concludes that state is not reachable. I don't
    know if it can be turned off or not.

    However, it is often not nearly enough to simply have the state
    machine recover from unused states to a known state. The "system" must
    also recover. What happens if your FSM jumps into the weeds when
    something else is waiting for an acknowledge from you? Unless you
    recover to the "correct" state, the system could still be hosed.

    Andy
    Andy, Dec 7, 2009
    #4
  5. Calvin C

    KJ Guest

    On Dec 7, 9:35 am, Thomas Reinemann <> wrote:
    > KJ wrote:
    > > Implementing state machines that recover from illegal states AND are
    > > one hot encoded tends to result in a lot of extra logic.  In your
    > > case, you've got 2^9 - 9 (503) illegal states that need to be
    > > covered...that's a bit of baggage for 9 valid states.

    >
    > That's to much. In a one-hot encoded FSM it is sufficient to detect whether
    > two registers are set, of the 9 storing the state. This will cover all
    > illegal states.
    >
    > Tom


    I understand that (but you also missed the all zeros illegal state).
    To cover all the combinations of two bits being set you have
    8+7+6+5+4+3+2+1 = 36 two input 'ands', plus one more 9 input 'and' all
    of which get or-ed together to detect the illegal states. A straight
    binary encoding would need to only or together two two input 'ands' to
    cover the illegals...i.e. (st(3) and st(1)) or (st(3) and st(2)).

    Seems like a bit of baggage to me.

    Granted this is a specific case and not the general one, but it would
    appear to me that at nine states the logic required to implement the
    recovery might start to overwhelm the decode advantage of the one
    hot. But that's why the synthesis tool should usually be deciding
    these things, by letting it pick an encoding that minimizes resource
    usage and/or increases performance. Manually choosing a particular
    encoding should be done on an exception basis unless there are
    specific overall design criteria that necessitate a particular
    encoding.

    Kevin Jennings
    KJ, Dec 7, 2009
    #5
  6. Andy wrote:

    > However, it is often not nearly enough to simply have the state
    > machine recover from unused states to a known state. The "system" must
    > also recover. What happens if your FSM jumps into the weeds when
    > something else is waiting for an acknowledge from you? Unless you
    > recover to the "correct" state, the system could still be hosed.


    Yes. In the end, the *system* has to work.
    Designing "safe" state machines or counters or shifters
    doesn't cover the question:
    How did I get into that bad state in the first place?
    The root cause is most likely a system issue.
    Static timing, synchronization, initialization,
    noise, test coverage etc.

    -- Mike Treseler
    Mike Treseler, Dec 7, 2009
    #6
  7. Calvin C

    JimLewis Guest

    Hi Calvin,
    Unfortunately for safe statemachines, most synthesis
    tools ignore 1076.6-2004 recommendations. Instead they
    each require you to use their attributes or directives
    to create a safe statemachine. So to get what you need,
    start reading the vendors documentation.

    Best,
    Jim
    JimLewis, Dec 7, 2009
    #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. walala
    Replies:
    4
    Views:
    2,101
    Ralf Hildebrandt
    Sep 8, 2003
  2. walala
    Replies:
    4
    Views:
    1,199
    Technology Consultant
    Sep 9, 2003
  3. Ron Vecchi
    Replies:
    1
    Views:
    673
    Ron Vecchi
    Jul 27, 2003
  4. Luca D.

    When others case and Synthesis

    Luca D., Mar 5, 2010, in forum: VHDL
    Replies:
    0
    Views:
    527
    Luca D.
    Mar 5, 2010
  5. Travis
    Replies:
    3
    Views:
    356
Loading...

Share This Page