Simulation
Introduction
As always, you can use your standard simulation tools to simulate the VHDL/Verilog generated by SpinalHDL. However, since SpinalHDL 1.0.0, the language integrates an API to write testbenches and test your hardware directly in Scala. This API provides the capabilities to read and write the DUT signals, fork and join simulation processes, sleep and wait until a given condition is reached. Therefore, using SpinalHDL’s simulation API, it is easy to integrate testbenches with the most common Scala unit-test frameworks.
To be able to simulate user-defined components, SpinalHDL uses external HDL simulators as backend. Currently, four simulators are supported:
GHDL (experimental, since SpinalHDL 1.4.1)
Icarus Verilog (experimental, since SpinalHDL 1.4.1)
VCS (experimental, since SpinalHDL 1.7.0)
With external HDL simulators it is possible to directly test the generated HDL sources without increasing the SpinalHDL codebase complexity.
How SpinalHDL simulates the hardware with Verilator backend
Behind the scenes, SpinalHDL generates a Verilog equivalent hardware model of the DUT and then uses Verilator to convert it to a C++ cycle-accurate model.
The C++ model is compiled into a shared object (.so), which is bound to Scala via JNR-FFI.
The native Verilator API is abstracted by providing a simulation multi-threaded API.
Advantages:
Since the Verilator backend uses a compiled C++ simulation model, the simulation speed is fast compared to most of the other commercial and free simulators.
Limitations:
Verilator accepts only synthesizable Verilog/System Verilog code. Therefore special care has to be taken when simulating Verilog blackbox components that may have non-synthesizable statements.
VHDL blackboxes cannot be simulated.
The simulation boot process is slow due to the necessity to compile and link the generated C++ model
How SpinalHDL simulates the hardware with GHDL/Icarus Verilog backend
Depending on the chosen simulator, SpinalHDL generates a Verilog or VHDL hardware model of the DUT.
The HDL model is loaded in the simulator.
The communication between the simulation and the JVM is established through shared memory. The commands are issued to the simulator using VPI.
Advantages:
Both GHDL and Icarus Verilog can accept non-synthesizable HDL code.
The simulation boot process is quite faster compared to Verilator.
Limitations:
GHDL accepts VHDL code only. Therefore only VHDL blackboxes can be used with this simulator.
Icarus Verilog accepts Verilog code only. Therefore only Verilog blackboxes can be used with this simulator.
The simulation speed is around one order of magnitude slower compared to Verilator.
Finally, as the native Verilator API is rather crude, SpinalHDL abstracts over it by providing both single and multi-threaded simulation APIs to help the user construct testbench implementations.
How SpinalHDL simulates the hardware with Synopsys VCS backend
SpinalHDL generates a Verilog/VHDL (depended on your choice) hardware model of the DUT.
The HDL model is loaded in the simulator.
The communication between the simulation and the JVM is established through shared memory. The commands are issued to the simulator using VPI.
Advantages:
Support all language features of SystemVerilog/Verilog/VHDL.
Support encrypted IP.
Support FSDB wave format dump.
High Performance of both compilation and simulation.
Limitations:
Synopsys VCS is a commercial simulation tool. It is close source and not free. You have to own the licenses to legally use it.
Before using VCS as the simulation backend, make sure that you have checked your system environment as VCS environment.
Performance
When a high-performance simulation is required, Verilator should be used as a backend. On a little SoC like Murax, an Intel® Core™ i7-4720HQ is capable of simulating 1.2 million clock cycles per second. However, when the DUT is simple and a maximum of few thousands clock cycles have to be simulated, using GHDL or Icarus Verilog could yield a better result, due to their lower simulation loading overhead.