Total Pageviews

Wednesday, October 15, 2008

Re-Use of Verification Environment for Verification of Memory Controller

Re-Use of Verification Environment for Verification of Memory Controller
Aniruddha Baljekar, NXP Semiconductors India Pvt. Ltd.
Bangalore, INDIA

Abstract:

With the complexity of the design on the rise, coverage of functional verification is one of the increasing challenges faced by the design and the verification teams. Reducing the verification time without compromising the quality of the verification is the greatest challenge to the verification engineers. Improving the verification process is highly critical to improve upon time to market. To achieve this, re-use of the verification environment across different levels is the way forward. The re-use of the verification environment can be achieved at following levels:


Reuse with different IPs
Reuse at different levels of integration
Reuse at different levels of abstraction (SystemC (PV/PVT), RTL)
The paper covers the following:

Methodology adopted to address the re-use of the test environment/testbench at unit level across testing of highly abstract level models (modeled in SystemC) and RTL models (modeled in VHDL/Verilog)
Methodology and challenges faced towards unit level verification of complex TLM (SystemC) model (memory controllers: external static memory controller and external nand flash controller) using this re-use methodology
Methodology in creating verification IP’s to provide interfaces to enable its re-use at these different levels of abstraction
Following tools are used in this methodology:

Specman Elite as the functional verification tool which supports coverage driven verification methodology
vManager for plan driven verification
Scenario builder to create specific scenarios.
eVCs as the verification IP’s
1. Introduction

The paper describes the methodology on re-use of unit level verification framework across different levels of abstraction. It also mentions about how to create a new eVC or extend an existing eVC to provide TLM interface. Inputs to this paper are based on the experience from verification of the memory controller (re-using the RTL verification components in verification of the TLM model).

2. Motivation

Re-use of the coverage driven verification framework and environment is very important to reduce the time taken for verification. With challenges to build a TLM model in line with the time to market, it is very important to reduce the time taken to create the model and validate the model without compromising the quality. At present in NXP there are portfolio IP’s available at RTL for which the SystemC TLM models are being developed. Lots of effort has gone in the verification these RTL IP’s. If there is a possibility to reuse the testbenches developed for RTL verification in the verification of the TLM models, then the time required to verify the TLM models can be reduced. In the near future, the SystemC TLM models will be developed much before the RTL models. In this case the testbenches developed to verify SystemC TLM models can be re-used and extended for the verification of the RTL models. Re-use of the verification framework across the various abstraction levels is extremely important to reduce the total development time.

3. Technical Details

The main expectations from such a re-use approach can be categorized into:

High Level:

Reuse of the existing RTL verification environment to verify SystemC model
Minimum bring up time of verification framework
Common methodology towards creation of re-usable verification framework for all groups and environments
Technical view:

Reuse existing Specman sequences, monitors, scoreboard and other eRM compliant verification components from the RTL verification environment
Clear methodology to support RTL and SystemC models
3.1 Verification Environment Overview



3.1.1 Recommendations in creating re-usable Module eVC

The following requirements are essential for Module eVC re-use:

No interference between eVCs
Common look and feel, similar activation and similar documentation
Support for combining eVCs (control, checking, layering etc.)
Support for modular debugging
Commonality in implementation
Avoid using too many output messages
Avoid using too many parallel threads
Avoid sampling events at @sys.any
Use list resize() for large lists
Use Keyed list for better memory performance
Use str_join() instead of append() for large strings
3.1.2 Integrating Module eVCs into an SVE

All eVCs and connections between them are created during generation. Best known practice of generating and connecting eVCs is discussed to address following issues.

Decide when to use pointers and when to use ports
Resolve generation issues such as :
Generation order
Connecting cross pointers
To connect eVCs with pointers:

In the system eVC, define the pointers from the system eVC to the interface eVCs
Avoid pointers in the opposite direction. The interface eVC should be independent of the system eVCs associated with it
In the SVE instantiate the eVCs
In both the eVCs and the SVE, connect the pointers procedurally
The pointers between eVCs are connected procedurally after generation of the architecture. The connect_pointers() method is activated in a top-down fashion. The method is called automatically after all units have been generated and the pointers of the parent unit have been connected by the parent unit’s connect_pointers() method
3.1.3 Configuration Re-usability

The eVC configuration is a reusable aspect that must be encapsulated with the eVC. When an eVC becomes part of a system, some of its configuration is fixed according to the specific use in the system.

Each level in the unit hierarchy can have a configuration struct. Configuration is always projected top down, typically using constraints from the parent.

The configuration of a component depends only on the configuration of the parent environment.

If the configuration of siblings is mutually dependent, the dependency must be generated in the parent environment and propagated down to the siblings.

The key of configuration reusability is determining what elements of the configuration are reusable when the system becomes part of a bigger system. The elements that are reusable should be part of the eVC itself. The non-reusable configuration elements go into the SVE configuration file

3.1.4 Reusing sequences

Reusing sequences from the various components of the environment saves effort when building the verification environment. SoC environments typically require synchronization of the input of several agents. Virtual Sequence is the solution for providing synchronization on SoC level verification.

Multi channel sequence generation can be defined as follows:

Ensure that each of the agents has its own sequence (and sequence driver)
Define a new (virtual) sequence (and sequence driver) using the sequence statement and omitting the item parameter
Add the existing sequence drivers as fields of the new sequence driver
Pass the existing sequence drivers using constraints to the BFM sequences done by the virtual sequence.
A virtual sequence driver is always instantiated at the SVE level. Its primary role is to drive coordinated scenarios involving multiple inputs to the system. These scenarios are built from reusable sequences from the lower-level eVCs. Virtual sequence drivers from the module level can be reused (instantiated) on the system level. These sequence drivers are:

Defined in module eVCs
Instantiated in the SVE of the module eVC (as a usage example)
Reused by instantiating in a system SVE
Module-level sequences are not always reusable on the system level. In general, mixing random sequences can break a design. For example, inputs that are accessible at module level might not be accessible at system level.

3.1.5 Additional recommendations

Create a uRM compliant top-level verification framework for it to be re-usable at different levels of abstractions (RTL and TLM)
Create test sequences using virtual sequences. Virtual sequences, unlike BFM sequences, are not tightly connected to a specific sequence type or item. Virtual sequences can do sequences of other types (but not items). As a result, one can use virtual sequences to drive more than one agent and models a generic driver. These virtual sequences can be easily connected to the driver of the Module eVC
Use ports for getting the internal state of the DUT. Do not use ‘tick defines to probe into the design. In case ‘tick defines is absolutely required, provide an option to switch off this tick defines when the DUT is SystemC. ‘tick defines in the code result in error during the creation of the stub e.g. sync true ( '~/ip_xxx_tb_testbench_full/pwr_c_sys_ack'== 0)
Use backpointers to units to access any object instantiated in the verification environment. Avoid using “sys.” to access the members of that object
In case the test cases are specific to only RTL or TLM, there should be a mechanism to turn off the sequences which are not relevant the DUT. e.g reset sequences are relevant to RTL designs but for TLM designs its not relevant.
A typical re-usable verification framework across different levels of abstractions is as follows:



Following verification components can be easily re-used at TLM and RTL:

uRM compliant SVE (top level verification framework)
Virtual sequences/Sequences
Scoreboards
Coverage implementation
Monitors
Limited re-use on checkers (e.g. Protocol checkers can be used only with RTL)
3.2 Challenges on “e” side

Creating eVCs with TLM interface
Typically an eRM compliant eVC implements port level implementation and communicates with the RTL signals. This section describes the methodology in writing new eVCs which can be used for verification of models @ different levels of abstractions and supports the following modes of operation:

RTL interfacing mode (wherein the DUT is RTL model)
TLM interfacing mode (wherein the DUT is SystemC model)
The methodology describes how to develop an eVC which supports different levels of abstractions. The methodology also specifies how to add a TLM interface to an existing eVC without TLM interface.

Structure of eVC

eVC is built using the eRM methodology for it to be re-usable across multiple projects. The extension of the eVC to support SystemC TLM interface is done in the BFM, monitor and signal map units. The sequence driver is abstract and doesn’t have dependency of the details of the DUT interface (RTL signal level interface, SystemC TLM interface or any other interface). The sequence driver generates transactions which are then passed to the BFM. The BFM then converts these transactions to the implemented interface (signal level or TLM).

Monitor decodes the transaction activity in the DUT into the same data as defined in the eVC for the sequence driver. The data checking and functional coverage is performed by extending the monitor and covering the fields of the data items as decoded by the monitor. The coverage items and data checks should be implemented in such a way that there is no dependency on the interface implemented by the design. Only the specific protocol checkers implemented in the monitor have the dependency on the interface of the design. So depending on the interface selected the protocol checkers need to switched ON/OFF.

A typical eVC has a config unit which handles the configuration of the eVC used in the verification environment. This needs to be extended to provide a field “mode” or “abstraction_level”. This takes the values “RTL” and “TLM”. This field is also added to the eVC agent, signal map, monitor and BFM units. With this it’s possible to create an instance of the eVC with TLM mode or RTL mode. This mode is then passed to all the instantiated units in the eVC. The eVC structure still follows the structure as indicated in the eRM methodology but it encapsulates the TLM or RTL specific implementation.

The figure below shows such structure of eVC supporting different levels of abstractions:



RTL interface
The signal level interface is defined in the signal map unit of the RTL subtype. The signal map contains the input and output ports which maps to HDL signals for the monitor to read and for the BFM to read and drive. The BFM unit of the RTL subtype receives the transfers which need to be driven to the HDL. The BFM then converts the received transfers to the pin level interface as per the protocol.

TLM interface
The TLM level interface is defined in the signal map unit of the TLM subtype. This contains the method ports that link directly to the SystemC master/slave methods for driving the transactions received from the BFM unit for read and write. The BFM unit of the TLM subtype receives the transfers which need to be driven to the TLM model. The TLM BFM calls the driving out-method ports implemented in the SystemC interface master/slave which is interfaced to the DUT. In case of active slaves this information is received via the in-method ports to generate the response to the transaction.

The monitor unit for the TLM subtype defines the in-method ports. The TLM monitor implements the functionality of these in-methods ports. These in-method ports are called from the SystemC master/slave or DUT. This unit then rebuilds the data items and implements the necessary events which can be used for coverage information.

Advantages of having eVCs with implementation of TLM and RTL interfaces:

Enables reuse of verification framework across different levels of abstraction
Enables reuse of the various components of the verification environment like:
Test scenarios
Coverage details
Monitor details
Scoreboard functionality
3.3 Challenges on “SystemC” side

Monitoring support for all *_tlm_evc
At TLM the monitor of a passive SLAVE is updated by calling the in-method ports from the DUT. There are two ways in doing this:

The monitor in-method ports are called explicitly from the DUT. i.e. the DUT code has to be modified to call these methods
Implement a channel between the master and DUT. The channel then updates the monitor via these method ports. This avoids the DUT code to be modified to add these methods.
The figure below shows the “generic channel” which updates the monitor of the passive SLAVE



Handling conversions between “e” and “SystemC” data types.
Default SystemC/C++ predefined types have a built-in type casting for conversion between SystemC and “e”. For all these types conversion between SystemC and “e” is automatic and is handled by Specman. No separate or additional instrumentation is required. However for “user” defined kinds a “user defined convertor” has to be created manually to handle the data conversion between SystemC and “e”. This converter is written in C++. It is a struct containing the conversion functions. The conversion functions are static functions, and the convertor is used only to group these functions. A convertor struct is never instantiated.

Also for a new developed TLM module, the corresponding “e” datatype need to be provided and a conversion for the “e” and SystemC types is required for verification of the model using Specman.

The SC2e utility from Cadence addresses the process to minimize the effort of creating the data types in “e” and the creation of the convert mechanism between these data types. The SC2e utility performs two main operations:

Creates “e” types, matching the given SystemC/C++ types
Creates a conversion function, able to transform a data item from a SystemC/C++ type into an e type and vise versa
The figure below shows the typical steps involved in generation of the convert file:



Typical usage of the SC2e utility:

Creating “e” types based on the SystemC types
The “e” struct is created based on the SystemC datatypes.


The SystemC classes are created first during the model creation. This SystemC class is used to generate the corresponding “e” types.

“e” code related to the verification tasks is written generated re-using this generated “e” types. The data conversion between the “e” types and the SystemC types is handled be the generated structure via the hdl_convertor() which points to this generated convert file.

Using the existing “e” structures
In case one wants to use the existing “e” structs rather than the generated “e” structs created automatically by SC2e then one needs to use the following steps:

Use the convertor generator to create a struct in “e” that directly corresponds to the SystemC type.
Extend the existing “e” struct with a method that converts it to the “e” struct created by the convertor
Extend the SC2e-created “e” struct with a method that converts it to the existing “e” struct
To pass the existing “e” struct to SystemC:
Call the method that converts the “e” struct to the SC2e-created “e” struct.

To get the existing “e” struct from SystemC:

Call the method that converts the SC2e-created “e” type to the existing “e” struct.


User defined conversion rules
User can configure conversion rules with a set of predefined e methods. The vr_sc2e package defines a global object in e called vr_sc2e_manager. This object has a set of initially empty methods that all are called during the convertor generation. Empty methods enable default values of the configurable parameters. Users can extend these configuration methods to provide custom, non-default values.

4 Summary

The need for Re-Use of verification environment is very high to reduce the project execution time and the cost of verification without compromising on the quality
A uRM compliant top level verification framework is essential to enable re-use at different levels of abstractions
Following verification components from RTL testbench were re-used to verify the TLM SystemC DUT:
eVCs (extended to support the functionality at both TLM and RTL interfaces)
virtual sequences
scoreboard implementation
coverage implementation
verification plan
5 Acknowledgements

India
Narendra Solanki ( AE Cadence)
Israel
Omer Schori ( R&D Cadence )
Germany
John MacBeth ( VCAD Cadence )
Michael Jacob ( AE Cadence )
Joerg Simon ( AE Cadence )
+ world wide NXP/Cadence management support

6 Appendix

Acronyms/Glossary
BFM Bus Functional Model
DUT Device Under Test
eRM “e” Reuse Methodology
eVC “e” Verification Component
RTL Register Transfer Level
SC2e “System to e” conversion Utility from Cadence
SVE System Verification Environment
Specman “Enterprise Specman Elite” testbench (verification tool from Cadence)
TLM Transaction Level Model
IES “Incisive Enterprise Simulator” from Cadence
IPCM “Incisive Plan to Closure Methodology” from Cadence

Tools used:

Sr. No. Name of the tool Version
1 Cadence IES 6.1
2 vManager 2.0.2
3 Scenario Builder 1.0.1
4 IPCM package 6.1

eVC’s used:

Sr. No. eVC’s Source Version
1 AHB eVC Cadence 2.2
2 AHB TLM eVC Cadence 1.0ea4
3 APB eVC (signal + TLM interface) Internal 3.0
4 Interrupt interface eVC Internal -
5 DMAC Interface eVC Internal -
6 External Bus Interface eVC Internal -

References


[1] eRM Developers manual from Cadence

[2] Specman Elite, Third party Simulators/Specman Elite Integrator’s guide / SystemC Specman Elite Integration from Cadence

[3] e Language Reference from Cadence

[4] SystemC Users Guide

[5] IPCM documentation from Cadence


Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)