A History of PSS

In a remark attributed to Otto von Bismarck (or perhaps misattributed), it is said that:

Laws, like sausages, cease to inspire respect in proportion as we know how they are made 

I think that we can add EDA standards to that list. This post gives a potted history of how the Portable Stimulus Standard (PSS) came about. Accellera formally approved the PSS earlier this week.

Ancient History

From the Cadence point of view, the germ of an idea that led to the Perspec product, and indirectly to PSS, started back in 2009. We had a customer who was facing serious issues trying to push the Specman e language up to a higher level, a true system level. They were having problems capturing everything in the form of constraints. The constructs of hardware-verification languages, such as SystemVerilog and e, are very much tuned for modeling data rules, such as hardware protocols, with a view to eventually generating “stimulus vectors”. But at the system level, a lot of verification is more about interactions between different behaviors and contention over shared resources. There are lots of ways that the system can be out of balance in an undesirable way, such as too much traffic on a bus leading to starvation, or a memory cache being too small. Although on a chip, everything can be reduced to vectors, these problems are not really easy to express that way.

The first idea to address this was to extend the "e" language with a couple of major enhancements making it easier to express sequences, but the customer's response to this was, "No, that's still not it." It turned out that we had a summit with another major customer soon after. On this opportunity we presented for the first time a whole new approach, now building on concepts of behavioral modeling.

In 2010, Cadence started to develop a prototype of these ideas that would eventually go on to become Perspec, and later still morph into what is now Accellera's Portable Stimulus Standard. The basic building blocks are not vectors, not even constrained vectors, but rather actions and how they may interact and contend for resources. As usual, the details of implementation are not as simple as the ideal model first appears. Tests are not just required for the hardware, but also for software on, perhaps, multiple processors. These are very varied and it is a big challenge to take a simple concept (for example, take a photo with the smartphone and store it), and what hardware and software needs to be exercised and validated. However, that is just one little world of its own. Another world might be making a phone call. This uses the same compute resources, buses, and memories as the photo. So the next level of complexity is to look at doing these two things simultaneously: taking a photo while making a phone call. Another layer is to look at how just these two actions might interact differently depending on timing, delaying the photo by a few milliseconds so that, for example, the data for the photo has to be transferred at the same moment as data is received on the phone channel (as opposed to comfort noise, or transmitting data on the phone channel).

Standardization

It turned out that there were three companies working around related problems with their own proprietary solutions: Cadence's Perspec, Breker's Trek Suite, and Mentor's InFact. They all had somewhat different models of the world and a different approach. Each tool had its own form of user input, but all three tools featured a graphical presentation of test scenarios. There were also some major customers in the background, meaning that everyone was being driven in several different directions at once. It was not, to put it mildly, the best starting point for standardization. When all the contributors to a standard are poorly aligned, the process tends to degenerate into everyone trying to pull the standard in their direction, since that is the least disruptive to the engineering organization and the customers already using the early products.

The starting point has been summarized to me as follows. Cadence and Breker were targeting a similar application domain, and shared to a large extent the understanding of the problem, but the approaches we took were very different. Mentor focused more on a different application domain, perhaps closer to where we had started, strengthening sequences within traditional hardware verification languages and testbenches. Interestingly, Mentor’s InFact and Cadence’s Perspec were more aligned on some of the fundamental features of the solution.

In 2014, the pre-working group was formed. Many people thought it was too early, since it was still very early days for these technologies, and there was no visibility on a clear path to convergence. The fact that it took so many years is an indication that it really was too early to start. But a working group was formed, and a call for contributions went out in August 2015. Until that point, the work had focused on nailing down the scope and criteria for contributions.

Since both Cadence and Mentor are large, it seemed unlikely that they would be the two companies in the working group who would collaborate most closely, but that is what happened. In the end, Mentor and Cadence produced a joint submission, and Breker produced their own submission. In their contribution, Breker were already using the same terminology of actions, inputs and outputs, and proposing algebraic constraints, similar to the Mentor-Cadence contribution. However, the concepts behind these terms were actually not so much aligned initially, and converging on them was a long process.

In 2016 there was a vote in the working group to go this route: take the Cadence/Mentor contribution as the basis of the constructs and semantics, both in the form of a new domain-specific language, and also in the form of a C++ library. The end-result was very close alignment. This was what eventually formed the basis of the PSS standard.

The choice of the working group to support two input formats initially triggered some concern from the user community—will PSS world split between two different languages? However, as the two formats were truly designed to expose the exact same set of constructs with identical semantics, these concerns are now put to rest. Having both input formats supported by PSS tools should actually bring the best of both worlds to users.

Portable Stimulus Standard

PSS is not just another hardware-verification language and not just a tweak to existing methodologies. It is not UVM-turbo. It is a fundamentally different approach. The seemingly familiar verification constructs, constrained randomization and coverage, are incorporated into a model that naturally describes behaviors, and not just data. The verification content in a PSS model is truly portable, because it is captured at a level of abstraction that is decoupled from the means to realize the tests in different platforms.

The Rest of the Story...

Hello Americans, I'm Paul Harvey. You know what the news is—in a minute, you're going to hear the rest of the story.

As this blog post makes clear, both the creation of Cadence's Perspec and the standardization have taken place over several years. The here is "the rest of the story", some of the blog posts and presentations at DVCon and CDNLive on the topics of Perspec and PSS over the period.

2017

• Mediatek Deploys Perspec for SoC Verification of Low Power Management, blog, July
• Qualcomm deploys Perspec across entire Mobile SoC product line, blog, April
• Renesas Accelerates IoT Design Using the Cadence Perspec System Verifier, news release
• STMicroelectronics: "Automated Test Generation to Verify IP Modified for System Level Power Management", DVCon

2016

• TI: Make Stimuli Portable by Using Perspec System Verifier CDNLive EMEA
• Infineon: Cadence Perspec System Verifier Usage at Sub-System/SoC/Silicon Level for Infineon Aurix Microcontrollers, CDNLive EMEA
• Microsemi: SoC Verification Using Perspec SystemVerifier, CDNLive Silicon Valley

2015

• Samsung: Incremental and Configurable Verification Strategies for Modern SoCs, CDNLive India
• STMicroelectronics, Enabling Verification of Complex System Scenarios Using Perspec System Verifier, CDNLive EMEA
• STMicroelectronics, Automated Test Generation to Verify IP Modified for System-Level Power Management, CDNLive EMEA
• TI: Cadence Perspec System Verifier on a Real SoC Verification of an MSP430 Mixed-Signal-Microcontroller, CDNLive EMEA

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.