Re-Use of Verification Environment for Verification of Memory Controller
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)
- 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
- 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
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
- 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.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
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
- 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
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.
- Defined in module eVCs
- Instantiated in the SVE of the module eVC (as a usage example)
- Reused by instantiating in a system SVE
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.<object hierarchy>” 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.
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)
Creating eVCs with TLM interface
- RTL interfacing mode (wherein the DUT is RTL model)
- TLM interfacing mode (wherein the DUT is SystemC model)
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
TLM interface
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
Monitoring support for all *_tlm_evc
- 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.
Handling conversions between “e” and “SystemC” data types.
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
Typical usage of the SC2e utility:
- Creating “e” types based on the SystemC types
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
- 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:
- To get the existing “e” struct from SystemC:
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
- India
- Israel
- Germany
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
|
NXP Hot IP
Related Articles
- API-based verification: Effective reuse of verification environment components
- Smart way to memory controller verification: Synopsys Memory VIP
- Metric Driven Verification of Reconfigurable Memory Controller IPs Using UVM Methodology for Improved Verification Effectiveness and Reusability
- What's The Best Way to Verify Your SSD Controller?
- High Bandwidth Memory (HBM) Model & Verification IP Implementation - Beginner's guide
New Articles
Most Popular
E-mail This Article | Printer-Friendly Page |