{"id":18112,"date":"2023-01-20T10:48:41","date_gmt":"2023-01-20T15:48:41","guid":{"rendered":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/?p=18112"},"modified":"2026-03-27T08:51:21","modified_gmt":"2026-03-27T12:51:21","slug":"uvm-factory-revealed-part-1","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/2023\/01\/20\/uvm-factory-revealed-part-1\/","title":{"rendered":"UVM Factory Revealed, Part 1"},"content":{"rendered":"\n
Introduction<\/h2>\n\n\n\n
When you first learn UVM, most of the concepts make sense, even if you are new to Object-Oriented Programming. Except one, the UVM Factory. Why do you need all that extra code, class::type_id::create()<\/code>, just to make an object? What\u2019s wrong with just calling new()<\/code>? The answer is teamwork!<\/p>\n\n\n\n
The Small Problem<\/h2>\n\n\n\n
Imagine you are trying to verify a design with the X bus protocol. You write UVM testbench components that speak that protocol, including the agent, driver, and monitor. Here is agent code that constructs the driver.<\/p>\n\n\n\n
class x_agent extends uvm_agent;\n x_driver drv;\n\n function void build_phase(\u2026);\n drv = new(\"drv\", this); \/\/ Construct the X bus driver\n endfunction\nendclass<\/code><\/pre>\n\n\n\n
In the build phase you call new()<\/code>. SystemVerilog says that this constructs the object based on the type of the handle on the left side, and so you end up with an x_driver<\/code> object. Job done and you didn\u2019t have to type all that type_id::create()<\/code> stuff.<\/p>\n\n\n\n
But then halfway through the project, your manager says the design must work with the next generation of the protocol, called the Xplus bus. She even gave you the xplus_driver<\/code> class that extends x_driver<\/code>.<\/p>\n\n\n\n
No problem, just add a flag variable and some code and your agent constructs both types. Since the new class extends the original one, you can reuse the drv <\/code>handle. You can even get fancy with the typed constructor.<\/p>\n\n\n\n
class x_agent extends uvm_agent;\n x_driver drv;\n bit use_xbus; \/\/ True: use X bus, False: XPLUS-bus\n\n function void build_phase(\u2026);\n if (use_xbus)\n drv = new(\u2026); \/\/ Contruct the X bus driver\n else\n drv = xplus_driver::new(\u2026); \/\/ Typed constructor builds xplus_driver object\n endfunction\nendclass<\/code><\/pre>\n\n\n\n
With this new agent and driver, you write a Xplus test, set the flag use_xbus<\/code>, and it passes. Who needs the factory when you can make a change this easily? Time to commit your changes and release them to the team.<\/p>\n\n\n\n
When you come in the next morning, there are several angry people outside your cubicle. There is a bug in your code \u2013 the default value of use_xbus <\/code>is 0, so the agent always constructs xplus_driver<\/code>. Everyone who tried to use your revised agent got the wrong driver and now all their tests fail.<\/p>\n\n\n\n
The Big Problem<\/h2>\n\n\n\n
The issue here is not the code bug. You are working in a team, so changes you make affect everyone. Every time you change shared code, adding more control variables, if<\/code>– and case<\/code>-statement for all the new variants, you potentially cause bugs. How can your tests inject the new xplus_driver <\/code>class without changing the x_agent <\/code>class?<\/p>\n\n\n\n
The Solution<\/h2>\n\n\n\n
Many UVM techniques involve polymorphism. Sounds tricky, but it just means you define a base class with virtual methods. These become \u201chooks\u201d to inject new behavior. How? Define a derived class and replace the base object with the derived one. Now when you call handle.action()<\/code>, you can get the base action or the derived, depending on the object type.<\/p>\n\n\n\n
The factory pattern is a little more subtle. Imagine that the factory is a printing press. If you load a drum with a base image, it will print base text. If you load one with a derived image, it prints the derived text.<\/p>\n\n\n\nThe UVM type-based Factory can print base and derived objects<\/figcaption><\/figure>\n\n\n\n
The UVM Factory prints objects. In the base x_driver <\/code>and derived xplus_driver<\/code>, use the `uvm_component_utils(x_driver)<\/code> macro to define type_id<\/code>. This is a \u201cproxy class\u201d, which means it is a \u201chelper\u201d of these classes, building their objects. Each type_id <\/code>is a unique class that, together, are the UVM Factory. The key is that all these proxy classes share a static array which is lookup table of base and derived types. By default, the following call builds an x_driver <\/code>object.<\/p>\n\n\n\n
The key concept is that from the test class, you can decide which object is built by the agent, without having to modify the agent’s code. In the test’s build_phase()<\/code>, add the following call.<\/p>\n\n\n\n
You can read this as follows. Tell the x_driver<\/code>\u2019s factory that when it is asked to create an object, use the type defined in the xplus_driver<\/code> class, where get_type()<\/code> returns the type xplus_driver::type_id<\/code>.<\/p>\n\n\n\n
The OOP hook here to inject new behavior is the virtual method create()<\/code>. The subtle difference is that the method is in the type_id<\/code> proxy class, not in any of the driver classes.<\/p>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
If you write your UVM testbench with the factory create pattern, instead of directly calling the new() constructor, you can inject new behavior by overriding a base class with a derived. Not only can you override components, but you can also extend a sequence item class, override the base type, and now all your sequences will get this new behavior, without changing their code. The factory pattern enables all this, plus a stable code base, so you can inject new features, without affecting your team.<\/p>\n\n\n\n
![\"The](\"https:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/54\/2023\/01\/type-rollers-1024x673.png\")