Open side-bar Menu
 Aldec Design and Verification
Henry Chan
Henry Chan
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

blog_img_053116_01When 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

dac 2016If 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.

Related posts:

Tags: , , ,

Category: Functional Verification

One Response to “The UVM Configuration Database”

  1. Jaya says:

    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.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

CST Webinar Series



Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy