Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Synchronous input FSM & sensitivity list

Status
Not open for further replies.
Are you certain this is accurate for VHDL? From what I've read, using default case and safe fsm are independent concepts.

The default state is the state your FSM is initialized into. When you power up your system, the FSM enters the default state. In this case, that state is A. The safe state is that which your FSM reverts to if it eventually enters an indeterminate state. In this case, it is still A.

Take, for instance, that you need five states, A, B, C, D, E. It might be equivalent to a 3-bit register with say 000, 001, 010, 011 and 100. But a 3-bit register can provide eight different values. So where are the rest of the values (101, 110 and 111)? They are undesired states, because you need only five states. If during transition, you eventually enter one of these states (i.e. the register contains 101, 110 or 111), you want to transition to your safe state. This is what others is used for. The state you select to go to with the others clause is your safe state.

Your reset state is that which you go to when you press your reset button. It is often the default state (000...)

There is nothing you can achieve with attributes that you cannot achieve without attributes. They are only made to make coding easier.
 

I believe the discussion about a safe state is partly missing the problem.

To determine if a FSM has the ability to get locked in an illegal state, you need to look at the gate level logic.

State machines of a certain complexity (probably not the A/B state machine discussed in this thread) are implemented by default with one hot coded state variable because the logic cell amount used for decoding is reduced and speed increases.
I'm not sure if tools ever re-encode the FSM though.
Specifying a particular state variable encoding is only a matter of design entry and is usually ignored by the synthesis tool.

Without applying vendor specific synthesis directives, the compiler assumes that illegal states (all state bits '0' or multiple state bits simultaneously '1') can't occur and thus doesn't handle it. That's just a side effect of the synthesis tool's logic optimizing strategy, similar to removing all logic related to a register bit that is detected as being always '0'.

Synthesis directives like the Altera safe_encoding state machine style add extra logic to the state machine that transfers all illegal states to the reset state.
 

There is nothing you can achieve with attributes that you cannot achieve without attributes. They are only made to make coding easier.

Are you including vendor-specific attributes?
 

There is nothing you can achieve with attributes that you cannot achieve without attributes. They are only made to make coding easier.
The statement is at least wrong regarding state machine encoding with Altera tools, I guess also for other vendors.
 

The statement is at least wrong regarding state machine encoding with Altera tools, I guess also for other vendors.

Why so please? Which attributes can't be equivalently coded manually?
 

Why so please? Which attributes can't be equivalently coded manually?

How far are you willing to go? For example, it looks like you can't use an enumerated type in VHDL if you want "when others" to include invalid states. However, you could manually encode the FSM as a std_logic_vector and then use "when others". So you are correct for this attribute.

syn_maxfan would probably be unreliable in an HDL only mode.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top