Course : UVM in Systemverilog 2 : L2.1 : Generic UVM TB Structure

[00:00:00]in this movie i'll be describing the generic structure of a uvm based response and also you'll see quickly the class hierarchy ue as i said earlier i will not be describing these topics in detail as this is a continuation course of my beginner level uvm course here you will get a brief overview of how this will look like so this is a class hierarchy the simplified class hierarchy of uvm so you can imagine that all uvm classes are derived from the oem class name uvm underscore object actually there are few more subclasses sitting in between them which you can ignore now there are two main streams of uvm classes which are uvm transactions streams and uvm competent streams so uvm transactions soon consist of transaction sequence item and sequences out of which you will use the uvm sequence to write a sequence of transaction and in order to write your own transaction you will be using umc site these are the uvm components which you will commonly use in the test phones which are the test the env agent sequencer driver and monitor here is a generic uvm base testment structure so the top level class that is instantiating all other components will be a uvm test so it will be euron test which will be extended from the uvm test and it will consist of a sequence subclass and environment subclass the sequence of class can be a single sequence or it could be a abstraction of multiple sequences or it can be even a virtual sequence which to which is used to coordinate between these two sequences and coming to the environment part it will consist of a um env or euron enemy which will be extended from the uvm env and every env will consist of multiple um agents again a single engine will consist of a uvm sequencer a um driver and a ua monitor additionally there could be there could be a checker and coverage component that is present within the uvm engine it is optional there could be multiple uv imagings present in the same environment on top of the agents there could be scoreboards and coverage collection components which will be acting across this division in general a single um agent will be acting on a single interface in the duty so these are two different interfaces if there are two different interfaces you need to use two different uvm variants and these scoreboards and coverage connection components which are not sitting in within an engine could be used to collect coverage or to do checking part of transaction that is coming between two interfaces so this is between interfaces and if at all these components are present these will be a per interface this is a generic structure of a uvm based test bench and from next section onwards you will be seeing in detail how you can write a complete uvm agent which can be reused across different clusters and different hierarchies