Aldec Design and Verification
Henry 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
May 31st, 2016 by Henry Chan
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.
Fig. 3) An example configuration
For the rest of this article, visit the Aldec Design and Verification Blog.
Category: Functional Verification
One Response to “The UVM Configuration Database”