The Portable Stimulus Standard (PSS) is a powerful verification language defined by Accellera, aimed at modeling verification intent. This standardized approach was initially released in June 2018, with the primary objective of porting a testbench from a simulator to an emulator. However, the nomenclature has led to confusion, as it describes its intended application rather than providing a clear definition of its functionality. Consequently, it is commonly referred to as PSS to avoid ambiguity.
Graph-Based Modeling:
At its core, the Portable Stimulus Standard relies on the mathematical concepts of graphs. The graph encompasses atomic actions, each associated with the data it requires or generates. These actions are interconnected by data flows, defining how data is transferred—whether buffered or streamed. The graph allows the composition of actions into more intricate sequences, enabling the definition of both sequential and concurrent actions. Crucially, a usable graph must articulate at least one viable path through the design, and the construction of graphs can be an incremental process.
Two Input Languages:
To facilitate flexibility, the Portable Stimulus Standard offers two input languages. The first is a domain-specific language (DSL) designed to closely resemble existing verification languages such as SystemVerilog. The second employs C++ in conjunction with a runtime library. Notably, both languages define identical semantics. The key distinction is that, unlike SystemVerilog and C++, PSS primarily operates in a declarative manner rather than a procedural one. Importantly, the DSL and C++ components can be seamlessly intermixed, promoting portability between different vendors.
Modeling with PSS:
Even when C++ serves as the input language, the outcome is a model, not an executable. This model, akin to a design description, requires a simulator or synthesis engine to interpret and take action. The synthesis engine, however, is not defined by the standard. The language essentially creates a comprehensive verification model, and a verification synthesis engine reads this model, generating testbenches that can target a variety of abstractions and execution engines.
Path-Based Verification:
A significant departure from preceding verification methodologies lies in the fact that the PSS graph defines complete paths through a design. Unlike traditional synthesis engines that may choose random paths, PSS ensures that these paths always form complete scenarios. Additionally, the graph introduces a notion of coverage, allowing pre-test assessment of whether all defined actions have been involved in verification. This inherent coverage concept is a distinctive feature compared to SystemVerilog and UVM, where separate models for stimulus, checkers, and coverage are employed.
Expected Outcomes and Verification:
In the PSS framework, actions within the graph can articulate their expected outcomes, which are then verified during design execution. This results in a comprehensive verification model where the graph itself encapsulates the entire verification process. This stands in contrast to methodologies like SystemVerilog and UVM, which employ separate models for stimulus, checkers, and coverage.
Synthesis Engine Expectations:
While the Portable Stimulus Standard doesn't prescribe specifics about the capabilities of the synthesis engine, certain expectations are common across vendor tools. Notably, there are two fundamental choices that define the behavior of the synthesis engine. The first is the mode of operation, where PSS allows for either a lockstep operation similar to SystemVerilog/UVM solvers or the ability to generate the entire test ahead of time. The second choice pertains to where the test is run, with options ranging from executing code on processors within the design to using a transactional methodology for non-processor designs.
Conclusion:
In summary, the Portable Stimulus Standard (PSS) presents a paradigm shift in verification methodologies by employing a graph-based modeling approach. The graph not only defines complete paths through a design but also introduces a coverage concept that is known before a test is executed. The two input languages, DSL and C++, provide flexibility and portability between vendors. PSS focuses on creating a verification model, with the synthesis engine responsible for translating this model into executable testbenches. As the industry continues to adopt PSS, it is crucial for verification engineers to familiarize themselves with its principles and explore how it can enhance and streamline the verification process.
References:
