FPGARelated.com

HDL Simulation

Category: Verification | Also known as: simulation, simulator

HDL simulation is the execution of a hardware description language (HDL) model -- written in VHDL, Verilog, SystemVerilog, or an HDL-like library such as MyHDL -- in software, so that the logical and timing behavior of a digital design can be observed and verified before synthesizing to an FPGA or ASIC. A simulator applies stimulus from a testbench, evaluates the design's logic, and records signal waveforms or log output for analysis.

In practice

HDL simulation is the primary verification step for RTL designs targeting FPGAs and ASICs. Designers write a testbench that instantiates the design under test (DUT), drives input signals, and checks outputs -- either through manual waveform inspection or automated assertions. Catching bugs in simulation is orders of magnitude cheaper than discovering them after synthesis, place-and-route, or tape-out.

Common open-source simulators include GHDL (VHDL), Icarus Verilog (Verilog/SystemVerilog subset), and Verilator (Verilog/SystemVerilog, compiled to C++). Commercial tools such as Siemens ModelSim/Questa, Cadence Xcelium, and Synopsys VCS offer broader language coverage and better performance on large designs. Cloud-based environments like EDA Playground let developers run simulation in a browser without a local toolchain install -- useful for learning and sharing small examples.

Simulation operates in a discrete-event model: time advances to the next scheduled event, and many events can be processed at the same simulation time. Signal changes are one kind of event that drives this scheduling. Delta cycles -- zero-time steps used to propagate combinational changes -- are a frequent source of confusion for beginners; a signal updated in one delta cycle is not visible to other processes until the next delta, which can produce unexpected behavior if testbenches are not written carefully.

Python-based HDL libraries such as MyHDL support conversion to standard HDL and co-simulation workflows; some testbench scenarios can be driven from a Python interpreter, though waveform generation and HDL execution typically still involve an external simulator or tooling. This can make unit testing and design exploration more accessible without writing a full HDL testbench from scratch. The blog posts "MyHDL @EDAPlayground" and "Using GHDL for interactive simulation under Linux" illustrate practical workflows for getting simulation running quickly on common open-source toolchains.

 Learn this in FPGA Fundamentals

Discussed on FPGARelated

Frequently asked

What is the difference between functional simulation and timing simulation?
Functional (RTL) simulation evaluates the logical behavior of the design without gate delays -- it is fast and runs directly from HDL source. Timing simulation runs after place-and-route and annotates the netlist with actual propagation delays extracted from the physical implementation (typically via an SDF file). Timing simulation is slower, and many teams now rely primarily on static timing analysis (STA) for timing closure rather than running full timing simulation; however, some projects still use timing simulation for signoff on critical paths or specific integration issues.
Does simulation prove a design is correct?
No. Simulation only verifies the specific stimulus applied by the testbench. A design can pass all simulated test cases and still contain bugs triggered by untested corner cases. Formal verification tools (model checkers, equivalence checkers) can provide stronger guarantees for bounded or finite state spaces, but simulation remains the dominant verification method in practice.
What are delta cycles, and why do they matter?
A delta cycle is a zero-time simulation step used to propagate combinational signal changes before advancing the simulation clock. In VHDL simulation semantics, a signal assignment does not take effect instantly -- it is scheduled for the next delta. Verilog and SystemVerilog have their own event queues and scheduling regions, but the general concept is similar: multiple delta cycles may be needed before all concurrent processes reach a stable state. Misunderstanding delta cycles is a common source of testbench bugs, particularly when reading a signal immediately after driving it in the same time step.
Can I simulate HDL without installing a dedicated tool?
Yes. EDA Playground (edaplayground.com) provides browser-based access to several simulators including GHDL, Icarus Verilog, and commercial tools, requiring no local installation. The blog post 'MyHDL @EDAPlayground' demonstrates this for MyHDL-based designs. For Verilog/SystemVerilog, Verilator can also be installed on Linux with standard package managers and compiles designs to fast C++ simulation models.
Is HDL simulation relevant for embedded software developers, or only for hardware designers?
Primarily hardware designers use HDL simulation for RTL verification. However, embedded software developers targeting FPGA-based platforms sometimes use simulation to test driver code against a simulated peripheral model before hardware is available -- a technique sometimes called co-simulation or virtual prototyping. It is also relevant to anyone writing HDL for custom peripherals or SoC designs intended to run embedded firmware.

Differentiators vs similar concepts

HDL simulation is sometimes conflated with emulation and with formal verification. Emulation maps a synthesized design onto an FPGA or dedicated emulation platform (such as Cadence Palladium or Siemens Veloce) to run at much higher speed than software simulation -- useful for booting an OS or running long test sequences that are impractical in a simulator. Formal verification uses mathematical reasoning to prove properties hold for all possible inputs, rather than exercising a finite set of test vectors; it complements simulation but uses fundamentally different tools and methods. Within simulation itself, RTL simulation (pre-synthesis, event-driven) is distinct from gate-level or timing simulation (post-synthesis, includes cell delays), which is a separate workflow that most teams now replace with static timing analysis.