Semiconductor chip and intellectual property (IP) development is in a constant state of change. For architects, paper specifications have largely been replaced by abstract, executable models. Designers migrated from polygons to gates to register transfer level (RTL) descriptions. Advanced programming languages have almost entirely replaced assembly code for embedded programmers. Verification and validation engineers have seen a dramatic shift from hand-written tests to constrained-random testbenches. The portable stimulus standard (PSS) is the next step in this evolution.

Introduction to PSS

The Accellera Systems Initiative, which has developed many design and verification standards, debuted PSS in 2018. The latest version is PSS 2.1, released in 2022. This relatively new standard tackled two key verification and validation challenges not well addressed by the Universal Verification Methodology (UVM), the prevailing approach for both chip and IP development:

• UVM does not directly support vertical portability from IP block to subsystem to system; most tests must be manually edited to be reused at a different level of the design hierarchy
• UVM is a solution for RTL design simulation only; it does not address tests for the embedded software within a system-on-chip (SoC) device, hardware/software co-verification, emulation, post-silicon validation in the bringup lab, or horizontal portability across these project stages

The goal of PSS was to define an abstract representation of verification (and validation) intent from which tools generate tests for the target level of the design and the target platform. It is really not the stimulus that is portable; it is the portable PSS model that enables generation of stimulus, results checking, and coverage metrics tuned for each target. For example, UVM tests are generated for simulation but not for the bringup lab, where tests are driven entirely by embedded code.

Using PSS in IP and SoC Development

The scope of PSS is broad, potentially providing the ability to generate all the tests needed for verification, pre-silicon validation, and post-silicon validation. As with many aspects of engineering, one way for a smooth migration is to adopt new technologies incrementally. An excellent place to start with PSS is creating models for the addressable registers in the design. Registers are used by system drivers and embedded software to configure the design, control its operation, and gather status or results. They are part of the hardware-software interface (HSI) of every modern design.

PSS 2.1 provides a solution with constructs for defining in an abstract and portable way both registers and the sequences that program them. EDA tools can generate tests specifically for each level of hierarchy and each platform, ensuring that they are all in agreement. This process usually starts at the IP level, where the architects or designers define the registers and then the verification engineers define the sequences and generate standalone tests. Engineers working on higher levels of the design hierarchy can generate appropriate tests at the push of a button.

The PSS approach completely replaces the traditional approach, in which the chip-level verification team struggles to reuse standalone IP tests and the embedded programmers must manually recreate the same sequences and tests in C/C++. It is quite likely that these different sequences will not match entirely, requiring a lot of time to debug issues found during verification and validation. Generating tests with PSS ensures consistency, saves engineering resources, and shrinks the project schedule. These benefits happen not just once, but every time that register or sequence specifications change.

Making PSS Easy to Use

Generating register tests from PSS sequences is just one example of specification automation, an innovative IP and SoC development technology pioneered by the Agnisys IDesignSpec Suite. For more than fifteen years, the tools in this suite have read executable golden specifications and automatically generated a wide variety of files for design, verification, programming, validation, and documentation. This solution now supports PSS for register, memory, and sequence specification, including an intuitive and powerful PSS editor built on the popular Visual Studio (VS) Code platform.

In addition to PSS, the IDesignSpec Suite supports many other input formats such as SystemRDL, IP-XACT, and spreadsheets. It can generate PSS outputs when these other formats are used for the golden specifications. Users can automatically generate both SystemVerilog/UVM and C/C++ tests from PSS models and merge these with tests generated from other input formats. Therefore, there is no need to convert existing register and sequence specifications to PSS manually in order to interact with other PSS-based verification and validation tools.

The suite also generates a Programmer’s Reference Manual (PRM) that provides comprehensive documentation for programmers, developers, and end users seeking a detailed understanding of the IP or SoC design. Users can generate the PRM interactively from within the graphical design interface or via a command line in batch scripts. The PRM includes three very useful views:

• The Register View provides complete information on register and memory data
• The Sequences Tabular View presents detailed information about the sequences 
• The Flowchart View includes a graphical representation illustrating the sequences

 

Conclusion

PSS is an important emerging method for specifying verification intent in an abstract way. Agnisys has added support for the standard alongside many other formats. This allows users to interact with PSS solutions from other vendors and to leverage PSS models provided with design IP. The Agnisys solution goes beyond other PSS-based tools by generating the RTL register design and PRM in addition to the C/C++ code, UVM tests, and testbenches required for verification and validation. This form of specification automation benefits all the teams on any IP or SoC project.