Be a Sequence Pro

to Avoid Bad Con Sequences

Presenters: Jeff Vance, Jeff Montesano
Contributors: Mark Litterick, Jason Sprott

1
 Introduction
UVM sequences are vital for verification success
Need Control Manage Complexity Need Reuse
• Reach scenarios • Debug constraint failures • Within a sequence library
• Find and isolate bugs • Reduce mistakes • With derivative projects
• Close coverage • Transfer knowledge • For generic VIP

UVM sequences are often not applied appropriately

Insufficient API Too Complex Not Reusable
• Can’t control from tests • Horrific constraint failures • Copy/pasted routines
• Can’t isolate features • Invalid stimulus • Tied to a specific DUT

Poor visibility of project status No risk-management of features

2
 Outline
• Introduction to sequences
• Sequence guidelines – improve control, complexity, & reuse
• Sequence execution – masters, reactive slaves, streaming data
• Verification productivity – strategies to manage features
• Portable Stimulus Considerations – how PSS impacts sequences
• Conclusion & references

3
What are UVM sequences and why do we care?

INTRODUCTION TO SEQUENCES

4
 What is a Sequence?
A sequence encapsulates a scenario

class access_seq extends base_seq;

rand master_enum source;
rand cmd_enum cmd;
rand bit[31:0] addr; Random control knobs for users
rand bit[31:0] data[];

constraint legal_c{ ...} Constraints on random options

task body(); Procedural body()

...
if(p_sequencer.cfg.chmode == ENABLED) Access resources via sequencer
...

5
 Why Bother Using Sequences?
class access_seq extends base_seq;
rand master_enum source;
rand cmd_enum cmd;
rand bit[31:0] addr;
rand bit[31:0] data[]; Both sequences and tasks
encapsulate a scenario
Both provide
constraint legal_c{ ...}
options
task body();
... Both have procedural body

task access_dut (master_enum source,

cmd_enum cmd,
bit[31:0] addr,
ref bit[31:0] data[]);
...
//Task body

6
 Why Bother Using Sequences?
class read_test extends uvm_test; class access_seq extends base_seq;
task run_phase(uvm_phase phase); rand master_enum source;
rand cmd_enum cmd;
`uvm_do_with(access_seq, rand bit[31:0] addr;
{source == PORT_A; rand bit[31:0] data[];
cmd == WRITE; start
addr == 'hA0; sequence constraint legal_c{ ...}
data == 'h55;})
... task body();
...

class read_test extends uvm_test; task access_dut (master_enum source,

task run_phase(uvm_phase phase); cmd_enum cmd,
bit[31:0] addr,
access_dut(PORT_A, WRITE, ref bit[31:0] data[]);
'hA0, 'h55); call task ...
... //Task body

In the most basic cases, tasks and sequences can be equivalent 7

 Why Bother Using Sequences?
Tasks Sequences
Arguments are mandatory Arguments are optional
(or fixed by default) (random by default)

Users must randomize args Legal randomization is built-in

With
guidelines
No built-in arg validity checks Constraints validate user options

Awkward to return data Caller can access any data

(use ref arguments) (with sequence handle)

No built-in access to resources Access to resources via sequencer

Adding args breaks existing code Adding options has minimal impact

8
 test
configuration
constraints

virtual
sequencer

Sequence A Sequence B Sequence C

Driver A Driver B Driver C

Sequence API Strategy
tests

virtual sequencers test ”test sequences”

seq lib

environment ”top environment

sequencer env sequences”
seq lib

UVC env UVC env

UVC env
sequencer uvc_env ”UVC sequences”
seq lib
sequencers

vbus vbus i2c

physical
(agent)

sqr vbus sqr vbus sqr i2c

seq lib seq lib seq lib

driver
vbus driver
vbus driver
i2c
agent#1 agent#2 agent

10
 Sequence Layer Roles
LAYER CONSTRAINTS PRIMARY PURPOSE
Reduce complexity
TEST Test scenario Highest-level sequence
at each layer
User DUT use cases/scenarios API for test writer
TOP
Lower System requirements Scenario building blocks
Control with
User Protocol use cases Encapsulates sequencer(s) intuitive APIs
Middle Protocol operations Encapsulates basic operations
UVC
Low Low-level requirements Data formatting Sequences decoupled
and reusable
Item Enforce legality Support all possible scenarios

Each layer resolves a subset of random options Existence of some layers is

application dependent
Benefits both directed and random tests

11
How to maximize the benefits of using sequences

SEQUENCE GUIDELINES

12
 Legality Guideline
Produce legal stimulus by default

class top_seq extends base_seq;

…
task body();
`uvm_do(ahb_burst_seq_inst) No knobs provided

start sequence

class ahb_burst_seq extends base_seq;

constraint legal_c{ Enforce legal stimulus

dir inside {WRITE, READ};
addr + length < cfg.get_max_addr();
… Users can provide 0 or
} more inline constraints
13
 Legality Guideline
class top_seq extends base_seq;
…
task body();
`uvm_do_with(ahb_burst_seq_inst,
{addr == ‘hFF00;}) Address set by user
start sequence

class ahb_burst_seq extends base_seq;

constraint legal_c{ Length still random and legal

dir inside {WRITE, READ};
addr + length < cfg.get_max_addr();
… Inline constraints are optional, but
} legality is always guaranteed

14
 Legality Guideline Without this guideline, we risk
wasting significant time!

class top_seq extends base_seq;

… Users must manage legal rules in
task body(); higher sequences
`uvm_do_with(ahb_burst_seq_inst,
{addr == ‘hFF0;
What if length is invalid?
length == 1024;})
(User error or bug)
start sequence

class ahb_burst_seq extends base_seq;

May produce illegal burst length
constraint legal_c{
dir inside {WRITE, READ};
addr < cfg.get_max_addr();
… Wasted time debugging
} invalid simulations
No constraint
on length
15
 Legality Guideline
class top_seq extends base_seq;
…
task body();
`uvm_do_with(ahb_burst_seq_inst,
{addr == ‘hFFFF_FFF0;
length == 256;}) Illegal address and length

start sequence

class ahb_burst_seq extends base_seq; Protect users from illegal stimulus

constraint legal_c{
dir inside {WRITE, READ};
addr + length < cfg.get_max_addr();
… Constraint solver fails
} on illegal options

16
 Control Knob Debug Guideline
Constrain control knobs with class constraints,
then pass results with inline constraints.

class ahb_write_burst_seq extends ahb_base_seq; Don’t pass inline

…
`uvm_do_with(ahb_seq,
ahb_seq.hwrite == HWRITE_WRITE;
ahb_seq.hburst inside {HBURST_SINGLE, HBURST_INCR};

start sequence

class ahb_burst_seq extends ahb_base_seq; All constraints solved concurrently,

rand write_enum hwrite; making solver failures hard to debug
rand burst_enum hburst;
…
}

17
 Control Knob Debug Guideline
class ahb_write_burst_seq extends ahb_base_seq;
rand hburst_t hburst; Use class constraint
constraint c_hburst {
hburst inside {HBURST_SINGLE, HBURST_INCR};
}
task body(); Pass result to sequence
`uvm_do_with(ahb_seq,
ahb_seq.hwrite == HWRITE_WRITE;
ahb_seq.hburst inside {HBURST_SINGLE, HBURST_INCR};
ahb_seq.hburst == local::hburst;

start sequence
Two-Step Randomization:
class ahb_burst_seq extends ahb_base_seq;
rand hwrite_t hwrite; 1. Randomize class variables
rand hburst_t hburst;
2. Run body() to randomize
Debug randomization in isolated steps lower sequences 18
 API Guideline
Minimize the number of control knobs
class ahb_master_write_seq extends ahb_base_seq;
rand int slave_num;
… Exposed control knob
protected rand int slave_id;
Hidden control knob
constraint id_c {
slave_id == p_sequencer.cfg.get_slave_id(slave_num);
}
Keep fixed and derived
virtual task body();
ahb_seq_item req;
variables in body()
`uvm_do_with(req,{req.hwrite == HWRITE_WRITE;
req.hprot3 == p_sequencer.cfg.get_hprot3();
req.haddr[31:24] == local::slave_num;
req.id == local::slave_id})
Users can’t control these
Users can’t misuse sequence
Sequences are easier to use and cause unexpected errors 19
 Reuse Guideline
Make tests independent of testbench architecture
class ahb_fabric_write_seq extends base_seq;
task body();
ahb_fabric_master_write_seq master_write_seq;
`uvm_do(master_write_seq)
endtask: body Test-level sequence decoupled
from testbench architecture
start mid-level sequence
class ahb_fabric_master_write_seq extends ahb_base_seq;
...
task body();
ahb_master_write_seq ahb_master_write_seqs[string];
...
`uvm_do_on_with(ahb_master_write_seqs[b], Only mid-level sequences
p_sequencer.agent_sequencer[b], reference sequencers
{…})

Test sequences are generic and reusable on derivative projects

 Adaptability Guideline
Use configuration objects and accessor methods
to adapt to project-specific configurations
class ahb_cfg extends uvm_object;
rand int slv_fifo_depth; Keep project-specific configuration
... constraints outside of sequences
constraint {
slv_fifo_depth inside {[1:`MAX_FIFO_DEPTH]};
};
function int get_fifo_depth();
return(this.slv_fifo_depth);
endfunction
class fifo_test_seq extends fabric_base_seq;
...
Sequence is generic
task body();
and reusable
for(int i=0; i<=cfg.get_fifo_depth(); i++) begin
`uvm_do_with(master_seq, {
Changes in spec hsize == HSIZE_32,
are transparent hburst == SINGLE)
 Self-tuning Guideline
Use utility methods to support self-tuning sequences
function automatic int calc_data_offset_from_address(ADDR_t addr);
return(addr / DATA_WORD_SIZE) % DATA_WORDS_PER_ADDR);
endfunction
Package-scope methods perform
class write_word_seq extends base_seq; common calculations
rand bit[31:0] addr;
package ahb_pkg;
task body(); `include “ahb_common.sv”
bit[31:0] ram_addr = addr / DATA_WORDS_PER_ADDR; ... //etc
endpackage
`uvm_do_with(write_single_seq, {
addr == local::ram_addr;
word_sel == calc_data_offset_from_addr(local::addr)})

• Derive values using formulas Avoid code duplication between sequences

• Calculate delays for transactions
• Calculate timeouts for waiting Sequences adapt to changes in calculations
 Sequence Library Tip
Use typedef header at top of sequence library file
typedef class power_on_seq; // powers on DUT
typedef class reset_seq; // hard reset of DUT
typedef class por_seq; // powers on and hard resets DUT
...
class power_on_seq extends base_seq;
...
endclass typically multiple classes per file
(normal UVM has one class per file)
class reset_seq extends base_seq;
...
endclass
documents content
class por_seq extends base_seq;
power_on_seq power_seq;
reset_seq rst_seq; allows sequences
... used in any order
endclass
 More Guidelines
Guidelines
Use Dedicated Constraint Blocks Inheritance vs. Composition
Use Soft Constraints Carefully Manage Control Knobs Hierarchically
Use Enumerated Types Provide Random and Directed Flavors
Use Descriptor Objects Messaging at Sequence Start and End

[1] Use the Sequence, Luke – Verilab, SNUG 2018

24
SEQUENCE EXECUTION

25
 Sequence Execution Overview
HANDLE TLM HANDLE CONNECT

VIRTUAL SEQUENCER DRIVER

ITEM SIGNALS
SEQUENCER

VIF

I/F
SEQ ITEM
DUT
SEQ

• Sequences execute on sequencers to control stimulus

– virtual sequences coordinate and execute one or more sequences
– physical sequences generate items which are passed to drivers
– drivers interact with DUT via signal interface
• Sequence execution affected by:
– verification component role - proactive or reactive
– sequencer type - virtual (no item) or physical (item)
– item content - single transaction or streams of data

26
 Proactive Masters & Reactive Slaves
• Proactive Masters: REQ
EXPLICIT 1 PROACTIVE 2
TEST STIMULUS MASTER
DUT
3
RESP
– Test controls when sequences are executed on the UVC and timing of requests to DUT
– Stimulus blocks test flow waiting for DUT response

• Reactive Slaves: 1 REQ

IMPLICIT OR REMOTE
DUT PROVOCATION DUT 2 REACTIVE
SLAVE
3
RESP
– Timing of DUT requests is unpredictable (e.g. due to embedded FW execution)
– UVC must react to request and respond autonomously without blocking test flow

27
 Proactive Master Operation
test or higher-level: generate sequence item drive request signals
start / do sequence & pass to driver via TLM according to protocol
on sequencer (& wait for response)
UVC ENVIRONMENT
MASTER AGENT

SVA
SEQUENCER DRIVER
1 REQ REQ
ITEM 3

VIF

INTERFACE
2
DUT
MONITOR 4 (SLAVE)
RESP
5 • coverage

VIF
• checks
TRANSACTION

monitor publishes full transactions decode response

via TLM analysis port (REQ & RESP) & return to sequence
28
 Reactive Slave Operation
test or higher-level: generates sequence item drive response signals
start / do / default & passed to driver via TLM according to protocol
forever sequence (based on request)
UVC ENVIRONMENT
that waits for REQ
SLAVE AGENT

SVA
SEQUENCER DRIVER
0 RESP RESP
ITEM 3

VIF

INTERFACE
2
TLM FIFO
DUT
1 REQ MONITOR (MASTER)
REQ
• coverage

VIF
4 • checks
TRANSACTION

monitor publishes full transactions decode request whenever DUT

via TLM analysis port (REQ & RESP) initiates it & publish to sequencer
29
 Virtual Sequences
• Virtual sequences: • high-level scenarios
– do not directly generate an item • parallel transactions
• multiple agents/UVCs
– coordinate & execute other sequences
– define scenarios, interaction & encapsulation

• Key characteristics
– full control over all child sequences
– may be blocked by time-consuming sequences
– multiple virtual sequences may run at same time
(nested or parallel) on same virtual sequencer
Must target different resources
(not possible for physical sequencers) 30
 Virtual Sequence VS
ENV

class my_virtual_seq extends uvm_sequence; AGENT

// rand fields ...;
// constraints ...; S D
... DUT
task body();
fork multiple sequences in parallel M
my_poll_fifo_seq poll_fifo_seq;
i2c_send_data_seq send_data_seq;
fork
`uvm_do_with(poll_fifo_seq, { execute on this virtual sequencer
timeout == 1ms;
(targets different physical sequencer)
})
`uvm_do_on_with(send_data_seq, p_sequencer.i2c_sequencer,{
slave == 1;
data == local::data; execute on referenced
}) physical sequencer
join
...

31
 Normal Sequences
• Normal sequences use a sequence item to:
– Generate stimulus via a driver • bus transactions
• data packet
– Describe required transaction-level stimulus
• power on/reset
– Define a single finite transaction

• Key characteristics:
– Driver is not autonomous
– Fully controllable from sequences (& config) Return after complete
transaction (& response)
– Sequence handshake is blocking
– Sequence items handled consecutively

32
 Proactive Master Sequence UVC ENV
class my_master_request_seq extends MASTER AGENT
uvm_sequence #(my_master_seq_item);
rand cmd_enum cmd; S D
rand bit[31:0] addr; DUT
rand bit[31:0] data[]; M
...
my_master_seq_item m_item;
...
task body();
`uvm_do_with(m_item,{
m_item.m_cmd == cmd; generate request item
m_item.m_addr == addr; based on sequence knobs
foreach (data[i]) m_item.m_data[i] == data[i];
...
})
...

33
 Proactive Master Driver UVC ENV
MASTER AGENT
class my_master_driver extends uvm_driver #(my_master_seq_item);
my_master_seq_item m_item; S D
... DUT
task run_phase(...); M
...
forever begin
seq_item_port.get_next_item(m_item);
drive_item(m_item);
seq_item_port.item_done();
end standard driver-sequencer interaction
endtask

task drive_item(my_master_seq_item item); standard handshake

... sequencer-driver
endtask drive request signals to DUT
(based on sequence item fields)
endclass

34
 Reactive Slave Sequence UVC ENV
class my_slave_response_seq extends SLAVE AGENT
uvm_sequence #(my_slave_seq_item);
my_slave_seq_item m_item; S D
my_transaction m_request; call forever loop inside sequence DUT
... (sequence runs throughout phase: M
task body(); ...do not raise and drop objections!)
forever begin
p_sequencer.request_fifo.get(m_request); wait for a transaction request
case (m_request.m_direction)
(fifo.get is blocking)
READ :
`uvm_do_with(m_item,{
m_item.m_resp_kind == READ_RESPONSE;
m_item.m_delay <= get_max_delay();
m_item.m_data == get_data(m_request.m_addr);
...
}) generate response item
... based on observed request

35
 Reactive Slave Driver UVC ENV
SLAVE AGENT
class my_slave_driver extends uvm_driver #(my_slave_seq_item);
my_slave_seq_item m_item; S D
... DUT
task run_phase(...); M
...
forever begin
seq_item_port.get_next_item(m_item);
drive_item(m_item);
seq_item_port.item_done();
end standard driver-sequencer interaction
endtask

task drive_item(my_slave_seq_item item); identical code structure

... to proactive master
endtask drive response signals to DUT
(based on sequence item fields)
endclass

[2] Mastering Reactive Slaves in UVM – Verilab, SNUG 2016 36

 Streaming Sequences
• Streaming is a stimulus pattern where: • clock generators
• background traffic
– Item defines repetitive autonomous stimulus • analog waveforms
– Driver generates derived patterns on it’s own (real number models)

• Key characteristics for successful streaming include:

– Sequences (& config) control the autonomous behavior
– Sequence handshake must be non-blocking Sequences can run forever
– Operation must be reentrant

Interrupt ongoing items to

provide new stimulus

37
 Streaming Sequence UVC ENV
class my_ramp_seq extends uvm_sequence #(my_analog_seq_item); STREAM AGENT
rand real start;
rand real step; S D
rand time rate; random real and time control knobs DUT
... M
my_analog_seq_item m_item;
...
// constraint start inside {[0.0:0.75]};
// constraint rate inside {[1ps:100ns]};
... real and time constraints
task body();
`uvm_do_with(m_item,{ totally normal physical
m_item.m_start == start; sequence structure
m_item.m_step == step;
m_item.m_rate == rate; generate normal sequence item
}) constrained by sequence knobs
...

38
 Streaming Driver UVC ENV
ANALOG
class my_analog_driver extends uvm_driver #(my_analog_seq_item); AGENT
my_analog_seq_item m_item; S D
... call item_done before drive_item DUT
task run_phase(...); to pass control back to sequencer M
...
forever begin
seq_item_port.get_next_item(m_item); blocking peek waits for new item
seq_item_port.item_done();
fork task drive_item(my_analog_seq_item item);
seq_item_port.peek(m_item); real value = item.start;
drive_item(m_item); forever begin // ramp generation
join_any vif.data = value;
disable fork; #(item.rate);
end value += item.step;
endtask ... // saturation & looping
... end
kill drive_item task when new item
endclass ... drive request pattern forever
endtask (unless new item received)
39
 Constraint Strategies
Constraint Strategy Ideal Purpose
class constraints legal requirements
inline constraints scenarios
configuration objects configuration register dependencies
descriptor objects bundle sets of control knobs
policy classes [3] dynamically redefine constraints or impose
constraints that bypass many layers

[3] SystemVerilog Constraint Layering via Reusable

Randomization Policy Classes – John Dickol, DVCon 2015

40
Strategies to apply sequence API to reach project goals

VERIFICATION PRODUCTIVITY

41
 How do we use our Sequence API?
• Problem: How can sequences help us reach project goals?
– Prioritize tasks and meet milestone deadlines
– Maximize chance of finding bugs
– Report status to stakeholders

• Solution: Use sequence API to manage DUT features more strategically

– Step 1: Choose control knobs to isolate key features
– Step 2: Control relationships between these features from tests
– Step 3: Build a test suite around managing these relationships

Our sequence API gives us control to efficiently reach

all project goals. 42
 Step 1: Feature Isolation
Identify design features that partition major DUT functionality

Configurations Data Patterns Timing

• number of channels • directed/random • directed / random
• mode of operation • corner cases • corner / use-cases
• memory size • use-case • flow patterns

Map features to sequence control knobs (enum types)

• CH_ALL, CH_1, CH_2 • FIXED, RAND • FIXED, RAND
• FAST_MODE, … • ADC_MAX, ADC_MIN • DELAY_MAX, DELAY_MIN
• M256, M512, M1024 • DEFAULT, CASE1, … • SEQUENTIAL, PARALLEL

Can stress any feature in isolation per test We can’t isolate every feature.
Choose strategically!
Can control mix of features per test 43
 Step 2: Manage Feature Relationships
Feature Mode Description Example
FIXED Hardcode value for test (never changes) mode, number of enabled channels
DEFAULT Default design value reset values of registers
RAND Randomly changes with each simulation design configuration registers
DYNAMIC Randomly changes dynamically within a delays between transactions
simulation
MAX / MIN Absolute max or min option max/min timing, max/min input value,
max enabled channels
TYPICAL A typical setting used for common use-cases Nominal FIFO behavior

Can manage configuration, data, and timing

options independently
44
 Step 3: Test Suite Strategy
Test Type Isolated Feature Other Features Purpose Test scope is obvious
Basic FIXED FIXED smoke/sanity test
Feature FIXED RAND, DEFAULT feature isolation Bugs less likely to block
progress on other features
Scenario FIXED RAND, DEFAULT general purpose case
Use-Case TYPICAL TYPICAL customer required case Debug issues rapidly:
Timing, Data, or Config bug?
Corner FIXED, MIN, MAX FIXED, MIN, MAX rare special case
Cross RAND RAND explore relationships Can adapt to changing
Exception FIXED, RAND FIXED, RAND abnormal, but legal scenarios requirements and schedules

Stress FIXED, RAND FIXED, RAND illegal scenarios Easy to target corner-cases
(check DUT doesn’t hang) and use-cases

Regression results are implicitly mapped to features

Only possible with a properly
Easy to allocate regressions to close feature coverage designed Sequence API
Easy status reporting with test-naming conventions 45
Where does portable stimulus fit in?

PORTABLE STIMULUS

46
 What is Portable Stimulus?
• Portable Test and Stimulus Standard (PSS) [5]
“[PSS] defines a specification for creating a single representation of stimulus
and test scenarios ... enabling the generation of different implementations of a
scenario that run on a variety of execution platforms...”

• Key features include:

– declarative domain-specific system modeling language
– higher level of abstraction for describing test intent
– test portability due to independence from implementation
– executes implementation-specific methods and sequences

• Does PSS replace all our UVM sequences and stimulus?

– no, but it can replace the test layer and some virtual sequences
47
 Test Reuse
PSS address reuse of test intent
– reuse from (block to) sub-system to full-system (within UVM)
– reuse of tests on different target implementations (e.g. UVM or SW)
– reuse of tests on different target platforms (e.g. simulation or hardware)
PSS Test Specification & Generation

UVM UVM SW TE CTRL SW

SENSOR SENSOR SENSOR
REG REG
S ADC MODEL S ADC MODEL ADC
D M A D D M A D MEM A D MEM
A A
CTRL F CTRL CTRL
CTRL P CTRL P CTRL
S S CPU CPU
D M BUS D M BUS
X Y Z X Y Z X Y Z
S DUT DUT
D M M

CLOCK RESET POWER SUB-SYSTEM CLOCK RESET POWER POST-SILCON

FULL-SYSTEM
SIDEBAND SIMULATION SIDEBAND SIMULATION SIDEBAND VALIDATION
48
 What Changes
• High-level test scenarios & use-cases delegated to PSS
– almost[*] all test sequences & components replaced by PSS
– many sub-system and full-system scenario virtual sequences replaced

• We do not implement these tests in UVM

– we generate UVM tests from the PSS tools
– we conceive test scenarios using PSS modeling paradigm

• PSS tests are responsible for corresponding high-level checks

• PSS also has built-in (stimulus) functional coverage capability
[*] Retain some pure UVM tests to sign-off & regress UVM environment
49
 What Does Not Change
• Intermediate virtual sequences in environment: unaffected
– these are used by PSS execution to actually stimulate DUT

• UVC virtual and physical sequences: unaffected

– these are used by PSS execution and enclosing environment layer

• Block-level test scenarios : unaffected (in most cases)

– validate comprehensive operation of block independent of system environment

• UVC and environment checks: unaffected, still required

– signal protocol checks (interface assertions)
– transaction content (monitors)
– transaction relationships (scoreboards)

• UVC and environment functional coverage: still required

– PSS coverage is only stimulus intent, not observed effect (we need both)
50
 PSS Tests & UVM Sequences
tests ALL HIGH-LEVEL TESTS
SPECIFIED IN PSS AND
GENERATED BY TOOLS
test ”test sequences”
virtual sequencers

seq lib
MANY HIGH-LEVEL
SCENARIO SEQUENCES
environment ”top environment DELEGATED TO PSS
sequencer env sequences”
seq lib
SOME LOW-LEVEL
UVC env UVC env SCENARIO SEQUENCES
UVC env DUPLICATED IN PSS
sequencer uvc_env ”UVC sequences”
seq lib
NO LOW-LEVEL
sequencers

vbus vbus i2c

PHYSICAL SEQUENCES
physical
(agent)

sqr vbus sqr vbus sqr i2c REPLACED BY PSS

seq lib seq lib seq lib

driver
vbus driver
vbus driver
i2c
agent#1 agent#2 agent ALL REMAINING
SEQUENCES
USED BY PSS
51
CONCLUSION

52
 Conclusion
• Apply guidelines to avoid common verification problems
– Retain control to reach scenarios
– Minimize complexity for improved efficiency and communication
– Improve reuse for future projects
• Apply sequence techniques for each situation
– Proactive masters, reactive slaves
– Streaming data sequences
• Design your sequence API to maximize project efficiency
– Risk management and prioritization of features
– Transparent status reporting
• PSS requires quality sequence APIs
53
 References
1 Use the Sequence, Luke – Verilab, SNUG 2018
2 Mastering Reactive Slaves in UVM – Verilab, SNUG 2016
3 SystemVerilog Constraint Layering via
Reusable Randomization Policy Classes, John Dickol, DVCon 2015
4 Advanced UVM Tutorial – Verilab, DVCon 2014
5 Portable Test and Stimulus Standard, Version 1.0, Accellera

Verilab papers and presentations available from:

http://www.verilab.com/resources/papers-and-presentations/

54
Q&A

55
The following images are licensed under CC BY 2.0
• Verdi_Requiem 008 by Penn State
• Sheet music by Trey Jones
• Flutist by operaficionado
• Cello Orchestra by Malvern St James
• Folk_am_Neckar_4915 by Ralf Schulze
• Flute by Bmeje
• Cello by Lori Griffin

56