SystemVerilog reference verification methodology: ESL

Verification components must therefore be coordinated to create the required stimulus. This coordination is easiest to achieve when a single, central XVC manager coordinates the execution of multiple XVCs.

The XVC manager

The XVC manager is an optional verification component responsible for the high-level synchronization of XVCs. The synchronization and XVC control mechanisms can be user-defined according to the need of the system or a specific test. There should be only one instance of the XVC manager in a testbench environment; using multiple managers would require an additional level of coordination among them.

The VMM for SystemVerilog specifies a predefined XVC manager that uses test scenario descriptions written as external configuration files in a plain text format. These files can be reused or modified to new requirements with relative ease. The ability to direct the test via simple text input files enables the user to quickly achieve effective test results without a detailed understanding of the internals of the verification environment.

Having test scenarios specified as external files also eliminates the need for any re-compilation of testbench components or the design to run different test scenarios. This specification in turn helps to minimize test turnaround times for large and complex system designs. Figure 2 shows the structure of the predefined XVC manager.

The concept of a test scenario is fundamental to the function of the predefined XVC manager. The predefined XVC manager directs XVCs within the scope of a test scenario. A system-level test program can contain one or more test scenarios. Test scenarios are designed to meet one or more verification requirements.

A test program might consist of a number of test scenarios that, when taken together, fulfill several test requirements for a DUT. Test scenarios can also be used to encapsulate common sequences of actions so they can be reused by different test programs. For example, the operations required of a number of XVCs to configure a system could be contained in a scenario.

Test scenario files for the predefined XVC manager are fixed prior to run time and cannot be dynamically modified. A test program includes the descriptions of test scenarios and information regarding the order in which each scenario is executed. Scenarios may be repeated any number of times and in any order.

Every test action that can be executed in the test program is checked by its target XVC before executing the first action. This checking prevents a semantic or syntax error in the scenario file from aborting a simulation after a long run.

System-level verification environments

To fully verify the requirements of a block or a system, common practice is to construct a custom testbench targeted solely at meeting these demands. However, unless a standard approach is taken, block-level testbench components or functional coverage elements cannot easily be reused at the system level.

One technique that works well is using a transactor in place of a processor (CPU or DSP) when doing system-level verification. A transactor presents a direct cycle-level accurate mechanism for driving stimulus into the system without the overhead of programming a processor to perform this task. This transactor provides an easy-to-control bus master. This approach also avoids the verification of both master and slave bus agents in one environment, which can lead to challenging error detection conditions.

For example, if there were an error in the connection of a master or slave bus agent, then either could be masking the connection issue. A transactor will also be easier to synchronize with other events in the system design or verification environment. Finally, a transactor can be written to generate a much wider range of protocol values and behaviors over a smaller number of bus cycles, and can therefore be used to achieve better functional coverage.

On the other hand, a transactor cannot directly execute the embedded code written for a CPU or DSP. Thus, detailed processor models are commonly used in software-driven, system-level verification environments. The VMM for SystemVerilog provides guidelines for setting up such an environment to perform software integration and verify the interactions between hardware and software.