Sequential Machines

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?
------------------------------------------------------------------------------

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?

john

john wrote:
>
> 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


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

rickman

rickman wrote:
> john wrote:
>
>>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?
>

you can also write it like this

http://toolbox.xilinx.com/docsan/xil...sim/vtex9.html

thomas

thomas wrote:
>
> you can also write it like this
>
> http://toolbox.xilinx.com/docsan/xil...sim/vtex9.html

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


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

rickman

rickman wrote:

> 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

Mike Treseler

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

Thanks
Regards
jim

rickman <> wrote in message
news:<>...
> thomas wrote:
> >
> > you can also write it like this
> >
> > http://toolbox.xilinx.com/docsan/xil...sim/vtex9.html
>
> 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
>
>
> 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

john

john wrote:
>
> Hello,
> I did not understand which document you are reffering! would you
> please clear your point...
>
> Thanks
> Regards
> jim
>
> rickman <> wrote in message
> news:<>...
> > thomas wrote:
> > >
> > > you can also write it like this
> > >
> > > http://toolbox.xilinx.com/docsan/xil...sim/vtex9.html
> >
> > 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!

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


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

rickman