ABSOLUTE VERIFICATION METHODOLOGY BASED GENERIC

PROCESS FOR DEVELOPMENT OF EFFICIENT VERIFICATION IPS

SHRUTHI.G
Don Bosco Institute of Technology (DBIT), Assistant Professor, [email protected]
Bangalore, India.

VIVEK.S
Sibridge Technology Pvt. Ltd, Member Technical Staff, [email protected]
Bangalore, India.

ABSTRACT: Due to increasing cost and price of VLSI chips,a need for efficient way to verify the
IP designsresulting in chips to become fully operational is desired. This paper gives an insight on
how a generic methodology based Verification IP can be developed not onlyfor verifyingthe
designbut also integration with the same. Also reusability of Verification components are very
essential for reducing the turn-around time of the verification which is the major time consuming
activity in a chip development cycle.The proposed Absolute Verification Methodology aids in
faster approach to complete development of Verification IP.

KEYWORDS: Verification Intellectual Property (VIP), Design Intellectual Property, System

Verilog (SV), Universal Verification Methodology (UVM), Open Verification Methodology
(OVM), Register Abstraction layer (RAL), Interfaces (I/F), Bus Functional Models (BFM),
Hardware description language (HDL), Verification Components.

INTRODUCTION

Verification plays a huge role in any chip design. In a chip design cycle, verification consumes
around 70% of the time while only about 30% of it is spent on design. Completeness of
verification is extremely critical. IP design is done depending on specification which is designed
with research and development. When an IP is designed by using hardware level languages, one
cannot be sure of correct operation until the chip is fabricated. But fabricating a chip incurs a huge
expense for any organization. After fabricationif the chip fails to produce the required
functionality, it is termed as failure resulting in huge loss of time, cost and effort. Therefore a
Design IP is subjected to verification initially. Main concern of the whole process is time,
efficiency, cost and proper functionality. Also there is a need to make sure that a verification IP
should support customizability, reuse friendly, debug-able, complete operation check. As per the
industry estimation, close to approximately 60% of chip re-spins are mainly due to functional
bugs. Therefore good class Verification IPs can be developed only by forecasting the development
and with efficient process.

PURPOSE OF VERIFICATION IP

Designing an IP based on specification is done with HDL, but until the design is finished, the
verification effort cannot be started. This results in loss of time since some part of the design has to
the completed for verification effort to be started. Thus Verification IP comes for the rescue i.e.
Parallel process on development of DIP and VIP is done. All functionality of a DIP is modelled in
VIP in parallel. Verification services include Testbench design/development, test-suites, Bus
Functional Models, coverage-driven verification, constrained randomization verification, assertion
based verification.

OVERVIEW OF ABSOLUTE VERIFICATION METHODOLOGY (Absolute VM)

Process of development can be divided into multiple stages:

A-Forecasting,B-Implementation and C- Cessation

Testplan Test Bench

Creation, Architecture &
Specification Coverage plan, Bus Functional Tick list and
understanding schedules A
Assertion plan Modeling

Interface Abstract Optimization

definition & Testbench BFM
Testbench definition implementation
Architecture
creation
review Configurable Coverage, B
Sanity environment Assertion,
Environment architecture Monitoring
bringup development development

Functional
Normal operation operation Error injection Coverage
execution execution execution achievement
C

Code optimization &

Ticking of completed task

Figure 1:- Absolute Verification Methodology (Absolute VM) overview

Forecasting
Forecasting is the main process before development of any VIP. Forecasting before
implementation makes objective of verification clear. Lots of brainstorming needs to be doneto
come up with an idea on how the VIP can be efficiently developed. If the is no proper planning
then it results in re-work resulting in delay and confusion. In this phase, different objectives are
taken care like

Specification understanding
First step is to have some knowledge over the protocol before developing the Verification IP. A
run through of the specification is recommended at this phasefor better understanding of the any
specification.

Test-plan creation, Coverage Plan, Assertion plan

With the understanding of the specification it is time to create a document for coverages,
assertions and test-cases. Doing this enables to capture the features that needs to be verified. This
phase is very important as it reduces lots of time as the development progresses. This is a excel
sheet containing all the scenarios for verification. Starting from the basic test cases and ending
with complete functionality verification check proper scheduling, engineers allotment, status
check etc. are essential part of document.

394
Testbench architecture &BFM
With above two section multiple scan would have resulted in better understanding of the
specification.At this phase, definition of the test bench architecture and BFM is done. This is very
crucial phase as it can stand the test of time, hence need to be fool proof. Lots of brainstorming
should be done during this phase.

Tick list and Schedules

Once the definition of architecture is forecasted,defining a tick list helps in knowing the direction
at which the development progresses. And also respective roles can be assigned for effective
completion of the Verification IP. This helps in checking if any missing activity exists while
development.

Implementation

Architecture Overview
Discussion over the architecture is done ensuring every aspects has been taken care. This increases
the confidence in the architecture and prevent any further need to revisit. Development is started as
per the forecasted phases.

Interface definition, Sanity environment

A virtual interface is created that will be hooked with the DUT or any other interface, if available.
Basic sequencing is done with initial environment setup. Sanity tests are made to run, in order to
understand the stability of the environment.

Abstract Testbench, configurable environment architecture

Once the above phases are done, full-fledged development starts where in required configuration
on which the environment can be made generic is designed. BFM is developed for the
functionality. Key properties, members of different classesare developed. It defines the
structures/classes for environment, agents, drivers, sequencers monitors, scoreboards, assertions,
checkers, sequences, test cases etc. Under this phase, test bench methodology which supports
generic way is supported. Methodologies like OVM, UVM can be made generic by using a
wrapper over the components that are created. For example, the same environment can be made to
work in OVM environment or UVM environment based on the run command. By this generic
method, flexible approach in having multiple environment for any integration is achieved. This is
achievableby having all components below agent level to be in SV, resulting in generic
methodology. OVM/UVM supported wrapper should be developed for driving or receiving of
data on the interfaces.

Optimization BFM, Coverage, Assertion and Monitoring

For faster simulation, optimized code is essential. Hence during this phase, BFM is optimized and
made generic. Parameterized classes, configurable data, constraint randomizations are covered in
this phase. Forecasted cover groups are developed for coverage of the protocol. Assertion
properties are incorporated in the design to check the correct working of the protocol. Separate file
can be maintained which is hooked on the interface, for checking the protocol. In other words,
monitoring on the interface is done for checking the functionality, timing related issues etc.

395
Cessation

Normal operation execution

With the above development, good shape and frame for the Verification IP is done with all
meaningful classes, components and BFM. Basic functionality should be verified, but this requires
logics and appropriate test case implementation.

Functional operation execution

Based on the test plan, coverage plan and assertion plan, all the operations are implemented. This
is main phase where full functionality should be achieved. Feature should be proceeded with care,
i.e., step wise development of feature needs to be done. For example, basic read write operation
should be completed before proceeding to speed change, multiple data interface etc. This helps in
incremental development of the design where the design is verified in small parts rather than
verifying it as a whole. Revisiting of the code can be avoided by this approach.

Error injection execution

Once basic operation and functional operations are working, erroneous scenarios has to be targeted
because verification is all about erroneous scenarios. A protocol is specified to work in a defined
manner, but when undefined scenarios are exercised, the VIP should be capable of issuing errors
and recovering from it. For example, CRC calculation is done by device during data transactions
an error may be injected into the calculated crc to check if the host is capable of detecting it. This
ensures that correct functionality of the DUT, or for that matter, the capability of recovering from
errors can be verified.

Coverage achievement
For the functional completeness of VIP, coverage has to be 100%. To attain 100% coverage,
multiple test has to be created with different scenarios to address any missed bins. Cover groups
should address all the essential part of the specification to be covered. Functional verification is
very important in achieving the completeness of verification. Coverage should include checkers as
well because no checker should have triggered. If any checker is triggered then the coverage
should go low resulting is lower result of coverage.

On every phase the tick list should be marked based on completion of the development. Discipline
coding, well commented, reusable method, etc. has to be done for development of good VIP.

CUSTOMIZABILITY OF VIP

Customizable verification IP should support the features as mentioned below:

Test Suite
Precise document containing full functionality verified is mentioned. Multiple tests are
invokedthrough command line. During the run on multiple tests, a mechanism called as seed is
used. Based on different seeds different randomization is done by which many scenarios can be
achieved. By running the test suite multiple times, a lot of bugs can be found because of
randomization. Every seed is distinctive in nature and gives a different randomization. But a
controllability should be provided to track the seeds runs and their history of run. Command line
should provide flexibility to run different seeds for different test cases.

396
 Constraint
randomization Control over
Test Suite
and log verbosity
configurability

Verification
Customizability Control over
component
of VIP feature support
integration

Checkers Register
Methodology
disabling on interface
generic
purpose

Figure 2: Customizability of VIP

Constraint randomization and configurability

Verification IP should provide a flexibility to control the configurable parameters. Configurable
parameters like disabling checkers, disabling passive components, data width, direction
controllability, clock frequency, component type, coverage for checkers etc. should be provided.
According to specification the constraints are added. However, in some cases, error constraints are
to be added to find the issues in the DUT. As transaction class has many packet variables,
flexibility of extending it should be provided with constraints support.

Verification component integration

A VIP should be easily integrated into the clients environment hassle free. Proper documentation
about the packaging and releases of the VIP results in better understanding to the clients. Easy
hooks to integrate the monitor or scoreboards has to be provided. The test bench of the client will
have a top module in which DUT resides and plugged according to the hooks without disturbing
the test bench.

Control over log verbosity

When multiple VIPs are used for verification huge logs are created which gives rise to the need
for more storage space. Controllability on logs has to be provided in development of VIP for better
tracking of the logs. For instance if there are two VIP in a test bench, VIP1 and VIP2. Consider
VIP1 has thoroughly verified the DUT, it is not required for the debugger to get the log as it results
in slowing down of simulation and huge log generation. Thus verbosity has to be added
accordingly to reduce the log generation for different VIPs.

Control over feature support

Specification has basic features, mandatory features and optional features. Based on the
application, DIP may have some features which arenot implemented. Hence to avoid verification
of the unimplemented features a VIP should provide control over it. User should be given easy
access to disable any features, if required. But a VIP should still contain all functionalities. All
features i.e. optional or mandatory should be incorporated in VIP.

397
Checkers disabling
Erroneous scenarios are required to have its checkers disabled because it is expected to fail.
However, in this case, the failure of the checker implies the success of the test. Hence, an option to
disable checker should be provided to avoid a failure in report or in some cases, the stall of the
simulation.

Register interface
Most of the DIPs have their registers for configuration or self-capability. These registers has to be
flexible enough to be written in zero time, based on which the DIP can function accordingly. UVM
provides a mechanism called as RAL. Using RALa verification engineer can read or write the
registers without consuming any simulation time. Various operation like front door or back door
mechanism support has to be provided.

Methodology specific
Developing the VIP specific to a methodology is not recommended as the same VIP can be used
for different environments. Therefore the same VIP should be capable of supporting industry
standard methodologies like UVM, OVM or basic SV. Once the flexibility is there, same VIP can
be distributed to different environment without much effort. This saves a lot of time after
development and any resolution to a bug will automatically be resolved for all methodologies.

INTEGRATION OF VIP WITH DIP

The Active VIP is configured as Device. In the verification environment the Active VIP is
connected as shown in Figure 3. Active VIP is responsible to generate stimulus to the Host DUT,
while Passive VIP is also responsible to check functional integrity of Host DUT. The scoreboard is
implemented between Active VIP and Passive VIP to validate the Data integrity.

Passive VIP

Bridge Interface DUT Interface Active VIP Bridge Interface

Figure 3:- Integration of Active and Passive VIP with DIP

In this environment, one instance is configured as a Passive Host VIP and the second is configured
as a Passive Device VIP. The verification environment is shown in Figure 4, where Host DUT and
Device DUT is connected. Here the Passive VIP checks the data integrity, operation functionality
check and functional coverage. Both Host DUT and Device DUT is verified by this above
integration.

Passive VIP

DUT Interface DUT Bridge Interface

Figure 4:- Integration of DIP with Passive VIP

398
CONCLUSION

Efficient process of developing generic verification environment is explained. By this approach

redesigning the architecture, repetitive works can be eliminated. Time and cost of development can
be minimized and systematic approach is achieved. Absolute VM helps in reusable development
as it helps is supporting multiple environments which is flexible to the client who are procuring the
VIP. Accuracy of verification is maintained and parallel verification during development of DIP is
achieved. Multiple verification environment following Absolute VM is easy to debug and
maintain. We are currently working on generic reusable architecture, wrapper for multiple
methodology and automated register support for VIP.

REFERENCES

IEEE Computer Society. IEEE Standard for System Verilog-Unified Hardware Design,
Specification, and Verification Language - IEEE 1800-2009. 2009
Accellera Organization, Inc. Universal Verification Methodology (UVM) May 2012.
Mark Glasser, (2009) Open Verification Methodology Cookbook, Springer 2009.

399