Verification Martial Arts: A Verification Methodology Blog

Namespaces, Build Order, and Chickens

Posted by Brian Hunter on May 14th, 2012

As described in the video, vkits are our convenient method of lumping together reusable UVM packages with the interface(s) that they operate on. Because code within packages can only peek or poke wires that are contained by a virtual interface, it is often useful to wrap these together somehow, and vkits are our technique at Cavium for doing that.

What goes in a vkit? Anything that is reusable. From simple agents and the interfaces they work on to complete UVM environments that connect these agents together, including scoreboards, sequence libraries, types, and utility functions.

What does not go in a vkit are items that are bound to a specific testbench, including the tests themselves.

The video describes the wildcard import syntax as an “egregiously bad idea.” First and foremost, doing so can lead to namespace pollution, which comes about when one engineer independently adds types or classes to their package and only later finds out that they conflict with those of another package. Secondly, wildcard imports prevent our shorter naming conventions of having an agent_c, drv_c, env_c, etc., within each package.

Not described in the video are CSR packages that are auto-generated by RAL, IP-XACT, or your script of choice. These packages should be independent of your vkits, such that your vkits refer to them with their explicit scopes (i.e., chx_csr_pkg::PLUCKING_CFG_C).

Future posts will go into more detail about how we architect UVM testbenches and some of our other conventions that work within this framework. Until then, I’ve got a lot of pies to eat.

PS. I’ll be at DAC this year! Come see me on Tuesday, June 5, during the “Industry Leaders Verify with Synopsys” lunch. Hopefully they’ll be serving some of my favorite foods!

6 Responses to “Namespaces, Build Order, and Chickens”

  1. Bryan Says:

    I love the recommendation to not import * and how it allows you stop prefixing everything with a package_name_. Just curious, what is the _c naming convention that you seem to be using?

  2. Brian Hunter Says:

    We add suffixes to the declared types to help identify what they are:

    _c = class
    _e = enumerated types
    _pkg = package
    _intf = interface

    It also helps to differentiate between the type and the instance names. Some tools do not permit the following, nor would it be particularly readable:

    foo foo; // BAD!

    It is also problematic to need to create instance names without resorting to meaningless prefixes:

    foo my_foo; // BAD!

    Instead, the types themselves shall have the suffixes: So, the above example of instantiating a foo class would be:

    foo_c foo; // GOOD!

  3. Bryan Says:

    One more question. Do you keep the prefix on the filenames that belong to the package? What I mean is, in the code example in the video it shows something like this:

    package chx;
    `import “”
    `import “”
    // etc.

    Do those files just become and (which would keep them matching the class name inside those files)? If so how do you make sure correct is `included into the correct package?

  4. Brian Hunter Says:

    We do keep the prefixes on the filenames, which probably seems like the opposite of what you’d expect. The reason is, though, that not all simulators will be able to discern what this means in the context of what file it’s found in:

    `include “”

    So, file names must be unique.

  5. Bryan Says:

    Commenting on an old thread here, but I started using the _c on my classes and someone told me he thought that was for constraints. Do you have a suffix you use on constraint names? I’ve see a c_ prefix (which kind of bugs me) and I’ve seen names in all caps (which I think I like better, we label asserts and properties in all caps and constraints seem similar).

  6. Brian Hunter Says:

    _cnstr – It’s a little clunky, but very unambiguous.

    Others in our arsenal:

    _t : typedefs
    _s: structs
    _cb : clocking blocks
    _mp : modports
    _cg : covergroups
    _i : interface instance names
    _vi : virtual interface instances