Simulation & Testbenches

Here is one of the most important rules in FPGA design: never go straight to hardware. Simulation lets you test your entire circuit on your computer in seconds, catching bugs that would take hours to track down on a real board. A single build-and-program cycle can take 30 to 60 minutes, but a simulation run takes seconds. In FPGA design, you write a testbench, simulate, inspect waveforms, fix problems, and only then build for hardware. This discipline separates working designs from frustrating ones.

Mini Waveform Viewer

Below is a simple AND gate. Set the stimulus for each time step by clicking the input cells, then run the simulation to see if the output matches what you expect:

The Testbench: Your Design’s Best Friend

A testbench is a piece of HDL code that wraps around your design and drives its inputs. It is not part of the final hardware; it exists only in simulation. Think of it as an automated lab bench: it generates clock signals, sets inputs to specific values at specific times, and optionally checks that the outputs are correct.

Every testbench has three jobs:

• Stimulus generation - Create the input patterns your design needs to process. This includes the clock signal, resets, data inputs, and control signals. Good stimulus covers normal operation, boundary conditions, and error cases.
• Design instantiation - Connect your design (the “Device Under Test” or DUT) to the testbench signals. The testbench drives the DUT’s inputs and observes its outputs.
• Output checking - Compare actual outputs against expected values. This can be as simple as printing values to inspect manually, or as rigorous as automated assertions that stop the simulation if something fails.

Waveform viewers are the primary debugging tool in simulation. They display every signal in your design as a horizontal trace plotted against time. The clock is typically at the top as a reference. You can zoom in, place cursors, and inspect the exact value of any signal at any point in time. When something goes wrong, waveforms show you where and when it went wrong, information that is nearly impossible to get from hardware alone.

Self-checking testbenches take this further. Instead of manually staring at waveforms, you write assertions, statements like “at this clock cycle, the output must equal this value.” If an assertion fails, the simulator flags it immediately. Professional FPGA teams write thousands of assertions to catch regressions automatically.

The key insight about simulation is speed. A full FPGA build (synthesis, place and route, bitstream generation) can take 30 minutes or more for a complex design. A simulation run takes seconds. You can iterate dozens of times in simulation while a single hardware build completes. This is why the industry rule exists: if it does not work in simulation, do not bother programming the FPGA.

Why This Matters

Simulation is not optional in FPGA development. It is the primary way you develop and debug. Hardware debugging requires an oscilloscope, logic analyzer, or embedded logic analyzers (like Xilinx ILA), and even then you can only observe a handful of signals. In simulation, you can see every signal in your entire design, step through time one nanosecond at a time, and reproduce any bug instantly.

Professional FPGA engineers spend far more time writing testbenches and running simulations than they spend synthesizing and testing on hardware. Simulation is 100x faster than hardware debugging, and the designs that ship on schedule are the ones that were thoroughly simulated first.