State machines vs. Schematics

[Thomas Bartzick]

Hi,

what's better for a reliable and compact (fpga!)-design:

- To compose the design structure in state machines as much as
possible?

or

- To make strong use of small single components (e.g. FFs, counters,
etc.), for which there can be implemented as library-elements or as
behavioural parts.

Any preferences?

For my own part I admire a structural implemented design with some
FSMs in some special situations (e.g. flow control or like that).
But from another point of view, state machines have much of advantages
because of their strong deterministic behaviour.

What's your opinion concerning this case?
Is there existing a application dependent guide of "good" design?

Regards,

Thomas.

 

[Mike Treseler]

Thomas Bartzick wrote

what's better for a reliable and compact (fpga!)-design:
- To compose the design structure in state machines as much as
possible?

A state machine is a quite limited subset of the
synthesizable descriptions available in the
synchronous vhdl process template. If you
want to try a vhdl description, focus first on learning
the synchronous process.

or
- To make strong use of small single components (e.g. FFs, counters,
etc.), for which there can be implemented as library-elements or as
behavioural parts.

Schematic or netlist design entry might be
reasonable if you don't have time to learn
an HDL.

Is there existing a application dependent guide of "good" design?

A good design has a working functional testbench, meets static timing,
fits in the intended device, and is easy to read and change.

-- Mike Treseler

 

[Andy Peters]

t.bartzick@gmx.net (Thomas Bartzick) wrote in message news:<cdd36e13.0404200619.175f2416@posting.google.com>...

Hi,

what's better for a reliable and compact (fpga!)-design:

- To compose the design structure in state machines as much as
possible?

or

- To make strong use of small single components (e.g. FFs, counters,
etc.), for which there can be implemented as library-elements or as
behavioural parts.

Any preferences?

My preference is for a design that functions reliably and can be
understood by a human six weeks after it was coded.

In other words, neither of your choices.

Some designs lend themselves well to formal state-machine descriptions
(like, say, an SDRAM controller). Others will need a mixture of
things. A DMA controller will usually have some sort of state-machine
control, but will use counters for the addressing mechanisms, and will
have some other glue logic to handle corner cases and such.

I avoid directly instantiating vendor library models as much as
possible, as it makes porting between vendors (and even device
families within a single vendor's portfolio) difficult. If there's
something that I must instantiate, I put it in a module instantiated
by the higher-level code. A generate can be used to select the module
with the library element or a different module with a behavioral
model, or a module with a library element for a different
device/family.

Really, trying to pigeonhole all of your designs into one style of
coding is a bad idea.

-a

 

[Thomas Bartzick]

I avoid directly instantiating vendor library models as much as
possible, as it makes porting between vendors (and even device
families within a single vendor's portfolio) difficult. If there's
something that I must instantiate, I put it in a module instantiated
by the higher-level code. A generate can be used to select the module
with the library element or a different module with a behavioral
model, or a module with a library element for a different
device/family.

Yes, I've done also the same!

Really, trying to pigeonhole all of your designs into one style of
coding is a bad idea.

Well, that's supporting my own conciderations.

Thank you all!

Best regards,

Thomas.