What FSM should I use ?

I have this large design which eventually has been redesigned from huge
blocks of combinatorial logic, to a rather elegant code with 9 finite state
machines, all talking to each other.

But what kind of state machine is teh best implementation in an FPGA ? I
started out with the common two-process design, that did not work, ISE found
lots of "clock-signals" and suggested that I should buffer them.

I then tried the 3-process design suggested in the ISE manual, but that did
not work either.

Finally, I tried to write the code as one-process FSM designs, as described
in ISE manual, and hurray ! It compiles fine in ISE, it is recognised as
FSM's ! And it work too !


I just wonder, since one- process FSM-coding works, what is the point with
two-process FSM coding ?
One-process coding is more is easier to read, less time-consuming to write,
and is easier to read for others.

Using two-process coding just seems like a waste of time-.

Thor Phersen

Thor Phersen wrote:

> Finally, I tried to write the code as one-process FSM designs, as described
> in ISE manual, and hurray ! It compiles fine in ISE, it is recognised as
> FSM's ! And it work too !

> I just wonder, since one- process FSM-coding works, what is the point with
> two-process FSM coding ?

Tradition.

> One-process coding is more is easier to read, less time-consuming to write,
> and is easier to read for others.
>

You're preaching to the choir

-- Mike Treseler

Mike Treseler

"Mike Treseler" <> wrote in message
news:...
> Thor Phersen wrote:
>
> > Finally, I tried to write the code as one-process FSM designs, as
described
> > in ISE manual, and hurray ! It compiles fine in ISE, it is recognised as
> > FSM's ! And it work too !
>
> > I just wonder, since one- process FSM-coding works, what is the point
with
> > two-process FSM coding ?
>
> Tradition.
>
> > One-process coding is more is easier to read, less time-consuming to
write,
> > and is easier to read for others.
> >
>
> You're preaching to the choir
>
What do you mean by "You're preaching to the choir?" That I am trying to
convert the already converted or something ?

I think one shuld not drag religion into this matter, after all, it's jus a
matter of computer programming. Religious stuff are for the heavy thinks in
life, like bearth an death.
Man skal vise litt respekt for slike ting.

Thor Phersen

Thor Phersen wrote:

> What do you mean by "You're preaching to the choir?" That I am trying to
> convert the already converted or something ?

I mean that I agree with you and that
I expect that several other frequent
posters here probably agree also.

The symbol implies humorous rather than
serious intent.

-- Mike Treseler

Mike Treseler

"Mike Treseler" <> wrote in message
news:...
> Thor Phersen wrote:
>
> > What do you mean by "You're preaching to the choir?" That I am trying
to
> > convert the already converted or something ?
>
> I mean that I agree with you and that
> I expect that several other frequent
> posters here probably agree also.
>
> The symbol implies humorous rather than
> serious intent.
>
My reply was also meant i a humourus way but I am still pussled about
the fact that most text-books promote two or even three process FSM designs,
when the one process design are so obvious much more simple an elegant ? I
just don't get it. Maybe I'm stupid or something.

Thor Phersen

Thor Phersen wrote:

> My reply was also meant i a humourus way but I am still pussled about
> the fact that most text-books promote two or even three process FSM designs,
> when the one process design are so obvious much more simple an elegant ? I
> just don't get it. Maybe I'm stupid or something.

If that's stupid, I'm really stupid because
I use one process per entity.

http://home.comcast.net/~mike_treseler/

Mike Treseler

On Sun, 14 Jan 2007 03:18:26 +0100, "Thor Phersen"
<> wrote:

> I am still pussled about
>the fact that most text-books promote two or even three process FSM designs,
>when the one process design are so obvious much more simple an elegant ? I
>just don't get it. Maybe I'm stupid or something.

No, you get it OK.

It is definitely *not* crazy to add a process to your FSM to describe
combinational decoding of the state, generating output signals that
are a function of the state. In the overwhelming majority of cases,
such combinational logic is rather simple and doesn't cause any
serious trouble with timing closure; and it may be appropriate and
convenient to add it to the state machine. Personally I like to do
it a slightly different way, so that I keep my single process; but
I really believe there is a sensible choice here.

What is truly crazy (in my opinion) is the endless promotion of
true Mealy-style state machine architectures, with a genuine
combinational path from inputs to outputs. That also requires
the FSM to be described as at least two processes; but I can
never recommend it, because of the risks it poses of introducing
combinational feedback paths (what happens when you have
two Mealy FSMs interacting???!!!) and the problems it's likely
to cause with timing closure and timing predictability.

Three-process coding of any FSM is unconditionally insane.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK

http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Jonathan Bromley

"Jonathan Bromley" <> wrote in message
news:...
> On Sun, 14 Jan 2007 03:18:26 +0100, "Thor Phersen"
> <> wrote:
>
> > I am still pussled about
> >the fact that most text-books promote two or even three process FSM
designs,
> >when the one process design are so obvious much more simple an elegant ?
I
> >just don't get it. Maybe I'm stupid or something.
>
> No, you get it OK.
>
> It is definitely *not* crazy to add a process to your FSM to describe
> combinational decoding of the state, generating output signals that
> are a function of the state. In the overwhelming majority of cases,
> such combinational logic is rather simple and doesn't cause any
> serious trouble with timing closure; and it may be appropriate and
> convenient to add it to the state machine. Personally I like to do
> it a slightly different way, so that I keep my single process; but
> I really believe there is a sensible choice here.
>
> What is truly crazy (in my opinion) is the endless promotion of
> true Mealy-style state machine architectures, with a genuine
> combinational path from inputs to outputs. That also requires
> the FSM to be described as at least two processes; but I can
> never recommend it, because of the risks it poses of introducing
> combinational feedback paths (what happens when you have
> two Mealy FSMs interacting???!!!) and the problems it's likely
> to cause with timing closure and timing predictability.
>

In my opinion, mealy state machines are not really state machines at all,
just huge clusters of logic.


> Three-process coding of any FSM is unconditionally insane.

I tend to agree with you on that, but there has to be some reason for Xilinx
to promote three-process FSM designs in the XST- manual ( 7.1)

> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
>
> http://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
>

Thor Phersen

Jonathan Bromley wrote:
>
> What is truly crazy (in my opinion) is the endless promotion of
> true Mealy-style state machine architectures, with a genuine
> combinational path from inputs to outputs. That also requires
> the FSM to be described as at least two processes; but I can
> never recommend it, because of the risks it poses of introducing
> combinational feedback paths (what happens when you have
> two Mealy FSMs interacting???!!!) and the problems it's likely
> to cause with timing closure and timing predictability.

The day the textbooks drop the words "Mealy" and "Moore" from the state
machine chapter is the day we know that true progress has been made.

I'm sure that's the day that the universe will implode.

If I interview a job candidate for an FPGA position and he uses the
words "Mealy" or "Moore," I know right then that he has zero practical
experience.

-a

Andy Peters

"Andy Peters" <> wrote in message
news: ups.com...
>
> The day the textbooks drop the words "Mealy" and "Moore" from the state
> machine chapter is the day we know that true progress has been made.
>
> I'm sure that's the day that the universe will implode.
>
> If I interview a job candidate for an FPGA position and he uses the
> words "Mealy" or "Moore," I know right then that he has zero practical
> experience.

Hmmm. I remember interviewing for a job straight out of college (company
shall remain nameless) and one of the things I was asked was to explain the
difference between the Mealy and Moore models of state machines. This took
me off my guard somewhat.

My answer was along the lines of "I vaguely remember learning about those
three years ago... something about how the outputs are calculated... but
they're functionally equivalent, I remember that. And *real* state machines
don't really look like either of them, do they?"

I got blank looks. I wasn't offered the job. I don't think I would've taken
it anyway.

Since then I have designed an awful lot of real state machines, and the
Mealy/Moore question never came up once.

-Ben-

Ben Jones