Integrating Portable Stimulus Standard (PSS) capabilities with the Universal Verification Methodology (UVM) is not the same as an integration between two languages.
In our previous column, Aileen Honess provided a backdrop as to why a team using Universal Verification Methodology (UVM) and SystemVerilog may want to extend their methodology by adding Portable Stimulus. By incorporating a constraint solver that understands not only combinatorial constraints but also the temporal aspects of a design, it becomes possible to generate more efficient tests that target a particular verification intent.
This blog will lay out the basic strategy for such an integration. It is important to note that integrating Portable Stimulus Standard (PSS) capabilities does not remove any of the capabilities that may already be in place. Existing testbenches will still work and they will continue to provide the same coverage. PSS adds new capabilities that become useful if you are having problems reaching the desired level of coverage or if you want to make test cases that are retargetable to emulation or can be used in chip bring-up.
Over time, you may find that you want to change your verification methodology to favor test cases generated by PSS rather than the more simplistic, random ones coming from your existing UVM environment. Those changes can be made over time as you become more confident in the capabilities of PSS. Furthermore, PSS also provides new — and, we believe, more intuitive — methods of scoreboarding and assessing coverage.
We also have to remind you that the integration of PSS and UVM is not the same as an integration between two languages. PSS defines a model on which a tool operates to produce a test case. It is the generated test case that is integrated with UVM. This means that, when talking about an integration, you cannot make it independent from a specific vendor’s tool. I will describe the integration in the most general terms possible, and it is likely that other vendors will have a similar set of steps, but the details or the levels of automation may be different.
The six steps are:
- Identify UVM interfaces, including transaction level modeling (TLM) interfaces, software interfaces, and memory. Configure the tool and integrate to UVM.
- Create PSS register-type descriptions. This can be done manually, through Hardware/Software Interface (HSI) register definitions, or by converting from an IP-XACT description.
- Identify the overall PSS model/representation for the design (components, actions, resources, etc.).
- Provide details for each “action.” These are defined in terms of portable primitives that can synthesize to either TLM or Software-Driven Verification (SDV) tests.
- Compile the model, synthesize test cases, and run UVM simulation.
- View and debug results, and analyze coverage.
We will use a fairly simple design to demonstrate these concepts. This design is derived from a public domain example and is available in the Breker distribution. The example has two CPUS, two UARTs, a DMAC, and an AES crypto-block.
Each UART has a Verification IP (VIP) used for configuration and to transmit and receive data. In addition, each of the CPUs exposes ports that are driven by AMBA Advanced Peripheral Bus (APB) VIP. TLM transactions and TLM ports are defined for the UART VIP; also, processor agents configured in the TLM mode are defined for the APB VIP. A memory resource is defined for use by DMAC operations.
Step 2 establishes the register and memory map of the VIP. Quite often, these have already been defined in an IP-XACT format, which is a common format for third-party IP blocks. Many companies also use it for documenting their internal IP. If this is the case, a utility will do the necessary conversion. Breker has adopted the proposed HSI, which was not ratified in the first release of the PSS standard.
Register descriptions for each of the three components (UART, DMAC, AES) are created easily using
trekhsi from the IP-XACT files released with the design. Field names can be modified for readability.
Step 3 is to identify the components of the system. For this design, the main IP blocks are UARTs, DMA, and AES that become a “PSS component.” Each block has core functionality described as “actions” and represented as a “PSS action.” Key functions (actions) of these blocks could be defined as:
- UART — configuration, receive, transmit
- DMAC — output data, input data
- AES — encrypt, decrypt
- CPU — output data, input data
Note that, when first writing a PSS model, it is not important that all actions are defined. At first, only the most important need to be defined and, as the verification task progresses, additional, secondary actions may also be defined. This does not impact any of the verification already performed — it just makes more sequences possible.
A resource pool is created for each of the computational elements (UART, DMAC, AES).
Interfaces into the blocks are defined using flow objects (FIFO, Reg) and a corresponding “pool” created for each.
Finally, the PSS locks control of the shared or exclusive use of resources. The scheduler will use these to ensure that it does not attempt to make the hardware perform mutually exclusive actions simultaneously.
The Entry action (top) will schedule two UART scenarios, an Encrypt and a Decrypt operation, concurrently. The UART scenario (bottom left) will pick a configuration for the DUT, configure the VIP to match, and perform a number of receive and transmit operations in parallel. The Encrypt and Decrypt operations are fed by DMAC transfers (bottom right). Resource locks are used to ensure that two operations on the same hardware block are not allowed to execute at the same time.
PSS code for the entire model is generated by the tool. Each generated action has a pair of
// Start of user code and
// End of user code markers within which the detail operation of the action may be entered. Code within these markers is preserved when the model is regenerated.
In our next column, we will cover the remaining three steps. Meanwhile, as always, please reach out to me with any questions or if clarification is required.