State machines vs. Schematics


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

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


- 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?



Reply to
Thomas Bartzick
Loading thread data ...

Thomas Bartzick wrote

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.

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

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

Reply to
Mike Treseler

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.


Reply to
Andy Peters

Yes, I've done also the same!

Well, that's supporting my own conciderations.

Thank you all!

Best regards,


Reply to
Thomas Bartzick

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.