1. Stitching UVM Test benches into Integration-Level
Wayne Yun David Chen Oliven Xie
Advanced Micro Devices, Inc Advanced Micro Devices, Inc Advanced Micro Devices, Inc.
Multi-Test Architecture
B. Avoiding Driver Conflicts
Comparing with legacy passive mode of UVM agent (i.e. sequencer and driver are not created). multi-test architecture suggests to replace the driver with a dummy one using factory override.
Integration-Level Test bench
The name of multi-test comes from the fact that there are multiple lower level tests instantiated in an integration- level test. This architecture is not described in any UVM literacy.
A. Multiple Tests in One Simulation
Figure 1 shows one possible implement for an SOC test. The SOC test is derived from an SOC test base class which in turn is directly or indirectly derived from uvm_test. The SOC base class handles common aspects of a group of tests, like instantiating IP tests, configuring them, etc. Derived SOC tests focus more on different scenarios.
top_ral_block
Multi-test architecture brings in extra flexibility and reuse opportunity at integration-level test benches while maintaining original UVM structure, compatibility, and feeling.
Figure 6 is showing one implemented sub-system test bench where 2-IP’s bench involved.
top_ral_block_A
top_ral_block_B
Map A
IP block-A1
Map B
IP block-B1 ……
Adaptor
Adaptor
SoC sub-blocks
// Derive a class from agent’s driver, overload the run_phase task so as not to
// drive the inferface.
class muted_driver extends agent_driver;
task run_phase(uvm_phase phase);
// Drive hi-z at all output signals
vif.out_signals = ‘hz;
// Complain about any item
forever begin
seq_item_port.get_next_item(req);
`uvm_error(“unexpected item”, “Unexpected sequence item is received.”)
seq_item_port.item_done();
end
endtask
endclass
// UVM factory is used to replace the original driver with the derived one
function void SOC_TEST_BASE::factory_override();
. . .
 // Type override is used in this example, instance override is used in Fig 5.
set_type_override_by_type(agent_driver::get_type(), muted_driver::get_type());
endfunction
SoC Map
SoC Adaptor
Centralized
Driver
DUT
DUT
shell IPs
Common Interface
IP- A
IP- B
Figure Hierarchical RAL model tree
C. Sim-Thread Sync-up mode
Refer to Figure 9 for the detail implementation of simulation thread sync-up between each test when needed.
Shared IP/IF (shell) TB
TEST top
Sync Control
Virtual Syncer
Test A
Env A
RAL A
Test B
Env B
RAL B
Evt Receiver
Test A
Test B
Event Trigger
Agent A (active)
Agent B
(active)
Event Trigger
Event 1
Evt Dispatcher
Event Resposer
Event Resposer
Figure Mute Driver to Avoid Driving Conflict
C. Redirecting Stimulus
Under multi-test architecture, it is repurposed to merge stimuli from multiple-IPs verification environments.
Figure Multi-Test Architecture Based on UVM
Figure Simulation Multi-thread Sync-up
// Base class of all SOC tests. Instead of creating a uvm_env, it instantiates
// one IP test for every instance of IP RTL
class SOC_TEST_BASE extends uvm_test;
// Handles to IP level tests
IP1_TEST m_ip1_test;
IP2_TEST m_ip2_test;
IP3_TEST m_ip3_test;
// Names of IP level tests, used to create IP test instances
string m_name_ip1_test;
string m_name_ip2_test;
string m_name_ip3_test;
// Some IP test bench components are replaced using UVM factory
extern function void factory_override();
// UVM build phase
function void build_phase(uvm_phase phase);
// Override IP internal components
factory_override();
// Create IP tests using UVM factory
if (!$cast(m_ip1_test, create_component(m_name_ip1_test, “ip1_test”)) begin
`uvm_fatal(“SOC_TEST_BASE”, “Failed to create IP1_TEST”)
end
if (!$cast(m_ip2_test, create_component(m_name_ip2_test, “ip2_test”)) begin
`uvm_fatal(“SOC_TEST_BASE”, “Failed to create IP2_TEST”)
if (!$cast(m_ip3_test, create_component(m_name_ip3_test, “ip3_test”)) begin
`uvm_fatal(“SOC_TEST_BASE”, “Failed to create IP3_TEST”)
endfunction
endclass : SOC_TEST_BASE
// SOC test is derived from SOC_TEST_BASE, focus on test scenario rather than
// environment structure
class SOC_TEST extends SOC_TEST_BASE;
. . .
endclass
Figure IP’s Combination Multi-test Compliance Sub-system
Friendly IP-Level test bench
Within the multi-test environment ,we are already achieving:
Multi-Test modes
see Figure 7 for the supported test-mode in detail:
Agent_inst_1
Agent_inst_2
Below are some guidelines for IP-level test bench. They make work at integration-level easier.
Avoid override sequencer of an agent from IP-level test benches.
Environments should accept handles of agents. Integration-level can pass in the handle of an agent created outside the IP environment.
Handle variables should be defined at IP Environments to reference sequencers.
All handles pointing to test bench components should be public.
Sequencer
Sequencer
Driver
Driver A.
IP-A
IP-A
CMN
iUVC
Figure 4 A Structure Merging Stimuli from Two Environments
Test
RTL : B.
IP-B
IP-B
A sequence sending out a sequence_item
class forwarding_seq extends agent_seq;
agent_item m_item;
task body();
start_item(m_item);
finish_item(m_item);
endtask
endclass
Derive a driver to redirect sequence_items
class redirecting_driver extends agent_driver;
// Handle to the sequencer in the agent controlling the interface
agent_sequencer m_ctrl_sqr;
task run_phase(uvm_phase phase);
forwarding_seq m_fwd_seq = new(”m_fwd_seq”);
forever begin
// Get a sequence_item
seq_item_port.get_next_item(req);
// Pass the sequence_item to the sequence
m_fwd_seq.m_item = req;
// Run the sequence to send the sequence_item
m_fwd_seq.start(m_ctrl_sqr);
// Flag done
seq_item_port.item_done();
end
UVM factory to create the redirecting driver inside agent
function void SOC_TEST_BASE::factory_override();
set_inst_override_by_type(“relative.path.to.driver”,
agent_driver::get_type(), redirecting_driver::get_type());
endfunction
CMN
iUVC
Test
RTL C.
IP-B
IP-B
Test/Seq
RTL
CMN
iUVC
IP-A
IP-A
Test/Seq
RTL
A New Paradigm of Reuse D.
IP-B
Multi-test architecture enables reusing UVM test benches from lowest level to intermediate or full chip levels. Somehow it enables new reuse patterns, provides more trade-off options, and optimizes cost.
The adaption of IP-level environment follows a regular pattern, and adapting code could be reused. This attribute eases creation of new subsystem test benches.
Many choices are provided for the integration-level test. IP-level tests and sequences can be reused without modification.
Higher debugging performance as the higher level environment becomes more familiar to IP engineers.
Third party UVM test benches can also be reused without reuse boundary
Reusability is tested by IP-level test. The test and environment are expected to run in the same way.
PASSIVE mode still supported by IP-level environment.
IP-B
Test/seq
RTL
CMN
iUVC
IP-A
Test/seq
IP-A
RTL
SoC
Seq
Figure Modes Supported by multi-test Bench
B. Distributed RAL modes
Refer to Figure 8 for the detail implementation of hierarchical RAL of each IP.
Figure A Structure Pseudo Code of Multi-Test Architecture
In order to achieving IP based test can be re-used under multi-test structure environment , An IP UVM environment might need certain adjustments to adapt to changes surrounding the design it targets. Such as :
Figure Redirecting Stimuli