International Journal on Recent and Innovation Trends in Computing and Communication ISSN: 2321-8169

Volume: 3 Issue: 5 2898 - 2902

_______________________________________________________________________________________________
UVM Based Verification of CAN Protocol Controller Using System Verilog
Suchika Lalit
P.G Students, Department of Electronics Engineering
Gujarat Technological University
Ahmedabad, Gujarat, India
[email protected]

Mr. Ashish Prabhu

Sr. Verification Engineer at LSI Pune, India
[email protected]

AbstractOver the years, design complexity and size have stubbornly obeyed the growth curve predicted by Gordon Moore. The
industry is migrating towards leading edge nodes, which can hold more than 100 Million gates. The chip makers want to pack as
many functions possible in their SoCs and provide as many feature additions to gain market share. And, of course, all of those
features need to be verified. Verification is currently the largest challenge facing the semiconductor industry in keeping pace with
both the customer demand for features and our technical ability to add millions of gates to our chips. Verification quality is a must
for functional safety in electronic systems. This paper describes the verification of CAN Protocol Controller using System
Verilog. The CAN Controller functions as the interface between an application and the actual CAN bus. Taking this need in
consideration, this paper describes flow from specification extraction to development of verification environment.

Keywords- UVM, ASIC, VLSI, CAN, DUT

__________________________________________________*****_________________________________________________
I. INTRODUCTION automatic test generation, self-checking testbenches and
coverage metrics to significantly reduce the time spent
During the last decades, several verification methodologies
verifying a Design Under Test (DUT).
have been developed to ease the process of ASIC
verification designs. EDA tool vendors usually develop
II. VERIFICATION
these methodologies which in most cases are not compatible
with tools from different vendors [4]. With the introduction
In VLSI (Very Large Scale Integration) technology we
of the Open Verification Methodology (OVM) which
design and make integrated chips. ASIC (Application
supports the use of SystemVerilog testbenches, need for
Specific Integrated Chip) designing is a process in which
verification became more standardized and hence, OVM
RTL (Register Transfer Level) design is made using
paved way for Universal Verification Methodology (UVM)
Hardware Description Language (HDL). Based on correct
which has become an official Accellera standard supported
RTL respective chip is manufactured. If RTL contains errors
by all EDA tool vendors today[4].
or bugs the final chip does not work properly according to
This research presents UVM based Verification process and
specified functionality. To make sure that RTL is working
methodology using SystemVerilog, explains verification
correctly according to specified functionality, verification is
strategy and reuse of design environment with reference to
required. According to Moores law number of transistor
verifying the CAN Protocol controller (IP) core.
increases in the design every 18 months. As the number of
Communication across a CAN bus starts with the
transistors in the design increases so the errors in the design
application providing the CAN controller with the data to be
increases. Thus verification is one of the most important
transmitted. The CAN controller provides an interface
processes of ASIC flow which make sure the functional
between the application and the CAN bus. The function of
correctness of the design.
the CAN controller is to convert the data provided by the
application into a CAN message frame fit to be transmitted
Verification is a process used to demonstrate the functional
across the bus. A transceiver receives the serial input stream
correctness of a design in its implementation [8].At every
from the controller and converts it into a differential signal.
step of developing a chip we need verification. At each level
The Physical connection of the CAN controller to the CAN
we need some
bus is done with the CAN transceiver.
level of verification. Basically verification covers the below
The Universal Verification Methodology (UVM) offers the
things.
most excellent structure to attain coverage driven
What we specified is what we envisioned.
verification. The coverage driven verification combines
What we design is what we specified.
2898
IJRITCC | May 2015, Available @ http://www.ijritcc.org
_______________________________________________________________________________________
International Journal on Recent and Innovation Trends in Computing and Communication ISSN: 2321-8169
Volume: 3 Issue: 5 2898 - 2902
_______________________________________________________________________________________________
What we taped out is what the RTL described.
What we manufactured is what we taped out.
Bug is error or misbehaving of design. It is unexpected
behaviour of the design. No design in VLSI is bug free.
Bugs found in early stages of verification costs very little. It
is always best to find bugs in the design as early as possible.
For complex designs synthesis takes lots of time. If we find
bugs in later stage it costs more.

Figure 3UVM phases

IV. CAN PROTOCOL CONTROLLER DESIGN

The interface between the CAN serial bus and CAN

Figure 1 Number of bugs vs time in verification flow application is provided by the CAN Controller Figure 3
shows a block diagram of CAN Protocol Controller with the
III. UVM pins and different blocks inside the controller.

UVM (Universal Verification Methodology) was introduced

in December 2009, by a technical subcommittee of
Accellera. UVM uses Open Verification Methodology as its
foundation. Accellera released version UVM 1.0 EA on
May 17, 2010. UVM Class Library provides the building
blocks needed to quickly develop well-constructed and
reusable verification components and test environments. It
uses system Verilog as its language. All three of the
simulation vendors (Synopsys, Cadence and Mentor)
support UVM today which was not the case with other
verification methodology.

Figure 3 Block diagram of CAN controller

A. Description of the CAN controller blocks [7]

Interface Management Logic (IML)

Interface management logic interprets commands from
CPU, controls addressing of the CAN registers and provides
interrupts and status information to the host microcontroller.
Transmit Buffer (TXB)
Transmit buffer is an interface between the CPU and the Bit
Stream Processor (BSP) that is able to store a complete
message for transmission over the CAN network. This
buffer is 13 bytes long, written to by the CPU and read out
Figure 2 UVM Basic Component Model.
by the BSP.

2899
IJRITCC | May 2015, Available @ http://www.ijritcc.org
_______________________________________________________________________________________
International Journal on Recent and Innovation Trends in Computing and Communication ISSN: 2321-8169
Volume: 3 Issue: 5 2898 - 2902
_______________________________________________________________________________________________
Receive Buffer (RXB, RXFIFO)
Receive buffer is an interface between the acceptance filter
and the CPU that stores the received and accepted messages
from the CAN-bus line. The Receive Buffer (RXB)
represents a CPU-accessible 13-byte window of the Receive
FIFO (RXFIFO), which has a total length of 64 bytes.

Acceptance Filter (ACF)

Acceptance filter compares the received identifier with the
acceptance filter register contents and decides whether this
message should be accepted or not. In the event of a positive
acceptance test, the complete message is stored in the Figure 4: Detailed Testbench Environment
RXFIFO.
VI. TEST PLAN
Bit Stream Processor (BSP) Test plan is a document which contains all possible
Bit stream processor is a sequencer which controls the data scenarios of test cases. Based on specifications we define all
stream between the transmit buffer, RXFIFO and the CAN- possible test cases and maintain a document for that. It is
bus. It also performs the error detection, arbitration, stuffing one of the most important steps of verification flow.
and error handling on the CAN-bus. Maximum number of test cases can find more bugs from the
design. In industry as much possible time is spent in
Bit Timing Logic (BTL) defining the test plan as according to test plan. Based on
Bit timing logic monitors the serial CAN-bus line and verification plan we implement all defined modules in
handles the bus line-related bit timing. It is synchronized to verification plan in terms of code using System Verilog
the bit stream on the CAN-bus on a recessive-to-dominant language.
bus line transition at the beginning of a message (hard
synchronization) and re-synchronized on further transitions
during the reception of a message (soft synchronization).
BTL also provides programmable time segments to
compensate for the propagation delay times and phase shifts.

Error Management Logic (EML)

EML is responsible for the error confinement of the transfer-
layer modules. It receives error announcements from the
BSP and then informs the BSP and IML about error
statistics.

V. DETAILED TESTBENCH ARCHITECTURE

For the verification process, UVM using System Verilog

and Mentor Graphics QuestaSim is used to create the Figure 5 Test Plan
testbench environment. A testcase is developed with
particular constraints that will limit the random stimulus VII. IMPLEMENTATION
generation.
To perform the verification, we need the complete and
The generator creates a programmable amount of random stable RTL design first. So as first task stable IP Core of
frames that will be inserted in the DUT (Design Under CAN Protocol Controller is collected. The CAN Controller
Test). The sequencer will take these frames and will IP Core is provided by OpenCores [12] community which
transform them into signals (bytes) and will send them provides free IP Core. Compilation results show that the
through the interfaces/driver. The scoreboard will predict RTL code of CAN protocol controller is syntax and other
the expected result from the driver and this result will be compilation error free. It means it is ready to be functionally
used by the checker to compare them with the received data verified.
from the DUT.

2900
IJRITCC | May 2015, Available @ http://www.ijritcc.org
_______________________________________________________________________________________
International Journal on Recent and Innovation Trends in Computing and Communication ISSN: 2321-8169
Volume: 3 Issue: 5 2898 - 2902
_______________________________________________________________________________________________
Table 1 Verification Component
Components Parent Description
Class

top.sv NA top module contains instantiation of

interface and CAN core.

interface.sv NA Interface block provides

communication path between
testbench and CAN core.
tr1_test.svh can_base_te tr1_test
st, uvm_test

can_env uvm_env Environment class has two

components viz. Agent, Scoreboard.

can_scoreboard uvm_scoreb Scoreboard provides output results

oard comparison mechanism and contains
function model of our design.
can_agent uvm_agent Agent provides three blocks namely
Sequencer, Driver and Monitor. It
also has connection between all
three components and with blocks of
Figure 6 Verification Component Hierarchy
Environment.
sequence_item uvm_seque To create transactions, apply
nce_item randomization to desired signals.

can_driver uvm_driver Driver converts transactions coming

from sequence to signal level
activities and applied them to CAN
core via virtual interfaces.
can_monitor uvm_monit Monitor collects results from the
or CAN core output ports via virtual
interface and sends them to
Scoreboard in form of transactions.

Scoreboard functionality is to compare all inputs to the

relative outputs. And for that scoreboard will be connected
to CAN functional model. Here, this functional model can
be in any foreign language like C, C++, Python etc or it can
be created in SystemVerilog. To connect CAN functional
model to scoreboard we require DPI-C if the model is in C
language.
VIII. SIMULATION RESULTS

A. tr1_test Figure 7 Verification Component Hierarchy

Two basic sequences are applied to check the UVM
environment for CAN protocol controller that are reset and B. can_pkg Package File
initialize.
package can_pkg;
Simulation waveform for tr1_test testcase is as shown
below. // Include Package Items and Macros
import uvm_pkg::*;
`include "uvm_macros.svh"

// Define Sequencer, Include Sequence Items

`include "sequence_item.svh"
typedef uvm_sequencer#(sequence_item) sequencer;
2901
IJRITCC | May 2015, Available @ http://www.ijritcc.org
_______________________________________________________________________________________
International Journal on Recent and Innovation Trends in Computing and Communication ISSN: 2321-8169
Volume: 3 Issue: 5 2898 - 2902
_______________________________________________________________________________________________
[2] Guo Jinyan, Hu Yueli, The Design and Realization of
// Sequences CAN Bit Timing Logic in Prime Asia 2010.
`include "sequences/base_sequence.svh" [3] Juan Francesconi, J. Agustin Rodriguez, Pedro M.
Julian, UVM Based Testbench Architecture for Unit
`include "sequences/reset_seq.svh"
Verification in Argentine School of Micro-
`include "sequences/init_seq.svh"
Nanoelectronics, Technology and Applications 2014.
`include "sequences/tr1_seq.svh" [4] Jonathan Bromley, If SystemVerilog Is So Good, Why
Do We Need the UVM?, 2013.
// UVM Components [5] Geng Zhong, Jian Zhou, Bei Xia, Parameter and UVM,
`include "can_driver.svh" Making a Layered Testbench Powerful, IEEE 2013.
`include "can_monitor.svh" [6] Philips Semiconductors. CAN Specification Version 2.0,
`include "can_agent_config.svh" Parts A and B [S].1992.
`include "can_agent.svh" [7] Philips Semiconductors, SJA1000 Stand-alone CAN
controller Datasheet, 2000.
`include "can_scoreboard.svh"
[8] Chris Spear, SystemVerilog for Verification, A Guide to
`include "can_env.svh"
Learning the Testbench, MA, Springer, p.15(2006).
[9] Accellera, Universal Verification Methodology (UVM)
// Base Test and Extended Tests 1.1 Users Guide, May 2011.
`include "test/can_base_test.svh" [10] Kuang-Chien (KC) Chen, Assertion Based Verification
`include "test/tr1_test.svh" for SoC designs, 0-7803-7889-X/03 IEEE, Published on
2003.
endpackage: can_pkg [11] Yang Guo, Wanxia Qu, Tun Li, Sikun Li. Coverage
Driven Test Generation Framework for RTL Functional
Verification Published in Computer- Aided Design and
IX. CONCLUSION
Computer Graphics, 2007 10th IEEE international
Verification plays an important role for the functional safety
conference, pp. 321-326.
and understanding of electronic circuits. Literature survey is [12] OpenCores, Free IP Core Provider, www.opencores.org
done to select the verification methodology as UVM. The [13] Overview and understanding of SystemVerilog and
Universal Verification Methodology (UVM) represents the Verification Environment. www.systemverilog.in
latest member of a family of methodologies for functional www.testbench.in
verification of digital hardware. UVM was built on the [14] Bhaumik Vaidya and Nayanpithadiya, An Introduction
principle of cooperation between EDA vendors and to Universal Verification Methodology published in
customers. It is based on SystemVerilog classes, and proven Journal of Information Knowledge and Research in
Electronics and Communication Engineering, 2012-13,
to be a powerful OOP technique with highly reusability.
pp. 420-424
Due to the wide range of applications of CAN controller in
automobile industry this protocol needs to be verified. The
main objective of this project is to develop a generic
verification environment in SystemVerilog by the UVM
methodology. So here a verification environment is
proposed for CAN Protocol Controller. Here layered
testbench is developed where each layer has particular
functionality. By using OOP concept different functionality
are divided into different classes. Global class contains all
global signals and signals which need to be randomized.
Generator class performs all randomization and data
generation operation. Driver class performs driving
command to DUT. Monitor class monitors all activity of
whole testbench. Scoreboard class keeps the track of passed
and failed transactions. So here self-checking and generic
environment is developed. According to specification
testplan is developed which contains all possible test cases
and scenarios.
REFERENCES
[1] G. Zarri, F. Colucci, F. Dupuis, R. Mariani, M.
Pasquariello, G. Risaliti, C. Tibaldi, On the Verification
of Automotive Protocols, 2006.

2902
IJRITCC | May 2015, Available @ http://www.ijritcc.org
_______________________________________________________________________________________