In large system-on-chip (SoC) and ASIC design projects, functional verification is typically on the critical path due to the large verification space of these designs. Even if one could construct a coverage-driven testbench with directed random tests to explore the entire verification space in a reasonable amount of simulation time, the predictability and correctness checking of the results may be difficult or even impossible when the design under test (DUT) is considered to be the entire design. 

 

Thus, large designs are typically partitioned into smaller logical blocks that are tested individually. Since the cone of logic is smaller when considering a block as the DUT rather than the entire design, it is easier for the testbench writer to control the stimulus to cover the verification space as well as predict the results.

 

Although verification at the block level reduces the verification space and provides more detailed checks of the DUT, by itself it may be insufficient to fully test the design. A larger testbench that includes a set of blocks (superblock) or covers the entire chip is required to test the interactions between blocks.

 

One could argue that if block-level testing is perfect in the assumptions made at the drivers and monitors, this type of problem could be avoided, perhaps rendering superblock and chip-level testing unnecessary. Although this may be true in theory, it is difficult to achieve in reality. In addition, superblock and chip-level environments provide a means to validate architectural assumptions that may be difficult or impossible to model and test at the block level. Thus, block, superblock, and chip-level testing are required for full verification of large designs. Verification at these various levels is referred to as hierarchical verification.

 

Hierarchical verification provides a comprehensive method to verify a design. In order to streamline the verification process and make efficient use of engineering resources, hierarchical verification requires reuse and leverage of verification components from one level to the next. One type of hierarchical verification methodology allows for reuse of all components from one level to another. In this methodology, the entire verification process starts at the lowest level blocks.

 

To achieve reuse of the environment, each block environment is based on a common methodology that provides a set of base libraries to assist in migrating to the next level environment. The libraries provide a common language, structure, and APIs.  In addition, since the verification structure is very rigid, inter-component connections are predictable.

 

As a result, intelligent scripts or algorithms can be created to provide assistance, such as connecting up the design verification (DV) components depending on whether or not a neighboring RTL block is present in the environment. In addition, the base library can automatically control whether a block is driven by the DV drivers or by the neighboring RTL. The main goal of this approach is the ability to reuse the entire block environment at the superblock or chip level. 

 

Although this hierarchical verification methodology provides a very easy migration path from block level to chip level in theory, experience has shown that this methodology does not scale well for large designs and introduces dependencies and inefficiencies. In order for chip integration to occur under this methodology, all block environments must be complete and stable. 

Since the chip level checker is composed of a collection of block checkers, if one of the checkers is not working properly, this will stall chip-level testing until the block-level checker is fixed. In addition, the intent of block-level and chip-level testing is vastly different and by bringing the entire block environment to the chip will introduce simulation inefficiencies.

 

The idea of reusing and leveraging DV components from one environment to another can still provide efficiency benefits, as well as reduce the schedule risk if the dependencies can be reduced. The challenge is to find the right balance between full reuse and no reuse in order to reap the benefits of the two methods. 

 

Finding the right balance of reuse to achieve maximum efficiency is difficult, will vary from project to project, and will depend heavily on the team composition. However, by developing a selective reuse methodology, the option to promote an environment component from block level to chip level is available. Therefore, reuse can be achieved when necessary to improve efficiency in environment development or DUT debug.

 

Selectively choosing the verification components to be reused can provide several advantages. First, it can still provide the reuse efficiency gained in the previous approach of full reuse. Common components do not need to be redeveloped for a different level of verification testbench; they can be shared between blocks, superblocks, and the chip level. Second, by only choosing a set of components to leverage, the chip-level testbench environment will be lighter weight, thus providing better simulation speed. Finally, the option to not reuse some of the verification components at various levels removes the dependencies one environment has on another.

 

The remaining sections will focus on how to build a verification methodology for selective reuse of verification components at various levels.

 

The first step to allow for reuse is to advocate a common methodology for all the environments. The best way to achieve this is through object-oriented programming by using base classes for the components. All of the components will need to derive from the base classes, which provide helper functions and structure for the environment.

 

The base class will help enforce structure for all the verification components in order to allow for reuse. This base class can contain common components such as logging mechanisms and other helper methods. In addition, this base class will automatically construct a component hierarchy and thus provide a unique identifier to each environment component. 

 

The constructor for the base class will take in a parent handle and the instance name of the component. As each component is instantiated, a parent-child relationship will be constructed, and the hierarchical name based on the component name will be built. With potentially hundreds of components in the testbench, this method is helpful for identifying a particular component for controllability. An example component instantiation is illustrated in Figure 1.

 

 

In Figure 1 above, the instance name of each component is in bold with the full hierarchical path to the component below it. As each component is instantiated, the hierarchical name is automatically constructed. Since the hierarchical name is unique, this name is useful during logging to identify which component is printing out the message. 

 

In addition, this unique identifier can be used to control the logging at various levels of the environment. For example, the user can enable verbose log messages only for components under top.mon_wrap.mon_2. Another use of the hierarchical name will be for writing aspect-oriented programming (AOP) tests and will be discussed in a later section.

 

The base class provides structure to develop the user classes. However, the issue remains how to integrate third-party libraries such as Verification Methodology Manual (VMM), which also provides base classes. These third party libraries provide a solid foundation to build the rest of the verification methodology by offering many basic components such as logging and thread communication. 

 

Since SystemVerilog does not allow multiple inheritance, third-party base classes must be at the root of the inheritance hierarchy or in the middle of the inheritance hierarchy. The former is not always practical as not all components may require the full functionality of the vendor’s base class. The better approach would be to allow the third-party base class to be in the middle of the inheritance hierarchy.