Downloaded 152 times
Uploaded byRamdas Mozhikunnath
SystemVerilog based OVM and UVM Verification Methodologies
The document provides an introduction to verification methodologies, specifically OVM (Open Verification Methodology) and UVM (Universal Verification Methodology), focusing on structured testbench architecture and the importance of standard methodologies for complex design verification. It highlights the need for automation, reusability, and interoperability in verification processes while detailing the components and phases involved in creating effective testbenches using these methodologies. Additionally, the document discusses transaction-level modeling (TLM), configuration, and the role of sequences in generating stimulus for design under test (DUT).
More Related Content
Similar to SystemVerilog based OVM and UVM Verification Methodologies
SystemVerilog based OVM and UVM Verification Methodologies
- 1. Introduction to Verification Methodologies- OVM/UVM Ramdas M Expert Verification Engineer 1/4/2016 Intro to Verification Methodologies - OVM/UVM Concepts 1
- 2. Agenda • Standard VerificationMethodologies – Need for Methodologies – Layered Testbench Architecture – TLM concepts – OVM/UVM concepts • Testbench structure - Agent, Env, Factory, Callbacks • Sequences • For more Course Resources, Tutorials see • http://verificationexcellence.in/ 1/4/2016 Intro to Verification Methodologies - OVM/UVM Concepts 2
- 3. Self Paced onlinecourses • New and engaging way to learn everything about Functional Verification • Sign up here: http://verificationexcellence.in/online- 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. Why do weneed 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. What must amethodology 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. What must amethodology 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. History of VerificationMethodologies 1/4/2016 Intro to Verification Methodologies - 7
- 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. OVM/UVM Conceptual View 1/4/2016Intro to Verification Methodologies - OVM/UVM Concepts 9
- 10. Highlights of OVMand 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. 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. Layered Test benchArchitecture • 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. Layered Test benchArchitecture • 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. Transactors • Components thatconverts 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. Operational Components • Transactionalcomponents 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. Analysis and ControllerComponents • 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. 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. 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. TLM interfaces supported 1/4/2016Intro 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. Analysis Ports • Analysisports 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. 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. UVM Component andSequences • 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. Available UVM components 1/4/2016Intro to Verification Methodologies - 23
- 24. UVM Agent • UVMagent – 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. 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. UVM Env • Collectionof 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. UVM Test • Testis 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. Testbench Build • All uvm_component_class objectsin 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. 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. UVM Phases • BuildPhases – 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. 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. 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. UVM Factory • UVMFactory – 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. Callbacks • Like thefactory, 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. UVM Configuration • Testbenches 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. UVM Configuration • uvm_config_dbclass 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. DUT – TBconnection • 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. End of TestMechanism - 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. Sequences - SeperatingStimulus 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. Layered Sequential Stimulus 1/4/2016Intro 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. 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. UVM Sequences • Sequenceis 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. 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. Virtual Sequences • Avirtual 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. Sequence-Driver API Calls 1/4/2016Intro to Verification Methodologies - 45
- 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. Acknowledgements/Reference • Thanks tofollowing 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. Thank you • Formore video lectures on same follow – http://verificationexcellence.in/online-courses/ • Follow on Facebook – https://www.facebook.com/verificationexcellen ce • Follow on Twitter – https://twitter.com/ramdas2m 1/4/2016 Intro to Verification Methodologies - 48
- 49. Thank You • Signup here – http://verificationexcellence.in/online-courses/ • Follow on Face book – Click Here – https://www.facebook.com/verificationexcellence • Follow on Twitter - Click Here – https://twitter.com/ramdas2m 1/4/2016 Intro to Verification Methodologies - 49
Editor's Notes
- #18 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
- #19 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.
- #21 Write method in analysis port gets actually implemented in all subscribers which need to implement write() Write() happens in zero time – non-blocking
- #26 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
- #31 All phases other than build are bottoms up. Only build is top down
- #34 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
- #38 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)
- #39 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
- #41 Create a sequence library package – where all sequence are defined Test can then start any sequence by calling start() method on any sequencer
- #43 When a sequence is used, it is created, then the body method is executed, and then the sequence can be discarded.
- #44 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