One big state machine or lots of little ones

As I have worked on several hobbyist fpga projects I have often run
into the situation of whether I should use one large state machine or
break things up into several smaller state machines.

On the one hand if I go with one large SM then common things like data
output lines or status bits could be shared. If I go with several
smaller SM's in different processes then data output would need to be
or'ed together since registers can not be shared.

Beyond maybe maintainability issues, is there any reason to choose one
over the other.

I have tended towards the one big state machine, but maybe I should not
be.

 

In my opinion, you'd better not use too large FSM. It will have a lot
of status you need to take care and transfer between them is more
complecated.

Any method you used should make your design clear and easy for
maintenance.

 

[Tommy Thorn]

javaguy11111@gmail.com wrote:

As I have worked on several hobbyist fpga projects I have often run
into the situation of whether I should use one large state machine or
break things up into several smaller state machines.

On the one hand if I go with one large SM then common things like data
output lines or status bits could be shared. If I go with several
smaller SM's in different processes then data output would need to be
or'ed together since registers can not be shared.

Beyond maybe maintainability issues, is there any reason to choose one
over the other.

Good question and I look forward to replies.

My hunch is that there isn't a simple answer other than "try all for
your application and pick the best", but off-hand it would seem the pros
of many small are:
- easier to maintain (as noted)
- easier to distribute and route (possible faster due to more placer
freedom).
- can use fewer memory bits (or more in not careful)

Probably more important is that the chosen SM maps well onto the
available memory primitives on the target FPGA.

Tommy

I have tended towards the one big state machine, but maybe I should not
be.

 

[Robert Finch]

As I have worked on several hobbyist fpga projects I have often run into
the situation of whether I should use one large state machine or break
things up into several smaller state machines.

On the one hand if I go with one large SM then common things like data
output lines or status bits could be shared. If I go with several smaller
SM's in different processes then data output would need to be or'ed
together since registers can not be shared.

Beyond maybe maintainability issues, is there any reason to choose one
over the other.

I have tended towards the one big state machine, but maybe I should not
be.

I've found that by breaking things up into more smaller state machines the
synthesizer seems to be able to do a better job at reducing the size of the
result and improving the timing.


Rob

 

[plugh]

On Sun, 23 Jan 2005 10:26:32 -0800, javaguy11111 wrote:

As I have worked on several hobbyist fpga projects I have often run into
the situation of whether I should use one large state machine or break
things up into several smaller state machines.

On the one hand if I go with one large SM then common things like data
output lines or status bits could be shared. If I go with several smaller
SM's in different processes then data output would need to be or'ed
together since registers can not be shared.

Beyond maybe maintainability issues, is there any reason to choose one
over the other.

I have tended towards the one big state machine, but maybe I should not
be.

I have had several projects that I have completely re-written
from scratch, sometimes more than once. I have always ended up
with more, smaller state machines in the re-writes. I find that
I end up with more functional, flexible, and robust designs. I
like to be able to hold the entire state machine in my mind so
I can *know* that it's correct.

Of course, after doing a project once, you have a much better
idea of where the boundaries of the state machines logically
lie - that's not necessarily obvious the first time through.

Regards,

plugh