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. Wayne.Yun@amd.com Dave.Chen@amd.com Oliven.Xie@amd.com 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 8 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 3 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 1 Multi-Test Architecture Based on UVM Figure 9 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 6 2-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 7 4-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 2 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 5 Redirecting Stimuli