VHDL Process Sensitivity Lists: The #1 Mistake That Causes Simulation-Synthesis Mismatch
If you've ever had a VHDL design that simulates perfectly but behaves completely differently on actual FPGA hardware, there's a good chance your sensitivity list is the culprit.
The Problem
In VHDL, a process block only re-evaluates when a signal in its sensitivity list changes. Miss a signal, and your simulator won't trigger the process when it should — but the synthesis tool will infer the correct hardware anyway, creating a mismatch between what you test and what you deploy.
-- ❌ BUG: Missing 'b' from sensitivity list
process(a)
begin
y <= a AND b;
end process;In simulation, y only updates when a changes. If b changes while a stays constant, y won't reflect it. But the synthesized hardware is just a physical AND gate — it responds to both inputs in real time.
The Fix
Always include every signal that is read inside the process:
-- ✅ CORRECT: Both inputs in sensitivity list
process(a, b)
begin
y <= a AND b;
end process;Or in VHDL-2008, use process(all) to automatically include every read signal:
-- ✅ VHDL-2008: Automatic sensitivity
process(all)
begin
y <= a AND b;
end process;The Rules
Process Type | Sensitivity List Should Contain |
|---|---|
Combinational | Every signal read in the process |
Synchronous (clocked) | Clock signal + async reset (if used) |
Clocked with async reset |
|
Why This Matters for FPGA Development
On an ASIC, a simulation mismatch might get caught in weeks of verification. On an FPGA, you're flashing real hardware — if your testbench passes but the board doesn't work, you've just lost hours debugging a problem that was hiding in plain sight.
Pro tip: Run your synthesis tool's lint warnings. Most modern tools (Vivado, Quartus) will flag incomplete sensitivity lists. Treat those warnings as errors.
This is exactly the kind of foundational detail we cover in depth in Module 1 of our VHDL & Tauri course — where we build correct, synthesizable designs from day one.
