SystemRDL

Contemporary system-on-chip (SoC) designs are essential for all the most demanding electronics applications: artificial intelligence (AI), high-performance computing (HPC), autonomous vehicles, smartphones, and more. Many different architectures, processors, bus protocols, and intellectual property (IP) blocks are available to support these diverse chips. However, one key design component spans all applications: programmable registers, which can be specified using the System Register Description Language (SystemRDL) standard.

Registers Are Everywhere

Registers are one of the basic design elements for all chips, but programmable registers have special importance. Also called architectural/architecturally visible registers and control/status registers (CSRs), they are mapped into the memory space of the system and are accessible from the processors. As such, they define the hardware-software interface (HSI) of the design. Programmers write to and read from the registers using an application programming interface (API).
Operating systems and applications do not usually access the registers directly; this functionality is typically reserved for drivers, interrupt service routines, embedded programs, and other low-level software. This code is responsible for initializing the registers at system start-up, configuring them, programming them to perform intended system operations, and gathering results and status. Registers can be quite complex and hierarchical, with groups, arrays, sub-registers, bit fields, and special attributes such as read-only bits.
Programmable registers are traditionally defined in natural language as part of the overall design specification. Naturally, this leads to misinterpretation, and different interpretations by different stakeholders. Many SoC teams must read this specification and deal with registers: the register-transfer-level (RTL) designers, the verification and validation engineers, the embedded programmers, and the technical writers who produce user documentation. Any inconsistency in interpretation leads to conflicts that must be resolved, delaying the project schedule.

The Role of SystemRDL

Recognizing the need for precise and unambiguous register specification, a group within the SPIRIT Consortium defined the SystemRDL standard for exactly this purpose. SPIRIT is now part of Accellera Systems Initiative, which says that SystemRDL was “designed to increase productivity, quality, and reuse during the design and development of complex digital systems. It can be used to share IP within and between groups, companies, and consortiums.”
There are two main benefits of specifying registers with this standard: a single “golden” source and the ability of electronic design automation (EDA) tools to automatically generate many of the files required for SoC projects. This ensures consistency across all register representations. The register definition changes many times over the course of an IP or SoC project as the design evolves. It is straightforward to update the SystemRDL specification and re-generate all files rather than hand-editing multiple files and producing even more inconsistency.

Request A Product Evaluation

WHICH PRODUCTS WOULD YOU LIKE TO EVALUATE?*

Agnisys.com needs the contact information you provide to us to contact you about our products and services. You may unsubscribe from these communications at anytime. For information on how to unsubscribe, as well as our privacy practices and commitment to protecting your privacy, check out our Privacy Policy.

SystemRDL Overview

Designers or architects use SystemRDL to describe registers (and memories) along with their properties in a concise format that is readable by both humans and EDA tools. Attributes of each register can include width, fields within the register, and number of bits in each field. There are two forms of register definition: anonymous and definitive. In the latter case, a register can be defined once and then instantiated multiple times within the SystemRDL specification.

Example of an Anonymous Definition

SystemRDL supports hierarchical structures, enabling the specification of complex register maps with nested modules and sub-registers. Users can define register files, which are logical groupings of register and register file instances. They can also define address component maps, where each addrmap contains registers, register files, memories, or other address maps, all assigned to a virtual or final address. As noted earlier, programmable registers must be mapped into memory for software to access them.
All the attributes of a component can be parameterized so that the value can be changed by parameter overriding for each instantiation. This is useful, for example, in defining similar registers with different bit widths. SystemRDL includes constructs that define properties such as constraints for formal verification. The standard also provides the ability to add comments and other information to the register descriptions, making it easier for designers to understand the intended functionality and enabling generation of high-quality documentation.

Agnisys SystemRDL Compiler

The Agnisys IDesignSpec™ Suite of specification automation solutions supports many standard languages and formats, including SystemRDL. The Agnisys SystemRDL Compiler reads in specifications and automatically generates synthesizable RTL register designs, C/C++ code, Universal Verification Methodology (UVM) testbenches and tests, validation testbenches and tests, and documentation. The compiler performs a wide range of semantic and syntax checks, including all the rules outlined in the SystemRDL standard as well as additional unique checks.
SystemRDL Compiler enables the definition of special register types well beyond the baseline of the standard, which defines only alias, counter, and interrupt registers. The SystemRDL Compiler, through User Defined Properties (UDPs), also supports the definition of lock, alternate, trigger-buffer, shadow, indirect, FIFO, read-only/write-only pair, paged, virtual, multi-dimensional, wide, triple module redundancy (TMR), and accumulator registers, and more. 
The Agnisys SystemRDL Compiler supports over 400 UDP properties to customize the generated output files. The generated RTL designs can contain much more than just the registers, including clock-domain-crossing (CDC) logic, block aggregation logic, interfaces to standard buses, low-power design features, security features, and functional safety structures such as parity, error-correcting codes (ECCs), cyclical redundancy checks (CRCs), and sniffers. Features in the generated UVM verification testbenches include coverage, customized class names, and custom code.

Agnisys SystemRDL Editor

In addition to the semantic and syntax checks for SystemRDL specifications, Agnisys offers a specialized text editor to make it much easier to write them efficiently and correctly. Key features include:
  • Essential functions such as copy, paste, select all, and find

  • Automatic indentation for better readability and maintenance

  • Keyword and syntax highlighting to aid in understanding components

  • Intelligent, context-specific SystemRDL property hinting (suggestions)

  • Template hinting and insertion with or without parameters

  • Highlighting of SystemRDL syntax errors.

  • Full support for parameter overriding, dynamic assignment, and stride syntax

  • Code folding so that long and complex code segments can be collapsed or expanded

  • Support for all UDP properties, with usage description and documentation links

Summary

Programmable registers are essential for the configuration and operation of SoC designs. The SystemRDL standard is one way to specify these registers in a clear and unambiguous way. With its SystemRDL Compiler, Agnisys fully supports this standard. The IDesignSpec Suite supports an unparalleled range of special register types and automatically generates all the register-related files required for design, programming, verification, validation, and documentation. This saves an enormous amount of time and resources many times over the course of an IP or SoC project. 

Scroll to Top