UVM Basics: Nagesh Loke ARM CPU Verification Lead/Manager

UVM Basics
Nagesh Loke
ARM CPU Verification Lead/Manager
1
What to expect …
▪ This lecture aims to:

▪ demonstrate the need for a verification methodology
▪ provide an understanding of some of the key components of a UVM testbench
▪ cover some basic features of UVM
2
ARM CCN-512 SoC Framework
3
What are the challenges of verifying complex systems?
▪ Typical processor development from scratch could be 100s of engineering years

▪ Requires parallel developments across multiple sites, and it takes a large team to verify a
processor
▪ The typical method is to divide and conquer, partitioning the whole CPU into smaller
units and verify those units, then reuse the checkers and stimulus at a higher level
▪ The challenges are numerous
▪ Reuse of code becomes an absolute key to avoid duplication of work
▪ It is essential to have the ability to integrate an external IP
▪ This requires rigorous planning, code structure, & lockstep development
▪ Standardization becomes a key consideration
▪ UVM can help solve this!
4
What is UVM and why use it?
▪ Stands for Universal Verification Methodology

▪ Benefits:
▪ supports and provides framework for modular and layered verification components
▪ Enables:
◦ reuse
◦ clear functional definition for each component
◦ configuration of components to be used in a variety of contexts
▪ is maintained and released by Accellera committee
▪ source code is fully available
▪ is a mature product
▪ significant amount of training and support available
5
Key components of a UVM testbench
TOP Env
TX Env RX Env
Scoreboard
TX Agent RX Agent
Sequencer Sequencer
Functional Coverage
Driver Monitor Driver Monitor
Interface Interface
DUT
6
UVM Sequence Item & Sequence Inheritance tree
7
UVM Component
▪ Basic building block for all
components that exercise
control over testbench or
manage transactions
▪ They all have a time consuming
run() task
▪ They exist as long as the test
exists
8
UVM Sequence Item & Sequence
▪ Sequence Item is the same as a transaction
▪ It’s the basic building block for all types of data in
UVM
▪ Collection of logically related items that are
shared between testbench components
▪ Examples: packet, AXI transaction, pixel
▪ Common supported methods:
▪ create, copy, print, compare
▪ UVM Sequence is a collection/list of UVM

sequence items
▪ UVM sequence usually has smarts to populate
the sequence but sometimes this is separated
into a UVM generator
9
TOP Env
TX Env RX Env
Scoreboard
TX Agent RX Agent
Sequencer Sequencer
Functional Coverage
Interface Interface
DUT
10
UVM Sequencer & Driver
▪ A UVM sequencer connects a UVM sequence
to the UVM driver
▪ It sends a transaction from the sequence to the
driver
▪ It sends a response from the driver to the
sequence
▪ Sequencer can also arbitrate between multiple
sequences and send a chosen transaction to the
driver
▪ Provides the following methods:
▪ send_request (), get_response ()
▪ A UVM driver is responsible for decoding a

transaction obtained from the sequencer
▪ It is responsible for driving the DUT interface
signals
▪ It understands the pin level protocol and the
timing relationships
11
UVM Monitor
▪ Monitor’s responsibility is to observe
communication on the DUT interface
▪ A monitor can include a protocol checker that
can immediately find any pin level violations of
the communication protocol
▪ UVM Monitor is responsible for creating a
transaction based on the activity on the
interface
▪ This transaction is consumed by various
testbench components for checking and
functional coverage
▪ Monitor communicates with other testbench
components using UVM Analysis ports
12
TOP Env
TX Env RX Env
Scoreboard
TX Agent RX Agent
Sequencer Sequencer
Functional Coverage
Interface Interface
DUT
13
UVM Agent
▪ UVM Agent is responsible for
connecting the sequencer, driver and
the monitor
▪ It provides analysis ports for the
monitor to send transactions to the
scoreboard and coverage
▪ It provides the ability to disable the
sequencer and driver; this will be
useful when an actual DUT is
connected
14
UVM Scoreboard
▪ Scoreboard is one of the trickiest and most important verification components

▪ Scoreboard is an independent implementation of specification
▪ It takes in transactions from various monitors in the design, applies the inputs to the
independent model and generates an expected output
▪ It then compares the actual and the expected outputs
▪ A typical scoreboard is a queue implementation of the modeled outputs resulting in a
pop of the latest result when the actual DUT output is available
▪ A scoreboard also has to ensure that the timing of the inputs and outputs is well
managed to avoid false fails
15
UVM Environment
▪ The environment is
responsible for managing
various components in the
testbench
▪ It instantiates and connects:
▪ all the agents
▪ all the scoreboards
▪ all the functional coverage
models
16
UVM Test
▪ uvm_test is responsible for

▪ creating the environment
▪ controlling the type of test you want to run
▪ providing configuration information to all the components through the environment
17
TOP Env
TX Env RX Env
Scoreboard
TX Agent RX Agent
Sequencer Sequencer
Functional Coverage
Interface Interface
DUT
18
UVM TLM
▪ TLM port is a mechanism to transport data or messages

▪ It is implemented using a SV mailbox mechanism
▪ It typically carries a whole transaction
▪ In some cases a broadcast of a transaction is necessary (one-many); this is achieved
using an analysis port
▪ A testbench component implemented using TLM ports is more modular and reusable
19
UVM Phasing
build Create components and allocate memory
connect Hook up components; key step to plumbing
start_of_simulation Print banners, topology etc.
reset Time consuming tasks

• Reset the design
configure • Configure the design
run • Main test stimulus
main • Stop the stimulus and provide time for
checking/draining existing transactions, replays or
shutdown restarts
check Do end of test checks (all queues empty, all responses received)
report Provide reporting, pass/fail status
final Complete the test

20
What we learned today …
▪ Discussed what a verification methodology is and the need for it

▪ Looked at block diagrams with key components in a UVM testbench
▪ Covered UVM and some of it’s basic features
21
Useful pointers
▪ https://verificationacademy.com/
▪ Accelera: http://accellera.org/downloads/standards/uvm
▪ Recommend watching short videos on UVM introduction on YouTube
22

UVM Basics: Nagesh Loke ARM CPU Verification Lead/Manager

Uploaded by

Copyright:

Available Formats

UVM Basics: Nagesh Loke ARM CPU Verification Lead/Manager

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UVM Basics: Nagesh Loke ARM CPU Verification Lead/Manager

Uploaded by

Copyright:

Available Formats

UVM Basics

▪ This lecture aims to:

▪ Typical processor development from scratch could be 100s of engineering years

▪ Stands for Universal Verification Methodology

▪ UVM Sequence is a collection/list of UVM

▪ A UVM driver is responsible for decoding a

▪ Scoreboard is one of the trickiest and most important verification components

▪ uvm_test is responsible for

▪ TLM port is a mechanism to transport data or messages

start_of_simulation Print banners, topology etc.

reset Time consuming tasks

report Provide reporting, pass/fail status

final Complete the test

▪ Discussed what a verification methodology is and the need for it

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.