YAML, SystemRDL and RALF: Construct Comparison for Registers

YAML, SystemRDL, and RALF: Construct Comparison for Registers

In the previous edition of our quarterly newsletter, we gave a basic comparison between SystemRDL and IP-XACT. The article focused on the comparison of basic constructs and its implementation using a Lock Register.  In this article, I will give a basic comparison between SystemRDL, RALF and YAML and a brief overview of construct comparison for registers.


What is YAML?

YAML stands for Yet Another Markup Language – is a data serialization language enhancing human readability at the register level.  It consists of minimal syntax and uses a python style indentation for indicating nesting.

It’s useful in the applications for debugging outputs and document headers targeting XML (Communication Applications). Application-based YAML editor lets you describe the modular specification which can be used as an input format for certain type of outputs. YAML offers several configuration options such as special symbols, active line, symmetric pairs, etc.

YAML is fast and concise. It contains vertical ruler which can be removed, consists of simple code completion for existing words, replacing always tab keypress by spaces (default may be set but configurable) and source formatter (can restore or drop comments as well). Enter your YAML in the area which can be input and you can immediately start editing it in a neat web-based or application based YAML editor.

IDesignSpec (as illustrated in Fig 1) takes YAML as an input format, read its configurations and functional specification and generates corresponding output from the specs. The register level information is configured and used as specification content and provides the required document headers for debugging outputs. YAML consists of templates and every template configures the attributes as per the required specifications.

Figure 1: IDesignSpec generated code using YAML as input

 

What is SystemRDL?

SystemRDL descriptions are used as input to software tools to generate circuit logic, test programs, printed documentation, and other register artifacts. It provides support for registers from the specification and uses for model generation and verification purpose in case of maintenance and documentation. Generating all the requirements from a single source ensures their consistency and accuracy.

A description captures the behavior of individual registers, the organization of registers into register files and allocation of addresses to registers. Information about the registers in a circuit design is required throughout its lifetime, from initial architectural specifications to the creation of an HDL description, and post-silicon testing to the deployment of circuits.

The SystemRDL language was specifically designed to describe and implement a wide variety of registers and memories. Using SystemRDL, developers can automatically generate and synchronize the register specification in hardware design, software development, verification, and documentation.

A variety of register behaviors can be described as simple storage elements, storage elements with special read/write behavior (e.g. ‘write 1 to clear’), interrupts, and counters.

The description of registers is necessary to have accuracy and consistency, so the registers specified by the architects and the registers programmed by the users for the final product are the same. SystemRDL is intended for RTL generation, RTL Verification, SystemC generation, documentation, passing through the material for other tools (debuggers), software development.

igure 2: System RDL generated code

 

What is RALF?

The VMM from Synopsys was released in 2005 and is currently based on the IEEE 1800 SystemVerilog standard. It offers a methodology for the development of powerful transaction-level, constraint-random verification environments and includes a library of classes and applications to provide higher level functions for improved productivity. One such application is Register Abstraction Layer (RAL) which defines blocks, registers, bit fields and addresses in a format called RALF. RALF can be used to create VMM architecture.

RALF is a register abstraction layer format which can be used to represent the RAL model in a text format.

The evolution of this methodology promises to be interesting as the support for other languages such as SystemC or ‘e’ comes on board as well as the maturing of various applications. The focus on the HW/SW interface verification could not have come at a better time.

RAL is used to model the registers and memories present in the design. UVM comes with a register package which is used to model these registers and memories. With its numerous advantages, there are also some disadvantages. The UVM RAL model is good for small testbenches but when one moves to large system level testbench which contains thousands of registers, it impacts the performance and adds significant load to the simulator designs. Download our whitepaper on –  In pursuit of faster register abstract layer.

The example illustrated below is used for formatting of register abstraction layer:

                                                     

Figure 3: RALF can be used to create a VMM infrastructure

  

Comparison

Using these three industry standard methodologies, registers can be described in textual format. Table 1 and 2 illustrate the comparison of basic constructs and external registers available in SystemRDL, YAML and RALF.

Table 1: Comparison of Basic Constructs

SystemRDLYAMLRALF
addrmaptype: blockblock
<block name>

 

<block_instance> @ offset

node

 

     offset: <Offset_Value>

<block name>

 

<block_instance> @ offset

externalproperty

 

      name: external

      value: true

memory
regwidthsize: <size_digit>bytes
regfiletype: sectionregfile
<regroup_name>

 

<regroup_instance>@ offset

node

 

     offset: <Offset_Value>

<regroup_name>

 

<regroup_instance>@ offset

regtype: regregister
reg <reg_name>type: reg

 

name: <reg_name>

register <register_name>
<reg_name>

 

<reg_instance>@ offset

node

 

     offset: <Offset_Value>

register

 

<register_instance>@ offset

hw = wo/rwhw_access: wo/rwaccess wo/rw
defaultdefaultVal:reset
descdoc:none
fieldfield:

 

     name: <field_name>

field
[Lsb]field:

 

     offset:

bits
[Msb : Lsb]field:

 

     offset:

bits
sw = wo/rwsw_access: wo/rwaccess wo/rw
[<repeat_value>]property

 

      name: count

      value: <count_value>

[<repeat_value>]
User Defined Propertiesproperty

 

      name:

      value:

None
Documentation ArtifactsNoneNone

Table 2: Comparison of Implementation of External Register

SystemRDLYAMLRALF
Property map_type { type=string; component=addrmap|reg;};  

 

    

addrmap Mem_Block {

 name = “block_name Address Map”;   

 reg SSHD {

    map_type = “mem”;

    regwidth = 32;

   field {

     hw = rw;

     sw = r;

   } SSHD[31:0] = 32’h0;

 };

 external SSHD SSHD[50] @0x00 +=0x4;

};

node:

 

           type: block

           name: Mem_Block

           offset:

           doc:

           node:

           –

                 type: section

                 name: SSHD

                 doc:

                 property:

                 –

                       name: depth

                       value: 50

                 –

                       name: external

                       value: true

                 –

                       name: type

                       value: mem

                 node:

                 –

                       type: reg

                       name: SSHD

                       offset:

                       doc:

                       property:

                       –

                             name: type

                             value: mem

                       field:

                       –

                             name: SSHD

                             offset: 31:0

                             defaultVal: 0

                             sw_access: ro

                             hw_access: rw

                             doc:

block Mem_Block  {

 

   bytes 4;

   

   memory SSHD  @’h0 {

      bits 32;

      

      access ro;

      size 200;       

      

   }

       

 }

Conclusion

IDesignSpec supports SystemRDL, YAML and RALF. It can take SystemRDL, YAML, and RALF as an input format and automatically generate various outputs from it such as RTL, UVM Register Model, C Headers, HTML and PDF Documentation. IDesignSpec can also generate SystemRDL, YAML, and RALF as outputs from various types of inputs for register specification. This article showed a comparison between SystemRDL, YAML and RALF for register descriptions.

Sequence Generation with ISequenceSpec and Cadence® Perspec™

With increasing complexity, there is a need to standardize the test intent and behavior of the design. Designers create the hardware design with certain functionality, configuration or sequence in mind. Verification engineers read and decode the spec and write SV/UVM sequences. Firmware engineers repeat the same step but this time in his/her own environment typically in C/C++. In short, the same sequence of functionality is repeated several times by different teams. On the other hand, A PCIe expert writing sequences for simulation may not be familiar in writing the same sequence for emulation or prototyping.

The Portable Test and Stimulus Standard (PSS) defines a specification for creating a single representation of stimulus and test scenarios. This can be used with different configurations across various levels of integration which enable the generation of different implementation scenarios. And these can run on various execution platforms like verification, emulation, firmware, and post-silicon validation. This helps in automating the test process, thereby reducing the time to generate complex use-case scenario development.  It generates tests, 10x faster than hand coding – from IP to sub-system to SoC level, including hardware-aware software.

ISequenceSpec integrated with Perspec™ uses Portable Test and Stimulus Standard (PSS) laying out a complete flow for SoC level specification from IP-level sequences to a high-level complex design.

  • It helps the design teams to generate a unified test and program sequences in UVM and firmware from the specification.
  • It then uses the register information for importing the standard formats like IP-XACT, SystemRDL, XML.
  • The user can define the test sequences in a simple editor, and then generate a unified test sequence from verification to validation.
  • The test generated serve UVM sequences for simulation and firmware sequences for HW/SW co-simulation and post-silicon validation like Start-up sequence, read-write operation shutdown sequence, low power mode sequence, etc.
  • Users no longer have to write long sequences manually dealing with registers and pin manipulation commands.
  • ISequenceSpec generates sequences for various platforms along with the portable stimulus “exec” blocks which contain all the firmware/SV sequence task/functions mapped with the PSS scenarios written by the test engineer.

Figure 1 – Sequence generation using ISequenceSpec with Cadence® Perspec™

Sequences generated by ISequenceSpec and the “exec blocks” along with test scenarios are realized in the PSS tools like Perspec which are used to generate the high-level test sequences to get the 100% coverage which is possible 10x times faster.  Figure 2 illustrates the integration of the PSS Tool with ISequenceSpec.

Fig 2 – Integration of PSS Tool with ISequenceSpec

Conclusion:

Perspec is useful for SoC high-level test scenario creation; the IP level details are currently handled using “exec blocks” The solution augments PSS tools and includes:

  1. Capturing sequences in a golden spec
  2. Generating implementation-level SV/UVM/C sequences that enable register R/W and pin manipulation commands

We were invited for a presentation at CDN Live 2019, please check the details here. If you’d like a copy of the presentation, send us an email at marcom@agnisys.com.

Scroll to Top