Reusable Verification Environment for Core based Designs

This paper describes the approach for a reusable verification environment for core based designs. It addresses some of the issues and benefits of reusable verification environment for getting a verification closure in a typical SOC.

1. Introduction

With the increase in Design complexity, the effort spent on SoC verification is increasing exponentially. With the increase in the chip complexity and reduced design cycle time there is an extensive need for reuse. In this paper we will stress on a generic verification platform for Core based designs. With this approach we can increase reuse of the verification environment and the testpatterns for Core based design. With the increase in reuse the verification engineer can spend more effort on quality of verification rather than spending the effort for redeveloping the environment
In this paper we will discuss about the challenges faced in creating a generic verification platform and ways to address these issues.  The term generic is used to describe the verification environment which is modular and can be used for bottom up approach i.e. from Module level environment model can be ported to top level verification environment and the verification environment can be ported across different core based SoC designs and reuse of testpatterns between silicon validation and SoC  verification environment.

2. Module level verification Environment

A typical SOC contains the following components: a processor, a peripheral bus, many peripheral devices such as UART, MACs, etc, a bridge between two buses.

Lot of effort is spent in creating and testing these devices independently before they are integrated into the SoC.

Reuse of checkers, external stimuli generator, and coverage metric for the module will help to boost the full system verification environment. Your module level verification environment could be similar to the one shown in the diagram (a)
    

Diagram (a) The structure of Module level Verification environment

With this approach we can enable the reusability of verification components associated with the DUT in the SOC level and across SOC’s where the IP is being reused.

In addition, it is also important that the module level test cases are easily ported to the system level environment as well. This can be done by using scripts to convert the tests to system level. The main purpose of doing this is to perform a sanity check of the module. Not all tests can be ported to the system level because of the constraints in the system level. The test cases such as module register access, interrupts triggering and its basic functionality can be ported depending on the complexity. The toggle coverage between the interface of the module and the system can serve as a measurement in such checks.

By implementing the above steps, the verification engineer can hence focus more on system level checks instead of recreating test cases for checking the integration of the module into the system. An example of the system level test would be to coordinate two or more modules in the system to perform specific routines. In some cases, the reuse module level test cases can also serve as a guide for verification engineers, who are new to the module, to properly setup and program the module. This would speed up the effort required to learn the new module, especially for the case of very complex modules.

3.    SoC   Verification Environment

Reusability and portability are the main focus in setting up the SoC verification environment. Reusing module level verification components (such as checkers and monitors) on top level can ensure the module functional consistency and also reduce the effort of rechecking the module. When setting up the test bench and compilation scripts in the top level, one should keep in mind of the ability to reuse the setup in another project having a similar architecture (often the same processor is being used). Majority of the setup should be kept generic with a portion being able to configure when porting over to a different project.

In addition, the description language used in the top level (e.g. SystemC, systemverilog, e, etc) should ideally be of the same type as in the reused module level verification components. This will greatly reduced the effort in developing SoC verification environment. These test cases generated by random methodology can also be converted to the assembly instructions or C to be loaded into processor for execution. At this point, it is important to stress the usage of the processor actual RTL (whenever possible) instead of a behavioral model even though it may result in sacrificing simulation speed. The aim is to eliminate the possibility of functional discrepancy between the model and the actual processor design which can turn out to be disastrous when the real silicon arrives.

Random verification plays a very important role in SoC verification. It is necessary for the environment to support this. The environment should be able to generate a stimuli file for the processor and for your external stimuli to enhance the real life possibilities. It is also necessary to have a self checking mechanism in environment this could be handled by the checkers, protocol checkers and also self checking mechanism within the test cases.

The following is an example of random verification in the SoC system. In this example, the system level testbench generates a constraint random CPU test case to program the DMA and Module 1 to write to and retrieve data from specific regions of the memories at the other end of the bus bridge (MEM A and MEM B respectively). This pre-generated test case is then simulated in the system level. At the end of the test case, the state of the DMA & Module 1 and the contents of the target areas in the memory are being verified. The goal of this test scenario is to stress the bus bridge with the use of real modules in the system level instead of models under the bus bridge module level verification environment. Similar test cases can also be constructed to include modules (such as SSC, ASC, USB, etc) that communicate to the external of the SoC.


Diagram (b) shows portion of the SoC that is under random verification.

Besides this, one must also take into account of including firmware verification environment in the system which can be easily ported across different projects that has similar firmware requirements. This is essential as firmware complexity has increases significantly due to the rise in system complexity.

4.   Silicon Validation using SoC verification Environment

It is seen that even though you spend several man months in verifying your design there is still a lot of effort that is spent on silicon validation. In order to attain a verification closure i.e. complete reuse of test patterns across boundaries of SoC verification you need the usage of higher level language such as ‘C’ for defining your routines, macros. You need to have common libraries between silicon validation and SoC environment to achieve this. Here the term libraries refer to a set of functions that are used in the tests. The parts that can be reused between the environments are the initialization files, macro definitions (functions), interrupt handlers, etc... It is possible to reuse them because these are the basic’s required for the tests in both the environment. You could have your validation patterns ready before your chip is back with the help of unified environment between   silicon validation environment and verification environment.

It has to be noted that your testpatterns for silicon validation should have some self checking mechanism. Your testpatterns should not be completely dependent on the monitor and checkers in the module to report an error since the debugging capability of your silicon validation environment will be different from that of your SoC verification environment.   

Thus it can be seen that this approach enhances the chances of debugging the pattern because of the visibility of the chip that you have in your SoC verification environment. It also reduces the effort of redeveloping the same set of patterns for validation.  You could also port additional patterns developed in your silicon validation environment to you SoC verification for debugging etc…

It has to be noted that when we port the pattern from silicon validation environment to the SoC environment for debug not all patterns can be debugged because of long run time in the SoC environment and limitations in the SoC verification environment.
 
Diagram (c) gives a brief description of your verification environment
 

Diagram (c) shows the structure of the verification environment for reusable stimuli file.

5. Essentials of Reuse
It is seen that conceptually you can reuse but practically it is not achieved at times because each SoC is associated with its own complexity. The key to reuse is to look into the way how the verification components are modeled.
Some of the keys for reuse are

1. Absolute paths are to be avoided in scripts and reusable verification components.
2. Common library files must be used to ensure complete reuse of testpattern across the various verification environments.
3. All stimuli files, scripts and project dependent files must be separated from the reusable files.
4. Monitor should be capable of being established and disabled in your SoC verification environment.
5. Directed and Random verification tests suites should be separated.
6. Proper Documentation of the verification environment structure and tests are necessary. It is usually seen that lack of proper documentation could also inhibit reuse.

In order to allow for verification environment to be ported and reused in different levels of design, it is important to follow a set of guidelines for creating reusable verification components for the next level of verification environment while one is building up the current level. This is essential in leveraging on the existing verification components rather than rebuilding them in the next verification level. Besides this, verification closure can be achieved through the use of higher level languages and common libraries. This would ease the task of validating the silicon in the final stages.
It is through portability, reusability and verification closure that one can cope with the rising design complexity of today’s SoC.