Accellera Unveils PSS 2.0 – Production Ready

I recently had a discussion with Tom Fitzpatrick of Siemens and Faris Khundakjie of Intel on the latest release of the Portable Test and Stimulus Standard (PSS). Faris chairs the PSS working group and Tom is vice-chair. In what follows I synthesize feedback from both, sometimes I call out interesting individual comments. My first obvious question: what distinguishes 2.0 from 1.0? I’m interested in motivation rather than technical details, so we started with the goals of 1.0 and how 2.0 has built on early release.

Evolution of PSS

PSS is a fairly big departure from the most commonly understood platform for IP and SoC test (UVM). UVM is great for many things, but not for software-driven testing, or porting tests between users at different levels of integration and under different configurations. Or even to support constrained random verification in a truly system level sense. Needs that have been vigorously demanded over many years by many verification experts. None of which could be managed comfortably in yet another rev of UVM.

Hence PSS 1.0 was born (and a little later 1.0a). It was a departure from a known environment and didn’t have the benefit of building on established solutions like AVM, OVM and Vera in the way that UVM could. Tom said the PSS first release had more in common with the SystemVerilog first release. Lots of promise but demanding quite a bit of reorientation from users and solution providers. Who, as they developed experience, started asking for a lot of new features. Those are now converging in 2.0, pointing to more maturing of the standard.

New features

Faris mentioned that 2.0 introduces a register model into PSS, to support configuration for example. Now PSS test designs can build tests with register references in a portable fashion. I poked at this a bit more. UVM has register modeling, what makes PSS different here? Faris said that it’s in the abstraction. PSS is careful about having a nimble model of registers and groups which doesn’t need to rest on a full instantiation. Allowing the realization layer to determine how best to handle these, in an emulator for example. Which no doubt can also map into a UVM realization where appropriate. Tricky stuff, this abstraction, but I see his point.

The new release also adds a lot more control over scenarios and how those scenarios are composed. Allowing for timing relationships when you might have power scenarios overlapping with functional and security scenarios. They also added a lot of enhancements around Exec blocks, that critical realization layer between the high-level test description and mapping to UVM, or C or whatever might be the target. These enhancements enable more reusability/portability by allowing users to add more abstract functionality to exec blocks. To help define procedural code in one place, yet still be able target all those different realizations.

Where’s PSS being used?

Another obvious question – how is PSS being used in practice today? Tom said that a very popular use model is in (pre-silicon) bring up testing. As you start pulling the SoC functionality together, there’s need to make sure that everything is at least able to converse. The essentials of system-level communication, even before you boot the OS. Here you can mimic scheduling in your PSS testbench. Subsequently, a great thing about the standard is that you can connect to the OS through API calls. To start to verify the hardware model is working correctly with that level of software. And you can begin randomizing to see what breaks. A pretty compelling application for tools based on the standard.

Ecosystem development

I wrapped up with a question about the supporting ecosystem – libraries, training and so on. First, in 2.0, the standard moved ahead of existing capabilities in tools, so they all probably have some catching up to do and the ecosystem will follow along. Faris sees a lot of opportunity for apps to develop around areas like security and coherency. These exist already but there’s value in seeing PSS-compliant implementations. Similarly, there’s great opportunity for PSS libraries around other standards: CXL, PCIe and so on. Being able to interact with these standards in system-level validation. Tom added that he’s also sure leaders in training are likely to jump on PSS 2.0, once the tools are ready.

Want to know more? Click HERE.

Also Read:

Functional Safety – What and How

An Accellera Update. COVID Accelerates Progress

DVCon 2020 Virtual Follow-Up Conference!