"when others" clause and synthesis

[Calvin C]

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

 

[KJ]

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

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

 

[Thomas Reinemann]

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

 

[Andy]

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

 

[KJ]

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

 

[Mike Treseler]

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

 

[JimLewis]

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