Introducing the Universal Verification Methodology (UVM ...

1 North American SystemC User's Group June 2, 2014. Introducing the Universal Verification Methodology (UVM) in SystemC and SystemC-AMS. Karsten Einwich Fraunhofer IIS/EAS. Martin Barnasconi NXP Semiconductors Thilo V rtler Fraunhofer IIS/EAS. Thomas Klotz Fraunhofer IIS/EAS. NASCUG 2014. Fraunhofer IIS/EAS. Outline n Introduction and Motivation n Universal Verification Methodology (UVM) what is it? n Why UVM in SystemC/C++/SystemC-AMS? n UVM-SystemC overview n UVM foundation elements n UVM test bench and test creation n Randomization and coverage n Contribution to Accellera n Applications and use cases of UVM-SystemC. n Summary and outlook NASCUG 2014. Fraunhofer IIS/EAS Karsten Einwich 1. Presented during DAC 51 in San Francisco, CA Page 1 of 24. North American SystemC User's Group June 2, 2014. Outline n Introduction and Motivation n Universal Verification Methodology (UVM) what is it? n Why UVM in SystemC/C++/SystemC-AMS?

2 N UVM-SystemC overview n UVM foundation elements n UVM test bench and test creation n Randomization and coverage n Contribution to Accellera n Applications and use cases of UVM-SystemC. n Summary and outlook NASCUG 2014. Fraunhofer IIS/EAS Karsten Einwich Introduction: UVM - what is it? n Universal Verification Methodology facilitates the creation of modular, scalable, configurable and reusable test benches n Based on Verification components with standardized interfaces n Class library which provides a set of built-in features dedicated to simulation- based Verification n Utilities for phasing, component overriding (factory), configuration, comparing, scoreboarding, reporting, etc. n Environment supporting migration from directed testing towards Coverage Driven Verification (CDV). n Introducing automated stimulus generation, independent result checking and coverage collection NASCUG 2014. 4. Fraunhofer IIS/EAS Karsten Einwich 2.

3 Presented during DAC 51 in San Francisco, CA Page 2 of 24. North American SystemC User's Group June 2, 2014. Motivation n No structured nor unified Verification Verification & Validation Methodology available for ESL design Methodology n UVM (in SystemVerilog) primarily targeting block/IP level (RTL) Verification , not system- UVM- SystemC* - AMS. level n Porting UVM to SystemC/C++ enables - AMS. TLM SCV. n creation of more advanced system-level SystemC- AMS. test benches n reuse of Verification components between SystemC. system-level and block-level Verification C++. n Target to make UVM truly Universal , and not tied to a particular language *UVM-SystemC = UVM implemented in SystemC/C++. NASCUG 2014. 5. Fraunhofer IIS/EAS Karsten Einwich Why UVM in SystemC/C++ and SystemC-AMS? n Strong need for a system-level Verification Methodology for embedded systems which include HW/SW and AMS functions n SystemC is the recognized standard for system-level design, and needs to be extended with advanced Verification concepts n SystemC AMS available to cover the AMS Verification needs n Reuse tests and test benches across Verification (simulation) and validation (HW-prototyping) platforms n This requires a portable language like C++ to run tests on HW prototypes and even measurement equipment n Enabling Hardware-in-the-Loop simulation or Rapid Control Prototyping n Benefit from proven standards and reference implementations n Leverage from existing Methodology standards and reference implementations, aligned with best practices in Verification NASCUG 2014.

4 6. Fraunhofer IIS/EAS Karsten Einwich 3. Presented during DAC 51 in San Francisco, CA Page 3 of 24. North American SystemC User's Group June 2, 2014. Outline n Introduction and Motivation n Universal Verification Methodology (UVM) what is it? n Why UVM in SystemC/C++/SystemC-AMS? n UVM-SystemC overview n UVM foundation elements n UVM test bench and test creation n Randomization and coverage n Contribution to Accellera n Applications and use cases of UVM-SystemC. n Summary and outlook NASCUG 2014. Fraunhofer IIS/EAS Karsten Einwich UVM-SystemC overview UVM- SystemC functionality Status Test bench creation with component classes: . agent, sequencer, driver, monitor, scoreboard, etc. Test creation with test, (virtual) sequences, etc.. Configuration and factory mechanism . Phasing and objections . Policies to print, compare, pack, unpack, etc.. Messaging and reporting . Register abstraction layer and callbacks development Coverage groups development Constrained randomization SCV or CRAVE.

5 NASCUG 2014. 8. Fraunhofer IIS/EAS Karsten Einwich 4. Presented during DAC 51 in San Francisco, CA Page 4 of 24. North American SystemC User's Group June 2, 2014. UVM layered architecture Spec Test Test Test ccases ases Verification environment (test bench). Scenario Functional coverage Sequences Verification component Functional Sequencer Scoreboard Command Driver Monitor Monitor Signal Device under test NASCUG 2014. 9. Fraunhofer IIS/EAS Karsten Einwich UVM-SystemC phasing UVM common phases Pre-run phases Runtime phases Post-run phases build connect run extract check report final . before_end_of_elaboration* end_of_simulation*. end_of_elaboration UVM runtime phases . Legend start_of_simulation configure main shutdown = SystemC process(es). pre- reset post- reset = top- down execution = bottom- up execution reset = SystemC- only callback *. n UVM phases are mapped on the SystemC phases n UVM-SystemC supports the 9 common phases and the (optional) refined runtime phases n Completion of a runtime phase happens as soon as there are no objections (anymore) to proceed to the next phase NASCUG 2014.

6 10. Fraunhofer IIS/EAS Karsten Einwich 5. Presented during DAC 51 in San Francisco, CA Page 5 of 24. North American SystemC User's Group June 2, 2014. UVM agent seq agent trans config n Component responsible for driving and sequencer monitoring the DUT seq_item_export analysis n Typically contains three components n Sequencer seq_item_port item_collected_port driver monitor n Driver vif vif n Monitor n Can contain analysis functionality for basic coverage and checking n Possible configurations n Active agent: sequencer and driver are enabled n Passive agent: only monitors signals (sequencer and driver are disabled). n C++ base class: uvm_agent NASCUG 2014. 11. Fraunhofer IIS/EAS Karsten Einwich UVM-SystemC agent (1). seq class vip_agent : public uvm_agent Dedicated base class to agent { distinguish agents from trans public: vip_sequencer<vip_trans>* sequencer; other component types config vip_driver<vip_trans>* driver; sequencer vip_monitor* monitor; seq_item_export analysis Registers the object UVM_COMPONENT_UTILS(vip_agent) in the factory vip_agent( uvm_name name ) seq_item_port item_collected_port : uvm_agent( name ), sequencer(0), driver(0), monitor(0) {} Children are driver monitor virtual void build_phase( uvm_phase& phase ) instantiated in { the build phase vif vif uvm_agent::build_phase(phase); Essential call to base class to if ( get_is_active() == UVM_ACTIVE ) access properties of the agent { sequencer = vip_sequencer<vip_trans>::type_id::create("sequencer", this); assert(sequencer); driver = vip_driver<vip_trans>::type_id::create("driver", this); assert(driver).}}}

7 } Call to the factory which creates and instantiates this component dynamically monitor = vip_monitor::type_id::create("monitor", this); assert(monitor); } NASCUG 2014 NOTE: UVM-SystemC API under review subject to change 12. Fraunhofer IIS/EAS Karsten Einwich 6. Presented during DAC 51 in San Francisco, CA Page 6 of 24. North American SystemC User's Group June 2, 2014. UVM-SystemC agent (2). seq agent trans config .. sequencer virtual void connect_phase( uvm_phase& phase ) seq_item_export analysis { if ( get_is_active() == UVM_ACTIVE ) seq_item_port item_collected_port { // connect sequencer to driver driver monitor driver- > (sequencer- >seq_item_export); } vif vif } }; Only the connection between sequencer and driver is made here. Connection of driver and monitor to the DUT is done via the configuration mechanism NASCUG 2014 NOTE: UVM-SystemC API under review subject to change 13. Fraunhofer IIS/EAS Karsten Einwich UVM Verification component n A UVM Verification component (UVC) UVM Verification component (env).

8 Is an environment which consists of config one or more cooperating agents seq agent trans n UVCs or agents may set or get config configuration parameters sequencer n An independent test sequence is seq_item_export analysis processed by the driver via a sequencer n Each Verification component is seq_item_port item_collected_port connected to the DUT using a dedicated driver monitor interface vif vif n C++ base class: uvm_env NASCUG 2014. 14. Fraunhofer IIS/EAS Karsten Einwich 7. Presented during DAC 51 in San Francisco, CA Page 7 of 24. North American SystemC User's Group June 2, 2014. UVM-SystemC Verification component class vip_uvc : public uvm_env { UVM Verification component (env). public: A UVC is considered as a vip_agent* agent; config sub-environment in large seq system-level environments agent UVM_COMPONENT_UTILS(vip_uvc); trans vip_uvc( uvm_name name ) config : uvm_env( name ), agent(0) {} sequencer virtual void build_phase( uvm_phase& phase ) seq_item_export analysis { uvm_env::build_phase(phase); seq_item_port item_collected_port agent = vip_agent::type_id::create("agent", this); assert(agent); driver monitor } vif vif }; n In this example, the UVM Verification component (UVC) contains only one agent.

9 In practice, more agents are likely to be instantiated NASCUG 2014 NOTE: UVM-SystemC API under review subject to change 15. Fraunhofer IIS/EAS Karsten Einwich UVC with AMS driver and monitor using SystemC-AMS. n Regular UVM-SystemC drivers and UVM Verification component (env). monitors are used in which SystemC-AMS. config Timed Data Flow (TDF) modules are seq instantiated agent trans n Factory overrides enable configuration of config the UVC's driver or monitor for specific sequencer AMS use cases seq_item_export analysis n For the SystemC-AMS modules, TDF ports are necessary to allow read / write seq_item_port item_collected_port AMS AMS. operations to the analog interface driver driver monitor monitor n The parent driver and monitor establish the vif vif connection from the TDF ports to the interface via the configuration mechanism NASCUG 2014. 16. Fraunhofer IIS/EAS Karsten Einwich 8. Presented during DAC 51 in San Francisco, CA Page 8 of 24.

10 North American SystemC User's Group June 2, 2014. UVM sequences sequence transaction n Sequences are part of the test scenario and define transaction streams of transactions n The properties (or attributes) of a transaction are transaction captured in a sequence item n Sequences are not part of the test bench hierarchy, but are mapped onto one or more sequencers seq1. n Sequences can be layered, hierarchical or virtual, and may contain multiple sequences or sequence trans items seq trans n Sequences and transactions can be configured via seq1. the factory seq2 seq2. trans trans NASCUG 2014. 17. Fraunhofer IIS/EAS Karsten Einwich UVM-SystemC sequence item class vip_trans : public uvm_sequence_item seq { agent Transaction trans public: defined as sequence item config int addr; int data; User-defined data items sequencer (randomization can be done bus_op_t op; using SCV or CRAVE) seq_item_export analysis UVM_OBJECT_UTILS(vip_trans); seq_item_port item_collected_port driver monitor vip_trans( const std::string& name = "vip_trans" ) : addr(0x0), data(0x0), op(BUS_READ) {} vif vif virtual void do_print( uvm_printer& printer ) const {.}}