An elegant testbench driver modeling for the verification of a configurable IP

by P. Venkata Giri Kumar, Synopsys (India) Pvt. Ltd. , TechOnline India - March 02, 2011

The article proposes a testbench driver model for verifying the multiple DMA interfaces of the configurable IP. The testbench driver model has been explained with DMA interface as an example but can be extended to other applications like multiple host bus interfaces, multiple cache controller interfaces, etc.

Abstract: The functional verification of a configurable IP across multiple configurations is a challenging task and as the number of configurations increase verification becomes a complex task too. If configurable IP supports multiple DMA interfaces such as internal descriptor dma, external dma, slave mode etc., it adds to the complexity of the verification. The verification team focuses on developing the testbench to verify the new configuration and in the process realize that majority of the testbench needs to be redesigned to support the new configuration along with existing configurations. This may result into loss of productivity, as lot of time is spent in redesigning the testbench with every new feature added to the configurable IP.

The challenge lies in developing reusable testbench for such applications. The functional coverage convergence across multiple configurations is another challenge in the verification of a configurable IP especially when it supports multiple DMA interfaces.  The transactions are handled differently by different DMA controllers in the RTL and hence it is important to measure the transaction level functional coverage for all of the DMA configurations supported by RTL.  In general a set of transaction level functional coverage points are defined at the beginning of the verification phase and verification engineers ensure that the functional coverage goals are met at the end of the verification. In addition to this, verification of configurable IP should ensure that the functional coverage goals are met for all of the supported DMA controllers. It is important to consider the functional coverage requirements during the testbench architecture phase such that it is easy to measure the configuration specific functional coverage goals and subsequently generate configuration specific coverage reports.
 
This article addresses the above mentioned verification challenges and defines an elegant testbench driver model for verifying the IP across multiple configurations. A set of guidelines are defined for developing the testbench driver models with a focus on reusability of the testbench across multiple configurations and measuring the functional coverage goals across multiple configurations. The proposed testbench driver model is implemented and used to verify the Designware Mobile Storage Host Controller IP. 

 

I. Introduction

IP reuse plays an important role in SoC development as the time-to-market for SoC is reduced by using designed and verified IP in the SoC environment.  The SoC developers focus on verifying the interfaces across multiple IPs rather than verifying the functionality of the IP. The basic data transfer tests are run to ensure the proper connectivity to the multiple modules connected to the IP. The test plan, functional coverage and code coverage reports provided by the IP vendors are used to measure the quality of IP verification. Hence it is very important for IP providers to thoroughly verify the functionality of the IP [1] they provide. The verification of configurable IP is a challenging task as the design needs to be verified across multiple configurations [2].
 
It requires an elegant testbench driver model for verifying the IP across multiple configurations especially if the IP supports multiple DMA interfaces. The testbench drivers for a configurable IP focus on performing read and write transactions using respective DMA interfaces of configurable IP and hence it is important to have a reusable testbench driver to verify such configurable IP.  The verification effort and time can be reduced with the use of reusable testbench [3].  This article discusses the problems faced in the verification of a configurable IP and proposes an elegant testbench driver model as a solution to the problems.
 

II. Multiple DMA Interfaces of a Configurable IP

The configurable IP is designed with a focus on meeting various requirements of SoC developers. The SoC developers, depending on their requirements may chose one of the multiple options for DMA support such as internal descriptor dma, external dma, slave etc., but IP developers need to support all the DMA interfaces such that end users can configure the IP to meet their requirements. Hence DMA Interface becomes a configuration parameter in configurable IP design. The support for multiple DMA interfaces is a complex task both in terms of design and verification. The configurable IP “Designware Mobile Storage Host Controller IP” [6] is designed to support the SD (Secure Digital) [4] and MMC (Multi Media Card) [5] protocols.  The latest versions of SD and MMC namely SD3.0, SDIO2.0 and MMC4.4 are supported with a backward compatibility to the older versions.

The host controller IP has support for multiple DMA interfaces as shown below:

  • INTERNAL DESCRIPTOR DMA  
  • EXTERNAL DMA   
  • GENERIC DMA  
  • SLAVE

 

III. Testbench Driver Requirements

The verification methodologies like RVM (Reference Verification Methodology) and VMM (Verification Methodology Manual) are well known to the industry for quite some time. These methodologies define a set of guidelines for the development of verification environment with a focus on improving the verification productivity and providing the reusability of the testbench components.  The VMM based verification environment follows a layered architecture as shown in Figure 1 and each layer provides a set of services to the upper layer with an abstraction to the low level details.
 
This article focuses on defining the implementation model for the functional layer which addresses the challenges in the verification of a configurable IP. The functional layer provides the necessary abstraction layers for processing the application level transactions and verify the correctness of the DUT. The guidelines are defined for the functional layer but the actual testbench infrastructure requirements and the implementation model depends on the DUT requirements. A testbench driver model is proposed which can primarily translate the application level transactions to meaningful physical transactions (such as AHB transactions) and verifies the correctness of multiple DMA interfaces of the IP. 
 

Figure 1.  Layered Architecture for Verification Environment

 

The verification challenges typical to the configurable IP are explained in this section.
 
A. Testbench Drivers for Multiple DMA interfaces

The verification of a configurable IP with multiple DMA interfaces requires multiple testbench drivers to be developed. The DMA interfaces supported by the configurable IP are defined in Section 2. The natural tendency would be to implement the drivers with one of the following choices.
 
Each driver will be implemented as a VERA or System Verilog class and hence multiple classes are required for multiple drivers. The drawback with this approach is that any change in the driver flow would call for changing all the drivers.
 
Alternatively, all the driver flows are implemented in one class with conditional statements to address multiple dma interface requirements. The drawback with this approach is that, if the testbench driver is fixed for a bug in one configuration might lead to fail in other configurations. It requires multiple iterations for successful completion of regressions across the configurations.
 
The verification engineers spend lot of time in re-designing the testbench drivers with any change in the flow.  As the number of testbench drivers increase it severely impacts the verification productivity and the testbench reusability.
 
B. Functional Coverage for Multiple Configurations

The functional coverage is an important metric in the verification. The verification is said to be complete only when the functional coverage goals are met. The verification team defines the functional coverage plan by identifying all the coverage points and implements the functional coverage model. The verification focuses on running the regressions until all the coverage goals are met. If the coverage goals are not met the regressions are continued by enhancing the scenario generation capabilities such that missing coverage points are hit.
 
The functional coverage plan defines the samples and crosses to cover all the possible transaction level scenarios such as read, write, suspend, resume etc., such that functional coverage plan will be more exhaustive. These scenarios need to be covered in all of the DMA interfaces as the way the transactions are handled by RTL is going to vary with DMA interface. The internal descriptor dma uses the descriptors to perform the read and write transactions, the external dma interface provides the request and acknowledge interface to the external dma controller based on the internal FIFO status and in the slave mode the read write transactions are performed by AHB master without any DMA. As the transaction level scenarios remain same across the DMA interfaces the natural tendency would be to cross all the transaction level sample points with multiple DMA interfaces. The drawbacks with such functional coverage model are explained in this section. 
 
The exhaustive set of coverage points may need fine tuning for each of the DMA interfaces. The reason being some of the coverage points may not be valid in certain configurations depending on the design requirements and hence it is required to ignore such crosses or define them as bad states. This requires additional effort in implementing such model and needs to be reviewed thoroughly such that valid coverage points are not ignored. As the number of configurations increase, engineers spend lot of time in implementing such crosses and analyzing them in the coverage reports.
 
Secondly, if regressions are run for a specific configuration say internal descriptor DMA, then the crosses pertaining to remaining dma interfaces are shown as uncovered in the final report and it requires additional verification cycles in generating configuration specific functional coverage report by eliminating the configuration specific invalid samples and crosses.
 
The verification engineers spend lot of time in defining and implementing the functional coverage model at the beginning of the verification phase and analyzing the functional coverage reports towards the end of the verification phase such that configuration specific functional coverage reports are extracted. As the number of configurations increases it severely impacts the verification productivity.
 
The article addresses the above said verification problems and proposes an elegant testbench driver model which provides solution to the testbench reusability across multiple configurations and generate the configuration specific functional coverage reports.

 

IV. Testbench Driver Modeling

The testbench driver, as explained earlier, translates the application level transactions into physical transactions. The implementation of such flows requires developing multiple tasks and functions for programming DUT registers, preparing the data structures for DMA, processing the interrupts etc. The term “method” is used here after to represent both task and function. A set of guidelines are defined to implement the testbench driver model and are explained below.

 
A. Guidelines

The following guidelines are defined for implementing the testbench driver for multiple DMA interfaces. The guidelines are generalized such that they are applicable for any of the object oriented languages like VERA, System Verilog.

  •  A base class with the name dma_ctrl is defined. 
  •  Multiple derived classes one for each of the dma interfaces are defined and extended from the base class dma_ctrl.
  • An exhaustive set of virtual methods are declared (not defined) in base class to meet the needs of the driver flow. 
  • The methods implementing the driver flow common to all the configurations are defined in the base class.
  • The methods implementing the configuration specific functionality are defined in derived classes. The functionality of the configuration specific methods varies across the configurations but the method name remains same. 
  • The handle of the base class dma_ctrl is declared in testbench driver class.
  • The driver flow is implemented as a method, by name execute_transaction, in the testbench driver class. The execute_transaction implements the sequence of operations defined by the driver flow by calling the methods in the dma_ctrl.

Following guidelines are defined for generating the configuration specific functional coverage.

  • The configuration specific coverage groups are defined in the derived classes of the base class dma_ctrl.
  • The configuration independent coverage groups are defined in the base class dma_ctrl.

The class infrastructure is developed based on the above said guidelines. During initialization of the testbench, depending on the selected configuration one of the derived classes of the dma_ctrl are instantiated in the top level testbench. The handle of the instantiated derived class is assigned to the base class handle dma_ctrl in the testbench driver.
 
The testbench driver in the functional layer, after receiving a transaction from upper layers, executes the method execute_transaction. The method execute_transaction calls the methods in the dma_ctrl using the base class handle but by virtue of polymorphism, an object oriented concept, it executes the methods of the derived class. This is because the derived class handle is assigned to the base class handle and the methods in the base class are defined as virtual. The verification of a configurable IP is a true application of polymorphism. The same testbench driver performs the data transfers for multiple configurations but calls to the methods in dma_ctrl execute differently with the configurations.

A. Implementation Details

The proposed model has been implemented and is used to verify ”Designware Mobile Storage Host Controller IP”. In this section the implementation of the testbench driver is explained. The mobile storage IP supports multiple DMA interfaces as explained in section 2. The testbench modeling is explained in three steps.
 
Step 1: At the beginning of the verification phase a set of classes (one base and multiple derived) and corresponding methods are defined which covers all the DMA interfaces. Table 1 explains the class structure for the multiple DMA interfaces.

 

 

 Table 1. Class Structure for Multiple DMA Interfaces

Table 2 provides the set of methods defined in the base and derived classes.

 

 

Table 2. Methods defined

 

The methods in base class dma_ctrl are common for all configurations. The methods in derived classes are specific to the configuration. The name of the method remains same in all configurations but the implementation of the method varies across the configurations.  The reason being the requirements are different for all the configurations as explained below.

  • The desc_dma needs the descriptors and data buffers to be prepared for the data transfers.
  • The external_dma and generic_dma requires the respective dma_controller models to be configured.
  • The no_dma interface requires a testbench bus master to perform the read write transfers using
    the slave interface of the IP.

Step 2: A generic driver flow is defined such that the flow remains same for all the DMA interfaces and a method called execute_transaction is defined in the testbench driver which implements the generic driver flow. The flow diagram for the method execute_transaction is shown in Figure 2.

 

 

Figure 2. Method execute_transaction

 
The flow diagram abstracts out the driver flow functionality without considering any of the DMA interfaces. It makes a series of calls to the methods in dma_ctrl class.
 
Step 3:  During the initialization of testbench, depending on the configuration one of the derived classes of the dma_ctrl is instantiated and the handle of the derived class is assigned to the dma_ctrl base class handle in the testbench driver as shown in Table 3.  The task initialization_of_dma  instantiates the appropriate dma controller in the testbench and  testbench configuration property dma_interface gets the value based on the RTL configuration.

Table 3. Initialization of DMA

 

The methods in the base class remain same for all the DMA interfaces and hence only the methods in the derived class differentiate the functionality of the execute_transaction.  If the handle of the desc_dma_ctrl is assigned to the base class handle dma_ctrl in the testbench driver, the execute_transaction executes the driver flow for DESCRIPTOR DMA interface. The same is applicable for other interfaces also.

 

C. Functional Coverage

The implementation details for the functional coverage model are explained in this section. The functional coverage plan needs to be defined independently for each of the supported configurations. The transaction level scenarios valid for each of the configurations are added into the respective fc plans for example the scenarios for internal dma are added into the fc plan for internal dma and so on. The scenarios common to all configurations will appear in all fc plans. The configuration specific scenarios appear in the respective fc plan. This guarantees that the fc plan is complete on its own for each of the configurations.
 
The coverage groups need to be defined for each of the configurations as shown in Table 4 and the samples and crosses are added as defined in the configuration specific fc plan.

 

 

                                                                Table 4. Configurations and coverage groups

The configuration specific coverage groups are added into the respective derived classes of the dma_ctrl and gets instantiated with the derived class.   The sample points which are crossed with the configuration parameter DMA interface earlier are added into the derived classes. A single coverage group is defined for all the samples and crosses which are configuration independent. The configuration independent coverage groups are added into the base class dma_ctrl and gets instantiated with the base class. The sample points which are not required to be crossed with the configuration parameter DMA interface are added into the base class. 

 

V. Advantages

The advantages of the proposed testbench driver model are explained in this section.

  • Any update in the methods of the base class reflects in all the configurations.  The updates may be the result of either bug fix or an enhancement and is applicable to all configurations.
  • Any update in the methods of the derived class is specific to the configuration and will not impact other configurations.
  • It enables engineers to work on multiple configurations simultaneously as the driver flows are implemented in different classes.
  • It enables to generate the configuration specific functional coverage report.
  • The configuration specific coverage points are not shown as uncovered if the regressions are not run for that configuration as we see when we cross the configuration parameter with the sample points.
  • The configuration related conditional statements are not required as the coverage groups are added into the respective derived classes.

 

VI. Conclusions


The article proposes a testbench driver model for verifying the multiple DMA interfaces of the configurable IP. The testbench driver model has been explained with DMA interface as an example but can be extended to other applications like multiple host bus interfaces, multiple cache controller interfaces etc. If the new DMA interfaces are defined for the IP, the modeling guidelines allow the team to quickly enhance the verification environment to verify the feature.

 

VII. References

[1]  Sean Smith, “IP Reuse requires a Verification Strategy”, D&R Article, 
http://www.design-reuse.com/articles/9658/ip-reuse-requires-a-verification-strategy.html

[2]  Vidhya Thyagarajan, “Verification of a Highly Configurable IP”, SNUG India 2006.
 
[3]  A Sagahyroon, G.Lakkaraju, M.Karunaratne, “A Functional Verification Environment”, 48th Midwest Symposium on Circuits and Systems, 2005.

[4] SD Association; http://sdcard/.org

[5] MMC Association; http://www.mmca.org

[6] Synopsys Designware Mobile Storage Host Controller IP
http://www.synopsys.com/dw/ipdir.php?ds=dwc_mobile_storage

 

About the Author:

P. Venkata Giri Kumar is Senior R&D Engineer, IP Engineering, Synopsys (India) Pvt Ltd. He can be reached at vgk@synopsys.com

Comments

blog comments powered by Disqus