DPI support in Renode for HDL co-simulation with Verilator and Questa

Hardware Description Languages (HDLs), such as Verilog and SystemVerilog, are used to express the behavior of digital electronic circuits for field-programmable gate arrays (FPGAs) and application-specific integrated circuits (ASICs). The HDL source can also be used for high-fidelity, cycle-accurate simulation of your circuits, but at the cost of lower performance compared to functional simulation, which abstracts away much of the complexity.

Cycle-accurate and functional simulators can be used together in a process called co-simulation, which allows HDL designs to be simulated alongside high-level models running in a functional simulator such as Renode. This method allows HDL designs to be verified in the context of larger system models, enabling more accurate testing and debugging of selected parts. There are several ways to connect an HDL model to a functional simulator, Direct Programming Interface (DPI) being a popular one.

Recently, in collaboration with Microchip, we have developed support for DPI to extend Renode’s co-simulation capabilities with industry-standard simulators such as Verilator, Questa or Vivado’s XSIM . This note will give some background and examples on how to use this integration in practice, and for more information you can head to the Renode documentation.

Co-simulating HDL peripherals with Renode

Co-simulation, an integral part of Renode for many years (since release 1.7.1), has opened up many scenarios for FPGA and custom SoC development, including simulating and testing HDL peripherals in larger contexts to more accurately replicate real use cases, providing a “best of both worlds” in terms of performance vs fidelity.

This feature is used for pre-silicon development by teams building ASICs and ASIC blocks, both internally and for our customers, where specific parts of a design undergoing heavy changes can be simulated directly from HDL, while the rest of the system can be functionally simulated with much higher performance. When using FPGA SoCs such as Microchip’s RISC-V based PolarFire SoC to build reprogrammable devices, the user cannot be expected to have the full HDL code for the “SoC part” of the chip, therefore it must be modeled functionally. The “FPGA part”, on the other hand, must be simulated directly from the HDL source to accurately reflect the state of the system at a particular time. Renode’s co-simulation feature is included in Microchip’s SoftConsole IDE to provide a complete development environment for FPGA SoC users, and can be integrated into other IDEs as needed.

So far, Renode’s co-simulation capabilities have been focused on Verilator, using a custom interface developed for this purpose, which we have used to create a number of co-simulation scenarios, including CFU, UART, RAM, and even an Ibex RISC-V CPU.

DPI gives you a more standardized way to communicate with HDL simulators that implement this protocol to co-simulate digital designs and integrate seamlessly into existing workflows. DPI integration in Renode supports buses such as AXI4 (both Subordinate and Manager) and APB3 (both Completer and Requester), allowing you to simulate blocks like DMA controllers.

Connecting HDL peripherals via DPI in Renode

We have prepared a repository that shows you how to run HDL models in Verilator or Questa and connect them to Renode using SystemVerilog Direct Programming Interface (DPI) calls. Once you have built Verilator and downloaded Renode, you can build one of the examples, e.g. axi_ram, using the following command:

mkdir build
cd build
cmake .. -DUSER_RENODE_DIR=../../../renode -DUSER_VERILATOR_DIR=../../../verilator
make

To confirm that the model can communicate with Renode, you can use the Robot Framework test suite, which connects to Verilator or Questa and performs simple operations involving memory:

renode/renode-test samples/axi_ram/tests.robot

Alternatively, you can run any of the examples by manually connecting Renode to an external simulator. First, run a script that creates a new platform with a co-simulated peripheral using:

renode/renode samples/axi_ram/platform.resc

To connect your Renode simulation to an external HDL simulator, you need to get communication parameters from your co-simulated peripheral:

(machine-0) mem ConnectionParameters

Use these parameters when starting the HDL simulator. In the case of Verilator, run:

samples/axi_ram/build/verilated <ReceiverPort> <SenderPort> <Address>

For Questa, use this command instead:

vsim design_optimized -work samples/axi_ram/build/work_questa -do "run -all" -GReceiverPort=<ReceiverPort> -GSenderPort=<SenderPort> -GAddress=\"<Address>\"

Now, you can run mem Connect to establish the connection between Renode and your external RTL simulator.

Automated HDL peripheral testing

Developing a completely open-source workflow allowed us to easily integrate the new features into a CI pipeline that automatically builds and tests the DPI integration against samples of varying complexity on different target OSes, for example Linux on Zynq-7000 with a verilated FastVDMA controller.

You can run this demo from renode-dpi-examples with a pre-built FastVDMA controller executable using a single command:

renode/renode -e start samples/axi_fastvdma_prebuilt/platform.resc

This allows you to verify your HDL model with every commit to quickly find, replicate, and fix bugs in a controlled environment.

Accelerate SoC and FPGA design with Renode

With Renode, you can quickly simulate complex systems and benefit from a repeatable, fully deterministic test environment. With newly improved co-simulation capabilities, you can connect to almost any HDL simulator, accelerate new silicon development, and have full control over the FPGA and ASIC design workflow.

If you are interested in integrating Renode into your existing workflow and building an automated test environment for your HDL models, contact us at contact@antmicro.com.