Using VERA to test Enhanced Secure Digital/Multi-Media Card Host Controller Module
Jackie Zhang
Freescale Semiconductor Ltd.
Jackie.zhang@freescale.com
ABSTARCT
With the time-to-market pressure and design complexity increasing, the functional verification becomes more and more important during the SoC development! Basically, a testbench automation tool should provide 3 components: Constraint-Random Stimulus Generation, Temporal and Data Integrity Checking and Functional Coverage. VERA[1] is one of the most popular functional verification and testbench automation tools in the EDA market. In this paper we will talk about our experience how to use VERA and VERA-based DesignWare AMBA VIP[2] to verify SD/MMC Card Host Controller combining with our Freescale internal verification methodology[3]!
1. Introduction
The verification of Enhanced Secure Digital/Multi-Media Card Host Controller (eSDHC) represented many challenges for verification engineers! Design complexity, aggressive schedule and reusability consideration are the main issues. Using the traditional means to develop the testbench is very inefficient and low-qualified!
This paper will introduce the new-generation verification technique based on Vera verification language combining Freescale internal developed verification methodology to reach the goals of testbench automation and verification quality improvement!
With our design built on an AMBA bus structure acting as a slave, one of most important things we need to get right at the outset is the accuracy of our AHB master modeling. To achieve this goal we will choose DesignWare AMBA VIP to represent an accurate AHB master model. This enables us to prove that our design is correct and also ensure us that our design is fully AMBA specification compliant, especially for the particular configurations we will use. At the same time, we will benefit from the availability of constrained random testing (CRT) provided by AMBA VIP in the simulation.
SPSVeraBase functional verification methodology is developed by Freescale, which will enable us to set up the verification testbench environment efficiently with high quality as well.
2. Overview of DUV
The Enhanced Secure Digital/Multi-Media Card Host Controller provides the interface between the host system and Multi-Media Card (MMC) and Secure-Digital Card (SD). It acts as a bridge to help to pass host bus transactions to external cards by sending the appropriate commands and perform data accessing from/to the external cards. It handles SD/SDIO/MMC protocol at transmission level.
Our eSDHC is not a brand-new IP; it is derived from its previous version. Besides it keeps its original functional features, it will enhance and add in some new features:
● AHB interface added to speed up its interrupt/DMA data processing
● IPSkyBlue[4](IPS) interface is still reserved for low-power consideration
● Supports 1bit/4bit SD and SDIO modes, 1bit/4bit/8bit MMC modes
● Supports single-block, multi-block read/write operations
● Designed to work with SD memory, miniSD memory, SDIO, miniSDIO, SD Combo, MMC and MMC RS cards
Figure–1 is the DUV basic block diagram
3. Co-Development of Testbench and Design
3.1 why we choose co-development method
The eSDHC module to be verified is an enhanced one derived from its previous version; its preliminary structure is the same as its predecessor except that a AHB interface is added to speed up its interrupt and DMA data processes. Therefore, we should not wait for the completeness of the design; we can start our verification work the same time with design team! This can help us to conquer the tight schedule. In order to achieve this goal, we create some stub files to represent its entities that are under development; others are reused from its previous RTL design codes.
On the other hand, it is time-consuming and challengeable to develop AHB-based system verification platform, to avoid those risks and ensure our verification components quality we will reuse the Synopsys DesignWare AMBA Verification IP to help us to implement those components that related with AHB protocol.
Figure – 2 is the co-development of testbench and design diagram
Note:
1. Blue blocks stand for extension from SPSVeraBase Library
2. Red blocks stand for encapsulating DesignWare AMBA VIP into SPSVeraBase testbench
3. Purple block stands for encapsulating Denali SD/MMC cards into testbench
4. White blocks in eSDHC stand for those sub-modules under development
3.2 Freescale SPSVeraBase Functional Verification Methodology
In order to improve functional verification speed and quality, Freescale has developed a very powerful methodology which provides many features. It defines a universal module level verification environment and creates a set of base classes named SPSVeraBase library coded in Vera language. Those classes will enable new verification environment reuse from verification components which are well verified and suitable for any conditions, this feature will improve verification effectiveness and increase the productivity of verification engineers largely. For considering verification is performed at multiple-levels of integration, those verification components are targeted accuracy, completeness and conciseness, its verification architecture can be reused and extended to any requirement as well.
The SPS Base Class Library is the foundation for achieving testbench component reusability. This methodology will provide 3 outstanding features:
● Consistent component interfaces
● Modular implementations
● Testbench component reuse
Another very important mechanism is this methodology embeds a sequencer, which is well-designed to help to control the whole simulation phases! The sequencer mechanism provides a complete implementation for controlling testbench components activities at appropriate phases in the simulation in order to achieve an orderly simulation sequences. It divides the whole verification process into 4 pieces, in order to manager each verification component in the testbench easily and effectively, they are RESTART, CONFIGURE, EXECUTE, FINAL_CHECK, sometimes we will add an optional FINAL_REPORT test phase to handle some particular cases!
Figure – 3 is the description of sequencer mechanism.
Note:
1. Red vertical bars stand for SPSVeraBase testbench synchronization points
2. All transaction-based stimulus are blocked type, that is to say, one stimulus will be executed until its previous stimulus is executed successfully
3.3 Integrating DesignWare AMBA VIP into testbench
The development of testbench for today’s large and complicated designs is becoming more and more complex. With increasing design complexity, different protocols being used in the design, and limited resources design verification represents a bottleneck in product development process. Ultimate requirement is to have support and solutions from reliable verification solutions providers.
Synopsys is one of the best vendors in the semiconductor industry, his DesignWare Verification Library provides the industry’s broadest portfolio of design-proven, high-quality, standards-based verification IP helping designers save testbench development time and reach functional coverage goals faster. DesignWare Verification IP offers advanced functionality for block and chip-level verification, and they are fully functional in Vera environment.
With using AMBA VIP we can reduce total testbench development man efforts and also promise its quality.
AMBA VIP integration flow is described below.
1. Hook to SPSVeraBase Testbench Environment through Transactor Component
2. Creating AMBA VIP Wrapper in SPSVeraBase Driver Component
3.4 Testbench Sanity Checking
When the initial version of testbench is released, what we should do following is to perform the testbench sanity checking in order to guarantee its all required components are created and connected correctly. In this step we will not create complicated scenarios to generate the required stimulus, we just only select a very simple case to generate the stimulus see whether the stimulus can go through the testbench well or not! For example, we choose register accessing vector to check whether the Vera interface is connected to Verilog interface correctly or not, and we also generate a interrupt event through forcing the Verilog interrupt signal to check whether Vera Monitor component can watch this specified interrupt event and then issue this interrupt event to other testbench components correctly or not.
Another goal of this kind checking is to guarantee the AMBA VIP is integrated into our testbench correctly. For AHB bus is very complex, we should pay much attention when we integrate its VIP according to our requirements. Firstly, we should check the configuration of VIP. For our eSDHC acts as a slave on AHB bus, we should configure the VIP to provide the slave interface that our design will be connected to. Secondly, we should check the VIP’s initialization routines are carried out successfully before the testbench “execute” phase.
4. Constrained-random stimulus generation
In our eSDHC there are two different internal bus interfaces, one is IPS bus interface, the other is AHB interface. In order to control the stimulus generation effectively, we will create two kinds of commands to control and generate two kinds stimulus which go through two bus interfaces respectively. We will heighten the stimulus abstract level to transaction to simplify the stimulus management. Those transaction information is encapsulated in COMMAND SPSVeraBase class component and transferred through command channel.
On the other side, the Driver component embeds an interpreter which help to interpret the higher abstract level stimulus to pin level signal values according to each interface protocol.
To avoid the conflicts between two command generation mechanisms, our Stimulus component has a special design technique that help to implement itself correctly and smoothly. It utilizes SPSVeraBase Stimulus component’s sub-class–SPSVeraStartupStimulusBase to make stimulus generation orderly and easy-of-management. The Startup Stimulus class will ensure that all reset routine and initialization routines and other important routines (for example, memory pre-loading operations) will be executed firstly before the normal simulation begins. At the same time, our Stimulus component embeds a workmanlike FSM that negotiates the resource between two kinds command generation processes. Therefore, we will divide stimulus into two sub-domains, this will help us manage randomization efficiently in each sub-domain.
Below is the example of Startup Stimulus component.
4.1 AHB Domain Stimulus Generation
In AHB interface stimulus generation domain, we focus on AHB bus burst transfer configurations required on our verification environment.
4.2 IPS Domain Stimulus Generation
In IPS interface stimulus generation domain, we focus our stimulus on how to and when re-configure eSDHC module. We should confirm to eSDHC module can work in different modes; on the other side, we should be enable to deal with some particular interrupt events, in these conditions, the stimulus is customed and generated as the specified interrupt sequence.
5. Conclusion
With the object-oriented features provided by Vera, we can make our verification environment more manageable and reusable. And the scheme of constrained-randomization stimulus generation can help us reduce a lot of redundant man efforts without any quality damage. Combining our own pre-verified SPSVeraBase methodology, we can create our testbench quickly and easily.
Most of the bugs were discovered in Vera randomization phase, only a small amount of bugs occurred in corner cases are detected by the directed tests. And the important aspect is our design engineers can fix those bugs quickly with the information generated from our verification environment!
6. Future work
Though most of eSDHC functional verification tasks are accomplished, we still have some important improvements to be added in in the future! First of all, we should write some assertion statements separately to help Monitor component to observe all kinds sequences appeared on the interface and also some critical timing relationships, which will help to ensure whether the interface is compliant to its own specification. On the other hand, they will also help to capture more interesting functional coverage. The second is to add temporal checking mechanism in SPSVeraBase ResponseChecker class. Though this goal is based on assertion technique, we should put it in ResponseChecker to be regarded seriously.
7. Acknowledgements
The author wishes to say thanks to all the people involved in eSDHC module design and verification work, it is with their help that makes the verification task accomplished on schedule. They are: Joe Zhang, Linda Lin, and Cynthia Hao.
References
[1] Synopsys, “Vera User Guide”, Version 6.2.3, December 2003.
[2] Synopsys, “DesignWare AHB Verification IP Databook”. Version 2.45b, August 2004
[3] Freescale, “SPSVeraBase Reference Manual”. Version 4.0, September 2004
[4] Freescale, “IP Interface Semiconductor Reuse Standard”. SRS V3.1.1 April 2003
Insight China
-
SNUG
-
White Paper
-
Good Chip Series
