UVM Factory

UVM Factory

The UVM Factory is a software design pattern employed in UVM. It operates as a singleton, meaning it maintains a single class instance. This pattern enables the overriding of objects and UVM components. In essence, it allows the creation and replacement of these elements without requiring modifications to the testbench.

Consider an example involving a testbench with an Ethernet agent. The test environment might be structured as follows:

Figure 1: environment example

Each component would be defined as shown in the following figures:

Figure 2: agent’s sequence example
Figure 3: agent’s driver example
Figure 4: agent’s s example
Figure 5: agent’s monitor example
Figure 6: agent’s top example
Figure 7: scoreboard’s example

If an update to the Ethernet protocol requires a modification to the sequence item, such as changing it to "eth_v2_pkt," it would demand altering all files that utilize that sequence item. However, the UVM Factory allows for overriding all sequence items with a single statement, as illustrated below:

Figure 8: testcase example

This override can be applied selectively to each test case, enabling specific tests to utilize different sequence items. In other words, UVM override allows it to maintain tests for both Ethernet versions by adding or removing the UVM Factory override statement.

UVM Factory requirements

Three requirements must be achieved to leverage the UVM Factory features:

  • Polymorphic compatibility

In the aforementioned example, the newer sequence item must extend from the older version.

Figure 9: polymorphic sequence item example
  • UVM FACTORY registration

Within the class definition, the corresponding statement must be added to register objects or components to the UVM factory.

Figure 10: example of a Factory registration of an object

‍

Figure 11: example of a Factory registration of a component
  • UVM FACTORY creation

The components and objects must be created using the UVM factory methods instead of the `new()` method.

Figure 12: instantiating agent’s parts example

Override options

While Figure 8 demonstrates overriding by type, it is also possible to override by name, or even override instances by type or name. The following templates illustrate these four cases:

Figure 13: overriding the types examples
Figure 14: overriding the instantiations examples

This function examines the entire UVM environment and performs the corresponding override actions.

The UVM Factory provides a print method that displays all registered types within the factory, along with the methods being overridden. This print method should be called from the Test's `build_phase` only once (as it is a singleton).

Figure 15: how to print the factory’s configurations

The transcript will display the test configuration and overrides.

Figure 16: factory’s overrides outputs
Figure 17: factory’s configurations outputs

Conclusion

UVM factory can save us headaches and countless editing hours when there are changes in UVM objects that are involved in several files through verification codebases. This method, if the code is written smartly, can change an entire environment with just one line of code.

Bibliography

‍

‍

Written by Roberto Millon Tello, Patricio Gallo & Marcelo Pouso

Edited by Adrian Evaraldo

For further inquiries, contact us: info@emtech.com.ar

‍