Sequential Machines

J

john

Hello,

I have basic questions regarding sequential machines

Q.1: Is the following way is the right way to define sequential
machine?

signal State : unsigned(7 downto 0);
signal nextstate : unsigned(7 downto 0);
constant E0 : unsigned(7 downto 0):="00000000";
constant E1 : unsigned(7 downto 0):="00000001";
constant E2 : unsigned(7 downto 0):="00000010";
constant E3 : unsigned(7 downto 0):="00000011";

Process (State,nextstate)
Begin

Case State is


When E0=>
..............
nextstate<=E1;

When E1=>
...............
nextstate<=E2;


When E2 =>
...............
nextstate<=E3;
When E3=>

................
nextstate<=E0;

When others =>
nextstate <= E0;
End case;
End Process;

Process (DPR_CLK,State,nextstate)
Begin

If (CLK'event And CLK='1') Then

State <= nextstate;
End If;
End Process;
End DPR_ARCH;

------------------------------------------------------------------------------

Q.2: some times the sequential mahine loose its direction. like state
E0 to E2,
What would be the solution?

Q.3: And whats the difference between
When others =>

nextstate <= E0;

AND
When others =>

nextstate <= NULL;

When we power up the CPLD, then by default the cpld goes to the state
E0, if
we use
When others =>

nextstate <= E0;
or the state machine will never run if we use

When others =>

nextstate <= NULL;
Please adivce me that I am right or wrong?
 
R

rickman

john said:
Hello,

I have basic questions regarding sequential machines

Q.1: Is the following way is the right way to define sequential
machine?

There are many ways to implement a FSM (Finite State Machine). This one
is fine. But why do you only have four states, but use an 8 bit vector
to indicate state?

signal State : unsigned(7 downto 0);
signal nextstate : unsigned(7 downto 0);
constant E0 : unsigned(7 downto 0):="00000000";
constant E1 : unsigned(7 downto 0):="00000001";
constant E2 : unsigned(7 downto 0):="00000010";
constant E3 : unsigned(7 downto 0):="00000011";

Process (State,nextstate)
Begin

Case State is


When E0=>
..............
nextstate<=E1;

When E1=>
...............
nextstate<=E2;


When E2 =>
...............
nextstate<=E3;
When E3=>

................
nextstate<=E0;

When others =>
nextstate <= E0;
End case;
End Process;

Process (DPR_CLK,State,nextstate)
Begin

If (CLK'event And CLK='1') Then

State <= nextstate;
End If;
End Process;
End DPR_ARCH;

------------------------------------------------------------------------------

Q.2: some times the sequential mahine loose its direction. like state
E0 to E2,
What would be the solution?

The code looks ok, so I would suspect some hardware issues. Do you have
clean power, clean clock. What board is this on? Does it work
correctly in simulation?

Q.3: And whats the difference between
When others =>

nextstate <= E0;

AND
When others =>

nextstate <= NULL;

This is not valid code unless you have defined NULL to be an 8 bit SLV
constant. You mean...

When others =>
NULL;

This is like saying NOP. The compiler will interpret that as hold the
previous state which will infer a latch separate from the register you
are inferring in the clocked process. I don't think that is what you
want. This is also true if you fail to account for all the posible
synthesizable states of your signal. That means you don't have to
consider X's and U's, etc, but you have to consider all possible
combination of 1's and 0's.

When we power up the CPLD, then by default the cpld goes to the state
E0, if
we use
When others =>

nextstate <= E0;

No, it can power up in state E1 and then procede through E2 and E3
before getting to state E0. You may not care, but the point is that you
are not resetting to state E0. Even if it reaches E0 after one clock
cycle, it first had to start in an invalid state on power up. To
initialize to a specified state, you need to add a reset signal of some
sort or specify an initial state. How to do this depends on your
tools.

or the state machine will never run if we use

When others =>

nextstate <= NULL;
Please adivce me that I am right or wrong?

Again, this will create a latch from your process with the case
statement. And it will lock up in the invalid state.
------------------------------------------------------------------------------

Q.3 Is sequential machine is the only best way to generate the cycles
for reading and
writing the Memory or is there an another way to do it?

This FSM is just a counter. Why not use a counter?

--

Rick "rickman" Collins

(e-mail address removed)
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
 
T

thomas

rickman said:
There are many ways to implement a FSM (Finite State Machine). This one
is fine. But why do you only have four states, but use an 8 bit vector
to indicate state?





The code looks ok, so I would suspect some hardware issues. Do you have
clean power, clean clock. What board is this on? Does it work
correctly in simulation?





This is not valid code unless you have defined NULL to be an 8 bit SLV
constant. You mean...

When others =>
NULL;

This is like saying NOP. The compiler will interpret that as hold the
previous state which will infer a latch separate from the register you
are inferring in the clocked process. I don't think that is what you
want. This is also true if you fail to account for all the posible
synthesizable states of your signal. That means you don't have to
consider X's and U's, etc, but you have to consider all possible
combination of 1's and 0's.





No, it can power up in state E1 and then procede through E2 and E3
before getting to state E0. You may not care, but the point is that you
are not resetting to state E0. Even if it reaches E0 after one clock
cycle, it first had to start in an invalid state on power up. To
initialize to a specified state, you need to add a reset signal of some
sort or specify an initial state. How to do this depends on your
tools.





Again, this will create a latch from your process with the case
statement. And it will lock up in the invalid state.




This FSM is just a counter. Why not use a counter?

you can also write it like this

http://toolbox.xilinx.com/docsan/xilinx4/data/docs/sim/vtex9.html
 
R

rickman

thomas said:

I noticed that this doc puts the FSM case statement into a clocked
process. This will work fine if you don't mind your output signals
being clocked (and therefor delayed). Otherwise it can be easier to use
a non-clocked process for the FSM case statement. Then you can define
outputs that depend on the current state and optionally the inputs
(Mealy vs. Moore). Of course the downside is that a non-clocked process
requires you to specify the *entire* sensitivity list!

--

Rick "rickman" Collins

(e-mail address removed)
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
 
M

Mike Treseler

rickman said:
I noticed that this doc puts the FSM case statement into a clocked
process. This will work fine if you don't mind your output signals
being clocked (and therefor delayed).

Synchronized outputs may be worth the wait.
Otherwise it can be easier to use
a non-clocked process for the FSM case statement. Then you can define
outputs that depend on the current state and optionally the inputs
(Mealy vs. Moore). Of course the downside is that a non-clocked process
requires you to specify the *entire* sensitivity list!

The other downside is that the outputs might glitch.

-- Mike Treseler
 
J

john

Hello,
I did not understand which document you are reffering! would you
please clear your point...

Thanks
Regards
jim
 
R

rickman

john said:
Hello,
I did not understand which document you are reffering! would you
please clear your point...

Thanks
Regards
jim

This took me awhile to find what you were unclear about. I see now that
the example uses a non-clocked process for the next state and output
specifications. The style of formatting did not make it clear where one
process began and the other left off. I use more white space in such
cases and I did not see the start of the combinatorial process.

--

Rick "rickman" Collins

(e-mail address removed)
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,768
Messages
2,569,574
Members
45,049
Latest member
Allen00Reed

Latest Threads

Top