11 Myths About the Portable Stimulus Standard

Developing advanced semiconductor chips gets harder all the time, pushing electronic design automation (EDA) vendors to innovate in their tools and methodologies. They’re working constantly to improve capacity and performance while supporting the latest silicon technology nodes. They also seek ways to raise the level of abstraction, such as high-level synthesis (HLS) and the Universal Verification Methodology (UVM).

One of the more dramatic innovations in recent years is the introduction of the Portable Stimulus Standard (PSS) by the Accellera Systems Initiative standards organization. A wide range of chip developers and EDA vendors has contributed to this standard, ensuring that it addresses real-world challenges. Version 1.0 of PSS was released by the Portable Stimulus Working Group (PSWG) in June 2018, and version 3.0 has been available since August 2024.

PSS raises the level of abstraction for both verification and validation of chip designs. It provides a way for developers to specify abstract verification intent, from which EDA tools can automatically generate tests. These tests range “vertically” from IP block to subsystem to full system and “horizontally” from simulation to emulation to silicon. PSS models are portable in that the same model is used to generate tests appropriate for each target platform.

Adnan Hamid of Breker Verification Systems published an excellent “11 Myths” article on the concept of portable stimulus as the standard was being finalized for initial release. A lot has happened since then, with multiple EDA vendors supporting PSS and many chip companies adopting it for leading-edge chip projects. As the standard has evolved, some new myths have emerged. This article discusses these myths and provides evidence to dispel them.

1. UVM users get no benefit from moving to PSS.

This myth has mostly faded away. When PSWG presented tutorials five years ago, many of the questions from the audience challenged why PSS was needed. That’s no longer the case. Most verification engineers now understand that PSS provides a new level of abstraction and portability.

UVM offers very limited vertical portability. Passive monitors can move from IP level to chip level, or vice versa, but stimulus generation and tests must be modified. UVM provides no help at all horizontally when moving from simulation to emulation or the bringup lab where there’s no longer a testbench. PSS isn’t a replacement for UVM; it’s complementary.

2. PSS is a purely academic standard.

PSWG contains no active members from academia, just commercial tool and chip developers. Well before Accellera started the standardization process, several EDA vendors had products that generated tests automatically from verification intent expressed in C++ or a custom language. Every one of these vendors has participated actively in PSWG from the beginning, contributing their expertise and the real-world experiences of their users. The chip developers in PSWG have ensured at every step that the standard is useful for hands-on verification engineers.

3. No real chip developers are using PSS.

There’s no way to assess how many companies have adopted PSS since EDA tool usage is often regarded as proprietary information. However, numerous “success stories” have been published and many users have presented their experiences at industry conferences. Companies that have publicly discussed their PSS usage include AMD, Analog Devices, Broadcom, IBM, Infineon, Intel, Qualcomm, Samsung, and Texas Instruments. This is a very impressive list that should put this myth to rest for good.

4. No EDA vendors are supporting PSS.

This myth is flat-out false. Even a quick search will show that there’s lots of industry support for PSS, including:

• Advantest – leverages PSS for its chip test cards
• Agnisys – supports PSS with a compiler and editor
• AMIQ EDA – supports PSS in its IDE family
• Breker – supports PSS in its test synthesis tools
• Cadence – supports PSS in its system verification solution
• Siemens EDA – supports PSS in its verification solutions
• Synopsys – supports PSS in its portable stimulus solution

5. PSS users must choose between two languages.

It’s true that early versions of the standard specified two input formats, one a domain-specific language (DSL) defined by PSWG and one using C++. Users were never forced to choose; they could mix and match however they wanted. But, as the standard added more capabilities, it became challenging to ensure consistency and interoperability between two languages. With the 3.0 release, only DSL is defined. This myth was never fully true, but now it’s completely false.

6. PSS doesn’t provide coverage.

Prior to the 3.0 release, the standard indeed had very limited coverage constructs. Improving this was high on the list of planned enhancements, and the latest version has rich data coverage, cross coverage, and behavioral coverage capabilities. Verification engineers can ensure that important scenarios and sequences of behavior are exercised.

7. PSS doesn’t provide enough support for registers and memories.

This is another myth that was true for early versions of PSS, but it’s now outdated. Users can describe register groups, registers, their fields, and how they’re organized in a memory map. They can also define address spaces and memory regions, allocate memory blocks randomly while running tests, and define buffers for data transfers between memories.

8. PSS doesn’t support real chips in the bringup lab.

The ability to automatically port tests from simulation to hardware is one of the greatest strengths of portable stimulus. An early case study reported C tests generated by a portable stimulus tool running simultaneously on 144 processors across three chips in the bringup lab at Cavium. While it’s hard to assess what percentage of projects take advantage of hardware portability, the capability has been clearly demonstrated.

9. Everything in PSS must be written from scratch.

Naturally, there’s less shareware and commercial IP available in PSS than for older languages. However, this is changing quickly. Many companies have used PSS on multiple products, with some building internal libraries of reusable components. EDA vendors offer example code as part of their training and support. In addition, PSWG is in the process of defining a methodology library for a future release of PSS.

10. Teams who try PSS once don’t continue using it.

There’s no better way to dispel this myth than this comment from Synopsys: “We see adoption, and for those who have adopted it, they continue with it. I have seen standards where they tried it once, maybe found it interesting, but didn’t use it next time. However, with PSS, once it’s adopted by one person, the team, then other teams begin to adopt. We haven’t seen discontinuation after someone started using it.” Other vendors report similar observations.

11. Nobody is talking about PSS anymore.

This article has cited many case studies and vendor offerings, showing that there’s lots of buzz about PSS online. In addition, PSWG has been invited to present tutorials and workshops at many industry conferences. There’s no shortage of interest, and people are definitely talking about PSS.

Although PSS usage isn’t yet ubiquitous in chip development, its usage is widespread. All major EDA vendors offering verification solutions support PSS, and many of the world’s largest semiconductor companies are using it every day. Anyone still clinging to any of these myths can safely and confidently adopt PSS today to experience its many benefits.