FSM single process...BIG question

On Dec 5, 5:20 pm, "carlob"
<carlo.beccia@n_o_s_p_a_m.n_o_s_p_a_m.libero.it> wrote:
Anyway...probably I was wrong...I don't need to avoid registered output
(and a lot of you were right)...in fact I'm always assigning the "output"
of a FF...therefore I'm sure that when fsm reach a state the output will
change to the value that is required on that state on the same clock
front
and I don't have to wait for another clock front to have that value on
output...

This is not completely true...state change immediately if change condition
is met...output is still at values on previous state...on the next clock
front the output goes to the new state value...this is the effect of the
output FF...I'm sorry a misunderstanding....
Click to expand...
No, something is wrong with your understanding. If your outputs are
defined at the same time as the next staate is defined, you can get
the outputs changing at the time as the state. It just means the
outputs will use similar logic to the state logic and will depend on
both the current state and the inputs, just as the state does. This
can all be in one process.

The only limitation of a one process FSM is that the outputs can only
respond to the inputs at a clock boundary. There are cases where the
output needs to change as soon as the input changes without waiting
for the next clock.


..the difference is now clear....I've just simulated the two
situations...(1 process, 2 process-no register)...and checked the
differences....
Click to expand...
If you are finding your outputs to be changing one clock cycle after
the state changes, then you aren't coding the output to depend on the
input, only the state.


Anyway...since all input signals "should be sinchronous" to the raise front
of the clock and the produced output MUST be synch I think that the best
way to achieve that is registering output and evaluating input on clock
raise...my previous implementation was wrong because output is allowed to
change asynchronously...I have to correct...and I think that 1 process
style fit better the requirements...
Click to expand...
An output can be synchronous and still be purely combinatorial. All
logic between registers is combinatorial, it has nothing to do with
how you code your HDL.


If in some cases I will need to unreg output I will use concurrent
statements outside of the process as pointed out in the discussion...
Click to expand...
But if you need your output registers to change at the same clock edge
as the state, that shouldn't be a problem. You don't need
combinatorial code to do that.

Rick
 
On Dec 5, 5:20=A0pm, "carlob"
carlo.beccia@n_o_s_p_a_m.n_o_s_p_a_m.libero.it> wrote:
Anyway...probably I was wrong...I don't need to avoid registere
output
(and a lot of you were right)...in fact I'm always assigning th
"output=
"
of a FF...therefore I'm sure that when fsm reach a state the outpu
will
change to the value that is required on that state on the same clock
front
and I don't have to wait for another clock front to have that value on
output...

This is not completely true...state change immediately if chang
conditio=
n
is met...output is still at values on previous state...on the nex
clock
front the output goes to the new state value...this is the effect o
the
output FF...I'm sorry a misunderstanding....

No, something is wrong with your understanding. If your outputs are
defined at the same time as the next staate is defined, you can get
the outputs changing at the time as the state. It just means the
outputs will use similar logic to the state logic and will depend on
both the current state and the inputs, just as the state does. This
can all be in one process.
Click to expand...
Hi Rick...yes...it is definitely....I understand your point...I think tha
we are expressing the same concept in different ways...it is not easy t
explain without an example.....

The only limitation of a one process FSM is that the outputs can only
respond to the inputs at a clock boundary. There are cases where the
output needs to change as soon as the input changes without waiting
for the next clock.
Click to expand...
Yes...definitely...I agree...that is another important difference....

An output can be synchronous and still be purely combinatorial. All
logic between registers is combinatorial, it has nothing to do with
how you code your HDL.


If in some cases I will need to unreg output I will use concurrent
statements outside of the process as pointed out in the discussion...

But if you need your output registers to change at the same clock edge
as the state, that shouldn't be a problem. You don't need
combinatorial code to do that.

Rick
Click to expand...
Yes...I agree again....what I wanted to say is that my input should b
synch with the clock...therefore I think that is a requirement to evaluat
their change only on a clock front...the output will change on a cloc
front too...
1 process approach seems to fit better (input are evaluated on cloc
raise/fall and, obviously, output will change only on a cloc
raise/fall...)...I don't wanted to say that you cannot do wit
combinatorial logic...but, in that case, you have to explicitily code FF
to have that (input and output)...with 1 process it is not needed...FFs ar
implicit in the HDL...

Hope to have explained my point...it is diffucult to say in words this kin
of concepts...

Thanx
Carlo




---------------------------------------
Posted through http://www.FPGARelated.com
 
Anyway...probably I was wrong...I don't need to avoid registered output
(and a lot of you were right)...in fact I'm always assigning th
"output"
of a FF...therefore I'm sure that when fsm reach a state the output will
change to the value that is required on that state on the same clock
front
and I don't have to wait for another clock front to have that value on
output...
This is not completely true...state change immediately if chang
condition
is met...output is still at values on previous state...on the next clock
front the output goes to the new state value...this is the effect of the
output FF...I'm sorry a misunderstanding....

..the difference is now clear....I've just simulated the two
situations...(1 process, 2 process-no register)...and checked the
differences....

Anyway...since all input signals "should be sinchronous" to the rais
front
of the clock and the produced output MUST be synch I think that the best
way to achieve that is registering output and evaluating input on clock
raise...my previous implementation was wrong because output is allowed to
change asynchronously...I have to correct...and I think that 1 process
style fit better the requirements...

If in some cases I will need to unreg output I will use concurrent
statements outside of the process as pointed out in the discussion...

Thanx to everyone who helped me...
Carlo
Click to expand...
Something that no-one seems to have brought up (sorry if I missed it) i
whether you are trying to implement a Mealy FSM or a Moore FSM. What yo
are doing will infer a Mealy FSM, but I suspect that you don't know why yo
are using that version. Reading up on the difference should be helpful
there is a lot of stuff available on the Interwebs that any decent searc
engine will find.

For high-speed stuff, I usually go for a Moore FSM, but with registere
outputs via a slightly subtle variation.


---------------------------------------
Posted through http://www.FPGARelated.com
 
Something that no-one seems to have brought up (sorry if I missed it) is
whether you are trying to implement a Mealy FSM or a Moore FSM. What you
are doing will infer a Mealy FSM, but I suspect that you don't know wh
you
are using that version. Reading up on the difference should be helpful -
there is a lot of stuff available on the Interwebs that any decent search
engine will find.

For high-speed stuff, I usually go for a Moore FSM, but with registered
outputs via a slightly subtle variation.


---------------------------------------
Posted through http://www.FPGARelated.com
Click to expand...
Hi,
Yes...it was a Mealy FSM...the output depends on state an
input...otherwise you can add more states and move to Moore...but...whe
you register the output are you already going toward Moore or not???
think that are similar...

It could be interesting to have more info on the the high-speed stuff...

Thanx
Carlo

---------------------------------------
Posted through http://www.FPGARelated.com
 
On Dec 6, 6:02=A0am, "carlob"
carlo.beccia@n_o_s_p_a_m.n_o_s_p_a_m.libero.it> wrote:
Something that no-one seems to have brought up (sorry if I missed it
is
whether you are trying to implement a Mealy FSM or a Moore FSM. Wha
you
are doing will infer a Mealy FSM, but I suspect that you don't kno
why
you
are using that version. Reading up on the difference should be helpfu
-
there is a lot of stuff available on the Interwebs that any decen
searc=
h
engine will find.

For high-speed stuff, I usually go for a Moore FSM, but wit
registered
outputs via a slightly subtle variation.

--------------------------------------- =A0 =A0 =A0 =A0 =A0 =A0
Posted throughhttp://www.FPGARelated.com

Hi,
Yes...it was a Mealy FSM...the output depends on state and
input...otherwise you can add more states and move t
Moore...but...when
you register the output are you already going toward Moore or not??? I
think that are similar...

It could be interesting to have more info on the the high-spee
stuff...

The Mealy vs Moore doesn't have to do with registering the outputs.
That is just an issue of delays since registering the inputs and/or
the outputs delays the outputs. The real difference is that the
outputs become a sort of separate state machine on their own although
the output values don't feed back to affect either the machine state
or the output state. But the outputs are an independent function of
the inputs and the outputs. The outputs can change value with input
changes without the state changing. The outputs can have a different
value for the same state depending on how you reached that state.
Click to expand...
Strictly speaking you are right... :))

I used to design FSMs considering the issues of Mealy vs Moore, but
now I just design FSMs based on what I need and don't even bother with
the M v. M distinction. The bottom line is there are many variations
on the theme, so why bother with just these two?

Rick
Click to expand...
Yes...in effect...you are right....I usually don't pay attention t
Moore/Mealy too....

Carlo


---------------------------------------
Posted through http://www.FPGARelated.com
 
On Dec 6, 5:20 am, "RCIngham"
<robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
Anyway...probably I was wrong...I don't need to avoid registered output
(and a lot of you were right)...in fact I'm always assigning the
"output"
of a FF...therefore I'm sure that when fsm reach a state the output will
change to the value that is required on that state on the same clock
front
and I don't have to wait for another clock front to have that value on
output...
This is not completely true...state change immediately if change
condition
is met...output is still at values on previous state...on the next clock
front the output goes to the new state value...this is the effect of the
output FF...I'm sorry a misunderstanding....

..the difference is now clear....I've just simulated the two
situations...(1 process, 2 process-no register)...and checked the
differences....

Anyway...since all input signals "should be sinchronous" to the raise
front
of the clock and the produced output MUST be synch I think that the best
way to achieve that is registering output and evaluating input on clock
raise...my previous implementation was wrong because output is allowed to
change asynchronously...I have to correct...and I think that 1 process
style fit better the requirements...

If in some cases I will need to unreg output I will use concurrent
statements outside of the process as pointed out in the discussion...

Thanx to everyone who helped me...
Carlo  

Something that no-one seems to have brought up (sorry if I missed it) is
whether you are trying to implement a Mealy FSM or a Moore FSM. What you
are doing will infer a Mealy FSM, but I suspect that you don't know why you
are using that version. Reading up on the difference should be helpful -
there is a lot of stuff available on the Interwebs that any decent search
engine will find.

For high-speed stuff, I usually go for a Moore FSM, but with registered
outputs via a slightly subtle variation.
Click to expand...
That's why I never bother to use these definitions anymore. I never
code either machine type really. I design FSMs to suit my situation.
These two machine types were created to facilitate the mathematical
analysis of FSMs and I find using these terms adds little to analyzing
my design.

Just my two cents...

Rick
 
On Dec 6, 6:02 am, "carlob"
<carlo.beccia@n_o_s_p_a_m.n_o_s_p_a_m.libero.it> wrote:
Something that no-one seems to have brought up (sorry if I missed it) is
whether you are trying to implement a Mealy FSM or a Moore FSM. What you
are doing will infer a Mealy FSM, but I suspect that you don't know why
you
are using that version. Reading up on the difference should be helpful -
there is a lot of stuff available on the Interwebs that any decent search
engine will find.

For high-speed stuff, I usually go for a Moore FSM, but with registered
outputs via a slightly subtle variation.

---------------------------------------            
Posted throughhttp://www.FPGARelated.com

Hi,
Yes...it was a Mealy FSM...the output depends on state and
input...otherwise you can add more states and move to Moore...but...when
you register the output are you already going toward Moore or not??? I
think that are similar...

It could be interesting to have more info on the the high-speed stuff...
Click to expand...
The Mealy vs Moore doesn't have to do with registering the outputs.
That is just an issue of delays since registering the inputs and/or
the outputs delays the outputs. The real difference is that the
outputs become a sort of separate state machine on their own although
the output values don't feed back to affect either the machine state
or the output state. But the outputs are an independent function of
the inputs and the outputs. The outputs can change value with input
changes without the state changing. The outputs can have a different
value for the same state depending on how you reached that state.

I used to design FSMs considering the issues of Mealy vs Moore, but
now I just design FSMs based on what I need and don't even bother with
the M v. M distinction. The bottom line is there are many variations
on the theme, so why bother with just these two?

Rick
 
rickman <gnuarm@gmail.com> wrote:
(snip)

The Mealy vs Moore doesn't have to do with registering the outputs.
That is just an issue of delays since registering the inputs and/or
the outputs delays the outputs. The real difference is that the
outputs become a sort of separate state machine on their own although
the output values don't feed back to affect either the machine state
or the output state. But the outputs are an independent function of
the inputs and the outputs. The outputs can change value with input
changes without the state changing. The outputs can have a different
value for the same state depending on how you reached that state.

I used to design FSMs considering the issues of Mealy vs Moore, but
now I just design FSMs based on what I need and don't even bother with
the M v. M distinction. The bottom line is there are many variations
on the theme, so why bother with just these two?
Click to expand...
Many years ago, I was using some system with a state machine compiler.
After doing a design (I believe as part of a tutorial session) I
figured out that my design was somewhere between Mealy and Moore.

Also, I once found a bug in the Altera state machine optimizer,
by designing one in a way that the tools didn't expect. It seems
that the tools wanted a separate verilog case block for state
selection and output generation. I believe that is independent
of the Mealy vs. Moore question, but they are much easier for me
to read with state selection and output selection together.

-- glen
 
I really do not recommend combined clocked processes with
combinatorial paths from in to out. They tend to have many of the
disadvantages of both clocked and combinatorial processes.

What's the difference between adding a flag (v_delay) and adding
another state?

In general, if I'm using an FSM to control the timing of something, I
don't want to also use flags set by the FSM.

Or if I'm using flags to control the timing of something, I don't want
to also use the FSM state itself (especially if the FSM is the one
controlling the flags)

So, you could add a TXD_Delay state to replace the flag:

if (reset='1') then
act_txd_state := TXD_IDLE;
elsif (clk'event and clk ='1')
then


case act_txd_state is


when TXD_IDLE =>
if (txValid = '1') then
act_txd_state := TXD_ACTIVE;
end if;


when TXD_ACTIVE =>
if (txReady = '1') then
act_txd_state := TXD_DELAY;
end if;

when TXD_DELAY =>
act_txd_state := TXD_END;

when TXD_END =>
if (txValid = '0') then
act_txd_state :=
TXD_IDLE;
end if;
end case;


end if;


if (act_txd_state = TXD_ACTIVE) OR act_txd_state =
TXD_DELAY) then
if (dataIn = "00000000") then
tx_data <= "01000000";
else
tx_data <= "11000000";
end if;
elsif (act_txd_state = TXD_END) then
tx_data <= dataIn;
else
tx_data <= "00000000";
end if;


Or you could create a better flag that tells you exactly when to alter
or pass data_in, and not have to bother with decoding the FSM
elsewhere.

This is my favorite method, if the outputs cannot be coded directly in
the case statement for the FSM. It decouples the FSM state
transitions, etc. from the output logic. If you later need to add/
remove/change states (for error handling, etc.), your output logic
need not change.

Note that since the flag is only used in conditional statements, it is
easier to use if it is defined as a boolean. Of course, it could
probably use a more descriptive name too.

if (reset='1') then
act_txd_state := TXD_IDLE;
v_flag := false;
elsif (clk'event and clk ='1')
then


-- v_flag := '0'; -- get rid of this, we don't
want it defaulting back to 0
case act_txd_state is


when TXD_IDLE =>
if (txValid = '1') then
act_txd_state := TXD_ACTIVE;
v_flag := true;
end if;


when TXD_ACTIVE =>
if (txReady = '1') then
act_txd_state := TXD_END;
v_flag := false;
end if;


when TXD_END =>
if (txValid = '0') then
act_txd_state :=
TXD_IDLE;
end if;
end case;


end if;

-- Do you really need tx_data to be "00000000" at the end?

-- I'm going to assume that you really don't care what it is, right?


if v_flag then -- greatly simplified here & decoupled
from FSM design
if (dataIn = "00000000") then
tx_data <= "01000000";
else
tx_data <= "11000000";
end if;
-- elsif (act_txd_state = TXD_END) then
else
tx_data <= dataIn;
-- else
-- tx_data <= "00000000";
end if;


Of course, this last example also would be simple to split into a
separate, clocked process for FSM, and a combinatorial process for the
data path (v_flag would have to be a signal.) Here is a concurrent
assignment statement that would do the trick:

tx_data <= "01000000" when v_flag and data_in = "00000000"
else "11000000" when v_flag
else data_in;

Hope this helps,

Andy
 
I agree with the advice to achieve the "very best performance," but
only if that means "fastest clock speed".

However, that is true for probably < 5% of most FPGA design work (not
necessarily only 2% of FPGA resources). Sure, there are pieces of many
FPGA designs where Fclk rules, but those pieces are usually small
(especially in terms of how difficult it is to describe) compared to
the rest of it.

My point is, don't start worrying about what will fit in a LUT until
you have to worry about Fclk. For the other 98% of your project that
doesn't care, best performance = "easiest implementation to read,
write, verify and maintain". For many organizations, "verify" also
means review/audit by peers, so approaches to design are preferred
that are simple not only for you to understand, but also your
potential reviewers/auditors. Luckily, approaches that are easy for
them to understand are also likely to be easily understood by
potential maintainers, which might even be yourself in another few
weeks/months/years.

Hint: describe the behavior you want, not the implementation you think
you want, at least until the tool tells you it can't come up with an
implementation on its own that meets timing and available resources.
 
On Dec 6, 3:52 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
rickman <gnu...@gmail.com> wrote:

(snip)

The Mealy vs Moore doesn't have to do with registering the outputs.
That is just an issue of delays since registering the inputs and/or
the outputs delays the outputs.  The real difference is that the
outputs become a sort of separate state machine on their own although
the output values don't feed back to affect either the machine state
or the output state.  But the outputs are an independent function of
the inputs and the outputs.  The outputs can change value with input
changes without the state changing.  The outputs can have a different
value for the same state depending on how you reached that state.
I used to design FSMs considering the issues of Mealy vs Moore, but
now I just design FSMs based on what I need and don't even bother with
the M v. M distinction.  The bottom line is there are many variations
on the theme, so why bother with just these two?

Many years ago, I was using some system with a state machine compiler.
After doing a design (I believe as part of a tutorial session) I
figured out that my design was somewhere between Mealy and Moore.

Also, I once found a bug in the Altera state machine optimizer,
by designing one in a way that the tools didn't expect.  It seems
that the tools wanted a separate verilog case block for state
selection and output generation.  I believe that is independent
of the Mealy vs. Moore question, but they are much easier for me
to read with state selection and output selection together.
Click to expand...
I agree. I think most FSMs are done so that the outputs are assigned
in the same conditionals that assign the states. Although technically
this makes it a Mealy machine with the outputs defined on the state
transitions, you could also consider it a Moore machine as long as
there is a mapping between the states and outputs which is independent
of the inputs. I guess that is more of what is meant by Mealy and
Moore structures rather than the implementation.

But like I said, I seldom use any of the FSM theory I learned in
school. Once you get used to designing them you just make them work
without any theoretical thought about it. :)

Rick
 
On Dec 6, 5:20 pm, Andy <jonesa...@comcast.net> wrote:
I really do not recommend combined clocked processes with
combinatorial paths from in to out. They tend to have many of the
disadvantages of both clocked and combinatorial processes.

What's the difference between adding a flag (v_delay) and adding
another state?
Click to expand...
None in reality, except that the flag is to be used as an output and
not just a state variable. The Mealy and Moore machines are inter-
convertible with a direct mapping between them. There is no problem
that one can solve that the other can't. You can always turn a Mealy
machine into a Moore machine by adding states and vice versa.


In general, if I'm using an FSM to control the timing of something, I
don't want to also use flags set by the FSM.
Click to expand...
Unless it makes the problem easier to visualize and understand. If
the problem is to generate an output that is asserted on the
transition of leaving a given state and it can go to a dozen different
states, to make a Moore machine you would need to add an extra dozen
transition states and set the output in each of them rather than just
setting the output on leaving the enabling state.

Rick
 
So, you could add a TXD_Delay state to replace the flag:

if (reset='1') then
act_txd_state := TXD_IDLE;
elsif (clk'event and clk ='1')
then


case act_txd_state is


when TXD_IDLE =
if (txValid = '1') then
act_txd_state := TXD_ACTIVE;
end if;


when TXD_ACTIVE =
if (txReady = '1') then
act_txd_state := TXD_DELAY;
end if;

when TXD_DELAY =
act_txd_state := TXD_END;

when TXD_END =
if (txValid = '0') then
act_txd_state :=
TXD_IDLE;
end if;
end case;


end if;


if (act_txd_state = TXD_ACTIVE) OR act_txd_state =
TXD_DELAY) then
if (dataIn = "00000000") then
tx_data <= "01000000";
else
tx_data <= "11000000";
end if;
elsif (act_txd_state = TXD_END) then
tx_data <= dataIn;
else
tx_data <= "00000000";
end if;
Click to expand...
Yes....this a cleaner solution than a flag...the approach is similar...bu
adding one delay state it is definitely more clear...thanx for advice...

Of course, this last example also would be simple to split into a
separate, clocked process for FSM, and a combinatorial process for the
data path (v_flag would have to be a signal.) Here is a concurrent
assignment statement that would do the trick:

tx_data <= "01000000" when v_flag and data_in = "00000000"
else "11000000" when v_flag
else data_in;

Hope this helps,

Andy
Click to expand...
Yes...better to use concurrent assignment/another combinatoria
process...and much more better to avoid combinatorial input/output pat
inside main fsm...you are right...I didn't like it too...That was only a
example for the discussion...I had to add signals in sensitivity list o
the clocked process...very bad...

I'm moving toward main fsm in one clocked process...registered output...an
in case I need an output unregistered concurrent statements...

Thanx a lot
Carlo

---------------------------------------
Posted through http://www.FPGARelated.com
 
On Dec 6, 5:30 pm, rickman <gnu...@gmail.com> wrote:
On Dec 6, 5:20 pm, Andy <jonesa...@comcast.net> wrote:
In general, if I'm using an FSM to control the timing of something, I
don't want to also use flags set by the FSM.

Unless it makes the problem easier to visualize and understand.  If
the problem is to generate an output that is asserted on the
transition of leaving a given state and it can go to a dozen different
states, to make a Moore machine you would need to add an extra dozen
transition states and set the output in each of them rather than just
setting the output on leaving the enabling state.

Rick
Click to expand...

I think we are in agreement with what you said.

But more than that, I'm trying (apparently not successfully!) to
communicate something else.

What Carlo's design was doing was using FSM states and a flag
generated by the FSM to control the data path. My preference is to use
either, but not both. In other words, either rework (add states if
necessary) the FSM such that a separate flag is not needed (e.g. the
datapath logic only needs to decode the FSM states), or rework the FSM
and flag such that only the flag is needed, and the state need not be
externally decoded to control the data path.

Of the two, I have a significant preference for the latter, since it
allows the FSM to be changed, but so long as it correctly generates
the control flag(s), the data path logic need not change. This concept
is sometimes called "decoupling", and is a very good SW engineering
principle for application to HDL-based HW design. SW concepts like
scope control, data hiding, separation of interface from
impementation, etc. all allow decoupling of one part of the design
from another. The bottom line is this: we want a design that is
relatively immune to small changes in one part rippling unnecessarily
to other parts.

This is not to say that the other method is discouraged either (at
least not completely). If the data path is such that its logic can be
incorporated directly into the FSM (this case is not a good example of
such), then I am all in favor of doing so, rather than simply
generating control flags to communicate with an external process (or
section of code outside the FSM case statement).

Long story short: If the datapath can be reasonably controlled within
the FSM, go ahead and do it there. If not, then have the FSM generate
control flags that are used by separate datapath logic, without the
datapath logic having to decode the FSM states.

Andy
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top