Co-simulating with an HDL simulator¶

Renode includes two integration methods for HDL co-simulation, allowing you to connect HDL peripherals with interrupts and external interfaces, like UART Rx/Tx lines:

• DPI-based SystemVerilog method (for simulators supporting DPI like Verilator, Questa or VCS)

• Custom Verilator-only C++ method

Adding co-simulated blocks¶

The Renode side of the integration layer is a plugin called VerilatorPlugin (the name will be revised to reflect the more general nature of its function in the near future), consisting of C# classes, which initiate the communication.

Typically an instance of the VerilatedPeripheral class (to also be renamed to reflect the more general nature of the co-simulation solution, see above) corresponds to an HDL model. To add a co-simulated block to your platform, use the following snippet in your REPL file:

block: Verilated.VerilatedPeripheral @ sysbus <0x20000000, +0x100000>

DPI-based integration method¶

In this case, messages between Renode and an HDL simulator are transmitted over TCP sockets using the standard DPI interface supported in many simulators, including Verilator, VCS or Questa.

As the DPI layer relies on a TCP socket connection, you need to also specify the address parameter for the peripheral:

block: Verilated.VerilatedPeripheral @ sysbus <0x20000000, +0x100000>
    address: "127.0.0.1"

The HDL side uses a SystemVerilog interface which connects directly to your HDL simulation using signals specific to the bus you are simulating.

The HDL simulator has to be running before starting the simulation.

Supported buses¶

• AHB

• APB3

• AXI4

• AXI4-Lite

Examples¶

You can find examples for every supported bus with instructions on building them in the renode-dpi-examples repository. All examples have been tested both with Verilator and Questa.

Custom, direct integration metod (Verilator-only)¶

When using Verilator, you can also compile your HDL simulation as a dynamic library and link it with Renode at runtime, instead of using TCP sockets. Renode can spawn or link a simulation on its own.

To interface your HDL simulation with Renode you need to connect signals of your HDL design with a C++ interface.

Supported buses¶

• APB3

• AXI4

• AXI4-Lite

• Wishbone

• CFU Custom Function Unit interface

Examples¶

You can find many examples of verilated peripheral models such as CFU, UART, RAM, and even a CPU in the renode-verilator-integration repository. For detailed instructions on how to build models from the repository or your own, see Co-simulating your verilated model.

Connecting to verilated models¶

When using Verilator, your HDL models are first translated to C++ (or ‘verilated’) and then compiled.

Renode comes with several .resc files that use HDL models precompiled in this way (we also sometimes call them ‘verilated’ in their compiled form, to explain their origin), like a verilated UART model or verilated Ibex.

The Monitor command used to load the verilated model library depends on your host OS. On Linux, to add a precompiled FastVDMA HDL model to a peripheral named dma, you would run:

dma SimulationFilePathLinux @https://dl.antmicro.com/projects/renode/zynq-fastvdma_libVfastvdma-Linux-x86_64-1246779523.so-s_2057616-93e755f7d67bc4d5ca33cce6c88bbe8ea8b3bd31

You you can use SimulationFilePathLinux, SimulationFilePathMacOS, and SimulationFilePathWindows in the same script if you want to provide different payloads for different OSes, making the script multi-platform. Renode will select the one that matches your host OS.

If you are interested in just a single operating system, you can simply use SimulationFilePath and Renode will interpret it as a model matching your current OS.

By convention, we host two types of precompiled models:

• models prefixed with V use the socket based integration

• models prefixed with libV communicate with Renode via library calls

Most of the built-in scripts use binaries with the libV prefix.