From specifying registers in SystemRDL to implementing the test intent using PSS

The complex SoCs of today typically contain thousands of registers, which are used to control the operations of the SoC/IP. The register specification, which is at the epicenter of a SoC/IP design is accessed by different teams such as hardware, software, verification and embedded design teams, all of which need to access the same source. A mismatch and misinterpretation of the specification simply results in un-necessary delays to the development cycle.

While there are several methods to define the register specification, such as Excel, Word, IP-XACT etc., SystemRDL is gaining popularity, as it is an easy-to-use textual language used for the design and delivery of SoCs/IPs. Released by Accellera, SystemRDL supports the complete project cycle of registers from the specification, model generation, and design verification to maintenance and documentation. It mitigates the problems encountered in describing and managing registers. SystemRDL enables a system architect or a hardware designer to create a functional specification of the hardware-software interface (HSI) for an SoC/IP, which can include addressable registers, interrupts, counters etc. This specification is then used by other members of the team including software, hardware and design verification to create representations of data in the languages they use in their aspect of the SoC development process.

During the verification and validation of the HSI, some of the issues found, require the original register specification to be modified. Changes such as these need to constantly get manifested in all the downstream data, which can be quite cumbersome and error prone process if done manually. In addition to this iterative process during the SoC/IP development cycle, the register specification can also get modified as a result of changes in the marketing requirements, software requirements, or physical implementation of the design.

To avoid the problem of incompatible register data and views between different development teams, SystemRDL coupled with a SystemRDL compiler provide users with a solution to shorten the development cycle and eliminate errors by using a single source of the specification and automatically generating the required data needed by the different teams.

The figure below represents a list of outputs automatically generated by the Agnisys SystemRDL compiler for various teams using a single HSI specification defined using SystemRDL. The SystemRDL compiler from Agnisys provides a number of error checking features to ensure valid code for the development teams. For example, according to the SystemRDL standard, the reset value of fields shall be unknown or, ‘X’ in Verilog/VHDL terms. But if no reset value is given, the field is not being reset, even if it has a ‘resetsignal’ associated with it. But it is critical to have deterministic reset behavior for every register. The same requirement applies to many cases of safety-critical FPGA designs, where a predictable and controllable reset state is highly valuable. So, a mistake to specify a reset value at the level of SystemRDL description would propagate unnoticed to the generated RTL implementations.

In all likelihood, it will be spotted later down the design flow at the level of functional simulation or by RTL linting tools. But the earlier the problem is identified, the less development time is wasted. Spotting this type of mistake visually in an industrial-scale register specification would not be easy even for experienced designers. The SystemRDL compiler from Agnisys prevents these type of mistakes very early in the development flow by displaying appropriate warning messages, which when fixed early in the specification can shorten the development cycle.

The Agnisys SystemRDL compiler also understands many other important design and verification functionalities that can be represented in SystemRDL with the help of UDP (user defined property) but are not a part of standard SystemRDL language and automatically generates outputs such as RTL, UVM, C/C++, SystemC models etc..

Once the register interface is specified, the next step is to create sequences using these registers that can be used for programming the device. These programing sequences define a layer of abstraction (Hardware Abstraction Layer or HAL) for the hardware. The HAL is used to create test stimulus for testing the device.

In a SoC, which typically contains several block level IPs and IP subsystems , each IP could have its own set of sequences that abstract out the hardware functionality. An IP subsystem could use these IP-level sequences and build its own hierarchical sequences. Then at the top, SoC level, there could be sequences built using the subsystem sequences. These hierarchical sequences are analogous to the register level hierarchy (or RTL hierarchy). Block level verification has been made easy by transaction level verification and UVM tests. But it is difficult to leverage block or subsystem-level test scenarios at a SoC and system level, which requires:

• High level tests
• Reuse of test intent
• Portability

To solve the problem about being able to easily verify the design at different levels of abstraction, and reuse existing sequences, portable stimulus is often used. The Portable Stimulus Standard (PSS) is used to avoid duplication of effort by different teams to create the test sequences required for a variety of platforms. This Accellera standard can not only be used to specify the tests that can be used on all platforms like simulation, emulation, prototype, validation, etc. but as of version 1.1 (soon to be released) it can be used to specify the HAL itself. PSS is a single representation of test intent that is reusable across:

• Different levels of integration, like, block-level, subsystem level, etc.
• Different configurations (easily configurable, for example, IP blocks are present or not)
• Variety of execution platforms, like, simulation, emulation, Post-Si prototyping, etc.
• Variety of users

It is important to note that the portable stimulus is not a monolithic representation and replacement for all current testing activities. With this standard, users can specify a set of behavior once from which multiple implementations can be derived. ISequenceSpec from Agnisys enables verification teams to define custom sequences, which can be used to verify and validate the HSI and larger functionality. Defining the sequences in conjunction with the HAL team, enables development teams to have a common set of sequences which are universally used by different teams to verify the SoC/IP. When this is coupled with PSS, it creates a very powerful mechanism to verify the hardware at all levels of abstraction. For more information on the System RDL standard and creating sequences, which can be reused and leveraged by the portable stimulus, attend the workshop on March 5^th, 2020 at DVCON. At DVCON, visit the Agnisys booth (#801) from March 2-5, to see the various products we are showcasing. These include

• IDesignSpec which is used to create the register interface using different formats – textual (IP-XACT, CSV, System RDL, XML, Yaml) or GUI (MS Word, Excel and OpenOffice) and automatically generate the outputs ( RTL – Verilog, VHDL, System Verilog, System C, C headers, HTML, PDF etc.) desired by the development team.
• IDesignSpec NG which is used to specify the register interface across all platforms providing designers with the same user experience and generate the desired output. Verification engineers can use IDS NG to define custom sequences to verify the HIS.
• ARV – Used to automatically generate standard sequences along with a UVM testbench and test plan to validate the HSI by using simulation and formal means. It also generates C sequences for design teams to use the sequences to validate the HSI on software, hardware and silicon platforms.
• ISequenceSpec – Enables verification teams to create complex custom sequences using machine language or pseudo code. These sequences are used as common building blocks for the HAL and hardware verification teams. It can also be used for portable stimulus.
• SoC enterprise – Design assembler, which can be used to stitch the connectivity fabric at IP/SoC levels.
• Specta AV – Automatic UVM testbench generator for SoCs and IPs.

For more information, click here .

This entry was posted on Friday, February 21st, 2020 at 11:38 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.