Simplifying Renode model generation with SystemRDL-to-C# conversion

SystemRDL is a standard from the Accelera initiative used to describe the register layout of hardware in order to provide a single source of truth for hardware and software artifacts. As a single, human-writeable and readable source of truth, SystemRDL provides a basis on which you can build other assets, such as SystemVerilog designs, test suites, software (drivers), and documentation.

SystemRDL files can also be used to prepare the structure of models in Antmicro’s open source Renode simulation framework. Typically, defining models in Renode requires users to extract the register layout themselves, based on technical reference manuals and available drivers. With SystemRDL in place, the process can be automated by generating boilerplates from available Register Description Language (RDL) files, reducing the required work and risk of error. This approach also simplifies the process of prototyping new platform support in Renode, providing a quick starting point for further development. At the same time, for RTL blocks that are being actively developed and do not have a stable interface yet, it’s much easier to utilize SystemRDL to keep all elements in sync instead of rewriting the models, drivers and documentation with every change.

In this article we describe how to simplify Renode model generation using Antmicro’s PeakRDL-Renode plugin. We will also show how to generate RDL descriptions from Renode models with Renode Models Analyzer, and present how we expose this information in our System Designer.

Generating Renode models from SystemRDL

The key components of SystemRDL include address maps, memories, registers, register files, and fields. The example below shows a simple SystemRDL file structure:

addrmap Peripheral {
    regfile {
        // Registers are 32-bit wide by default
        default regwidth = 32;

        reg {
            // Defines a 32-bit register with two 16-bit fields
            name = "Example_Register";
            field {
                name = "FIRST";
                desc = "First 16-bit field";
                // Field is readable and writable by software
                sw = rw;
                // Field is writable by hardware
                hw = w;
                // Write One To Clear: field set to 0 when 1 is written
                onwrite = woclr;
            } first [15:0];
            field {
                name = "SECOND";
                desc = "Second 16-bit field";
                sw = r;
                hw = w;
                // Reading the field automatically clears it
                onread = rclr;
            } second [31:16];
        // Register address offset relative to the register file address
        } example_register @ 0x100;
    // Register file address offset
    } example_register_file @ 0x200;
};

PeakRDL is an open source, Python CLI-based SystemRDL toolchain, offering broad configurability options via custom plugins. To enable generating Renode models from SystemRDL, we created our own plugin called PeakRDL-Renode. The plugin takes the RDL spec and generates a C# stub containing registers with named fields of defined width, with placeholders for callbacks. This boilerplate is a good starting point for implementing the core logic, and can save time otherwise spent on initial laborious work. It’s especially useful for big peripherals, where parsing the available RDL documents to get initial register definitions simplifies the process of creating their Renode models.

The plugin provides a fast way of prototyping support for new platforms, complementing our standard peripheral modeling guide.

Below, you can see a Renode model generated from the example file described above:

Extracting SystemRDL from Renode models

Since SystemRDL can be used to generate Renode models, we decided to enable the opposite scenario as well. To this end, we created the Renode Model Analyzer, allowing us to parse Renode peripheral models and output SystemRDL files describing the register layout of the models.

The tool uses the Roslyn compiler framework for syntactic and semantic analysis of the peripherals’ source code. The results of this analysis can be used to verify their completeness, correctness and compatibility with firmware, as well as report diagnostics, generate automatic reports and compare peripheral models for best fitness. The Renode Model Compare subproject enables converting between different peripheral representations, including generating SystemRDL model descriptions from Renode peripheral data, which can be then further processed, as described in the README.

The example below shows an RDL file generated for the Potato_UART peripheral.

addrmap Potato_UART {

addrmap {
    desc = "Generated by RenodeModelsAnalyzer";
    reg {
        name="TransmitRx";
        regwidth=0x40;
            field {
                desc = "This field has the following custom Renode callbacks: Write.";
                sw = rw;
            } TransmitRx[63:0];
    } TransmitRx @ 0x0;
    reg {
        name="ReceiveRx";
        regwidth=0x40;
            field {
                desc = "This field has the following custom Renode callbacks: Provider.";
                sw = r;
            } ReceiveRx[63:0];
    } ReceiveRx @ 0x8;
    reg {
        name="StatusRx";
        regwidth=0x40;
            field {
                desc = "This field has the following custom Renode callbacks: Provider.";
                sw = rw;
            } ReceiveRxEmpty[0:0];
            field {
                desc = "This field has the following custom Renode callbacks: Provider.";
                sw = rw;
            } TransmitRxEmpty[1:1];
            field {
                desc = "This field has the following custom Renode callbacks: Provider.";
                sw = rw;
            } ReceiveRxFull[2:2];
            field {
                desc = "This field has the following custom Renode callbacks: Provider.";
                sw = rw;
            } TransmitRxFull[3:3];
    } StatusRx @ 0x10;
    reg {
        name="ClockDivider";
        regwidth=0x40;
            field {
                sw = rw;
            } ClkDiv[63:0];
    } ClockDivider @ 0x18;
    reg {
        name="InterruptEnableRx";
        regwidth=0x40;
            field {
                desc = "This field has the following custom Renode callbacks: Provider.";
                sw = rw;
            } Interrupt_Receive[0:0];
            field {
                desc = "This field has the following custom Renode callbacks: Provider.";
                sw = rw;
            } Interrupt_Transmit[1:1];
    } InterruptEnableRx @ 0x20;
} Registers_addrmap;


};

We’ve also made this data available in our System Designer, a comprehensive portal combining Antmicro’s tools and workflows, providing a unified interface for building digital prototypes, from SoCs to complex, multinode systems. For example, if you go to the sifive,gpio0 hardware block, you will see all the available assets, including an RDL file generated from the Renode model, as well as the model itself.

Simplified platform support prototyping in Renode

With the SystemRDL support described in this article, Antmicro provides a streamlined approach to prototyping new platforms in Renode, allowing hardware developers, IP vendors and silicon companies to simplify their hardware design workflows by removing the need to manually ensure the memory map in a Renode model is consistent with their design. As Renode already leverages automatic platform description generation with the dts2repl tool, used heavily in the Zephyr Dashboard and U-Boot Dashboard projects, support for SystemRDL makes the process of enabling new platforms even more streamlined.

If you would like to find out more about Antmicro’s services around the Renode framework or learn how we can help you ensure consistency and interoperability in complex digital designs using unified register interface definitions, reach out to us at contact@antmicro.com.