SystemVerilog reference verification methodology: ESL

This is the third in a series of four articles outlining a reference verification methodology that covers both RTL and system-level requirements. This methodology is enabled by the SystemVerilog hardware design and verification language standard and is documented in the Verification Methodology Manual (VMM) for SystemVerilog, a book jointly authored by ARM and Synopsys. This article focuses on the techniques recommended by the VMM for SystemVerilog for ESL verification.

Introduction to system-level verification

In its most general terms, an electronic system is a design comprising independently designed and independently verified blocks as well as a block interconnect infrastructure. System-level verification is the verification of the correct interaction among these individual blocks.

Each block, including the block interconnect infrastructure, must be verified individually. Therefore, system-level verification should focus on the functionality embodied by the combination of the blocks. Any functionality that is entirely contained within a block is better verified at the block level.

System-level verification can take place on systems of any size, from tens of thousands to tens of millions of gates. In all cases, the principal requirement of verifying that the specified functionality and performance goals have been met is the same.

The system architect establishes performance, latency, and bandwidth goals for the various components of the system. The implementation teams must meet these goals. The verification teams, along with demonstrating that these goals are met, must verify all corner cases introduced by the implementation to demonstrate that an invalid state or behavior cannot be reached.

The biggest challenge facing a system design team is not in the specification and integration of many design blocks, but rather in achieving a confidence level in the correctness of the final design. This article describes a methodology and verification tasks applied to system-level verification. It should be of interest to block and system-level architects and verification engineers, with a focus on system-level integration verification.

Extensible verification components

The layered-testbench approach discussed in the second article in this series recommended the creation of individual transactors that can be reused from block-level to system-level environments. When considering these transactors from a system-level perspective, it may be necessary to extend or combine their block-level functionality into system-level functionality. Individual transactors can be structured into system-level transactors, each referred to as an extensible verification component (XVC).

XVCs provide a foundation for modular, scalable and reusable system-level verification environments, with the aim of minimizing test setup overhead. XVCs can be used to drive block interconnect infrastructures or external interfaces. They can also support other XVC components by monitoring system state and providing notification information.

The purpose of an XVC is to support system-level integration and functional verification using both directed and constrained-random testing under a unified methodology approach. The structure of an XVC is such that it is highly portable to different system-level designs and across design abstraction levels.

An XVC can encapsulate verification expertise and system-level functions in a standard way. Despite potentially having widely varying levels of functionality, the user of an XVC is always presented with the same look and feel at a testbench level, which contributes to a reduced learning curve and enables a consistent system-level testbench control mechanism.

An XVC is a container for verification IP divided into two layers, as shown in Figure 1. The generator layer is a user-extensible library of test actions that can be executed by the XVC, with a defined action interface for integration into a verification environment. The driver layer integrates individual transactors for implementing the actions on a physical-level or transaction-level interface interacting with the design-under-test (DUT). The generator layer controls the transactors in the driver layer.

Figure 1 — The XVC is structured into two layers: generator and driver.

The action interface of the generator layer allows coordination of test stimulus. The generator layer verification environment interface of an XVC can connect directly to an XVC manager. An XVC manager can support any number of XVCs at one time and uses this interface to schedule execution of individual actions within any given XVC. XVCs can also pass data and status back up to the test control infrastructure to communicate with other XVCs in the same environment.