Coding State Machines

[Ardni]

Hi all,
I have a query regarding state machines that I hope someone can clear up.

Basically I have been writing state machines by following a method that a workmate showed me for some time and I am thinking now that this method may be incorrect as I did notice some strange things in timing simulation.

I have been studying how they should be written and from reading an document by altera on recommended coding styles. (http://www.altera.com/literature/hb/qts/qts_qii51007.pdf?GSA_pos=1&WT.oss_r=1&WT.oss=coding style). On page 6-66 the state machine example can be found, but to save cluttering, I will summerize my doubt...

There are two processes, one which assigns the next state to the current state on each clock edge and the other which reads the inputs and modifies the outputs and assigns next state. In the sensitivity list of the process which calculates the next state contains the inputs, which could change at any point in time, now suppose they change more than once during a clock period and that they directly affect what the next state may become...what would happen if one of the inputs change very close to the clock edge, thus changing next_state. When the clock edge arrived and the frist process goes to assign the next state to the current state, if next state is in the process of changing, is there a possibility that the signal holding next state could be read metastable and thus transferred to the current state, which could cause a failure?

Previously I had written state machines using just one process, to read inputs, assign outputs and assign the state all on 1 clk edge. I think maybe this was bad practice, but I don´t understand why there would eb a problem with it´.

I´d be grateful if someone could clear this up for me.

Many Thanks

 

[jeppe]

Hi

First will I point - you can't solve this problem by using only one process for the complete statemachine. The result (read hardware) will properly be the same with one, two or three processes used to descripe your state machine.

Its true that metastability could give a digital design great problems, but I would compare this with the change of winning the BIG price in a lottery (two weeks in a row) - no the REAL problem will be hazard - static and timing types (please consult text-books for more)

To make long story shot - in order to avoid problems all asynchrone inputs must be synchronized before they are used in the "next state logic" - basically can this be done with a single F/F (per input signal) but if you want to be "100%" sure must you use more advanced tecniques like connecting more F/Fs in series and scale down the clock frequency for this purpose (Read more in the book from Wakerly)

Your welcome
Jeppe

 

[Ardni]

Thank you very much for your reply.

OK i understand now why metasatbility is unlikely to be a problem if the nessesery precautions are taken.


Also, one final question.
Is it ok to read and assign signals used in the component that are also used by other processes? or should inputs and outputs only be used?

It´s just that i saw some strange results in timing simulation, like signals going undefined without reason, but if I changed the state that they were assigned in or the order etc, then the simulation would work fine.

Many thanks for any help.

 

[jeppe]

Hi Ardni

If you follow the rules of VHDL (could be hard some times) will your code produce combinatorial hardware (and-or-logic) and F/F's.

However will there always exist delays inside a FPGA due to transmission and gates. If your simulation shows undefined signal could it be real problem, but most likely will it be due to a "creative" use of VHDL (my own experience : )

I got a little example at the button at this page:
http://www.jjmk.dk/MMMI/Exercises/04_Statemachine/No2_Implementation/exer4_2_implemtations.htm

The Serial adder example gives you a hint about the rules to follow.

Your welcome
Jeppe

 

[Ardni]

Thank you again for the reply and also for the examples Jeppe.

Could you please clarify for me what are the advantages or disadvantages of using 1, 2 or 3 process to implement the state machine. I do not fully understand why it is better or worse to use one approach instead of another.

Also could you please clarify what you meant by the "creative" use of VHDL?
Does it mean bad coding practice? Also there are no problems with reading or writing ti signals that could be read and written to by other processes in the component?

I am very interested to understand this, as I have experienced problems during simulations that i couldn´t explain. I would like to better understand how to code state machines properly because in the past I believe I have not been doing it properly.

Many thanks.

 

[jeppe]

Hi
Could you please clarify for me what are the advantages or disadvantages of using 1, 2 or 3 process to implement the state machine. I do not fully understand why it is better or worse to use one approach instead of another.

If you only use 1 process for your design (FSM ect) and this process operates
with several signals, connected at a serial maner (check my serial adder example) will you get several F/F's due to the clock driven process.
This could be good if you wants it - or bad if your not aware.

With 3 processes can you split your design at the logical elements you need for the FSM - "pure" combinatiorial logic and F/F's as well.
The Gnome processer at my site done with the same technique.

About "the Creative use" - if you forget signals in the sensitivitylist will the tools try figure out a circuit which could fit your needs. This could result in "implied latches" and extra logic. VHDL was originally created for simulation purposes and hence can a sourcecode give one result at the screen and another when put in hardware.

 

[Ardni]

Thank you Jeppe