Knowledge Center
Navigation
Knowledge Center

Portable Stimulus (PSS)

Hardware Verification Language, PSS is defined by Accellera and is used to model verification intent in semiconductor design.
popularity

Description

Portable Stimulus is a verification language defined by Accellera. It is used to model verification intent. The initial version was released June 2018. The name is confusing to many people because it describes its first intended application rather than being a description of what it actually is. Because of this confusion, Portable Stimulus is often referred to as PSS. The initial application was to port a testbench from a simulator to an emulator. However, it is not the testbench that is portable; instead PSS is a verification model that can be synthesized into a testbench targeting either simulation or emulation. Many other verification tasks could be targeted by a synthesis engine.

The standard is based on the mathematical notions of graphs. The graph contains atomic actions and the data each action requires or generates. The actions are joined by data flows and these define how the data is transferred, such as being buffered or streamed. Actions may be composable into more complex actions that may define sequential or concurrent actions. A usable graph defines at least one path through the design. Graphs can be built incrementally.

Two input languages are defined. The first is a domain specific language (DSL) that makes it as similar as possible to existing verification languages, such as SystemVerilog. The second is C++ coupled with a runtime library. However, unlike SystemVerilog and C++, the language is primarily used in a declarative manner rather than procedural. Both languages define the same semantics. While many vendor tools have a graphical input or output form of the graph, this is not defined by the standard. The DSL and C++ may be freely intermixed and should be portable between vendors.

Even when C++ is used as the input language, what is created is a model, not an executable. It is very similar to writing a design description. The model needs a simulator or synthesis engine to read it and to perform an action on it. The same is true for PSS. The language creates a model. A verification synthesis engine, which is not defined by the standard, reads that model and generates testbenches that may target an array of abstractions and execution engines.

A major difference between a PSS verification methodology and the ones that preceded it is that the graph defines complete paths through a design. While a synthesis engine can pick random paths through the graph, they will always form complete scenarios. The graph also defines a notion of coverage in that if all paths have been exercised, then all defined actions have been involved in verification. This notion of coverage is known prior to a test actually being run. In addition, the graph actions can define their expected outcomes which can be checked during design execution, meaning that the graph is a complete verification model. This is unlike SystemVerilog and UVM which have separate models for each verification component: stimulus, checkers and coverage.

While the standard does not define anything about the capabilities of the synthesis engine, there are some aspects of it that are expected behaviors for all of the vendor tools. The first is the modes of operation. A SystemVerilog/UVM solver is run in lockstep with the simulator. At each step, as the design advances, it goes back to the stimulus solver to get the next input vector. PSS can be run in this mode although PSS synthesis engines have the ability to generate the entire test ahead of time. The PSS solution may still need a lightweight engine that can feed the pre-generated stimulus into the design and coordinate activity on the design ports.

The second fundamental choice is where the test is run. If the design contains one or more processors, then the synthesis engine could generate code that will be executed on those processors. When no processors exist, the stimulus is fed in using a transactional methodology. In many cases, a combination of the two will be used. Transactional interactions with the design are likely to be through UVM verification IP models.


Related Entities


Related Technologies