A Verification Methodology and Environment

Click Icon for a PDF version of this document.

This document lists the requirements for a next-generation verification environment, and describes characteristics of the environment that satisfy these requirements.

General Verification Requirements

There are several requirements that must be present in a verification environment to support tomorrow's designs.

Simple to Use
Creating new tests should be simple in the verification environment. The test writer should not have to understand all of the internal workings of the low-level programs used. High-level functions should also be available as test building blocks.

Long-Lasting
A verification environment needs to change and adapt for each new project. Therefore, the environment should not depend on any vendor-specific tool and should be able to be expanded as needed.

Speed
Most systems being designed today are very large and complex. Running the whole system using the RTL model is too slow. The verification environment should be designed to easily switch between high-speed behavioral and more accurate RTL models.

Easy to Implement with Different Tools
Most companies have slightly different environments for each of their design groups. It is important that the methodology and environment not prevent groups from using their preferred tools.

Provides Support for Regression
To maintain the quality of the simulation models, regression testing needs to be a standard part of the design flow, and should be supported by the verification environment.

Random Testing
All tests should be made as random as possible (all but the essential data should be randomly generated in an intelligent fashion). Using random tests will make the regression run differently each time, exposing problems that may not have been considered in the test plan.

Visible and Interactive
It is important to have high visibility into all models within the verification environment. This refers not only to capturing data during the run, but also to interactively examining and changing data during the simulation, which can shorten the debug time.

Intellectual Property Reusability
Models/tools developed for one project should be reusable in other projects. In order to reuse models and tools, well-structured code and clear documentation must be available.

Verification Metrics
A verification environment should use tools that help management make project-related decisions about the overall quality of the design.

Supported Tools
Tools used in the environment should be available from several external companies.

Self-Checking
A verification environment needs to be self-checking to support regression and random testing.

Revision Control
Every verification project should be under revision control. Each product should have a unique mark to ensure that the environment can be accurately re-created if problems occur.

Multi-Site Support
An environment should be easy to install at another site, and should enable groups to work in remote locations.

Extended Use of the Verification Environment
The verification environment used for designing the system should be structured to allow for as much reuse as possible in (physical) prototype debug.

Open Interfaces/Languages
A verification environment should be based on open languages and interfaces.

Future Extensions

A verification environment is not static, and will occasionally require the addition and/or removal of parts. The environment must be flexible, and designed to allow for these changes.

Possible future verification extensions include:

• Formal verification.
• Extension of the verification environment into the lab using programmable signal generators to communicate between the simulation and the real physical prototype.
• Emulation. Future designs may have to be verified with the aid of an emulator to get the required performance.
• Formal specification. Using a formal language for the design specification would make it possible to simulate the specification and still achieve consistency.

A Suggested Verification Flow

The following diagram illustrates a theoretical general verification flow. (Click Icon Below to see Diagram)

The flow can be seen as two parallel but interconnected tracks. The first is the RTL design, starting with an ASIC specification and going through RTL coding and synthesis. The second flow is the verification flow, starting with the verification specification and going through verification environment development and regression. This flow illustrates the methodology used by ASIC Alliance for design and verification, and is referred to as SYLVER™.

Design and Verification Tools

TestBenchPlus™
TestBenchPlus (TBP) is a generic tool that connects an HDL simulator to a high-level language like C or C++. TBP works with all major HDL simulators on the market.

SYLVER™ Highlights
ASIC Alliance's SYLVER (System-Level Verification Methodology and Environment) is a well proven state-of-the-art verification flow. SYLVER builds a high-speed environment by replacing as much of the system's HDL code as possible with C models called transactors. Most of the system environment is modeled using C, which simplifies the task of building self-checking, pseudo-random environments. Another component of the SYLVER methodology is the efficiency layer, which is a layer of system setup functions/routines, between the C models and the test writer, that aids in writing tests. By using the efficiency layer, test writers do not need to have extensive system knowledge; instead, they can use high-level functions like reset_system() or configure_channel_0().

A traditional approach of verification is to gather a list of functions to be tested, and complete tests for each item in the list until the verification is done. The SYLVER methodology uses a different approach. Most tests in a SYLVER environment are pseudo-random, that is, they test the ASIC (slightly) differently each time they are run.

The efficiency layer in the SYLVER environment makes it very easy to create extensive new tests without a deep knowledge of transport mechanism.

Instead of just marking off a list of individual tests, the goal with SYLVER is to run extensive system simulations on a large number of computers for a defined time (for example, a week) without finding any bugs. The verification is not considered complete until this goal is reached.

Verification Metrics

An important aspect of any verification environment is the ability to determine how well the verification runs are progressing, and how much of the system is not being covered. Two additional metrics should also be followed: bug and coverage tracking.

Bug Tracking
A bug tracking system must be in place to monitor items such as number of open bugs, bugs logged over time, and total number of bugs.

Coverage tracking
Coverage tracking can be used to understand how specific parts of the design have been tested.

Visibility and Interactivity
It is important to build an environment that supports maximum visibility and as much interactivity as possible for both the HDL and the software side.

Revision Control
A unified revision control with release control should be incorporated into every project.

Back To Top

Home | About Us | Solutions | Innovation | Jobs@Zaiq |News | Partners | Site Map | Contact Us