AXI based DMA Memory System Testbench

Architecture Using UVM Harness Technique

Anjali, J. P. Anita
Department of Electronics and Communication Engineering
Amrita School of Engineering, Coimbatore
Amrita Vishwa Vidyapeetham, India
anjali.jangra75@gmail.com, jp_anita@cb.amrita.edu

Abstract— SoC (System on Chip) designs have become
increasingly complex and dense containing multiple subsystems.
Functional verification of such multi-block systems demands the
need for a highly reusable and scalable testbench. Universal
Verification Methodology (UVM) test bench addresses these
needs with some challenges. In a traditional UVM testbench, each
signal on every block needs to be reconnected to its interfaces in a
system testbench. But, this task becomes ominous when there are
multiple blocks with many signals requiring reconnections. Such
connections also limit the ability to inject stimulus into any
portion or block within the system. Enhanced UVM Harness
technique provides a solution to these challenges. With this
approach, connections made in a block-level test bench can be
reused in a multi-block testbench and specific blocks within the
system can be tested without any changes to testbench. In this
paper we have applied enhanced UVM Harness technique to
verification of AXI based DMA Memory system and
demonstrated verification of a specific portion - AXI based
Memory without changes to testbench. We have analyzed the
benefits and challenges in enhancing an existing UVM based
testbench to support Harness technique.
falls apart for multi-block test benches [5]. To make writing
testbench easier better approach is to use a reusable harness.
Using Harness connections made in a block-level test bench
can be reused in multi-block level testbenches. Also, a set of
harness can be grouped together into virtual harness which can
be used to connect system-level environments to sub-modules
[6]. In this paper, we have compared the UVM testbench with
and without UVM harness technique by presenting the analysis
of DMA Memory system verification.
The rest of the paper is organized as follows: section II
gives a brief introduction over UVM testbench architecture and
UVM Harness technique. The main features provided by UVM
harness technique related with conventional UVM is also
discussed. In section III explanation of implementation of
UVM harness technique on DMA memory system is given.
Section IV discusses about limitations and challenges. Finally,
section V describes and analyzes all the verification results.
II. UNIVERSAL VERIFICATION METHODOLOGY HARNESS

Keywords—UVM; RTL; DMA; multi-block; harness; A. UVM Architecture

I. INTRODUCTION
In 1965, Gordon Moore predicted that in a single integrated
circuit number of transistors will get doubled in every two
years and this exponential growth would continue further.
Because of this growth, the verification of the design has
become more complex and time taking. Hence, new tools and
methodologies are needed with the increase in state space for
verification.
The Universal Verification Methodology (UVM) offers
base class libraries for developing reusable, robust and scalable
test benches [1]. An UVM testbench is composed of reusable
verification components such as monitor, agent, driver,
sequencer and environment which helps verification engineer
to find more bugs earlier in the design process ([2], [3]). UVM
verification components are consists of a complete set of
elements for stimulating, checking, and collecting coverage
information for design under test (DUT) [4].
In every UVM testbench, signals in RTL are connected to
test environment using System Verilog interfaces. This
approach is fine to use for single-block level test benches, but it
The UVM offers class library which provides generic
utilities, such as configuration database, transaction library
model (TLM), component hierarchy, which facilitates the
verification engineer to create robust, reusable and scalable
testbench [7]. UVM adopts all advanced features of System
Verilog [8]. It reduces effort to write testbench code. In UVM
testbench typically connections between the Design under Test
(DUT) module and the UVM Test class is done by instantiating
and configuring the connections between them [9]. As shown
in Fig. 1 [9], traditionally, DUT is connected to a UVM
verification by declaring one or more interfaces inside a
testbench module and connect the DUT and interfaces together.
This This traditional way of connecting interface and
verification component is not ideal in following cases:
• Verification of multiple design versions with different
number of interfaces.
• Frequent hierarchical changes in design.
For any change in design related to DUT’s port or
hierarchy, testbench developer needs to make changes in all
interfaces and spend time re-compiling and debugging again.

978-1-7281-5523-4/19/$31.00 ©2019 IEEE 152

Authorized licensed use limited to: UNIVERSITY OF BIRMINGHAM. Downloaded on May 11,2020 at 04:33:45 UTC from IEEE Xplore. Restrictions apply.
In case of multi block level design, it becomes difficult and
time consuming to make changes in all interfaces connected to
the design and chances to make any mistakes also increases.
Fig. 1. Traditional interface handling in UVM
B. UVM Harness Technique
1) Interface Ports
The basic harness is a wrapper interface that instantiates all
the interfaces to be connected to a target module. In UVM
Harness technique all signals are required to declare as net
ports instead of variable inside the interface. Inside interface
additional signals can be defined provided that connections to
the DUT will always be made to the interface ports as shown in
Fig. 2[9].
Fig. 2. Declaration of signals as ports in interface in UVM Harness technique
2) Interface Binding
The interface is bind to the module using System Verilog
bind directive. This is like instantiating an interface inside of
DUT as shown in Fig. 3[9], which eliminates the need for the
testbench module to instantiate any interfaces. And since, the
connections of an interface are made to the port names of the
module and hence the connections are always valid for each
instance of this module. Using this technique interface
connections becomes independent of module hierarchy, which
makes it reusable between testbench environments. This
minimizes the time for testbench developer to write testbench.
Fig. 3. Traditional vs. UVM Harness interface placement
2019 9th International Conference on Advances in Computing and Communication (ICACC)
Authorized licensed use limited to: UNIVERSITY OF BIRMINGHAM. Downloaded on May 11,2020 at 04:33:45 UTC from IEEE Xplore. Restrictions apply.
In UVM Harness technique, all the signals in interface are
declared as input ports [9]. And later using System Verilog
feature of port coercion we can drive any signal in any
direction as per our requirement [10]. This makes testbench
more flexible to use. In this approach, declaration of inout ports
in interface is avoided, as they cannot tolerate changes in signal
widths [9]. Input ports allow us to use max-width interfaces
that support connections of smaller width while allowing the
simulator to coerce the port directions during elaboration.
This technique allows user to modify signal widths anytime
while writing the testbench without making any modification in
module instances. Using System Verilog bind directive, we can
bind interface connections to module instances for different
parameterized signal widths [5]. Also, without changing any
interface connections and recompilation Agent role can be
changed between active and passive or between master and
slave depending on the target module [9].
III. TESTBENCH ARCHITECTURE FOR DMA MEMORY
SYSTEM
DMA Memory System consists mainly of two blocks: AXI
based Direct Memory Access (DMA) controller and AXI Slave
based Random Access Memory. Configuration of registers is
done with the help of Advanced Peripheral Bus (APB).
With traditional UVM approach, interfaces are created at
the testbench top module and connected to DMA Memory
System instance. Here, all the interface connections are made at
top level. Reference of interface instance is passed to
corresponding drivers within agents, in which the stimulus gets
driven.
With UVM harness approach, test bench architecture is
modified as shown in Fig. 4. Interface harness is created for
individual blocks - DMA and AXI slave and are bind together
using System Verilog bind directive.
Fig. 4. DMA Memory System Block Diagram using harness technique
153
 Interface port of all the interfaces within each harness are
declared as inputs as shown in Fig. 5. The direction of these
ports gets controlled with System Verilog port coercion
feature. This can be seen in action with AXI interface, which
acts like a master in block level tests and becomes passive
agent during system level tests.
We have enhanced an existing traditional UVM AXI agent
to support harness technique with following steps:
Step 1: Declare all AXI interface signals as input ports.
Fig. 5. AXI interface signals declared as input ports in UVM Harness technique
Step 2: Provide controllability of port direction.
Add clocking blocks, events and functions in AXI interface
to provide controllability of port direction to the driver as
shown in Fig. 6. Based on the test configuration, driver can
trigger and wait for events within interface to accordingly drive
or observe the ports.
Step 3: Modify AXI driver to support driving interface
ports instead of signals as shown in Fig.7.
2019 9th International Conference on Advances in Computing and Communication (ICACC)
Authorized licensed use limited to: UNIVERSITY OF BIRMINGHAM. Downloaded on May 11,2020 at 04:33:45 UTC from IEEE Xplore. Restrictions apply.
Driver needs to drive signals declared inside output
clocking block within AXI interface and call the output event
triggering function. Input signals needs to be accessed from
input clock blocking.
Fig. 6. Function to convert input output signals
Fig. 7. Driving stimulus onto interface ports in AXI driver
Step 4: Create Harness interface.
An interface referred as harness is created for each target:
DMA Harness and AXI Memory Harness. Also, instances of
each individual block level interfaces – clock reset interface,
APB interface and AXI interface are created within its
corresponding block harness interface.
Within DMA Harness, APB interface is instantiated and
connected to DMA module’s APB signals. Within AXI
154
Memory Harness, AXI interface is instantiated and connected corresponding design block is skipped from compilation,
to Memory module’s AXI signals as shown in Fig. 8. shown in Fig. 12.

Fig. 8. AXI interface harness Fig. 9. Polymorphic Harness implementation

Step 5: Create polymorphic harness, set interface instances
in configuration database and bind harness to design module.
A polymorphic harness referred here as ‘pharness’ allows
us to embed functionality in the harness and provide additional
control over harness to testbench components [11]. As shown
in Fig.9, each harness is connected to its corresponding block
with the help of bind statement. Interface instances are then set
in configuration database.
Step 6: Update agent configuration class to support roles.
As shown in Fig. 10, configuration abstraction of test
bench agents is achieved through ‘role’ handle which an
enumeration that gives options for the test to configure
individual block agents as acting_on, just_looking or blind [9]. Fig. 10. Define configuration roles for each block environment
Step 7: Modify UVM environment to support role-based
configurations. Step 9: Write block level test and set appropriate roles for
sub blocks within system.
In the build phase of environment, based on block level
configuration, corresponding agents can be either active or As shown in Fig. 13, in the build phase of directed block
inactive, shown in Fig. 11. level test, set the role of block level test environment which
needs to be made active or inactive [9].
Step 8: Create stubs for design blocks.
With UVM Harness approach, we get the flexibility to run
When targeting a particular design block, other blocks gets tests either on entire DMA Memory System or any particular
replaced by stubs [12]. Testbench files are compiled before block within the system. To run tests targeting a particular
design files. Based on compiler directives, if a stub enabled the block, remaining blocks can be replaced by a stub module. In

2019 9th International Conference on Advances in Computing and Communication (ICACC) 155

Authorized licensed use limited to: UNIVERSITY OF BIRMINGHAM. Downloaded on May 11,2020 at 04:33:45 UTC from IEEE Xplore. Restrictions apply.
 Fig. 15. Simulation results for DMA Memory System

this case to target AXI Slave Memory, we stub DMA block. System level and block level tests are run on the same
Stub modules replace the actual module during compile time testbench providing us with maximum reusability.
based on define statements. On compilation, design hierarchy
gets updated with harness interface created within each target
block as shown in Fig. 14.

Fig. 13. Build phase of directed test

Fig. 11. Build phase of block level environment

Fig. 12. Stubs for design blocks

We have created a basic test configured to target the entire
DMA Memory system and other test directed at AXI Memory
block. When running tests at system level, APB agent gets
configured as uvm_active (driver is enabled) and AXI agent
gets configured as uvm_passive (driver is disabled). In AXI
Memory block level directed tests, APB agent gets configured
as uvm_passive and AXI agent gets configured as uvm_active.
Fig. 14. Design hierarchy using UVM harness
IV. LIMITATIONS AND CHALLENGES
This approach requires modifications to existing test bench
agents with signal-based interfaces which are defined without
ports. Design modules needs to be correctly wrapped by
compiler directives and corresponding stub needs to be created.

2019 9th International Conference on Advances in Computing and Communication (ICACC) 156

Authorized licensed use limited to: UNIVERSITY OF BIRMINGHAM. Downloaded on May 11,2020 at 04:33:45 UTC from IEEE Xplore. Restrictions apply.
 V. RESULTS AND ANALYSIS hierarchical changes in design and supports verification of
We have analyzed a traditional UVM based test bench of multiple design versions with different number of interfaces.
DMA AXI Memory system using QuestaSim 10.2c and A traditional UVM based test bench of DMA AXI Memory
successfully migrated the same to UVM Harness based test system was analyzed and successfully migrated to UVM
bench. We have listed the steps that needs to be followed to Harness based test bench. Steps that needs to be followed to
change an existing UVM based testbench to support UVM change an existing UVM based testbench to support UVM
Harness technique [9]. Simulation result for applied test on Harness technique are documented. Better code coverage was
DMA Memory System is shown in Fig. 15. found in the new enhanced test bench.
In a single block test bench, we can control the stimulus of
AXI memory block within the system with the help of harness REFERENCES
and System Verilog port coercion features. Roles of AXI Agent [1] T. M. Pavithran and R. Bhakthavatchalu, "UVM based testbench
is shown to be changed to target and write directed tests on a architecture for logic sub-system verification," 2017 International
portion of the testbench in isolation – AXI Slave memory or Conference on Technological Advancements in Power and Energy
DMA without creating separate testbench for each block. (TAP Energy), Kollam, 2017, pp. 1-5.
On running a few basic test cases on both traditional UVM [2] W. Ni and J. Zhang, “Research of Reusability Based on UVM
testbench and UVM harness enhanced testbench, 6.43% of Verification”, 2015 IEEE 11th International Conference on ASIC
(ASICON), Chengdu, 2015, pp. 1-4.
difference is observed in code coverage of AXI Slave Memory
[3] B. Vineeth and B. Bala Tripura Sundari, "UVM Based Testbench
block. Code coverage results for traditional UVM testbench Architecture for Coverage Driven Functional Verification of SPI
and UVM Harness testbench are obtained and shown in Table I Protocol," 2018 International Conference on Advances in
and Table II respectively [13]. This better code coverage is Computing, Communications and Informatics (ICACCI),
found to be attributed to the ability of testbench in enabling the Bangalore, 2018, pp. 307-310.
creation of specific test scenarios which would otherwise be [4] K. Salah, “A UVM-based smart functional verification platform:
limited by other blocks within a system. Concepts, pros, cons, and opportunities,” 2014 9th International
Design and Test Symposium (IDT), Algiers, 2104, pp. 94-99.
TABLE I [5] D. Larson, “UVM Harness Whitepaper: The Missing Link in
FUNCTIONAL COVERAGE REPORT FOR TRADITIONAL Connectivity”, Synapse Design Automation 2011
UVM TESTBENCH [6] J. Vance, J. Montesano, K. Johnston, “Verification Prowess with
the UVM Harness”, SNUG Austin, October 2017
Scope TOTAL Statement Branch [7] “UVM User Guide 1.2, Accellera,” , pp. 1–8, October 2015.
[8] J. Bromley, "If SystemVerilog is so good, why do we need the
TOTAL 40.66% 74.58% 57.39% UVM? Sharing responsibilities between libraries and the
axi_slave_ram 40.14% 74.00% 56.42% core language," Proceedings of the 2013 Forum on specification
and Design Languages (FDL), Paris, France, 2013, pp. 1-7.
axi_slave_mem 76.88% 100.00% 100.00%
[9] Jeff Vance, Jeff Montesano, Kevin Vasconcellos and Kevin
Johnston, “My Testbench Used to Break! Now it Bends: Adapting
TABLE II to Changing Design Configurations”, Verilab Inc. , DVCon 2018
[10] IEEE Std 1800-2012, “Standard for SystemVerilog – Unified
FUNCTIONAL COVERAGE REPORT FOR UVM HARNESS Hardware Design, Specification, and Verification Language”
TESTBENCH
[11] S. Bhutada, “Polymorphic Interfaces: An Alternative for
SystemVerilog Interfaces”, Verification Horizons, November
Scope TOTAL Statement Branch 2011
TOTAL 47.09% 78.77% 65.91% [12] A. Melikian, P. Marriott, “Perplexing Parameter Permutation
Problems?
axi_slave_ram 46.94% 78.28% 65.13% Immunize Your Testbench”, SNUG Canada, April 2017
axi_slave_mem 77.28% 100.00% 100.00% [13] Chien-Nan Jimmy Liu, Chen-Yi Chang, Jing-Yang Jou, Ming-
Chih Lai and Hsing-Ming Juan, "A novel approach for functional
Further directed tests and stub changes can be added coverage measurement in HDL," 2000 IEEE International
to reach special scenarios and improve coverage. Symposium on Circuits and Systems. Emerging Technologies for
the 21st Century. Proceedings (IEEE Cat No.00CH36353),
Geneva, Switzerland, 2000, pp. 217-220 vol.4.
VI. CONCLUSION
Using UVM Harness technique, it is possible to reuse the
block level testbench at system level. It adapts frequent

2019 9th International Conference on Advances in Computing and Communication (ICACC) 157

Authorized licensed use limited to: UNIVERSITY OF BIRMINGHAM. Downloaded on May 11,2020 at 04:33:45 UTC from IEEE Xplore. Restrictions apply.