Pleg said:
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-