SystemC library supporting OVM compliant verification methodology

Update: Cadence Completes Acquisition of Evatronix IP Business (Jun 13, 2013)

Arkadiusz Koczor, Evatronix SA
Bielsko-Biala, Poland
Wojciech Sakowski, Silesian University of Technology
Gliwice, Poland

Abstract:

This paper describes the SystemC library that support Open Verification Methodology as defined by Mentor Graphics and Cadence with their SystemVerilog–based approach. Application of the library in development of a testbench for the simple component is presented. Advantages of its other possible uses are pointed to.

MOTIVATION

Open Verification Methodology was an important step towards improved efficiency of the verification process of more and more complex Systems on Chips and their submodules. However its current support is limited to SystemVerilog language which often requires heavy use of multilanguage simulation environment – in particular for interaction with SystemC–based TLM models
 
 

             
 
Fig.1 Hierarchy of main component classes supporting OVM methodology .

CLASS HIERACHY

The existing SystemC library provided by Cadence for support of OVM methodology has not been meant to fully support it, but only to maintain certain degree of interoperability between SystemVerilog–based OVM environment and SystemC models.

We developed SystemC class library (named EVM lib) in order to support development of OVM–compliant test environments in SystemC only. The classes it contains correspond to original SystemVerilog classes developed for OVM support and they enable defining test transactions and sequences. Other elements of testbench infrastructure necessary for test generation and stimulation of design-under-verification (DUV) can also be defined.

Figures 1 and 2 show the implemented class hierarchies. The classes defined in SystemC are all named with evm_ prefix and are represented by boxes with white background. OVM methodology assumes application of constraint driven verification which requires use of pseudorandom generators with appropriate constraints settings, checkers and/or scoreboard for monitoring the correctness of DUV responses to tests and quantifiable coverage metrics.
OVM methodology as such was defined for SystemVerilog simulation environment, with appropriate support in tools from Mentor Graphics and Cadence. Therefore no support for some of its aspects (like functional coverage models) is offered in the public domain SystemC simulation environment. However code coverage and assertion coverage metrics can be inspected also in HDL simulators that do not support SystemVerilog.

 

Fig.2 Hierarchy of main data classes supporting OVM methodology.

The most time effective approach to verification closure is automatic test generation within an infrastructure that can mimic environment in which particular system or its component will be used.

SystemC language with its SCV (The SystemC Verification Standard) library provides verification engineers with functionality required to implement testbenches with pseudorandom generators. They can be made configurable so that the control of different test attributes is easy and therefore they can be used to bring automated test generation into verification process.

We called our library EVM (for Evatronix flavor of Open Verification Methodology) to differentiate from OVM [1] as required by SystemVerilog OVM library license. Existing SCV library and OVM support for SystemC interoperability along with our EVM library contain most of the functionality necessary to deploy OVM–based verification i.e. object template, classes that define sequence, sequencer, transaction used to develop test scenarios. The basic principle of OVM–based approach to functional verification based on automated generation of tests in the SystemC simulation environment is illustrated in Fig 3.

In order to verify functional correctness of the DUV according to OVM methodology we need to use:

• assertions (written in PSL or SVA) embedded in line in the RTL source code or placed within monitors of verification environment
• infrastructure built with monitors and with a scoreboard.

Off-line analysis that enable identification of bugs caught during simulation runs require recording of testing transaction and DUV responses. We defined within EVM library a class that make possible to record some or all transactions to the hard disk.

According to OVM methodology there are two major collective components that support reuse of test environment elements: the agent and the test environment itself.   
 
 

         

Fig.3 Automated test generation based on EVM class library, base OVM classes and SCV library

The structure of the agent component implemented in System C is presented in the Fig. 4.

Fig.4 Agent component architecture for SystemC implementation. Developed along with [2]. 

Objects of class evm_agent contain the following attributes [2]:

• Bus driver – an object of the class evm_driver which enables interfacing between TLM level of abstraction of the test environment and RTL level design under verification;
• sequencer – object of the class evm_sequencer that:
  • passes transactions generated by the test sequence to the bus driver;
  • passes back transactions received from the driver to the test  sequence.
• monitor – object of class evm_monitor; 
• scoreboard – instance of the class evm_scoreboard, which analyzes correctness of the DUV reaction to the given test sequence; use of its functionality within agent is limited ;
• configuration fields that contain information of the agent mode of operation; there are two modes possible:
  • passive mode – agent just monitors activity of the DUV;
  • active mode – agent monitors and stimulates the DUV;
• instance of tlm_analysis_port class (from TLM 2.0 library), who enables hierarchical connection of the monitor contained within agent with a scoreboard placed in the higher layer of test environment
• sc_port class objects, that are necessary to hierarchically connect the driver ports with the upper layers ports (reaching representation of the bus in the highest layer of test environment) – TB_TOP.

DEVELOPING OF I2C TESTING ENVIRONMENT

The second collective component supporting verification reuse is the test environment itself. 

We implemented a generic model of the test environment in SystemC and applied it to develop the specific testbench for the Evatronix I2CS core. Its architecture is presented in the Fig 5.

There are two agents used in this testbench: one dealing with SFR interface of the DUV, the other with its I²C interface. Ports that belong to each agent were hierarchically connected with ports of the I2CS_verification_env and I2CS_test layers of the test environment.
 
 

Fig. 5 Architecture of OVM compliant test environment of Evatronix I2CS core.

Binding of interfaces – i.e. connection of the agents with I2CS core interfaces by means of appropriate communication channels is realized at the top hierarchy level of the test environment – TB_top. Interface of I²C agent was connected to DUV by means of the communication  channel of type   sc_signal_resolved. The SFR agent interface was connected to DUV by a simple channel: sc_signal.

Synchronization of the data passing executed by means of interfaces of specific agents is realized within virtual sequence - vi_sequence, that launched by virtual sequencer – vi_sequencer. Virtual sequence coordinates the following lower level sequences:

• for SFR sequencer:
  • sequence that handles interrupt coming from I2CS core;
  • sequence that configures I2CS core;
• for I²C sequencer:
  • sequence that transmit pseudorandom data over I2C bus;
  • sequence that collects data coming from  I²C bus.

As stated above SCV library along with OVM SystemC support and our EVM SystemC libraries make possible to build entire verification environment compliant to OVM. For the moment the major drawback of this approach is lack of coverage models in the SystemC environment that we use. Lack of coverage models makes full implementation of CDV (constraint driven verification) problematic. However – use of assertions – both embedded within RTL source and at DUV pin level as well as at higher level of abstractions  may provide equivalent functionality within any VHDL or Verilog simulator supporting SystemC and PSL (or SVA).

At the time when I2CS component was originally developed (2001) the only coverage metrics used within Evatronix were typical code coverage indicators. Use of the OVM-like approach and freshly developed SystemC EVM class library brought us to 95-100% code coverage within just two weeks. The development of original Verilog testbench of I2CS core along with test suite took 4 times longer.
 
INTENDED OTHER USES – TLM MODEL VERIFICATION AND EMULATION

The testbench architected with the presented library may be used also with transaction level model of the DUV. It is just a question of removing or replacing the bus drivers so that interface between the testbench and DUV is TLM – compliant.

Such a testbench may be used in an early stage of the DUV development (provided that its TLM model is available before synthesizable RTL is ready). This may lead to using software to define and carry out part of the core testing. Use of software for test development may occur in so-called native mode or through integration of ISS of the target CPU within testbench and cross compilation of software tests [5].

We have also carried out successfully first experiments with internally developed low cost emulation system. In such a system drivers that drive RTL model in simulation environment have to be replaced with SCE/MI [5] compliant transactors that are stimulated by the SystemC testbench run on the host computer.

Such transactors have software and hardware component (as shown in the Fig. 6) – the latter embedded in the FPGA on prototyping board is responsible for stimulating the synthesized DUV as well as passing back its responses to the host computer. Link between the host and prototyping board – whether USB2 or PCI-X is completely hidden within SCE/MI transactor.

 

Fig. 6 Architecture of OVM compliant test environment of Evatronix I2CS core.

In both cases introduced briefly above no HDL–based (whether VHDL or Verilog) simulator is necessary.

CONCLUSIONS

While SystemVerilog environment is best suited for development of fully OVM compliant verification environments we have shown that use of SystemC is also possible to achieve similar goals.

Development of higher level test scenarios in conjunction with use of TLM models and use of software to support verification may be done entirely within C++ environment (supporting SystemC of course!) which may substantially reduce the cost of a verification seat.

Such approach may be directly extended to support early phase of hardware prototyping/emulation provided that appropriate hw/sw infrastructure (SCE/MI transactors) is available. 

LITERATURE

[1] M. Glasser, Open Verification Methodology Cookbook, Springer, 2009

[2] Mentor Graphics Corporation, Analysis Guide for OVM, 11 June 2011r

[3] Mentor Graphics Corporation, Testbench Guide for OVM, 11 June 2011

[4] Mentor Graphics Corporation, Sequences Guide for OVM, 11 June 2011r

[5] I. Sobanski, W.Sakowski, Verification of USB 3.0 Device IP Core in Multi-Layer SystemC in Proceedings of  IP-ESC 2009 Conference, Grenoble, France, 1-2 December 2009

[6] W.Wrona, W.Pietrasina, W.Sakowski, D. Nycz, A SystemC/SCE-MI based methodology for IP core debugging and FPGA prototyping, Proceedings of the Conference on System, Software, SoC and Silicon Debug, Sophia Antipolis, France, September 24th & 25th , 2009