The UVM Way<\/h2>\n\n\n\n
UVM testbenches have two major groups of classes: transactions and components, plus minor utilities. All UVM classes are derived from uvm_object. In my last post, I recommended that you give every SystemVerilog object either a unique ID or name. uvm_object has both as seen in its constructor.<\/p>\n\n\n\n
class uvm_object;\n function new(string name);\n m_inst_id = m_inst_count++;\n m_leaf_name = name;\n endfunction\nendclass<\/pre>\n\n\n\nThis code follows the convention that member variables start with the prefix of \u201cm_\u201d.<\/p>\n\n\n\n
UVM Topology<\/h2>\n\n\n\n
In the following diagram, all the boxes are components: test, environment, agent, monitor, driver, sequencer, and scoreboard. The gold dots are transactions that are generated in the gold sequence and flow to the driver, or are sampled in the monitor and sent to the scoreboard.<\/p>\n\n\n\n
UVM Topology with components and transactions<\/figcaption><\/figure>\n\n\n\n The OOP term \u201chierarchy\u201d refers to the tree of base classes and their extensions, an is-a<\/em> relationship. The UVM term \u201chierarchy\u201d is a has-a<\/em> relationship, like an agent has-a driver. To avoid confusion, I call this relationship the UVM \u201ctopology\u201d.<\/p>\n\n\n\n
UVM components have a fixed topology. A driver is always inside an agent, so UVM says that the driver\u2019s parent is the agent. The agent\u2019s parent is an environment, whose parent is the test.<\/p>\n\n\n\n
You can see this in the constructor for the base component class which passes the name up to uvm_object and saves a copy of the parent handle. Neither the name or parent need a default.<\/p>\n\n\n\n
class uvm_component extends uvm_object;\n function new(string name, uvm_component parent);\n super.new(name);\n m_parent = parent;\n endfunction\nendclass<\/pre>\n\n\n\nTransactions have no fixed location, flowing from one component to the next. You can’t verify a design with a single transaction, so UVM groups one or more of them into a sequence. This is why transactions in UVM are derived from uvm_sequence_item. This class is derived from uvm_object, and its constructor does not have a parent argument. However the name must have a default value.<\/p>\n\n\n\n
class uvm_sequence_item extends uvm_object;\n function new(string name=\u201duvm_sequence_item\u201d);\n super.new(name);\n endfunction\nendclass<\/pre>\n\n\n\nLife in the Tree of Components<\/h2>\n\n\n\n
Another dimension of your testbench is time. When are these objects constructed and then garbage collected? When you start simulation, UVM builds the components from the top down, from the test down to the driver and monitor. These objects exist for the entire simulation \u2013 you wouldn\u2019t want the driver to get garbage collected halfway through the test! I call component objects \u201cpermanent\u201d.<\/p>\n\n\n\n
After the components are built and connected, UVM runs your test. Hundreds or thousands of transactions are created in sequences, flow through the testbench into the design, or captured by the monitor and sent to the scoreboard. When no longer needed, the objects are garbage collected. Transactions are very dynamic.<\/p>\n\n\n\n
Who\u2019s Jiving Who?<\/h2>\n\n\n\n
The final big difference between these two types is their focus. Transactions are passive containers of properties such as address and data. The have functions to print, copy, and compare the properties. This pseudo-UVM Packet class gives you the flavor. The calcCsm function calculates the checksum (csm) based on the src, dst, and data properties.<\/p>\n\n\n\n
The Packet class with functions, and a Packet class variable<\/figcaption><\/figure>\n\n\n\n Components are active, operating on transactions. (Technically, they have class variables with handles to the transaction objects.) Components have tasks to send and receive transactions. You would never print, copy, clone, or compare a component.<\/p>\n\n\n\n
The Packet_Driver class with run_phase task, and a class variable<\/figcaption><\/figure>\n\n\n\n Summary: UVM Categories<\/h2>\n\n\n\n
The following table compares the two major categories of classes in UVM, with examples based on the above code.<\/p>\n\n\n\n
What<\/strong><\/td> Transactions<\/strong><\/td> Components<\/strong><\/td><\/tr> UVM Topology<\/td> No fixed location<\/td> Fixed location<\/td><\/tr> Constructor<\/td> function new(name=”default”)<\/td> function new(name, parent)<\/td><\/tr> Factory macro<\/td> `uvm_object_utils(class_name)<\/td> `uvm_component_utils(class_name)<\/td><\/tr> create call<\/td> pkt = packet::type_id::create(“pkt”)<\/td> drv = packet_driver::type_id::create(“driver”, this)<\/td><\/tr> Lifetime<\/td> Short<\/td> Permanent<\/td><\/tr> active\/passive<\/td> Passive: method operate on itself<\/td> Active: methods operate on transaction objects<\/td><\/tr> Methods<\/td> Functions to print, copy, clone, compare, this object’s properties<\/td> Tasks such as run_phase() and functions that operate on transactions<\/td><\/tr><\/tbody><\/table> Comparison between UVM transaction and component classes<\/figcaption><\/figure>\n\n\n\n Final Note<\/h2>\n\n\n\n
This post goes over many concepts that confused me when I first learned UVM, such as why some constructors have one argument, and other have two. Another issue: what is the difference between a sequence and a sequencer? Just remember that a sequencer, like a driver, and monitor, is an active component \u2013 they all end in \u2018r\u2019. Hopefully you can get up to speed faster than me!<\/p>\n\n\n\n
This describes a very simple system with the minimum number of classes. The code examples left out many details. Otherwise, this post would be twice as long and twice as confusing!<\/p>\n\n\n\n
![\"UVM](\"https:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/54\/2021\/06\/2_1_uvm_topo.png\")
![\"\"](\"https:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/54\/2021\/06\/2_2_packet_class-1.png\")
![\"\"](\"https:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/54\/2021\/06\/2_3_driver_class-1-1024x616.png\")