How to force FSM to use "gray" type?

Hi All ,
Iam using 2 process type FSM in my VHDL code
the problem is the FSM is not working correctly , It hazards randomly
when I checked the syntheizer reprt I founded that

"Using one-hot encoding for signal <currentstate>"

It automatically uses one hot techneque for the FSM

Now , how can I force it to use "gray" type ?

it depends on what synthesis tool u are using, then, what's it?

If you use Synplify Pro as synthesis toll,you can use attribute 'syn_encoding'.

Here is an example for this attribute:

library synplify;
use synplify.attributes.all;
package my_states is
type state is (Xstate, st0, st1, st2, st3, st4, st5, st6, st7,
st8, st9, st10, st11, st12, st13, st14, st15);
signal s1 : state;
attribute syn_encoding of s1 : signal is "gray";
end my_states;

Re: FSM Problem

Iam using ISE6.1.03 and I want to know 2 things

1- what can cause hazards in the state transition
Does the process sensitivity list can affect by any means
2- how can you force the synthizese tool (ISE) to make the state gray coding

Can any body help

Re: FSM Problem

Your first problem will be more clear to us if u post code of ur FSM..
Regarding 2nd problem, u can change FSM Encoding by going to Process Menu..click properties> HDL Options> FSM Encoding Algorithm Tab.. from there u can select gray etc..(This is from ISE 5.2) Hope this helps..
tut..

Re: FSM Problem

to the first question:
under some special conditions,such as low temperature,the FSM will not turn to the scheduled state you make,for example:you want the state change from 000 to 011 under some condition,but the last two bits can't chage in the same time,then 000 will change to 010 ,and the state will stay for a time,which will make a error!any one is welcome if she or he disagree my idea!

Re: FSM Problem

Hi guyes ,

First I want to thak you all for your contribution
I have just discovered why it wasn't work correctly and I thought that
you should know it not to fall in the same mistake

Now from my experience in this project,
If you want to make a stable FSM you shoud :

1- Make it constructed from 3 processes (transition,state register,output)
It's better to separate the output process from the state register process

2- all of them should be clocked but the the transition process clock
shouldn't be the same edge of the others , i mean if the others were
+ve edge the transiton should be -ve and vise versa
" To be ohnest this will reduce the maximum frequency allowed
to the half but it will guarantee a stable functionality of your FSM"

3- Finally there is very very important condition which is :
all inputs to the state register process should be
CLOCKED and REGISTERED
this is very important and you will notice the difference if you
tried to implement your design in te real world

In simulation you will not notice any difference and you will see
all things works but you will face the truth when it comes to
implementation

ofcourse there are many other design tech. but this is the only state that
works with me
I hope this may help any body works in the same field

Best regards

I think the third point is most important!
The others are not important.

To nicolepsn:
Do u have any experiences like you said. Wonder the low temperature can prevent two bits change simultaneously in the PGA logic internal.

Regards
Ifarmer

Re: FSM Problem

nicolepsn said:

to the first question:
under some special conditions,such as low temperature,the FSM will not turn to the scheduled state you make,for example:you want the state change from 000 to 011 under some condition,but the last two bits can't chage in the same time,then 000 will change to 010 ,and the state will stay for a time,which will make a error!any one is welcome if she or he disagree my idea!

Click to expand...

What are you goning to explain?
I think it simply means the design is not reliable if it's sensitive to such kind of variation.

Re: FSM Problem

If it is correct , there is no relation with the code , I think he means the chip c/cs ... but I don't think that can be correct ...
I have read before that the coding technique may cause something like that if you are using high frequency , so they prefere gray coding for FSM than binary and one hot ...

ifarmer said:

To nicolepsn:
Do u have any experiences like you said. Wonder the low temperature can prevent two bits change simultaneously in the PGA logic internal.

Regards
Ifarmer

Click to expand...

Maybe it means the delay of logic is changed and there is a setup/hold time violation under low temprature environment.

Re: FSM Problem

I have to disagree with some of the points made by Vonn above:

1) In a state machine the state is ALWAYS registered, the outputs are usually registered, and the transitions (case statement) usually aren't.

2) In a sound synchronous design, you very rarely use both edges of the clock. All of the processes should be clocked on the same edge. It really wreaks having on timing analysis.

3) It would be nice if all of the inputs to the SM could be registered, but they don't have to be as long as setup and hold times are met.

Radix

next state is combine logic
current state is sequence logic
fsm out is sequence logic!

you can understand the structure by using hdl design series from mentor!

Re: FSM Problem

Hi Guyes ,
You are completely right about what you said ,
If you refer to the XST (Xilinx Synth. Guide ) and look at the FSM
3 process structure , you will find that the first is clocked while the 2 others are not , when I make my design like that , it gives me perfect results in simulation , but when i tried to implement it on chip and come to the real world , the states didn't work correctly ..
for example , i make a state x contains only one command which is :
nextstate <= y ; OK , I think this is the simplest one in the world !!!!!
Actually , that doesn't happen , the FSM transition was not correct at all , On the other side when I make all of them clocked , It works !!!
I am speaking from practical experience not from simulation point of view , please if any body want to add post or suggestion regarding this issue , he must make sure that his recommendition based on practical experience not from just reading or simulating because it's completely different , in the real world you face problems you never think about ...

Agree with radix in that "do not use both edeges of the clock because it will pains the timing analysis."

FSM Problem

I agree with radix and RemyMartin. Although your reasoning is based on your practical experience, I guess that you have a hidden trouble in your design. Perhaps your testbench do not simulate your real world or you only have done a behavioral simulation. In my whole practical experience I only needed to work in both edges in two designs and only in the last pipe level (IOB registers). If you apply the design methodology you explained, I believe you will have a lot of troubles in your future designs.

Re: FSM Problem

Hi..

Ya, by registered all input pin at your FSM able to avoid all the hazard in digital design, but if two FSM is communicate with each other, i think the most important thing is to use handhasking process. by using register all input at FSM is very costly, althought FPGA rich of flip-flop.