Coding Guidelines
What are VHDL Coding Guidelines?
VHDL is used to describe digital hardware, but writing correct VHDL isn’t just about making it “run.”
Good code should be easy to read, easy to reuse, and ready for synthesis — meaning it should work properly when turned into real hardware.
That’s why engineers follow a few simple rules called coding guidelines.
​
Write Code in Modules
​
Always break your big design into small pieces.
Each piece (called an entity) should do one clear job — like a counter, adder, or decoder.
Then you connect these small blocks at the top level.
This makes debugging, testing, and changing the design much easier.
Each entity should be in its own file, and the file name should match the entity name.
​
Use Clear, Meaningful Names
​
Your signal and port names should clearly tell what they do.
Avoid short, confusing names like a1 or temp.
Use names like clk_sys, reset_n, data_in, count_out.
This helps everyone (including future you!) understand the design easily.
If you want, you can follow a pattern like:
-
Input → ends with _i
-
Output → ends with _o
-
Active low → ends with _n
Example: reset_n_i means input reset, active low.
​
Separate Sequential and Combinational Logic
​
When you write code inside processes, keep clocked logic (with rising_edge(clk)) separate from combinational logic (simple if or case without clock).
This makes the design behave correctly and avoids unwanted latches.
Example:
VHDL
Always Use a Reset Signal
​
Every sequential design (with flip-flops) should have a reset.
It sets all registers to known values when the circuit starts.
Use a synchronous reset (inside the clock block) for predictable results.
VHDL
Avoid Latches
​
A latch appears when you forget to assign a signal in all possible conditions.
They are usually unwanted and cause timing issues.
​
Wrong:
VHDL
When sel = '1', y gets a new value (a).
But when sel = '0', y is not assigned anything —
so it must remember its old value.
To “remember” a value, hardware automatically creates a latch —
a small memory element that holds the last output.
That’s why a latch is inferred here.
It’s not a loop, but an unwanted memory.
​
Correct:
VHDL
Why this is bad (in most RTL designs)
​
-
Latches are level-sensitive, not edge-sensitive like flip-flops.
-
They can cause timing issues (race conditions).
-
They are harder to control and verify in synthesis.
-
In FPGA/ASIC design, they are usually unintentional.
Use Rising Edge for Registers
​
All flip-flops should be written using rising_edge(clk) or falling_edge(clk).
Never use delays like after 10 ns inside RTL — they are only for simulation.
​
Good:
VHDL
Bad:
q <= d after 10 ns; -- Only works in simulation, not hardware
Use the Right Libraries
​
For math or arithmetic, always use:
use IEEE.NUMERIC_STD.ALL;
and use unsigned or signed types.
Don’t use the old, non-standard libraries (std_logic_arith, std_logic_unsigned) because they can give wrong synthesis results.
Example:
signal a, b : unsigned(7 downto 0);
signal sum : unsigned(8 downto 0);
sum <= ('0' & a) + ('0' & b);
​
Don’t Use Simulation Delays in RTL
​
Commands like wait for 10 ns; or signal <= value after 5 ns; are only for testbenches.
Never write them inside your actual hardware design, because hardware doesn’t know about “nanoseconds.”
They exist only in simulation.
​
Use Generics to Make Reusable Designs
​
If you want your design to work for different sizes (like 4-bit, 8-bit, or 16-bit), use generics.
It makes your code flexible without rewriting it.
VHDL
Now you can make a 4-bit or 16-bit counter by just changing N.
Write Comments and Document Clearly
​
Good VHDL is easy to read.
Add small comments explaining what each process or signal does.
Also, write a short description at the top of every file:
-- File: counter.vhd
-- Author: <your name>
-- Function: 4-bit up/down counter
-- Date: <date>
​
This makes your project look professional and helps others (and your future self).
​
Test Everything with a Testbench
​
Every VHDL design must have a testbench.
The testbench gives input signals (stimulus), checks outputs, and shows waveforms.
You can write it manually, file-based, or using a BFM style.
Testing is how you make sure your RTL really works.
​
Why These Rules Matter
​
These rules aren’t just for style — they help your design work correctly in both simulation and synthesis.
They make the code easier to reuse, faster to debug, and ready for FPGA or ASIC tools.
If you write clean, modular, and well-commented VHDL, your design will always be reliable.
