What's New in PSS 3.0? Key Additions to the Portable Stimulus Standard

14 Dec 2025 • 6 minute read

The Portable Stimulus Standard (PSS) Language Reference Manual (LRM) has evolved significantly since its introduction by Accelera in 2018. It has become a powerful language for creating portable and reusable stimulus specifications. The PSS LRM has matured to meet the complex needs of verification workflows while also incorporating essential language general-purpose elements like a robust type system and clear semantics.

This blog explores the additions of the PSS 3.0, released in August 2024, through these two parallel axes, focusing on Cadence Perspec support aspects and highlighting relevant planned additions for the next LRM version: PSS 3.1.

Language General-Purpose Additions
Portable and Reusable Stimulus Aspects
PSS 3.1

Language General-Purpose Additions

Collection of Reference Types

PSS reference types are described in PSS 2.1 already for special modeling types such as components and actions. In PSS 3.0 they get additional enhancement by the ability to declare collections of references. These are polymorphic, meaning that, for example, the same list<ref C> can hold references to component instances of different subtypes of C. The main usage is for storing in advance references to register components and doing read/write operations on them within the exec body.

array<ref C,3>

list<ref C>
array<list<array<ref C,2>>,3>

Perspec supports collections (lists and arrays, including multi-dimensional) of component references from 24.06.

In PSS 3.1 it is expected that it will be possible to declare fields of reference types and also fields of collections of ref types in actions. This approach enhances the user's flexibility by enabling the selection of registers at solve time.

Comments in Template Blocks

Target template exec and function blocks have been supported since PSS 1.0. Previously, all code within the target template was generated. However, there are scenarios where users may want to exclude certain code from generation. The main reason for this is the presence of mustache expressions that users prefer not to evaluate in specific cases.

To address this need, PSS 3.0 introduces the ability to differentiate between code that should be included in the generated output and code that should remain excluded. This is achieved by using {#..#} comments inside the template exec block.

See the following example:

action my_action {

exec declaration C = """

//This comment will appear in the target code.

{#

This comment code.

#}

"""";

}

Perspec has been supporting target template exec code since its early days and supports the new enhancement of {#..#} comments since version 24.11.

“Sub-String Operator” and String Methods

String data type exists in the PSS LRM from version 1.0. In PSS 2.1, string formatting capability was added (similar to C printf()). Strings are usually used for messages and file content, but also for generating statements for the generated C code. However, de facto, it was very hard to use them till PSS 3.0.

In PSS 3.0 the sub-string operator and a few string methods (such as size(), find(), split(), etc.) were added, as well join() and str_from_chars().

For example:

string str = "hello Perspec";
int size_result = str.size(); // 13
list<int> find_all_result = str.find_all("e"); // {1; 7; 11}
int find_last_result = str.find_last("e", 8); // 7
string upper_result = str.upper(); // "HELLO PERSPEC"
string lower_result = str.lower(); // "hello perspec"
list<string> split_result = str.split(" "); // {"hello"; "Perspec"}
list<bit[8]> chars_result = str.chars(); // {104; 101; 108; 108; 111; 32; 80; 101; 114; 115; 112; 101; 99}
string slice_result = str[2..7] // "llo Pe"

Perspec supports all of them starting from 25.08.

Const Parameters

PSS 3.0 supports declaring function parameters as const. This means that the value of such a parameter cannot be modified within the function body. It is mainly useful for parameters of aggregate types, which are passed by handle and therefore can be modified by the function. Declaring such a parameter as const is supposed to guarantee that the content of the aggregate parameter will not be modified upon the return from the function. This will be supported by Perspec in a future version.

Portable and Reusable Stimulus Aspects

Address Space Group

The PSS Core library, introduced in PSS 2.0, provides standard portable functionality and utilities for common PSS applications. This also includes utilities to manage memory allocation in a system. Among those are address spaces, which contain memory regions, allowing actions to claim memory from. Each address space is considered completely disconnected from all others.

However, different IP PSS models may have different usage models for claiming address space storage atoms. Therefore, in PSS 3.0 an address space group defines the union of multiple individual address spaces that share common storage elements. The PSS input model can allocate common storage elements for the exclusive use of certain behaviors. The usage model is determined by the address space trait type, the address space region types, etc.

For example:

component chiplet {

transparent_addr_space_c<subsys_1_trait> mem1; // 4 regions x 8MB, some shareable

transparent_addr_space_c<subsys_2_trait> mem2; // 8 regions x 4MB, some secure

addr_space_group_c mem_group;

exec init_down {

// by being in the same group, the two address-spaces represent the same physical memory:

mem_group.add_addr_space(mem1);

mem_group.add_addr_space(mem2);

}

Perspec supports it from 24.04.

Yielding Control with Cooperative Multitasking

When a yield statement is used in a target exec block or function, it pauses the current block, giving other parallel exec blocks on the same executor a chance to run.

Perspec has supported this functionality from early days, however, as a function (yield ()) rather than a statement (yield). Therefore, from 24.09, yield() has been deprecated, and yield has been introduced.

Enhanced Support for Platform Qualifiers on Function Prototype Declarations

Perspec supports these from 24.10. Deprecations were added for the previous behavior where the restrictions were not enforced to enable backwards compatibility.

Note that these qualifiers existed before PSS 3.0 but were redefined and improved in PSS 3.0.

Behavioral Coverage

Until PSS 3.0, the PSS LRM defined data coverage, covering value ranges and combinations, similar to UVM coverage.

PSS 3.0 adds behavioral coverage, meaning coverage of scenarios. A scenario is defined as one or more actions that are expected to be observed. Perspec has been supporting a proprietary solution called Activity Based Coverage (using monitor actions), which provides the same needs, but with different syntax.

PSS 3.1

The upcoming PSS 3.1 is expected to contain several new features and enhancements, such as: annotations, activity statement enhancements, component instantiation enhancements, core library enhancements (such as ability to share an address claim between overlapping actions, target time communication) and more.

Some of these items are already supported by Perspec, such as:

Initialization of non-rand attributes in action handles: Perspec supports it from 25.03.
Defining component reference fields in actions (Perspec supports it from earlier versions).
Triple-quoted string with mustache notation, in the solve platform. Perspec supports it from 24.03.
PSS annotations have been supported since 22.02 in proprietary format and will soon be enhanced to align with the LRM definition.

With version 3.0, PSS has achieved a level of maturity that enables the language to effectively articulate system-level scenarios while also ensuring the model stability necessary for large teams and long-term design projects.

While staying tuned for the upcoming release of PSS 3.1, check out the PSS 3.0 (and upcoming PSS 3.1) items supported by Perspec. Explore how these can enhance your current code and methodology.