Verification Engineer's Blog: February 2016

Thursday, 11 February 2016

uvm_config_db

The uvm_config_db class is the recommended way to access the resource database.

A resource is any piece of information that is shared between more than one component or object.

We use uvm_config_db::set to put something into the database and uvm_config_db::get to retrieve information from the database.

The uvm_config_db class is parameterized, so the database behaves as if it is partitioned into many type-specific "mini databases."

There are no limitations on the the type - it could be a class, a uvm_object, a built in type such as a bit, byte, or a virtual interface.

There are two typical uses for uvm_config_db. The first is to pass virtual interfaces from the DUT to the test, and the second is to pass configuration classes down through the testbench.

----------------------------------------------------------------------------------------------------------------------

/*****************ARGUMENTS*****************/

T is the type of the element being configured - usually a virtual interface or a configuration object.

cntxt and inst_name together form a scope that is used to locate the resource within the database.

The scope is formed by appending the instance name to the full hierarchical name of the context.

{cntxt, ".", inst_name}. or {cntxt.get_full_name(),".",inst_name}. //need to confirm

If cntxt is null then inst_name provides the complete scope information of the setting.

field_name is the key through which you can store and get that particular object.

field_name must be same during get & set, because while getting from uvm_databse it will find for field_name.

value is the thing or resource which is actually going to be put into the database.

value name can be different but value type must be same for get and set.

Both inst_name and field_name may be glob style or regular expression style expressions.

----------------------------------------------------------------------------------------------------------------------

Precedence:

Build Phase:

----------------------------------------------------------------------------------------------------------------------

Example1:

----------------------------------------------------------------------------------------------------------------------

Example2:

----------------------------------------------------------------------------------------------------------------------

Run Phase:

----------------------------------------------------------------------------------------------------------------------

Example1:

----------------------------------------------------------------------------------------------------------------------

Example2:

----------------------------------------------------------------------------------------------------------------------

/*********************Guideline**************************/

1. Before set anything into database first allocates memory to them and then put into database using set method.

Friday, 5 February 2016

`uvm_info vs uvm_report_info in SystemVerilog

--------------------------------------------------------------------------------------------

How to change verbsity for particular component in UVM

There are two ways to set/control/change verbosity of particular component.

Using method call
Through Command line

Here I explained both using example.

Let's go through examples.

1. Using method call

-----------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------

2. Through Command line

-----------------------------------------------------------------------------------------------------

Now run with 3 different simulation commands and see the difference.

+uvm_set_verbosity=component,id,verbosity,phase

-----------------------------------------------------------------------------------------------------

Reference:

1. http://www.sunburst-design.com/papers/CummingsSNUG2014AUS_UVM_Messages.pdf

2. http://www.testbench.in/UT_03_UVM_REPORTING.html

import vs `include in SystemVerilog

The compiler goes through a pre-processor step. This step processes all the include files, conditionals, and text macros into a single stream of text. Except for error reporting and debugging, the compiler does not care how many files were used to make up that stream of text.

`include directive is just a mechanism for assembling text. The directive provides two key pieces of functionality:

Maintain repetitive blocks of text in a single file,
Specify file compilation order dependences from within a file instead of on the compiler command line,

SystemVerilog also supports separate compilation units. A compilation unit is one stream of text.

If you have multiple compiler command lines, then you will have at least one compilation unit per command line.

If you have multiple compilation units and have a set of classes that need to be shared across the compilation units, then you must use a package to define those classes or any user defined type.

And then in other compilation you can access that set of classes by importing that package.

Let’s go through one example,

1. Include

----------------------------------------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------------------------------

After `including class A into each package, you wind up with two definitions of class A. Using `include is just a shortcut for cut and pasting text in a file. Importing a name from a package does not duplicate text; it makes that name visible from another package without copying the definition.

2. Import

-----------------------------------------------------------------------------------------------------------------------------------

Class A is declared in package P, and only in package P. The variables R::a1 and S::a1 are type compatible because they are both of type P::A. The fact that class A was `included from another file once it is expanded is no longer relevant once you consider the placement of the text from the file.

Reference:

1. https://verificationacademy.com/forums/ovm/do-you-include-or-import

2. https://blogs.mentor.com/verificationhorizons/blog/2010/07/13/package-import-versus-include

Thursday, 4 February 2016

$unit vs $root in SystemVerilog

In one line you can say that, $unit represents the top level of each compilation unit, but $root refers to the top level instance.

Now let’s discuss it in little-bit more detail.

$root:

$root is the root of the instantiation tree.
SystemVerilog introduced the concept of $root as a global scope that allowed any kind of declaration (data types, classes, variables) along with module definitions nested in that global scope.
Any un-instantiated module is implicitly instantiated in $root.
A top-level module is implicitly instantiated once in $root, and its instance name is the same as the module name.

$unit:

A compilation unit formalizes a scope that represents what is visible in a compilation step – called $unit in SystemVerilog.
SystemVerilog borrowed the concept of packages from VHDL and standardized the concept of a compilation unit. A package allows you to compile definitions in a separate step and import those definitions into another compilation step.

Basic example of $unit,
-----------------------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------------

If you have a design that is compiled as a single compilation unit, there is really no conceptual difference between $unit and $root.

However, once you have a design with multiple compilation units, then $unit represents the top level of each compilation unit, and there is nothing in $root except for the implicitly instantiated module instances.

The only time you need to use $root or $unit is when a local name in the current scope hides a name in a higher level scope. For example,

-----------------------------------------------------------------------------------------------------------------

Here module “mod2” and module “mod1” has same task called “print”. The ambiguity is resolved by giving priority to the local scope and thereby preventing access to the top-level path. $root allows explicit access to the top level in those cases in which the name of the top-level module is insufficient to uniquely identify the path.

Note that there is no way for compilation unit 1 to directly refer to anything in compilation unit 2, or the other way around.

Reference:
1. https://blogs.mentor.com/verificationhorizons/blog/2009/09/25/unit-vs-root/