Meta

Henry ChanHenry provides support and guidance to Aldec customers as an Applications Engineer. Specializing in Active-HDL™ and Riviera-PRO™, he is well versed in Aldec’s industry leading FPGA design and simulation tools. His diverse knowledge from hardware description languages to functional verification makes him adept at solving complex verification problems. Henry received his B.S. in Computer Engineering from the University of Nevada, Las Vegas in 2015. « Less

Henry ChanHenry provides support and guidance to Aldec customers as an Applications Engineer. Specializing in Active-HDL™ and Riviera-PRO™, he is well versed in Aldec’s industry leading FPGA design and simulation tools. His diverse knowledge from hardware description languages to functional … More »

The UVM Configuration Database

When I want to wear a certain clothing item, I take out it of the closet. When I go shopping, I add those clothes it to my closet and there are now new items for me to pick out in the future. A database works much the same way, a collection of information that is stored and accessed on demand.

Take the UVM configuration database for example. It basically acts as a repository so that when the time comes, certain portions of the UVM testbench can be obtained from the database and used to build the structure.

When items are placed in the database with a set() method (uvm_config_db::set()), components in lower levels will call the get() method in order to obtain the necessary parts to build the verification framework.

Sharing an interface

If I were to ‘set’ an interface from my top level into the database while simultaneously giving it an identifying name, officially referred to as the ‘field name’, I could later use the field name to retrieve that interface in my driver to connect to the DUT by calling the get() method (uvm_config_db::get()).

Fig. 1) Setting the interface in the configuration database using an identifier ‘my_identifier’

Fig. 2) In order to connect a monitor or driver to the dut, the get() function will need to be called to access the interface in the respective build phase.

Setting up configurations

If I wanted to change or modify my testbench structure, I could create a ‘configuration’. In my configuration, I could specify some rules as to what components I want my testbench to have. If I am designing a processor where I’ve already loaded up the memory with instructions, there’s no need to generate stimulus, therefore I could eliminate the driver and sequencer.

This is what UVM refers to as passive and active modes. Passive mode is where only a monitor exists to observe data and active mode is where a driver and sequencer are needed to generate stimulus. Placing certain variables in the configuration database can help to determine whether the testbench is setup as passive or active.

In order to declare the testbench as passive or active, a configuration object is created. The built in uvm_active_passive_enum data type is used to indicate whether the testbench is UVM_ACTIVE or UVM_PASSIVE.

One Response to “The UVM Configuration Database”

It’s a best article about handle the future technology. Thanks for taking the time to discuss this, I feel happy about and I like to learning more about this topic. keep sharing your information regularly for my future reference.