Portable Stimulus Standard, What’s New from Cadence

I’ve been hearing about the Portable Stimulus Standard (PSS) since DAC 2016, so it’s helpful to get an update from EDA vendors on what their involvement level is with this emerging standard and how they see it helping design and verification engineers. Earlier in September I scheduled a conference call with Cadence and spoke with Sharon Rosenberg about the state of PSS at Cadence. What follows is my Q&A session.

Q: EDA has lots of standards, so why do we need something like PSS?

SoC teams need to re-use engineering, and have more automation. Our key role at Cadence is to bridge the gap.

• Reuse aspect
• Solving and automating scenarios, beyond UVM

Q: I thought that UVM was helping verification engineers with reuse?

A reuse approach is the goal of both UVM and PSS standards. Designers build the golden device, place one agent per interface, add a library of sequences, then coordinate multiple VIPs.

What breaks in this approach? It’s likely that the testbench breaks at the SoC/System level. UVM is a great approach to automate the subsystem level tasks, but UVM is not very reusable, because one or more interfaces is broken.

Q: What makes PSS different than UVM?

With PSS we have a modeling approach to define activities from within the system or sub-system, coming from the spec. The spec stays valid independent of platform, languages or abstraction, which is a much more reusable approach. PSS is not describing stimuli, rather actions.

You could use UVM and call UVM sequences, which is just an implementation detail. It’s really about actions, and how they are defined. Realization is secondary. Actions are reusable. Our high level intent is reusable, but low level details are not.

Q: Design abstraction is moving upwards, so is verification abstraction also moving upward?

Yes, the verification abstraction is moving upward to the system level to meet different challenges, not exhaustive test creation at sub-system levels, but rather testing system-level features. PSS coordinates traffic and use cases, something that UVM wasn’t designed for. System level challenges are different because highly parallel execution takes place, so how to coordinate and time between threads?

With PSS we have virtual sequence logic, something that UVM cannot handle.

Q: How does PSS work with UVM then?

PSS complements UVM by adding virtual sequence logic on top of UVM. This combination is valid for embedded SW running on multiple CPU cores. There’s really no definition collision between PSS and UVM. UVM is great for exhaustive testing and HW verification. PSS is instead a SW driven approach.

Q: What is the state of PSS as a standard from Accellera?

For PSS there’s a review version issued and it is open for feedback until October 30, so users can download, review, and send feedback to the committee.

Q: Do I have to learn yet another language syntax for PSS?

With PSS there are two syntax styles, or input formats, DSL (Domain Specific Language) and also a C++ library. They provide exactly the same concepts. For compactness DSL has fewer lines compared to C++. Cadence will support both styles of syntax. Some companies love C++, others DSL. We will support both styles including hybrids.

Our Perspec System Verifier tool accepts PSS syntax, and we introduced Perspec first in 2011 as a product. With Perspec you use concepts of actions from the spec, state machines, data flow and controller flow. You then teach the tool what is legal, and not legal, define the scenario space, and model first your system as a legal scenario space.

Perspec Example

Q: How is PSS going to help my job as a verification engineer?

Parallel execution of tests is complex, so in PSS we teach the tool all of the system rules (what is legal, not legal), then go to scenario creation, shortening debug cycles. With PSS you state what you want, then the tool goes out and finds it. You can ask what kind of UVM sequences can run at the same time, then PSS knows what is legal to run.

Q: Because PSS is new, I have a learning curve, so what’s that process like?

There is a learning curve, you start by describing behaviors, which is actually easier than learning UVM. A test writer without PSS would have to know all of the rules, configurations, accessibility, much knowledge, however now with PSS they just think about activities and use cases instead, so you’re at a high level.

You make goals for the tool with PSS, which is much simpler. In Perspec there’s a GUI which can be used with PSS, so that’s quick to learn. It’s probably weeks to months of a learning curve.

Related blogs:

· See Perspec Running Accellera Portable Stimulus Examples Here and Now!
· How To Create L3 Cache Command Overflow Stress Test in Less Than 2 Days
· How to Model State Machines in the Accellera Portable Stimulus Standard for Low Power SoC Verification

Q: What are some PSS benefits?

You can quickly try all traffic kinds, with multiple parallel activities, show me all legal traffic. Using PSS will improve test thoroughness.

Q: What kind of PSS libraries does Cadence provide?

There are libraries already created for you to start out with like: memories, cores, multiple activities to stress IP, memory virtualization. So not so many lines of code are required to write in PSS. ARM library is available out of the box. Coherency, low power, memory virtualization – all pre-created libraries.

Q: Accellera is standardizing PSS, so what makes Cadence a trusted vendor?

Cadence has offered technology in this area since 2011 (Perspec) and been involved in defining PSS, plus Cadence AEs are well versed in PSS. We’ve also got multiple customer successes.

• Mediatek Deploys Perspec for SoC Verification of Low Power Management
• Qualcomm deploys Perspec across entire Mobile SoC product line
• Renesas Accelerates IoT Design Using the Cadence Perspec System Verifier
• Automated Test Generation to Verify IP Modified for System Level Power Management”