Co-Developing IP and SoC Bring Up Firmware with PSS

With ever challenging time to market requirements, co-developing IP and firmware is imperative for all system development projects. But that doesn’t make the task any easier. Depending on the complexity of the system being developed, the task gets tougher. For example, different pieces of IP may be the output of various teams distributed geographically. Some pieces of IP may be sourced from third-party IP suppliers. The SoC integration testing not only has to contend with quality and reliability of the IP blocks but also with testing various operating scenarios. And then there is the matter of verification.

Verification of complex SoC designs involves multiple platforms including emulation and FPGA prototyping. Each platform usually requires its own way of specifying the tests. This results in expending a lot of time and effort in recreating the same test information for various platforms for the same project. What if there is a way to describe the verification intent as a single abstract specification? Accellera Systems Initiative (Accellera) developed the Portable Test and Stimulus Standard (PSS) to address this need. Accellera is an independent, not-for-profit organization dedicated to create, support, promote, and advance system-level design, modeling, and verification standards for use by the worldwide electronics industry.

Portable Test and Stimulus Standard

The following is a description from the Accellera website.

“The Portable Test and Stimulus Standard (PSS) defines a specification to create a single representation of stimulus and test scenarios usable by a variety of users across many levels of integration under different configurations. This representation facilitates the generation of diverse implementations of a scenario that run on a variety of execution platforms, including, but not necessarily limited to, simulation, emulation, FPGA prototyping, and post-silicon. With this standard, users can specify a set of behaviors once and observe consistent behavior across multiple implementations.”

Can PSS help with co-developing IP and SoC bring-up firmware? This is the topic of a talk by Matthew Ballance from Siemens EDA at the 2022 DVCon. He presents details of leveraging PSS for co-developing and co-verifying IP and firmware that eases SoC integration testing challenges. Matthew is a senior principal product engineer and portable stimulus technologist. The following is a synopsis of the salient points from his talk.

While it is straightforward to write directed and constrained random UVM sequences to exercise IP behavior, integration tests at the SoC level are more complicated. With many different pieces of IP getting integrated, there are lots of scenarios to exercise and ensuring the interoperability of multiple drivers become a challenge.

Interoperability Framework

While the need for interoperability exists, there is no need to reinvent the wheel for implementing a framework. A real time operating system (RTOS) provides such a framework, having to deal with multiple drivers from different sources. A RTOS is designed to work on very low power with constrained resources too. Matthew uses Zephyr, an open-source RTOS in his presentation. For a typical test configuration, the memory footprint for the Zephyr RTOS image is around 8KB, which is attractive for an SoC verification environment.

Creating Drivers

Creating device drivers in C code calls upon the same knowledge and skills that UVM sequence code writers use with System Verilog. The Zephyr RTOS specifies a format for drivers in the system and defines the data types and structures that fit into the driver framework. This makes it easy to configure the various aspects of the drivers. Zephyr RTOS defines several standard APIs for supporting standard devices such as DMAs or timers but can support custom APIs as well. Refer to Figure below for a sample piece of driver code.

PSS Building Blocks

There are two parts to a PSS model. The first part addresses the test intent and the second part handles the test realization. This structure allows for modeling scenarios in terms of high-level abstractions in the test intent section, reserving the low-level details to the test realization section. This makes it easier for creating multiple tests just like it is done in System Verilog by changing the seed to create new test variants. What is handed off to the SoC team includes not just RTL deliverables but also the PSS code along with driver code. At the SoC level, all IP blocks and firmware are integrated and managed under the Zephyr RTOS framework.

Refer to Figure below for a sample piece of PSS code. The bottom portion of this code segment is a call to the driver code. In this example, it is an action for doing a memory to memory transfer on a DMA channel. The call contains the details of the channel id and spells out the resource that the transfer requires.

Summary

Verification at the SoC level can be performed efficiently using PSS. A key requirement for this, is of course making lower-level driver firmware available to be called via PSS actions. More details about creating device drivers and connecting PSS to the device drivers can be found in a technical paper authored by Matthew. Zephyr RTOS is one way to enable multiple firmware modules to interoperate. There is an expanded list of IP deliverables as a result of co-developing IP and firmware using this approach. In addition to the usual RTL deliverables, driver firmware and reusable PSS code are also handed over to the SoC verification team.

Matthew’s DVCon talk can be accessed here by registering at the DVCon website.

Matthew’s presentation slides can be downloaded here.

Matthew’s technical paper can be downloaded here.

Also read:

Leveraging Virtual Platforms to Shift-Left Software Development and System Verification

Using a GPU to Speed Up PCB Layout Editing

Dynamic Coherence Verification. Innovation in Verification