Coding style for nested FSM?

[Pleg]

Hi everybody,
in a project I'm working on I have a FSM with 7 states, each one is
implemented as another FSM (5 to 20 states each). Could you please suggest
me a good coding style for such a thing?

Thx,


Pleg

 

[Mike Treseler]

in a project I'm working on I have a FSM with 7 states, each one is
implemented as another FSM (5 to 20 states each). Could you please suggest
me a good coding style for such a thing?

My suggestion is to avoid such a description.
See if you can't simplify it by
adding some counter or shifter objects.

-- Mike Treseler

 

[Pleg]

in a project I'm working on I have a FSM with 7 states, each one is

My suggestion is to avoid such a description.
See if you can't simplify it by
adding some counter or shifter objects.

I'm not sure to understand what you mean. I explain further: the system
takes some data from an ADC, performs some elaboration, creates packets with
the elaborated data and sends them to a PC.
The "general" FSM has a state for initialization, another for reading from
the ADC when the data are ready, another for elaboration, and so on.
Each one of these states is implemented as another FSM, for example for the
elaboration I must call the RAM, take the data, send them to the elaboration
block, wait until it's finished, then give control back to the "general"
FSM. The state after calls the "packet builder" entity, and so on.

I know I'm unexperienced with HDLs and hardware elaboration and probably
what I'm doing is not the best way to solve the problem efficiently... and I
don't even understand fully your answer ^__^; the counter you're talking
about, I can use them to reduce the number of states (actually some of them
are there only to syncronization, and can be removed and replaced with a
counter, I guess that's what you were telling me?), but I don't understand
the "shifter objects".

Thanks for all the help,


Pleg

 

[Mike Treseler]

The "general" FSM has a state for initialization, another for reading from
the ADC when the data are ready, another for elaboration, and so on.
Each one of these states is implemented as another FSM, for example for the
elaboration I must call the RAM, take the data, send them to the elaboration
block, wait until it's finished, then give control back to the "general"
FSM. The state after calls the "packet builder" entity, and so on.

It sounds like you already have something working in your head.
Try it that way and see if sims ok.

I know I'm unexperienced with HDLs and hardware elaboration and probably
what I'm doing is not the best way to solve the problem efficiently... and I
don't even understand fully your answer ^__^; the counter you're talking
about, I can use them to reduce the number of states (actually some of them
are there only to syncronization, and can be removed and replaced with a
counter, I guess that's what you were telling me?), but I don't understand
the "shifter objects".

I see a counter, shifter, or state machine as
as a set of registers, each with its own initialization
and update procedures. I don't see any fundamental
difference between these "objects", and I
tend to mash them together.

-- Mike Treseler

 

[Ben Jones]

I'm not sure to understand what you mean. I explain further: the system
takes some data from an ADC, performs some elaboration, creates packets
with
the elaborated data and sends them to a PC.
The "general" FSM has a state for initialization, another for reading from
the ADC when the data are ready, another for elaboration, and so on.
Each one of these states is implemented as another FSM, for example for
the
elaboration I must call the RAM, take the data, send them to the
elaboration
block, wait until it's finished, then give control back to the "general"
FSM. The state after calls the "packet builder" entity, and so on.

Sounds quite complicated. From what you're saying, it seems that you have
some hardware that reads the ADC data, some hardware that does this
elaboration, some hardware that builds packets, some hardware that transmits
packet data, and maybe some other hardware as well. Furthermore, it seems
like these hardware blocks spend most of their time idle, waiting for your
"master" state machine to select them and instruct them to do their work.

This is all fine, but it may be very inefficient to have all that hardware
sat around waiting for something to do. There are two ways to improve
efficiency:

(1) A pipelined design. Elminates the master state machine, and chain up the
data processing elements so that they pass their data on to the next block
whenever it's ready. This will give you the highest performance (but the
biggest circuit).

(2) A resource-shared design. Instead of having several custom bits of
hardware with a specific task, combine them into one bit of hardware and a
slightly more complicated state machine to co-ordinate the data processing.
(Taken to the extreme, this just becomes a general-purpose processor!) This
will give you the smallest circuit (but the lowest performance).

You ideal solution will probably lie somewhere in the middle, depending on
your size and performance constraints.

Whatever your final design looks like, Mike's advice to get your simulation
working first and foremost is spot on. As for how to write the code for the
various FSMs, I would try to use a single synchronous process with a
clearly-defined section for each state machine's logic; or, if you prefer, a
separate entity for each processing element (so the state machines will each
live in a separate component). In any case, try to communicate between state
machines using registered signals. And, of course, draw a good diagram of
how the sub-blocks communicate with each other, along with lots of comments
in the code!

Good luck,

-Ben-

 

[Ahmed Samieh]

Hi everybody,
in a project I'm working on I have a FSM with 7 states, each one is
implemented as another FSM (5 to 20 states each). Could you please suggest
me a good coding style for such a thing?

Thx,

Pleg

you may re-define the FSMs to one FSM
so insted of :
S0:
S00
S01
S02
S03
S1:
S10
S11:
S110
S111
S112
S12
S2:
S20
S21
S22
S23:
S230
S231
S24
S25
.....
you may od it like:

S000
S010
S020
S030
S100
S110
S111
S112
S120
S200
S210
S220
S230
S231
S240
S250
........

 

[Pleg]

It sounds like you already have something working in your head.

Try it that way and see if sims ok.

Yes actually I've already a first version of the code up and running, and it
works fine. Just my code seems to me very "ugly", inefficient and difficult
to understand and mantain, and I wanted to find a better way to describe my
system.
I see that there's no good way to describe my "nested" FSM, so I'll try some
other approach.

Thanks,


Pleg

 

[Pleg]

[cut]

Thanks for the advice to you both, I'll think about what you said and I hope
to come up with some better (more efficient, readable and mantainable)
logical description.


Pleg

 

[Pleg]

you may re-define the FSMs to one FSM

so insted of :

[cut]

I thought about it but I think it makes the machine even more difficult to
understand... anyway, maybe I'll give it a try.

Thx!


Pleg