Process · Verification & Validation
RTL simulation
Execution of a register-transfer-level description with an event-driven simulator to observe cycle-by-cycle behaviour. It is the workhorse of pre-silicon functional verification, fast enough for large regressions but far slower than emulation or silicon.
- Also known as
- Behavioural simulation, Functional simulation
- Type
- Process
- Domain
- Verification & Validation, Simulation
Notes
Typical throughput is tens to a few thousand design clock cycles per wall-clock second depending on design size.
Overview
RTL simulation is the running of a chip's register-transfer level description, written in a language such as SystemVerilog or VHDL, on a software simulator to see how the design behaves before it is built. A testbench drives inputs into the design and checks its outputs, and engineers study the resulting waveforms and logs to find bugs. It is the main tool of pre-silicon functional verification, but it runs far slower than real hardware, so large designs also use emulation and prototyping.
How it works
A simulator compiles the RTL and the testbench together, then advances simulated time, evaluating the design's logic as signals change. Event-driven simulation re-evaluates only the parts of the design whose inputs have changed; cycle-based techniques evaluate the logic once per clock and are generally faster, and most commercial simulators combine both. Open-source tools take other routes: Verilator, for example, translates Verilog or SystemVerilog into a C++ model that is compiled into its own executable.
The testbench does much of the work. In SystemVerilog with UVM it generates constrained random stimulus, drives it into the design, monitors the outputs, compares them against expected behaviour and records code and functional coverage. Assertions in the design flag illegal conditions the moment they occur. Large numbers of tests run on compute farms as regressions, and failures are debugged with waveform viewers and logs.
RTL simulation checks function, not real timing: delays are idealised, and timing is verified separately by static timing analysis. It is also slow for a full SoC, which is why booting an operating system or running long software workloads usually moves to emulation or FPGA prototyping.
Examples
- A UVM testbench sending constrained random traffic into a PCI Express controller, with a scoreboard checking every transaction.
- A nightly regression of block tests on a compute farm using a commercial simulator such as Synopsys VCS.
- Verilator compiling a RISC-V core into a fast C++ model for software-driven tests.
- A waveform debug session tracing a failing assertion back to a FIFO overflow in a bus bridge.
Why it matters
Design and verification engineers run RTL simulation every day, and a project's regression results are one of the main measures of whether the design is ready. Bugs found here are cheap to fix compared with bugs found after tapeout, which can require a new set of masks.
Related terms
- Gate-level simulation
- Emulation
- Event-driven simulation
- Testbench
Part of the Verification & Validation glossary, with every term in the topic and the lifecycles, tools and standards that use them.
Where it appears on the Hub
Used on 14 pages of the Hub. In each group, the pages that mention it most come first.
Lifecycle stages and gates
Tools
Suggest an improvement
Suggest an improvement to this entry
A clearer definition, an example, a correction or a source an editor can check. Editors review every suggestion before the entry changes.
Last reviewed . Written by The Semiconductor Hub editorial team. The full glossary