In fact, a typical SoC project has several different system-level verification environments. For a given system design, its associated functional verification plan specifies system-level verification requirements.
It is easier to use a number of different verification environments to meet these requirements. Each environment is concerned with a particular set of orthogonal functional verification goals and is designed to cover those requirements efficiently. The orthogonality of the system-level requirements makes using a single environment needlessly complex and can in fact mask certain system configuration errors.
In addition to the software test environments, the VMM for SystemVerilog defines four types of verification environments:
The "block interconnect infrastructure environment" pre-verifies the block interconnect infrastructure. Verification components substitute for the master and slave peripherals at the points where the peripherals would interface to the bus. The purpose of this verification environment is to check the functional correctness of data transfers, protocol rules, and bus performance requirements, such as latency and bandwidth.
The "basic integration environment" checks the correctness of the connectivity by toggling all I/O ports in a system. Replacement for the various system components with verification components to drive bus transactions is the preferred method of applying integration stimulus. Integration tests are written to ensure that each block has been correctly integrated into the system-level hierarchy. Internal functional behavior of the system components is not verified.
The "low-level system functional environment" covers any functionality that cannot readily be observed from the transactor substituting for the CPU/DSP. Such functionality may include monitoring of control signals, reset mode checking, or any other functionality that is not easily looped back to the CPU/DSP for read-back or control. As with the basic integration environment, internal functional behavior of the system components is not verified.
The "system validation environment" ensures that the overall performance requirements—such as latency and bandwidth—of the system are met. In this environment, verification components drive or monitor the external interfaces of all blocks in the system. As shown in Figure 3, only the CPU/DSP is replaced with a transactor. This environment should use an abstraction model of the system that efficiently simulates with high throughput and the required level of accuracy to help minimize test turnaround time.
Figure 3 — The system validation environment must be efficient to measure system performance.
System-level verification environments should reuse block-level verification components where applicable. The guidelines outlined in the VMM for SystemVerilog make it possible to architect block-and system-level verification environments so that the effort spent in creating the different block-level verification components is not discarded when moving to the system level.
Verification components constructed as per the guidelines can readily be reused at the system level when required. However, instead of being directly controlled, block-level components can be reconfigured to let them perform operations that are more relevant to the system. The re-configurability of verification components addresses the difference in purpose between block- and system-level verification.
Transaction-level models
The system-level verification methods described in this article often entail modeling some portion of the DUT at the transaction level. Writing a transaction-level model of the entire design is an intrinsic part of some development methodologies.
