These are my notes while reading the Portable Stimulus Standard. I will keep updating on the go.

The specs define PSS as:

The Portable Test and Stimulus Standard defines a specification for creating a single representation of stimulus and test scenarios, usable by a variety of users across different levels of integration under different configurations, enabling the generation of different implementations of a scenario that run on a variety of execution platforms, including, but not necessarily limited to, simulation, emulation, FPGA prototyping, and post-silicon. With this standard, users can specify a set of behaviors once, from which multiple implementations may be derived.

So, it’s basically it’s abstract language to define tests and EDA tools can generate SV/UVM/C tests depending on target platform and integration level.

1.3 Modeling basic Link to heading

  • Model: representation of some view of a system’s behavior, along with a set of abstract flows
  • Action: elements of behavior
  • objects: passive entities used by actions, such as resources, states, and data flow items, collectively called objects
  • Activities: The behaviors associated with an action are specified
  • Components: Actions and object definitions may be encapsulated in components to form reusable model piece
  • Package: All of these elements may also be encapsulated and extended in a package to allow for additional reuse and customization.
  • scenario: A particular instantiation of a given PSS model. Each scenario consists of a set of action instances and data object instances, as well as scheduling constraints and rules defining the relationships between them
  • A consistent scenario: is one that conforms to model rules and satisfies all constraints.
  • atomic actions: Actions may correspond directly to operations of the underlying system under test (SUT) and test environment, in which case they are called atomic actions.
  • Actions also use activities to encapsulate flows of simpler actions, constituting some joint activity or scenario intention

Test realization Link to heading

A key purpose of PSS is to automate the generation of test cases and test suites. Tests for electronic systems often involve code running on embedded controllers, exercising the underlying hardware and software layers.

From the PSS model perspective, these are called target files, and target languages, which jointly implement the test case for a target platform.

Aggregate literals Link to heading

Aggregate literals for use with arrays, lists, and sets

value_list_literal ::= { expression { , expression } }

int c1[4] = {1, 2, 3, 4}; list l = {1,2,3};

Map literals

map_literal ::= { map_literal_item { , map_literal_item } } map_literal_item ::= expression : expression

map<int,bool> m = {1:true, 2:false, 4:true, 8:false};

Structure literals

struct_literal ::= { struct_literal_item { , struct_literal_item } } struct_literal_item ::= . identifier = expression