SystemVerilog based OVM and UVM Verification Methodologies


Published on

Introduction to System Verilog based verification methodologies - OVM and UVM concepts
For more online courses and resources follow

Published in: Technology, Design
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Abstracting time reduces the number of activation of processes. Event based vs cycle based simulations. RTL evaluation of nets/signals vs evaluation of transactions

    Abstracting data - forms transaction objects instead of bit by bit details

    Abstracting function – TLMs implement design functionality with functions rather than with real registers or actual circuit as in RTL
  • Value of TLM - Modularity and re-use. For eg: in above diagram, the target can be easily replaced by another component that has same interface.
  • Write method in analysis port gets actually implemented in all subscribers which need to implement write()
    Write() happens in zero time – non-blocking
  • Standard UVM Agent configurations
    UVM_ACTIVE - Active agent which can have driver, sequencer and monitor
    UVM_PASSIVE - Passive agent which can have only a monitor – and still can do coverage/checking
    user defined configurations - eg: address configurations of slave
  • All phases other than build are bottoms up. Only build is top down
  • For objects or sequences - only type override is really used – as the hierarchy is not possible for them unlike components
    Eg : for component override – You may have default components with default behavior which you might want to override in specific tests with a more controlled behavior or so.
    Eg: for Sequence override - You want to have a normal transaction and an error transaction and pick one of them randomly
  • Passing Interface information from DUT to Test and then propagating it down to all agents using config data base is for modularity and re-use even though it is a round about way (instead of passing it directly to agents in TB)
  • End of test occurs when all of the time consuming phases have ended. Each phase ends when there are no longer any
    pending objections to that phase. So end-of-test in the UVM is controlled by managing phase objections
  • Create a sequence library package – where all sequence are defined
    Test can then start any sequence by calling start() method on any sequencer
  • When a sequence is used, it is created, then the body method is executed, and then the sequence can be discarded.
  • Start() has an argument which is pointer to the sequencer
    m_sequencer is a handle inside the sequence (which is transient) that gets assigned when the start() is called with the pointer of the actual sequencer
  • SystemVerilog based OVM and UVM Verification Methodologies

    1. 1. Introduction to Verification Methodologies - OVM/UVM Ramdas M Expert Verification Engineer 1/4/2016 Intro to Verification Methodologies - OVM/UVM Concepts 1
    2. 2. Agenda • Standard Verification Methodologies – Need for Methodologies – Layered Testbench Architecture – TLM concepts – OVM/UVM concepts • Testbench structure - Agent, Env, Factory, Callbacks • Sequences • For more Course Resources, Tutorials see • 1/4/2016 Intro to Verification Methodologies - OVM/UVM Concepts 2
    3. 3. Self Paced online courses • New and engaging way to learn everything about Functional Verification • Sign up here: courses/ • Structured online courses – SOC Verification using System Verilog – Learn SVA and Coverage Coding – Learn to build OVM/UVM Testbenches from scratch 1/4/2016 Intro to Verification Methodologies - OVM/UVM Concepts 3
    4. 4. Why do we need Standard Methodology? • Traditional methods doesn’t scale up or enable re-use across verification for complex design • Verification is increasingly becoming critical and complex – Building constrained random test benches is complex and time consuming – Projects demand verification engineers to divide and conquer • Following needs to be addressed for efficiency – Automation – Abstraction – Re-use – Interoparability – Quality 1/4/2016 Intro to Verification Methodologies - 4
    5. 5. What must a methodology Provide? • Standard to enable re-use – Abstraction/Project/Company/Industry wide re-use • Layered approach to enable a division of skills and development – Developing verification IP – Re-using and configuring existing verification IP – Separation of Stimulus from Testbench Structure – Writing of new code • Assertions and/or coverage points • Writing or re-using checkers • Writing or re-using test cases 1/4/2016 Intro to Verification Methodologies - 5
    6. 6. What must a methodology Provide? • A consistent approach – Naming conventions – Verification IP configuration • Defining the number of agent • How they connect to the DUT • Whether an agent is ACTIVE or PASSIVE – Well-defined generation and simulation phases • Build, connect, pre-run, run, post-run • The power to find bugs fast – Faster development of Testbench – Good control on stimulus, observability and debug ability • Vendor/Tool independence • Verification Management - Planning, progress and completion 1/4/2016 Intro to Verification Methodologies - 6
    7. 7. History of Verification Methodologies 1/4/2016 Intro to Verification Methodologies - 7
    8. 8. What is OVM/UVM ? • OVM - Open Verification Methodology – Backward compatible with AVM and URM • UVM - Universal Verification Methodology – Accellera standard – SystemVerilog UVM Base Class Library (BCL) – Near-backward compatible with OVM • Both are Open source (Apache licence) • Test benches for (System)Verilog / VHDL / SystemC designs • SystemVerilog class library 1/4/2016 Intro to Verification Methodologies - 8
    9. 9. OVM/UVM Conceptual View 1/4/2016 Intro to Verification Methodologies - OVM/UVM Concepts 9
    10. 10. Highlights of OVM and UVM • Constrained random, coverage-driven verification • Configurable, flexible, test benches • Verification IP reuse • Separation of tests/stimulus from test bench • Transaction-level communication (TLM) • Layered sequential stimulus • Standardized messaging • Register layer (Newly added in UVM) – Enables programming and verifying registers in a consistent and efficient manner 1/4/2016 Intro to Verification Methodologies - 10
    11. 11. UVM – OVM - Differences • UVM is based on OVM 2.1.1 – The deprecated features from OVM were removed in UVM (deprecated.txt file in the OVM install area). – The URM and AVM compatibility layers were removed from UVM. • Updates in UVM – Enhancements to the OVM callback facility, including a new message catching facility. – Enhancements to the OVM objection mechanism. • These enhancements introduce some minor backward incompatibilities to the OVM callback facility. – Few capabiilties donated from VMM (not sure what?) – Other than this – it is a blind change from ovm_* to uvm_* for the whole library 1/4/2016 Intro to Verification Methodologies - 11
    12. 12. Layered Test bench Architecture • Structured Test benches are important for complex DUT Verification – Better maintainability – Better reusability – Parallel Development and Verification 1/4/2016 Intro to Verification Methodologies - 12
    13. 13. Layered Test bench Architecture • Bottom layer – Pin level interface • Next layer abstracts to transactions • All further layers above work on transactions 1/4/2016 Intro to Verification Methodologies - 13
    14. 14. Transactors • Components that converts stream of transaction to pin level interface and vice versa – Monitor • Passive components that watches the pin toggles and converts them to a stream of transactions – Driver • Converts a stream of transactions to pin level activity – Respondent • Similar to a driver but responds to an activity rather than initiating activity 1/4/2016 Intro to Verification Methodologies - 14
    15. 15. Operational Components • Transactional components that provides everything needed for DUT to operate – Stimulus Generator • Creates stream of transactions to stimulate the DUT. Can be random, directed or pseudo-random – Master • Bi-directional component that can send requests and can receive responses – Slave • Bi-directional component that responds to requests by returning with responses 1/4/2016 Intro to Verification Methodologies - 15
    16. 16. Analysis and Controller Components • Analysis components receive information about activities in the testbench and use that information for determination of correctness or completion – Scoreboards • They receive information about what’s going into and out of the DUT and analyze those for the correctness of DUT – Coverage collector • The count streams of transactions and different aspects to transactions and help in determining the completeness of verification • Controller forms the main thread of the test – They receive and send information from various testbench components to control the test – They control the start and stop of stimulus generators 1/4/2016 Intro to Verification Methodologies - 16
    17. 17. Transaction Level Modelling • Transaction-level models consist of multiple processes communicating with each other by sending transactions back and forth through channels. – Abstracts time • Reduces the number of activation of processes • RTL evaluation of nets/signals vs evaluation of transactions – Abstracts data • Form transaction objects instead of bit by bit details – Abstracts function • Implement functionality with functions/processes rather than with real registers or circuits 1/4/2016 Intro to Verification Methodologies - 17
    18. 18. Understanding TLM - OVM/UVM • TLM is the basis for modularity and re- use in OVM/UVM • TLM is all about communication through method calls – A TLM port specifies the “API” to be used – A TLM export supplies the implementation of the methods • Connections are between ports/exports, not components • Transactions are objects • Ports & exports are parameterized by the transaction type being communicated 1/4/2016 Intro to Verification Methodologies - 18
    19. 19. TLM interfaces supported 1/4/2016 Intro to Verification Methodologies - OVM/UVM Concepts 19 • Unidirectional – Blocking (Tasks) • put • get/peek – Nonblocking (functions) • try_put • try_get/try_peek • write • Bi directional – Master • put_request • get_response – Slave • get_request • put_response – Transport • transport • nb_transport (function) – Sequence/Driver • get_request • put_response
    20. 20. Analysis Ports • Analysis ports support 1:many connections • Meets “observer pattern” where observers register with a single source of information • Used by coverage collectors and score boards • write() needs to be non-blocking 1/4/2016 Intro to Verification Methodologies - 20
    21. 21. UVM Testbench Hierarchy • Testbenches are built from classes derived from uvm_component class • Top level class is a test class that instantiates “env” class which instantiates a series of components • Modular to facilitate the reuse of groups of verification components – Across projects (horizontal reuse) – Across levels of integration (veritical reuse) • Two main collective component types – the env (short for environment) – the agent 1/4/2016 Intro to Verification Methodologies - 21
    22. 22. UVM Component and Sequences • Structural components of Testbench and Stimulus generation are kept separate. • All structural components of testbench are derived from uvm_component base class – Creates a static hierarchy • All transient objects are derived from uvm_sequence base class which are created, used and garbage collected when de-referenced 1/4/2016 Intro to Verification Methodologies - 22
    23. 23. Available UVM components 1/4/2016 Intro to Verification Methodologies - 23
    24. 24. UVM Agent • UVM agent – collection of a group of uvm_components focused around a specific pin-level interface – Multiple agents can be used for multiple DUT interfaces which has different protocol – Agents can be reused for similar interfaces 1/4/2016 Intro to Verification Methodologies - 24
    25. 25. Agent Components • Driver – Converts data inside a series of sequence_items into pin level transactions. • Sequencer - Routes sequence_items from a sequence where they are generated to/from a driver. • Monitor - Observes pin level activity and converts its observations into sequence_items which are sent to analysis components • Configuration object – Contains information about agent which determines what it does and how it is built and connected. 1/4/2016 Intro to Verification Methodologies - 25
    26. 26. UVM Env • Collection of UVM Agents – Allows interface level reuse • Has its own configuration object – eg: can control no of agents, env.config can set agent.config • Can have analysis components like scoreboard, coverage monitor • Multiple block level env classes can be instantiated to have top level env 1/4/2016 Intro to Verification Methodologies - 26
    27. 27. UVM Test • Test is the top level class that instantiatiates ENV, configures the testbench and intiates construction • Individual tests derive from uvm_test – Each test case instantiates uvm_env and configures them • Testbench activated with a call to run_test() which starts build phases 1/4/2016 Intro to Verification Methodologies - 27
    28. 28. Testbench Build • All uvm_component_class objects in Testbench hierarchy constructed top down – Build() method in uvm_test gets called first and then propagates down 1/4/2016 Intro to Verification Methodologies - 28
    29. 29. UVM/OVM Simulation Phases • When using classes, you need to manage environment creation at run-time • Test execution is divided to phases – Configuration, testbench creation, run-time, check, etc • Unique tasks are performed in each simulation phase – Set-up activities are performed during “testbench creation” while expected results may be addressed in “check” – Phases run in order – next phase does not begin until previous phase is complete • OVM/UVM provides set of standard phases enabling VIP plug&play 1/4/2016 Intro to Verification Methodologies - 29
    30. 30. UVM Phases • Build Phases – Build Top-Level Testbench Topology – Connect environment topology – Post-elaboration activity (e.g. print topology) • Run Phases – Run-time execution of test – All phases except run() execute in zero time – Lots of sub-phases not used really • Cleanup Phases – Gathers details on the final DUT state – Processes and checks the simulation results. – Simulation results analysis and reporting 1/4/2016 Intro to Verification Methodologies - 30
    31. 31. Run Phases • start_of_simulation() – occurs before the time consuming part of the testbench begins. Called in bottom up order • run() – stimulus generation and checking activities – all uvm_component run tasks are executed in parallel. • pre_reset() – Its purpose is to take care of any activity that should occur before reset eg: waiting for a power good signal to go high • reset() - for DUT or interface specific reset behaviour. • post_reset() - – Intended for any activity required immediately following reset. • pre_configure() – Intended for anything that is required to prepare for the DUT's configuration process after reset completion. • configure() – Used to program the DUT and any memories in the testbench so that it is ready for the start of the test. 1/4/2016 Intro to Verification Methodologies - 31
    32. 32. Run Phases • post_configure() – Used to wait for the effects of configuration to propagate through the DUT. • pre_main() – Used to ensure that all required components are ready to start generating stimulus. • main() – This is where the stimulus specified by the test case is generated and applied to the DUT. It completes when either all stimulus is exhausted or a timeout occurs. • post_main() – Used to take care of any finalization of the main phase. • pre_shutdown() – This phase is a buffer for any DUT stimulus that needs to take place before the shutdown phase. • Shutdown() – Used to ensure that the effects of the stimulus generated during the main phase have propagated through the DUT and that any resultant data has drained away. • post_shutdown() – Perform any final activities before exiting the active simulation phases. 1/4/2016 Intro to Verification Methodologies - 32
    33. 33. UVM Factory • UVM Factory – Allows an object of one type to be substituted with an object of derived type without testbench edits/re-compile – Works on the concept of polymorphism which allows a derived class object to be accessed using a base class type handle • All objects should be registered with factory class – `ovm_object_utils (for sequences) and `ovm_component_utils (for components) – Use ::create() method of factory instead of calling new() • Two types of override possible – Type overrides • Every time a component class type is created in a testbench hierarchy, a substitute type is created in its place. Applies to all instances of that component type – Instance override • A specific component instance is overridden by specifying its position in the uvm component hierarchy 1/4/2016 Intro to Verification Methodologies - 33
    34. 34. Callbacks • Like the factory, callbacks are a way to affect an existing component from outside – The SystemVerilog language includes built-in callbacks e.g. post_randomize(), pre_body() • A call back function can be defined as a virtual function in the base class and implemented in the derived class as needed • Similar to how in computer programming – how a low level software can call a user defined higher layer function 1/4/2016 Intro to Verification Methodologies - 34
    35. 35. UVM Configuration • Test benches need to be as configurable as possible for re-use – Each component can have a config object – Global config objects are also possible • Several variables can be configurable and test can control runtime – e.g. for loop limits, randomization weightages, coverage bins etc. 1/4/2016 Intro to Verification Methodologies - 35 • UVM config database takes care of scope and storage of these config objects
    36. 36. UVM Configuration • uvm_config_db class is recommended way of accessing config across components – ::set* and ::get* methods available • Two typical uses with uvm_config_db – Passing virtual interfaces from DUT to test • In module top() - add the physical interface into config db using config_db::set() method • In class uvm_test() – get the handle to interface using config_db::get() and pass down to agents – Passing configuration classes down through TB 1/4/2016 Intro to Verification Methodologies - 36
    37. 37. DUT – TB connection • DUT is in static world and TB is in dynamic world • For modularity and re-use – DUT should provide information of interfaces to testbench without knowing how it is configured – Test to propagate it down to agents based on config data base 1/4/2016 Intro to Verification Methodologies - 37
    38. 38. End of Test Mechanism - Objections • End of Test – Happens when all time consuming phases end – A phase end happens when there are no pending objections to that phase • uvm_objection class – Provides a shared counter between all participating components and sequences – Each participant can “raise” (increase) or “drop” (decrease) objection – Used in run() phase of UVM to determine end of phase when an “all dropped” (zero count) is reached • Methods – ::raise_objection() – ::drop_objection() 1/4/2016 Intro to Verification Methodologies - 38
    39. 39. Sequences - Seperating Stimulus from Testbench • Key to reusability – Separate Behavior from Structure • Sequences provide a highly modular and flexible means for building complex stimulus generators 1/4/2016 Intro to Verification Methodologies - 39
    40. 40. Layered Sequential Stimulus 1/4/2016 Intro to Verification Methodologies - 40 • Every stimulus drives some transactions as pins on DUT – eg: a read or a write transaction to a DUT • A group of transactions can be combined to form a sequence – e.g. read-modify-write – Can be a deterministic sequence – Can be a random or constrained random • A test will define what sequences and the order of them • Enables re-use at different levels of verification
    41. 41. UVM Sequences - Overview • A sequencer controls the generation of random stimulus by executing sequences • A sequence captures meaningful streams of transactions – A simple sequence is a random transaction generator – A more complex sequence can contain timing, additional constraints, parameters • Sequences: – Allow reactive generation –react to DUT – Have many built-in capabilities like interrupt support, arbitration schemes, automatic factory support, etc – Can be nested inside other sequences – Are reusable at higher levels 1/4/2016 Intro to Verification Methodologies - 41
    42. 42. UVM Sequences • Sequence is a transient object with limited life time unlike a uvm_component – Each sequence will have to implement a task called body() – This can be implemented to create other sequences or to generate sequence_item and send to driver • Sequencer is an intermediate component that implements communication channels and arbitration mechanisms between sequence and driver • Sequence item – Data object that contains all the needs of a driver to driver on pin level – Most randomization done on this object – Should implement all of the virtual methods like copy/clone/compare/print etc 1/4/2016 Intro to Verification Methodologies - 42
    43. 43. Sequence Execution Flow • Call uvm_sequence::start() to start sequence execution – Will internally call the body() method – The body() can implement what all sequence_items to be send to driver or whether to spawn other sequence etc.. • Controlling multiple sequences to a single driver – Sequencer has 5 arbitration schemes that can be configured – Sequence id field can be used for correlating response from drivers to a sequence. – Methods like grab or lock are available if a sequence need exclusive access to driver • Controlled stimulus generation on multiple drivers connected to different interface – Use a Virtual sequence which can start sub-sequences 1/4/2016 Intro to Verification Methodologies - 43
    44. 44. Virtual Sequences • A virtual sequence is a sequence that can start sub-sequences on multiple sequencers in different agents. – Also called “co-ordinated sequence” • In below e.g. you might want a specific bus sequence happening at same time when a specific GPIO sequence is happening on a different interface in a controlled manner 1/4/2016 Intro to Verification Methodologies - 44
    45. 45. Sequence-Driver API Calls 1/4/2016 Intro to Verification Methodologies - 45
    46. 46. Register Abstraction Layer • Abstracts a common reference specification for all registers – To be shared across design/verification/Software teams – Can be created using a generator application or hand coded 1/4/2016 Intro to Verification Methodologies - 46
    47. 47. Acknowledgements/Reference • Thanks to following useful content – Accellera SystemVerilog workshop foils at DAC2003 – Verification Academy Trainings and OVM/UVM cookbooks – Several other Reference papers on DVCon etc 1/4/2016 Intro to Verification Methodologies - OVM/UVM Concepts 47
    48. 48. Thank you • For more video lectures on same follow – • Follow on Facebook – ce • Follow on Twitter – 1/4/2016 Intro to Verification Methodologies - 48
    49. 49. Thank You • Sign up here – • Follow on Face book – Click Here – • Follow on Twitter - Click Here – 1/4/2016 Intro to Verification Methodologies - 49