UVM based STBUS Verification IP for verifying
SoC Architectures
Pranay Samanta#1, Deepak Chauhan*2, Sujay Deb#3, Piyush Kumar Gupta*4
#
Electronics and Communication Engineering, Indraprastha Institute of Information Technology
New Delhi, India
1 3
pranay1299@iiitd.ac.in, sdeb@iiitd.ac.in
*
ST Microelectronics
Greater Noida, India
2 4
deepaks.chauhan@st.com, piyush-kumar.gupta@st.com
Abstract— In this paper, we propose the design and
development of verification IP (VIP) of STBUS, a widely used
bus protocol from STMicroelectronics [1]. VIP is a standalone,
pre-verified and built-in verification infrastructure, which can be
easily plugged in the simulation-based tests. We have followed
Universal Verification Methodology (UVM) for the modelling of
the STBUS VIP. Firstly we have verified the important
properties of the STBUS protocol and made the VIP. Then we
have shown how to use the VIP in a SoC to verify IPs.
Keywords— VIP, UVM, STBUS, functional verification, DUT.
I. INTRODUCTION
In general to verify a SoC the first step is to verify the
standard bus interconnecting IP Cores in the system [2]. The
full verification process of SoC consumes on average 70% of
the total design time. In this work, we concentrate on
following problems:
1. Verify a bus protocol which is an essential part of SoC
verification.
2. Make VIP of that bus protocol.
3. Using that VIP, a SoC is verified and coverage is checked.
To illustrate our methodology, we have verified the STBUS
protocol, and then made a VIP of the STBUS protocol. Then
we have used that VIP in register write/read operation and
basic data flow in a SoC.
VIP is a reusable verification environment and so it can be
used to verify different SoCs designed using STBUS. The in-
built tests employed in the STBUS VIP can give a jumpstart
to achieve the required coverage goal which results in
decrease of the verification time.
II. LITERATURE SURVEY
Before introduction of UVM, the industry has used several
methodologies for hardware verification and making VIPs. In
[3] eRM, Advanced Verification Methodology (AVM),
Universal Reuse Methodology (URM), Open Verification
Methodology (OVM) have been used to create the verification
testbench. UVM is the latest methodology created by
Accellera [4]. Bus protocol such as PCI local bus has been
done widely in various works [5]. More advanced bus
protocol verification like AMBA has been done in [2] which
supports burst transfer.
978-1-4799-4006-6/14/$31.00 ©2014 IEEE
III. STBUS VIP AND VERIFICATION ENVIRONMENT
STBUS is an on-chip bus protocol developed by ST
Microelectronics. We have verified Type 1 and Type 3
protocols and made VIP of both type. Discussion has been
done about the components of the VIP in below. Fig. 1 shows
the architecture of the STBUS VIP.
Agent: Agents are the environment integrator which integrates
driver, sequencer and monitor together. STBUS VIP has two
active agents to implement initiator and target respectively.
Init Agent (Agent of initiator block) initiates transaction to the
Device under test (DUT). Targ Agent (Agent of target block)
reacts to the transaction and responses.
Driver: Drivers are the active entity of the design. Driver
emulates logic that drives to DUT. It repeatedly receives data
items from the sequencer and sends it to the DUT. After
sending the transaction to the DUT, it sends item_done signal
to the sequencer to inform that the request has been sent. The
driver of initiator agent sends a request transaction to the
interface. The driver of target agent sends the response of the
requests to the interface.
Sequencer: Sequencers use the defined sequence_item (In our
VIP, it is the packet corresponding different signals of STBUS
protocol), randomizes it, and sends it to the driver when
requested. The users can constraint the values of the data
items also. As we are verifying a bus protocol, the function of
the initiator sequences is more important as we drive different
stimuli via the initiator driver to the interface to verify
different properties of the bus protocol. The sequencer of the
target is used to make the target driver working.
Monitor: We have implemented a common monitor for both
the agents, so it works as bus monitor. It monitors and collects
transactions from the interface sent by both initiator and
target. The transactions then are sent to the coverage checker
and scoreboard for checking purposes via analysis port.
Scoreboard: We have implemented a scoreboard to check
whether DUT is working correctly. This includes ensuring the
accurate functioning of DUT and proper handling of all
stimuli that DUT receives.
Coverage Collector: STBUS VIP has a coverage collector to
monitor the functional coverage. The covergroup, coverpoint,
and coverbin has been used to record the functional coverage.
Environment: The env is used to connect all the components
 Table I. COVERAGE OF VERIFICATION ENVIRONMENT
Feature Coverage (in %)
Overall 95.65
Code 94.84
Functional Assertion 94.32
Covergroup 98.6
Table II. FUNCTIONAL COVERAGE
Feature Coverage (in %)
Testbench_top 92.17
Flextf_top 96.56
Assertion 94.32
Table III. CODE COVERAGE
Feature Coverage (in %)
Testbench_top 100
Flextf_top 87.91
Assertion 98.55

of the environment like agent, scoreboard, monitor, coverage

checker etc. Fig. 1. STBUS VIP Architecture
Assertion Checker: We have implemented an assertion
checker. This checker checks whether the requests and
responses are protocol specific or not. If any request or
response which violates the protocol, it would generate an
error response and test would be terminated immediately.
Tests and Sequences: STBUS VIP has 59 in-built tests and a
different sequence for each test. Few error tests with
erroneous sequences are also added for the users to use to
check how the DUT reacts when given an erroneous stimulus.
This library of built-in sequencers helps jump-start the task to
achieve coverage goals and will enable the user to get to high
coverage very rapidly.
IV. RESULTS & ANALYSIS
This STBUS VIP can be used to verify any IP communicating
Fig. 2. Verification Environment
with STBUS protocol as either a master/initiator or
slave/target. The initiator agent has to be deactivated if the
user verifies an IP acting as master. In this scenario, the IP
will generate the requests and the target agent of STBUS VIP address coverbins. Table II and table III shows the functional
will respond. The target agent has to be deactivated if the user coverage and the code coverage of the environment
verifies an IP acting as slave. In this scenario, the initiator respectively.
agent of STBUS VIP will generate the requests and the IP will V. CONCLUSION
respond.
This work has shown how to use UVM methodology to make
The developed VIP has been used to verify a IP. Fig. 2 shows a verification solution. STBUS bus protocol has been verified
the verification environment. The IP has a register bank and a and VIP of it has been implemented.
memory. STBUS T1 protocol and STBUS T3 protocol have
been used for the register and memory read-write operation.
REFERENCES
Table I shows the coverage of the whole environment in code [1] http://www.st.com
and functional coverage. 95.65% overall coverage has been [2] P.Chauhan, E.M. Clarke, Y.Lu and DongWang, “Verifying IP-
got. It is not 100% as there is unreachable or unobservable Core based System-On-Chip Designs”, Carnegie Mellon
code like testing logics, redundant code, and functionality not University Research Showcase.
under verification. The functional coverage is divided into [3] S.D’Onofrio, “Migrating existing AVM and URM testbenches
assertion and covergroup coverage. Assertion coverage is not to OVM”, http://www.paradigm-
100% as there remain few assertions which are meant to check works.com/common/pdfs/papers/AVMandURMtoOVMMigrati
whether the IP gives error response in an erroneous request. on-Paper.pdf
[4] www.accellera.org/
But erroneous scenarios cannot be generated as there is no
[5] F. Aloul and K. Sakallah. ‘‘Efficient verification of the PCI
such functionality added in the RTL. The covergroup local bus using Boolean satisfiability’’, In International
coverage is not 100% as we have not checked all the different Workshop on Logic Synthesis (IWLS), 2000.