How to Automate Millions Lines of Top-level UVM

Testbench and Handle Huge Register Classes

Namdo Kim, Young-Nam Yun, Young-Rae Cho, Jay B. Kim, Byeong Min
Infrastructure Design Center
Samsung Electronics Co. Ltd.
Yongin-City, Korea
nd.kim@samsung.com

Abstract—Not only design automation, but also testbench (TB) This paper explains the factors that need to be considered in
automation heavily affects design period, so that diverse TB the automation of SV UVM-based top-level verification
automation solutions have been developed and applied to the environment and eventually how to automatically generate
verifications ranging from IP level to top-level. Top-level 1.8M lines of TB. It will also show that not only the size of
verification environment is much more complex and big, DUT but also the size of TB impacts simulation performance
approximately 2M lines of code (LOC), so automatic generation and will show a simple TB management skill that could
of top-level TB is an inevitable process for competitive design enhance simulation performance by 50%.
period. This paper presents an experience of SV (SystemVerilog)
UVM (Universal Verification Methodology) TB automation on an
over 100M gate top level SoC design. Most of the TB, 88% of 2M II. TOP LEVEL UVM TESTBENCH OF SOC DESIGN
LOC except test scenarios and user codes, has been automatically
generated by the proposed automation solution. The automation
solution has strong flexibility and high level maintainability upon
frequent specification changes. Also, the configurable TB for
various DUTs resulted 50% simulation performance
enhancement.

Keywords – Verification, SoC, SystemVerilog, UVM, testbench

I. INTRODUCTION
Fig 1. Testbench architecture
One of the problems in SOC verification area is that users
have many choices in verification language which are Verilog, 150M gate AP processor has multiple hierarchical buses
SystemVerilog, Vera, Specman e, and system C. More and various IPs which have tens to hundreds registers
complicated burden to the users is SystemVerilog and three configured by AXI. A verification environment for the AP
verification methodologies, OVM, VMM, and UVM, co- processor in Fig. 1 basically requires VIPs, register adapters
existing in this area. Mentor Graphics and Cadence support that convert generic register transaction into bus transaction
OVM and Synopsys and ARM is on the VMM. However, the [3], dozens of local verification environment, tens of thousands
standard organization, Accellera, announced UVM 1.0 and of register modeling, hundreds of test scenarios ranging from
UVM 1.1[1] in 2011, the battle for dominance seems likely to simple register access tests to complicated tests, and top
lean to UVM because many companies started to actively use module which instantiates DUT and TB.
UVM as a major SV verification methodology.
The Universal Verification Methodology (UVM) standard,
developed by Accellera's Verification IP (VIP) Technical
Subcommittee (TSC) [5], is available as a Class Reference
Manual accompanied by an open-source SystemVerilog base
class library implementation and a User Guide. The UVM
standard establishes a methodology to improve design and
verification efficiency, verification data portability and tool,
and VIP interoperability [2].
Generally, a verification environment consists of multiple
verification IPs (VIP) for various protocols, reference models
for expected data generation, scoreboard for data integrity, test
scenarios for various functionality, and scripts for maintenance
of simulation process. Unlike the IP-level verification
environment, which has the DUT less than a multi-million gate
design, a top-level verification environment requires more Fig 2. Ratio of top-level SoC TB
considerations when its DUT is over 100M gate SoC.

978-1-4673-2990-3/12/$31.00 ⓒ2012 IEEE

-3- -
- 405 ISOCC 2011
ISOCC 2012
 Fig. 2 shows the code analysis result on a top-level SoC easily explore codes and quickly reflect changes on either the
TB. Register modeling[4] and register access tests occupy most TB template codes or the parse and generator codes.
repetitive codes, while TB architecture and verification
environments take very small portion of codes. Two noticeable
things from the analysis are huge volume of repetitive codes
and small portion of complicated integration between
verification components. Obviously repetitive codes need to be
automated not to waste human efforts in error-prone repeated
works. Regarding the complicated integration parts, the size of
those codes is very small compared to register related code.
However when it comes to code complexity, it seems that both
initial building integration parts of code and updating them
after the initial building would demand huge human efforts and Fig 3. SV template codes for register model
expertise in both SV and UVM.
Fig. 3 shows a SV template code example for register
AMBA VIP related codes seem a good automation modeling. Based on the template, 1.7 M lines register classes
candidate because its configuration and register adapter layer has been generated with the excel inputs. Other TB codes like
which converts generic register’s transaction into AMBA’s VIP integration, TB architecture, configuration file, and
transaction are very straightforward and could be reusable as it register access tests are generated based on predefined SV
is. Moreover, TB environmental codes and running scripts need template codes. The SV template codes are implemented based
to be automatically generated due to their complex hierarchy on TB that had been applied to real project.
and huge options.
IV. DYNAMICALLY CONFIGURABLE TESTBENCH
III. AUTOMATIC ESTABLISHMENT FOR MULTI-MILLION COL
TESTBENCH Generally simulation performance is affected by design size
and time precision. Therefore securing mandatory design
As listed in previous chapter, automation candidates are blocks only for each data path is indispensable to performance
register modeling, register access test scenarios, TB in over 100M gate top-level simulation. According to data
architecture, skeleton of verification environment, VIP path, design blocks are selectively excluded and dozens of
configuration, environmental codes and running scripts. DUT are defined for a SoC. Fig. 4 shows the description rule
Once above top-level SoC TB is automatically generated, which defines a DUT called “PERIPHERAL” and final
design or verification engineers have to supplement user codes compilation options. And Fig. 5 shows configured TB
in it. To generate proper TB for a specific SoC, design architecture based on definition of Fig. 4.
specification in term of verification point of view need to be
provided to an automation solution [6]. In order to capture TB
intent, two type of excel sheets have been developed. One is
intended to hold project information, and the other is for IP
information. The project information is list of IP, address map,
type of bus attached, etc... In the IP description, list of register,
access type, offset, initial value, etc… are specified.
While verification period, design specification had been
changed frequently due to various reasons. If the design
specification changes affect TB codes, then, TB has to be
rebuilt. However not all of TB has to be regenerated but some
Fig 4. Description for dynamic configuration
of portion, register modeling, need to be regenerated and other
part of codes touched by users should be remained still. To
make sure that user touched codes are not overwritten by TB
rebuilding, a utility just for generating register modeling off
from an automation solution.
Less than design specification changes but changes on
either TB architecture or skeleton of verification environment
come with maintenance issue of automation solution. If
template codes of TB, parser, and generator codes in an
automation solution are all mixed together, it would be very
hard to explore codes to be updated and to maintain the codes.
To easily maintain an automation solution, template toolkit has
been used to implement template codes of TB. The template
Toolkit is a fast, flexible and highly extensible template
Fig 5. Configurable TB
processing system [7]. Template codes of TB are separated
from parser and generator codes. Therefore, developer could

978-1-4673-2990-3/12/$31.00 ⓒ2012 IEEE

-3- -
- 406 ISOCC 2011
ISOCC 2012
 There is one more thing that’s important to simulation
performance. The number of SV classes badly affects
simulation performance next to the size of design and 95% of
classes in TB are from register modeling. Thus, the concept of
minimum set of blocks for specific data path has been applied
to register modeling instantiation similarly. The register model
instances are selectively chosen based on individual DUT.
Fig 6. Register model for configuration
Fig. 6 shows an example of configurable register model.
Only necessary verification environments for individual DUT
are defined in configuration file. Out of tens of thousands of
register instances, only thousands of register instances are
included in each DUT. 50% simulation performance
enhancement could be achieved with the configurable TB.
978-1-4673-2990-3/12/$31.00 ⓒ2012 IEEE
-3- -
- 407
V. &21&/86,21
This paper showed a TB automation experience on an over
100M gate top-level SoC verification. With the automation
solution, 88% of 2M line TB can be generated based on a
simple excel file. Through the generated TB, register access
tests for each IP can be started in the early stage of design
cycle.
By splitting the register generation solution, TB has strong
flexibility in frequent design specification changes. Template
based code generation gives high level maintainability.
Configurable TB technique is applied to beat performance
degradation and it results 50% simulation performance
enhancement.
Besides, the proposed standard naming convention and TB
architecture help designers easily communicate and quickly
jump into another project without additional learning curve.
VI. 5()(5(1&(6
[1] Accellera, UVM 1.1 Reference Manual, 2011
[2] Accellera, Universal Verification Methodology (UVM) 1.1 User ̉ s
Guide, 2011
[3] Sharon Rosenberg and Kathleen A Meade, ̌ A Practical Guide to
Adopting the Universal Verification Methodology(UVM)̍, Cadence
Desgin Systems, 2010
[4] UVM 1.1 kit - includes UVM base class libraries - Free downloads -
www.uvmworld.org (choose Download)
[5] Accellera Organization Inc Verification Intellectual Property Technical
Subcommittee.
http://www.accellera.org/activities/committees/vip
[6] Young-Nam Yun, “Beyond UVM for Practical SoC Verification”,
ISOCC, 2011
[7] http://template-toolkit.org/
ISOCC 2011
ISOCC 2012