Proposed Reusable Verification Environment Architecture

Thanks to Moore’s Law “The numbers of transistors that can be placed on
a semiconductor die doubles approximately every 18 months”.
From 1965 till date the density of transistors on the die is increasing which
in turn result in to exponentially increase in the complexity of the whole SoC
design
Verification challenges increases drastically as time to market becomes
crucial for every company. Some companies are having their legacy
environment which exists from long and some is moving towards latest UVM
based env, so it is very important that VIP’s should designed and architected
in such a way that it meets all the required scenarios as well as met time to
market.
Through this paper I will try to put sample environment architecture which is
fully reusable at every level. To move ahead it is very important to highlight
on important question- why reusable?

Why reusable?
As design complexity is increasing and as a result 50-70 % of total effort
goes in to verification. Due to complexity risk is also rising exponentially.
Reusability will provide:
1. Build effort will reduced.
2. It will decrease the verification risk.
3. Team gets ready to use the VIP with limited expertise of
technology/protocol.
4. Easy to integrate with existing environments.
5. It is easy to take multiple instantiation.
6. Test case development is comparatively easy.
7. Post sales support needs will reduce exponentially.
Verification Environment Components and Industry best practices:

In this section we will brief about each verification component shown above
in figure1 and the best practices followed to make it as reusable
components.

1. Scoreboard
2. Checker
3. Monitor
4. Coverage
5. Data/Transaction/Messaging
6. Scripting/Directory Structure
7. Documentation

Scoreboard
Purpose of the scoreboard is to collect data and compare the same. i.e. data
integrity.
Scoreboard should be designed in such a way that it can be easily integrated
at:

• Block level
• End - End level

Scoreboard should independent component it should not depend on any BFM
or Monitor signals. Scoreboard should be parameterized. There should not be
any hardcoded/constant value for any items/fifo/memory etc.

Checker
I would suggest dividing the checker in to five parts:

• Timing Checker
• Functional Checker
• Clock checker
• Reset Checker
• x/z checker

I suggest all the above checkers should be develop using system verilog
assertions to the extent possible. In addition there should not be any fixed
values, it should be configurable.
Also checkers should be designed in such a way that it can be plug without
dependency on any of the other verification components.

Monitor
As shown above in the architecture, monitor is classified in to –

• BFM monitor
• Active Monitor
• Passive Monitor
• Interface Monitor

Monitor job is not only to monitor the activity on the interface but it has to
even deliver the data to scoreboard and checker. Point should be taken care
that monitor should not snoop any design signals even it should not have
any dependency on scoreboard and checker to complete its activity. It
should have a capacity to work as an independent component. Monitor
should have a facility to disable/enable it’s functionality as per user needs.

Coverage
Coverage can be classified in to –

• Functional coverage
• Checker coverage
• Test coverage

Coverage should be designed in such a way that we can separate
implementation and non-implementation specific coverage for reusability.

Data/Transaction/Messaging
Data/Transaction is a very important part of any environment. It should be
designed in such a way that we can make maximum use of randomization.
Constraints on data items is written in such a way that it does not contain
any fixed values e.g if we want to generate address in range 32’h00-32’h0f,
we have to pass config field to set the values , this way of design will give us
mode of reusability.
Messaging plays a very crucial role; it should be clear and distinct. Some of
the common messaging rule which we can follow is to have a separate id for
each id/note. In addition we have to put a clear thought on termination
messages. Special care needs to be given on formatting of the message.

Scripting/Directory Structure
Scripting is a very important part in automation. Scripting should not contain
any absolute path. Directory structure should be kept simple. Script should
be designed to create a complete directory structure and brings only the
necessary files. Even we have to take care that user does not have to pass
more option to generate the requested data.

Documentation
Plays a very crucial role, I would recommend three different type of
documentation:

· Integration document – It will highlight ways to connect
components. E.g How to connect scoreboard at block level, end-end
level etc. In case of Ethernet VIP this document will highlights the way
in which VIP can be used as a MAC or PHY. In case of PCIe documents
will highlight the ways to use it as End-point, Root Complex or Switch.

· Configuration document - In this document we should highlight the
different ways in which we can modify BFM, data class, scoreboard,
checker and monitor. E.g If we want to configure VIP for x4 lane this
document should highlights the corresponding parameter or macro
which users need to configure to make all the Verif components work
in x4 mode. This document should also highlight the test related
configuration that user can set to generate the desired scenario.

· Architecture document – Intention of this document is to give
detailed information about the whole VIP starting from licensing,
directory structure, scripting to architecture and internals of the same.
This should be the ultimate guide for the user.
Above practices will not only ease the life of verification engineer but
definitely increase the quality of verification and not needed to say that it
will save time and help companies to tap time to market.