5
\$\begingroup\$

So I have really been hitting the example code hard this week in an attempt to better understand some HDL design basics, specifically FPGAs with VHDL. The book I am using (if anyone is interested) is "FPGA PROTOTYPING BY VHDL EXAMPLES" by Pong P. Chu.

After a few examples, I am starting to wonder.

How does someone initially design a digital system for HDL?

(Flowchart/Block diagram? Signal list? etc)

For example, I love to use Logisim to flesh out simple digital circuits. The graphical interface is easy to follow and I can get on-the-fly simulations without all the synthesis. But when I am satisfied with my Logisim design, I find it difficult to transfer that design into HDL.

Is there a way to understand how you should structure your HDL design, or does it just come with practice?

\$\endgroup\$
7
\$\begingroup\$

I generally take a top-down design approach, and I start by drawing a block diagram that shows the interfaces among the top-level blocks. I then draw additional diagrams that represent the implementations of the top-level blocks in terms of lower-level blocks.

This hierarchy of block diagrams translates pretty much directly to the hierarchy of the HDL modules. Once I get to a low enough level of detail on the block diagrams, I start coding and stop drawing diagrams.

The block diagrams also function as dataflow diagrams, since they show at every stage how the data flows from one module to another.

When it comes to specific interfaces between modules, I also draw timing diagrams that show the details of the interface protocol. I also use timing diagrams to keep track of the flow of data through the pipeline stages inside a module. In both cases, these diagrams serve as a reference when looking at waveforms in the simulator during verification.

\$\endgroup\$
2
  • \$\begingroup\$ +1 start with a data path, then identify control signals, then design your control logic (i.e. state machines) \$\endgroup\$ – vicatcu Oct 30 '14 at 22:17
  • \$\begingroup\$ Just before start coding the blocks, I try to write down the register map en define all register fields. E.g. STATUS[0]=FIFO_empty, ... It helps me to keep overview on which features still needs to be implemented during the code phase. \$\endgroup\$ – vermaete Oct 31 '14 at 8:28
3
\$\begingroup\$

Books and lectures will tell you that there are two ways: bottom-up and top-down.

In my option, beginners should start top-down, because you know what you want (the system) and you can divide it into modules like Dave described.

If you gathered some experience you will probabily have some kind of a module collection or your design goal is not to build a system but rather a component like a VGA controller. So in this way you can build your component out of your module collection and add some glue logic and some FSMs. To test this component you will also need to write a top-level which employees your component.

So this is a kind of bottom-up design strategy or a mixture of both. I think there is a shift in the design style from top-down to more bottom-up if you gather more experience.

Besides your collection of modules, you will also gather some kind of design patterns and protocols which proofed in the past that they are useful to solve a problem: the usage of a fifo interface to pass datastreams or some kind of a handshaking protocol to couple FSMs.

Students often tend to start coding without any drawings and wounder by VHDL behaves in simulation and/or hardware in a different way. I try to convince them to draw high-level RTL schematics and if need low-level RTLs, too. This has 3 advantages:

  1. you can transform the RTL into code
  2. you won't write unsynthesizeable code
  3. you can check your tool's output against your drawing

Unfortunately schematics and timing diagrams for HDL designs are not so widespread as UML diagrams for complex software systems.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.