Sie sind auf Seite 1von 2

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

* ST Microelectronics Greater Noida, India

2, 4

AbstractIn 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.



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


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.


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


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



Coverage (in %)













Coverage (in %)









Coverage (in %)







of the environment like agent, scoreboard, monitor, coverage checker etc. 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.


This STBUS VIP can be used to verify any IP communicating 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 will respond. The target agent has to be deactivated if the user verifies an IP acting as slave. In this scenario, the initiator agent of STBUS VIP will generate the requests and the IP will respond.

The developed VIP has been used to verify a IP. Fig. 2 shows the verification environment. The IP has a register bank and a memory. STBUS T1 protocol and STBUS T3 protocol have been used for the register and memory read-write operation. Table I shows the coverage of the whole environment in code and functional coverage. 95.65% overall coverage has been got. It is not 100% as there is unreachable or unobservable code like testing logics, redundant code, and functionality not under verification. The functional coverage is divided into assertion and covergroup coverage. Assertion coverage is not 100% as there remain few assertions which are meant to check whether the IP gives error response in an erroneous request. But erroneous scenarios cannot be generated as there is no such functionality added in the RTL. The covergroup coverage is not 100% as we have not checked all the different

Fig. 1. STBUS VIP Architecture Fig. 2. Verification Environment
Fig. 1. STBUS VIP Architecture
Fig. 2. Verification Environment

address coverbins. Table II and table III shows the functional coverage and the code coverage of the environment respectively.



This work has shown how to use UVM methodology to make a verification solution. STBUS bus protocol has been verified and VIP of it has been implemented.




P.Chauhan, E.M. Clarke, Y.Lu and DongWang, “Verifying IP-


Core based System-On-Chip Designs”, Carnegie Mellon University Research Showcase. S.D’Onofrio, “Migrating existing AVM and URM testbenches


to OVM”, http://www.paradigm- on-Paper.pdf


F. Aloul and K. Sakallah. ‘‘Efficient verification of the PCI local bus using Boolean satisfiability’’, In International Workshop on Logic Synthesis (IWLS), 2000.