Simulating Verilog, particularly once a design grows beyond anything simple
can be both tricky and frustrating. I’m going to describe the simulation
process that I’ve used during development of the Oldland CPU
project in the hope that it might be useful to others.
It is entirely possible to develop a design in the FPGA tools, but this
doesn’t scale - you’re confined to the lacklustre editor, long compile times
and cryptic error messages in addition to being tied to a vendor flow.
Instead, I’d recommend a flow where development happens outside of the FPGA
tools and then the FPGA is a validation target instead of the main flow.
FPGA tools are generally less friendly than some of the free tools, notably:
- It takes a suprisingly long time to even complain about syntax errors.
- Some of the errors/warnings are detected post-synthesis. This can be
particularly confusing for things like combinational loops once optimizations
have been applied - the loop can include generated nodes that have no clear
origin and aren’t easily mapped to source lines. Verilator is so much
Use multiple simulators
For any moderately complex design, it’s important to use multiple simulations,
typically using one as a golden reference for behaviour and another to develop
the RTL. In the Oldland CPU case, I have a behavioural model of the CPU,
written in C that I use as the golden reference that allows me to quickly
prototype new features and be sure that the design is sensible. When I
implement a new feature, I first make sure that it works in the software
simulation, then I can develop the Verilog, making sure that all simulations
match. The software model can run at high speeds making it practical to run
real software under there, using it to test higher level system tests.
For the Verilog itself, there are two main free options on Linux, Icarus
Verilog and Verilator.
Icarus is a compliant simulator that is event driven and so provides an
accurate model of the circuit and supports the full language including
non-synthesizable constructs, making it useful for certain models. For
example, SDRAM vendor models such as the Micron model I use in the Oldland
project use delays to model the real-world delays and so this simulator can
model board-level delays and give confidence that the design will work on real
hardware. The main downsides to Icarus are that it only supports Verilog and
not SystemVerilog, and that the accuracy of the simulation means that it is
not the fastest.
Verilator takes a different approach, converting Verilog into optimized C++
models that work on a cycle basis, dropping the multiple drive levels and
event triggering. This means that Verilator models can be many times faster
than Icarus models, also capable of running real-world applications.
Verilator also supports elements of SystemVerilog which can be beneficial to a
Where possible it’s best to support every simulation possible and verify them
all against each other. In some cases it can even be possible to run each
simulation in lockstep and verify that they all maintain the same state.
In general, debugging Verilog is harder work than debugging software, but
there are some advantages. Most simulators will support writing trace files
such as vcd or lxt2 which allows you to view the state of any signal in the
design at any time, which is fantastic for post-mortem analysis, but doesn’t
allow for interactivity. Additionally, dumping traces of the entire system
can really slow down the simulation, so consider adding a mechanism to start
tracing on a given command, event or state.
For interactive debugging, build debugging into the design and present it to
the outside world in a consistent way across all simulations. In the Oldland
CPU, this interface is the JTAG debugger, and this gets exported as a TCP
socket. In the software simulation there is a thread that receives events
from the socket and interacts with the model. For the verilog there is a
common debug controller that is present in the Icarus and Verilator
simulations, but also in the FPGA design too. The Icarus simulator uses a
small VPI stub to connect the debug controller to a C library to talk to the
socket, the Verilator model uses direct C calls, and the FPGA uses the Altera
The end result is that the debugger can connect to the C model, either Verilog
simulator or the FPGA itself and load programs, read/write the registers,
memory and any control registers to get the system into a specific state and
Maintaining multiple simulators is the only way to develop quickly and be sure
that you don’t introduce bugs. The most important things that I have learnt
- Never develop in the FPGA tools, treat them as a validation target for
- You must be able to build all simluations in a single command.
- All of your tests should be run with a single command on all simulators
and should take as short a time as possible.
- The framework for running your tests should not be dependent on the
- Use Verilator for linting even if you don’t use it for simulationg, the
errors and warnings are far superior to Icarus and FPGA tools.