So far when presenting Renode we mostly focused on using it as a separate tool that provides a closed simulated universe. This approach has several advantages including ease of deployment, full control over all elements of the simulation, and determinism.

Need for co-simulation

There are, however, situations when providing models for all of the elements of the simulation is either impossible or just impractical. It happens, for example, when developing and prototyping software for new platforms when the hardware is still in the making. Even though creating models of peripherals in Renode is easy, they would have to be updated every time the prototyped hardware is modified. This, in turn, would require additional work and could lead to inconsistencies resulting in errors and even more wasted time.

A common technique in pre-silicon development of software is using FPGAs to implement the logic of the upcoming chip. This is however an expensive, slow and hard to reproduce development platform. Running the entire system (especially for complicated designs) in FPGA has a very long turnaround in terms of synthesis and requires a lot of processing power.

An alternative is to use HDL simulation where the FPGA is replaced by software. Unfortunately, this can be very slow as well so it does not address the turnaround problem.

The solution can be to narrow down the scope of the HDL simulation by reducing it to a subset of the design and co-simulate it with most of the system running in Renode. We have described this approach in more detail in the Co-simulating HDL models in Renode with Verilator blog post.

Combining FPGA with Renode

There are also cases where there is a need for another way: combining the flexibility of Renode with the fidelity of the FPGA, for example when you have a binary blob (so there are no sources of your IP that could be used to generate a simulation) or when you are targeting a complex design that integrates external components (e.g. mechanical parts).

Similarly to how the Verilator-based co-simulation is structured, Renode can share part of the system bus (effectively importing external peripherals) over a network socket using the popular open source EtherBone protocol, allowing to connect any EtherBone-enabled HW/FPGA/simulation software over the network (local or Internet) to the simulation.

Using Renode as the base and attaching single physical IPs to it will allow you to use all the tracing and debugging power of the simulator which makes developing and analyzing driver’s code much easier than on plain HW.

In the following section we will show you how to use this feature in your project!

Using the EtherBone bridge in Renode

Start by creating a "classic" Renode platform by describing it in a repl file (or use an existing one)::

mem: Memory.MappedMemory @ sysbus 0x0
size: 0x00040000

cpu: CPU.VexRiscv @ sysbus

uart: UART.LiteX_UART @ sysbus 0xE0001800
-> cpu@2

This is an example of a minimalistic platform containing a CPU, memory and a UART as a basic I/O device.

Now extend it with an EtherBone bridge peripheral by adding the following lines:

bridge: EtherBoneBridge @ sysbus <0xE0060000, +0xF000>
    port: 1234

And that's it!

When you simulate the platform all read/write operations directed to addresses in the 0xE0060000 - 0xE006EFFF range are automatically translated into EtherBone packets and transmitted over the network.

The receiving end must, of course, also understand the EtherBone protocol in order to be able to communicate with Renode. It translates packets back into the Wishbone transactions and executes them as if they were coming from the local CPU. The response to the operation is then transferred back to Renode the same way.

For this, just include an open source EtherBone Core in your FPGA design. There are also other options, like LiteX server - a software tool that implements the EtherBone protocol and translates it into USB packets (thus avoiding the need of having Ethernet support in the FPGA).

You can use many EtherBoneBridge entries in your platform, thus importing many physical peripherals (possibly running on independent FPGA boards) at the same time.

In the Renode documentation you can find a real life example of using the EtherBone bridge to control the physical LED on Fomu (a Lattice iCE40UP5K-based board that fits in your USB port) via an emulated Zephyr OS running in Renode. We will be showcasing this in a dedicated tutorial with Antmicro and Google during the upcoming RISC‑V Summit in Santa Clara this December.

The power of Renode

No matter whether you want to simulate your setup in a completely isolated environment, co-simulate it with external tools like Verilator or even connect it to physical FPGA boards - Renode is here to help you. Check out other features in the documentation, browse the source code or just contact us if you want to know more.