2016 3rd International Conference on Advanced Computing and Communication Systems (ICACCS -2016), Jan.

22 & 23, 2016, Coimbatore, INDIA

A SV-UVM framework for Verification of SGMII IP

Core with reusable AXI to WB Bridge UVC

Gayathri M, Rini Sebastian, Silpa Rose Mary, Anoop Thomas

Dept. of Electronics and Communication
Rajagiri School of Engineering and Technology
Kochi, Kerala, India
Email: [email protected]@[email protected]@rajagiritech.ac.in

Abstract-Exponential advancement in technology has led to The rest of the paper is organized as follows. Section-II
the development of complex digital systems, which has made introduces the key features of SV and UVM environment. In
them more error prone. Conventional verification techniques section-III, SGMII IP core for which the UVM framework is
lacks flexibility of verification environment and are inefficient to created is introduced. Section-IV explains DUT and Section-V
balance between market demands and time to market. Universal
presents our proposed UVM framework. In section-VI consists
Verification Methodology (UVM), a System Verilog (SV ) based
of simulation result of our work. The paper concludes with
methodology helps to create robust and reusable verification
section-VII.
environment. In this work, we present an efficient SV-UVM
framework for the verification of Serial G igabit Media Inde­
pendent Interface (SGMII) IP core, a single lane 1.25 G bps data II. SV-UV M FOR V ERIFICATION
rate interface between Ethernet Media Access Control (MAC) and
Traditionally, when integrated circuit designs were not
P hysical ( PRY) layer. The core has an AMBA AXI ( Advanced
complicated, verification task was done solely by designers us­
eXtensible Interface) master interface to access the register space
of the IP. UVM Verification Component (UV C) of AXI to WB ing in-house developed test bench in Verilog-alone or together
(Wishbone) bridge is reused in the verification of SGMII core with other language like C/C++ due to lack of capabilities
for the configuration of several registers in the core which is WB needed for verification in Verilog language. As chip size kept
compatible. All simulations are done in NCsim and waveforms decreasing, chip function became more and more complicated
are analysed using Simvision. The coverage analysis is done using such that verification effort dominated the design process and
Incisive Metrics Center ( IMC). conventional methodology fell short for verification of modern
Index terms - Verification, SV, UVM, AXI to WB bridge, designs. At this point, verification took divergence from VLSI
SGMII. design. It became necessary to introduce a methodology for
verificaton and the skill set needed by the verification engineer
I. INTRODUCTION were totally different from that of a designer. Consequently,
System Verilog was introduced, which emphasized on the
The silicon revolution is largely governed by Moore's
features required for verification. SV emerged to a single
Law, which states that the number of transistors on an in­
language that is sufficiently expressive to model digital systems
tegrated circuit doubles every one to two years. The era of
at various levels of abstraction from untimed functional models
semiconductor has thus evolved VLSI, an integrated system
all the way to netlist level.
consisting of multi-million transistors on a single-chip. These
design complexities are accompanied with the interdependen­ System Verilog aims to provide a complete set of object­
cies of various functionalities which makes the design more oriented programming language that includes domain-specific
susceptible to bugs. Day-after-day, VLSI is facing challenges features to support digital hardware verification. Notable fea­
in the subsection of functional verification. Verification is a tures among them are constrained random generation, temporal
process of ensuring that a design implementation meets its assertion, interface, clocking block, program block and func­
specification. Verification is the most critical phase in chip tional coverage constructs. An overview of System Verilog's
design cycle and takes nearly 70-80 percent of the total design special features can be found in [6]. Thereby, the generated
cycle. So, there is a need for constructing a flexible and robust stimulus is much more likely to hit corner cases which make
verification environment. discovering unexpected bugs easier and thus minimizing the
coverage holes.
Conventional verification involves driving the stimulus
through testbenches written in HDL like Verilog or VHDL, The inability of SV to support macros made it insufficient
which become tedious and inefficient for complex designs. to enable widespread adoption of the best-practice verification
System Verilog, the Hardware Desciption and Verification techniques that is why UVM was adopted. UVM is a standard­
Language (HDVL) has extensive advancements over Verilog ized methodology for System-on-Chip functional verification
which provides several features to create a potential verifica­ that uses SV for creating components and transaction level
tion environment. A methodological approach for verification model (TLM) for interconnects between components. This
increases the efficiency and reduces the verification effort. In standardization allows users to implement verification modules
this paper, we use UVM, a SV based methodolgy to provide that are portable and highly compatible thereby enforcing
necessary infrastructure for creating a reusable, reliable and certain aspects of interoperability. It provides a rich base
robust verification environment. class library thus supporting the construction and deployment
2016 3rd International Conference on Advanced Computing and Communication Systems (ICACCS -2016), Jan. 22 & 23, 2016, Coimbatore, INDIA

of verification component (VC) and testbenches, dramatically E. Scoreboard

reducing the coding effort [3].
It is a self-checking mechanism that checks if the DUT is
A VC is an encapsulated, ready-to-use, configurable ver­ working as expected. It uses the response of a reference model
ification environment for an interface protocol, a design sub­ to compare with the actual response of the DUT.
module, or a full system which is reusable. Each VC follows
a consistent architecture and consists of a complete set of
F. Environment
elements for stimulating, checking, and collecting coverage.
Stimulus provided to the design under test (DUT) through VC The environment (env) is the top-level component of the
verifies protocol implementation and design architecture. Fig.l verification component. The main function of the environment
shows a generic UVM test bench architecture. class is to model behaviour by generating constrained random
traffic, monitoring DUT responses, checking the validity of the
It consists of a top level module which contains the protocol activity, and collecting coverage.
DUT and the testbench connections to it. UVM testbench
comprises of sequence item, sequencer, driver, monitor, agent, A more detailed description of UVM features can be found
scoreboard, environment and test. in [5].

Top III. SERIAL GIGABIT MEDIUM INDEPENDENT

INTERFACE (SGMII)
Test
In Ethernet, the interface between the Media Access
Env Control (MAC) layer and the Physical (PRY ) layer is
I Scoreboard l specified by IEEE 802.3 and has evolved from the lO pin
Media-independent Interface (MIl) for lOI100 Ethernet, to
the 20 pin Gigabit Media-independent Interface(GMII), to the
Agent
36 pin lO Gigabit Media Independent Interface (XGMII). In
r---- course of time the difficulty of synchronization requirement,
[ MonitorJ [ Sequencer [ led to the development of SGMII.

II
Interface
" 1
Driver I
OUT
"
I

Fig. 1: UVM testbench architecture

A. Sequencer

Fig. 2: SGMII connectivity

Verifying a RTL design requires defining of what kind of
data should be sent to the DUT. Transactions are the smallest
data transfers that can be executed in a verification model.
An ordered collection of transactions are called sequences. A Fig. 2 shows the SGMII connectivity. SGMII uses two data
sequencer is stimulus generator that controls the sequences that signals and two clock signals to convey frame data and link
are provided to the driver for execution. rate information between a lO/lOO/lOOO PRY and an Ethernet
MAC. One pin in each pair is dedicated to the signals moving
from the MAC to the PRY, and one pin dedicated to traffic
B. Driver moving in the opposite direction, from the PRY to the MAC.
Fig. 3 shows the SGMII core architecture. The transmit and
A driver is an entity that repeatedly pulls transactions from
receive data paths leverage the lOOOBASE-X Physical Coding
sequencer and drives it to the DUT. The driver will end its
Sublayer. It is a 1.25 Gbaud interface with a 625 MRz clock.
operation the moment the sequencer stops sending transactions.
More details on SGMII can be obtained from the CISCO
datasheet [7].
C. Monitor

IV. DESIGN UNDER TEST

A monitor is an entity that samples DUT signals and
sends them to the various analysis ports such as coverage and The verification of SGMII open core involves the config­
scoreboard. It does not drive any signals into the DUT. uration of several registers in the IP. The register space of
the SGMII can be accessed through the WB interface. The
WB interconnect, an Opencore standard is a general purpose
D. Agent
interface. Thus creation of a conunon interface for IP cores
An agent encapsulates a driver, sequencer, and monitor. improved portability and reusability of the system that resolved
2016 3rd International Conference on Advanced Computing and Communication Systems (ICACCS -2016), Jan. 22 & 23, 2016, Coimbatore, INDIA

fork
w_add_channel(transaction_handle); //Write
address
w_data_channel(transaction_handle);
//Write data
w_resp_channel(transaction_handle);
//Write response
r_add_channel(transaction_handle); //Read
address;
r_data_channel(transaction_handle); //Read
data
join
Fig. 3: DUT
The design of testbench involves monitor which observes
the communication of the DUT with the testbench. It observes
the pin level transaction at the outputs of the DUT and stores
System-on-Chip (SoC) integration problem. This resulted into the database that can be used to return an error if the protocols
faster time-to-market for the end user [9]. are not met. The agent connects all these components together.
Here, the prediction of the DUT functionality is made in
Fig.3 shows the block level description of DUT. The
the monitor and the scoreboard is compares the predicted
SoCs today are mostly based on AMBA bus system. Recently,
response with the DUTs actual response. The instantiation and
AMBA AXI has gained significance in industries mainly due
connection of agent and scoreboard is done in the env class.
to the five independent channels that work concurrently to
achieve the performance constraints efficiently. So here we use
V I. RESULTS
an AMBA AXI Master interface to access the register space
of the IP, so that SGMII core with WB compatible interface Simulations are done in NCsim and waveforms are anal­
can easily adhere to an AMBA bus environment. ysed using Simvision.

An AXI to WB Bridge converts the AXI transaction to

proprietary WB protocol and configure the registers in the
SGMII core which is WB compatible. AXI to WB bridge is
glued to the SGMII core using Verilog code.

V. U V M FRAMEWORK

The architecture of UVM environment begins with

transaction. Transaction is a class object, usually extended
from uvm_transaction or uvm_sequence_item classes.
Sequence item consists of all the required data transfers that
can be randomized or constrained to the specified boundary
by using UVM constructs. Sequences are extended from
Fig. 4: Configuration phase of the DUT
uvm_sequence and the generate multiple transactions. Address
and corresponding data needed to configure registers in the
core are provided in the sequence as follows,
Fig.4 shows the configuration phase of SGMII configu­
ration. AXI master driver is used to configure the registers
//Restart Autonegotiation
of the SGMII core. The address of the registers are given in
'uvm_do_with(transaction_handle,
write address channel and valid signal is asserted. The data
axi_aw_addr==32'hO; axi_w_data ==
to be written in the corresponding register is given in the
32'h00002040; read_write==l'bO; );
AXI write data channel. The AXI to WB bridge converts AXI
signals into the SGMII compatible WISHBONE signals. After
//Autonegotiation Enable
obtaining the ready signal, the data is transferred to the register
'uvm_do_with(transaction_handle,
of SGMII core which configure it. The configuration starts with
axi_aw_addr==32'hO; axi_w_data ==
synchronization, consequently the link timer sets on. With the
32'h00005640; read_write==l'bO; );
expiration of timer o_ANDone signal is set high.
The generated sequences are taken to the driver using a
Fig.S shows the serial transmission between MAC and
sequencer class. Sequence is connected to the sequencer in
PHY at SGMII tranciever end. The tranciever end of the core
the test class. Register configuration addresses and data are
transmits 8bllOb encoded data serially through Double Data
provided through the AXI write address and data channels.
Rate (DDR) interface, o_SerTx.
This initiates the corresponding task in the driver. AXI
master driver consists of four task each for each of the Fig.6 shows the data transfer through GMII interface after
independent channels. The tasks are run simultaneously autonegotiation. The GMII interface transmits and receives
through a 'fork...join' call. data at the frequency of i_RxClk and i_TxClk. Since the core
2016 3rd International Conference on Advanced Computing and Communication Systems (ICACCS -2016), Jan. 22 & 23, 2016, Coimbatore, INDIA

ACKNOWLEDGM ENT

The authors would like to thank the faculty of Dept. of

Electronics and Communication, Rajagiri School of Engineer­
ing and Technology, who reviewed and revised the intellectual
content of this paper.

REF ERENCES

[1] J Francesconi. J A Rodriguez, M P Julian, "UVM Based Test bench

Fig. 5: Serial Transmission between MAC and PHY Architecture for Unit Verification," 2014 Argentina Conference on Micro­
Nanoelectronics. Technology and Applications (EAMTA), pp. 89-94,
Mendoza, July 2014.

[2] K Salah, "A UVM-Based Smart Functional Verification Platform: Con­

cepts, Pros, Cons, and Opportunities," 2014 9th International Design and
Test Symposium, pp. 94-99, Algiers, Dec 2014.

[3] J Bromley, "If System Verilog Is So G ood, Why Do We Need the

UVM?", 2013 Forum on Specification and Design languages (FDL), pp.
1-7, Paris, Sept 2013.

[4] H Y Yang, "Highly Automated and Efficient Simulation Environment

with UVM". IEEE, 2014.

[5] Mentor G raphics Corp, UVM Cookbook, 2014. [Online]. Available:

https:llverificationacademy.com/cookbookluvm.
Fig. 6: Data transfer after Autonegotiation
[6] Accellera, System Verilog 3.1a, Language Reference Manual, 2004.

[7] Serial-GMII Specification: ENG-46158 Revision 1.7, Cisco systems, July

2001.

is set in loopback mode, after autonegotiation, the data from [8] SGMII core, [Online]. Available: www.fpga-ipcores.com.

8-bit input interface i8_TxD is transferred out to 8-bit output [9] Wishbone Specification site, [Online]. Available:
data interface 08_RxD of GMII interface. www.opencores.org/downloads/wbspec b3.pdf.

Every design verification technique requires coverage met­

rics to analyse the progress and assess effectiveness which
helps to determine whether the design is robust enough for
tapeout. The results of coverage analysis in IMC are given in
Fig.7.

VERIFICATION HIERARCHY

Nam e Loc.1 Loc.1 Loc.1

Over.11 Gr.d e Over.1I Uncovere Over.11 Covered
=- g Verif,cat,on Metnes n/. 0 0/0
1±ilG! Types 0 /0

El !ill Inst.nces r/. 0/0

I±i ill uvm_pkg r/. 0/0
ill $uniCOx546d1669 0/0

El ill .xUgmiUop ==r.iIIOO% 9!9

ill vC
i .xi o !0
I±i ill dut c::::::!J 93.22% 8 110/118

Fig. 7: Sununary of coverage analysis

V II. CONCLUSION

In this paper, we created a verification environment for

SGMII IP core using reusable AXI to WB bridge UVc. The
post-verification analysis is done in IMC, a coverage analysis
tool which returned a coverage of 93.22%. This pre-verified
SGMII IP-Core can be plugged into SOC without requiring
any further verification effort.

Recently, AXI has become an industrial standard bus for

interconnecting different IP cores in an Soc. So, this UVC can
be reused across the project for verification of other IP.

As a future work, we would like to incorporate Assertion

Based Verification (ABV) which can uncover further design
bugs and improve coverage.