FSM single process...BIG question

On Dec 6, 3:52=A0pm, 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. =A0The 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. =A0But the outputs are an independent function of
> > the inputs and the outputs. =A0The outputs can change value with input
> > changes without the state changing. =A0The 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. =A0The 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. =A0It seems
> that the tools wanted a separate verilog case block for state
> selection and output generation. =A0I 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.

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=A0pm, 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?

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.

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

Yes....this a cleaner solution than a flag...the approach is similar...but
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
>

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

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

Thanx a lot
Carlo	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On Dec 6, 5:30=A0pm, rickman <gnu...@gmail.com> wrote:
> On Dec 6, 5:20=A0pm, 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. =A0If
> 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


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