A Novel Approach for HW/SW Co-verification Leveraging PSS to Orchestrate UVM and C Tests

The complexity of system on chips (SoCs) continues to grow rapidly with the integration of more functionality onto a single chip. As a result, traditional verification methodologies struggle to keep pace with the growing complexities, leading to longer development cycles and increased risk of design errors. In response to this challenge, hardware and software co-verification emerges as a pivotal technique in validating SoC designs. However, there is much testing that needs to be done at the block- and subsystem-level before software-driven system-level testing can begin.

Traditionally, this early testing is done in simulation using the Universal Verification Methodology (UVM) to create a set of modular reusable verification components assembled into “testbenches” (UVM environments), including stimulus sequences to exercise specific transactions across the different interfaces of the device-under-test (DUT). When the full SoC design is assembled, it usually includes an embedded processor and requires software, usually written in C, to exercise the same functionality that was previously modeled as UVM transactions driven by an agent executing a sequence.

This need to duplicate the verification implementation, first in UVM and then later in C, is a substantial bottleneck that negatively impacts the verification productivity of many projects. The Portable Test and Stimulus Standard (PSS) from Accellera1 was architected specifically to address this need to reuse verification intent throughout a project across multiple, possibly heterogeneous, implementations.

By definition, a PSS test defines a set of actions that represent the verification behaviors required to exercise desired functionality of the DUT. These actions themselves can be defined at multiple levels of abstraction, from basic bus read/write operations to higher-level actions, such as direct memory access (DMA) transfers, message passing, or other behaviors. An action that may be driven by a UVM agent at the block level may easily represent a C-level function that may be called from a software driver running in the embedded processor at the SoC level.

A PSS test is composed of the following:

1. A set of actions that define the set of behaviors to be executed
2. An activity that defines the critical actions and their relative scheduling constraints
3. Data flow requirements between actions
4. Additional data and scheduling constraints
5. Target-specific implementation(s) of each action

From these elements, a PSS tool can generate a target-specific implementation of the overall test scenario, check Figure 1. To the extent that the schedule and constraints are flexible enough to permit multiple scenarios to satisfy the specified verification intent, a PSS tool can effectively create a constrained-random implementation of the desired scenario.

This scenario-level randomization makes it easier to create complex test scenarios from easy-to-describe tests. This approach also provides the secondary benefit of allowing the block-level verification team to create a library of actions that can be reused at the subsystem and system level.

^{Figure 1: PSS orchestrating UVM and C tests}