The Ten Commandments of good VHDL Design

(last edit: 10. December 2024)

Preface

The Ten Commandments of good VHDL Design is ...

The main feature of The Ten Commandments of good VHDL Design is that it embodies much practical wisdom gathered over many VHDL projects. It warns you of the most common language errors, gives clues where to look when your code will not compile, alerts you to synthesis issues, and gives advice on improving your coding style.

Using these Commandments

The Ten Commandments of good VHDL Design


Nbr.	Description

I: Design Before You Code	- Know the structure of what you are designing first.
	- Draw a block diagram of the datapath - Understand the timing (draw diagrams) - Draw bubble-and-arc diagrams for FSMs - Only once you have a design should you start coding in VHDL - VHDL is only a way to ask for component

II: Always Be Synchronous	- One global clock
	- Flip-flops generate inputs to combinational logic, which computes inputs to flip-flops - Exactly one value per signal per clock cycle - Do not generate asynchronous reset signals; only use them if they are external - Edge-triggered flip-flops only. Do not use level-sensitive logic. - Do not generate clock signals. Use combinational logic to create �clock enable� signals on flip-flops.

III: Always Be Sensitive	- In Combinational processes: list all process inputs
	- In Sequential processes: always include the clock. - Include reset if asynchronous, and nothing else.

IV: Assign All Outputs	- Synthesis might infer level-sensitive latches if you do not assign all outputs in all states.

V: Enumerate States	- Better to use an enumeration to encode states: Allows for the tool to decide one-hot/gray coding or other implmentation

VI:	-

VII: Always Avoid Asynchronous	- Only use asynchronous reset when there is one global signal from outside.

VIII: Only One Version	- Never assume signals from the test bench that are not there on the board
	- It is hard enough to make simulation match the design; do not make it any harder - If you must slow down hardware, carefully generate a slower clock and only use that clock globally.

IX: Do Not Test For 'X' Or 'Z'	- It can not be synthesized.

X: Do Not Specify Delays	- The wait statement can delay for a certain amount of time, e.g., 'wait 10ns;'
	- It is good to use in test benches that are not meant to become hardware - Do not use them in the design of your hardware - can not be synthesized.

1. All state machine outputs shall always be registered
2. Thou shalt use registers, never latches
3. Thy state machine inputs, including resets, shall be synchronous
4. Beware fast paths lest they bite thine ankles
5. Minimize skew of thine clocks
6. Cross clock domains with the greatest of caution. Synchronize thy signals!
7. Have no dead states in thy state machines
8. Have no logic with unbroken asynchronous feedback lest the fleas of myriad Test Engineers infest thee
9. All decode logic must be crafted carefully - eschew asynchronicity
10. Trust not thy simulator - it may beguile thee when thy design is junk

If You do not take into account the internal structure of the FPGA you are using, you might end up writing your VHDL in a way that uses the resources in the FPGA in a bad way, e.g. creating slower circuitry or using more resources than nesessary. It might even lead to erronous functions.