Jump to content

Recommended Posts

As an (unfortunately very) old hand at design and functional verification in VHDL, PSL, UVM/e, C ..... (yawn), and now a few months into SV UVM, I would appreciate people's opinions on coding guidelines.  I've read and considered a lot of  "macros are/aren't evil" arguments, naming convention "rulebooks" etc, and I'm not concerned with who's right or wrong (too long-toothed to believe there is one).  I would, however, like to suck the brains of those of you with more experience and do my best to achieve the following, without endlessly revisiting code to do fiddly edits:

  • fewest tool-compatibility issues down the line
  • maximum ease of use for other people using/inheriting my code


To kick off, what's the thinking on:

  • Implementing the standard do_compare, do_print etc. tasks as provided by the uvm_field_* macros.
    • Not really interested in the macro/self-coded question, more about which UVCs should implement them and which not.  Looking at various examples, sequence item UVCs generally seem to have them (makes sense since they're obvious candidates for copying and printing) but agents/drivers/monitors often don't.  Is this just the usual coder-laziness syndrome (I include myself here) or is there actually good reason for not doing them?  If they're not implemented, can it cause problems later?
  • Use of m_ prefixes and _h suffixes.
    • Some people use them, some don't.  Coding guidelines seem to imply m_ is for local protected variables only, but most code uses it regardless of protectedness.  Similarly, _h sometimes gets used for handle variables (e.g. an agent's pointer to it's config DB object) and sometimes not (virtual interface inside a driver).  Again, rather than right or wrong, I'm more interested in how people think it affects "legibility" for code-inheritors if these  (or others) are missed out or misused?
  • Finally, when should interfaces (and other possible cross-UVC connections) be made?
    • For example, driver UVCs connecting to the virtual DUT interface. Some code does it inside the connect_phase() of the driver, using the config_db to get the handle, and some does it by assigning to the interface field of the driver from the agent's connect_phase().  Both make sense to me, but I'd be interested to know any solid reasons for one over the other such as added flexibility or run-time issues.





Link to comment
Share on other sites

By not writing the do_print, do_compare, do_everything functions yourself, you're avoiding writing your own bugs. Let the tool do this for you for free whenever possible because it works correctly. It's not that UVM doesn't have bugs--it does--but everything we write has bugs so the less you write the cleaner it will be.


We also use the macros for configuration fields in components, so we don't have to write the uvm_config_db::get calls. Again, the less time I spend coding the fewer bugs I'll make.


We do not have m_ and h_ prefixes, but we do have suffixes. Classes are _c, virtual interfaces _vi, packages _pkg, etc. We also have standard names for drivers (drv), sequencers (sqr), monitors (mon), etc. Then, we lump all of our different kits into packages to avoid namespace collisions.


Virtual interfaces get put into the resource database by the testbench where they're instantiated, and they're given a name. The base test then assigns these names to configurations fields in monitors and drivers as strings. Then, during the build phase, once the interface name has been pulled out of the configuration database the monitor/driver pull the virtual interface assignment from the resource database. We simplify this by putting it all in macros (see "The Less You Write" argument, above).


I've been wanting to publish our coding guidelines but I've gotten too much resistance from management here. Maybe it's time I revisit the issue.

Link to comment
Share on other sites

  • 5 weeks later...

 Yes, please try again to get your coding guidelines published.


 I raised the same request at a company and believe management was worried about sharing something that was not 'perfect' and its reflection on the company.  Probably another view is that coding guidelines are trade secrets.  While I think both of those ideas have merit, in these 'still early' days of SV/UVM, I  think there is more to be gained by sharing a still 'imperfect'/'unfinished' set of guidelines.


 I believe the upside of a company opening their coding guidelines to the public are:

 *The guidelines might be adopted by other companies.  This is particularly true for the first to market.  If the guidelines attain any traction at all, the company is positioned as somewhat of a leader in the space.  And besides, in this new SV/UVM world it seems to me that most companies are still sculpting their environment and flow standards and are hesitant to show that they are still fumbling around.  (But, unless the guidelines released were atrocious, I don't think there is a huge potential for embarrassment.)

 *The company gets useful feedback from the community to improve them.

 *Any industry-convergence around parts of the company's coding style will help to simplify the assimilation of new hires.


 This is purely anecdotal, but I've heard it is not uncommon among software startup teams to just following Google's (publically available) coding guidelines for various languages, rather than crafting their own.

There is an open field to do this in the SV/UVM space.  Someone needs to jump in there.


 I particularly think that becoming a leader or first-mover in this space as an IP vendor like ARM, or a company that sells VIP, would be useful.


 I know that Mentor has published coding guidelines.  However, it'd be more impactful if a non-EDA company in our space would follow Google's example.


 The major idea behind UVM is to align how we verifiy.  More companies throwing their internal best-practices into the ring would help to align the industry.  While it might assist a competitor, I think it is much more likely help the company that shares.


Those are my two unsolicited cents for the community.  But, bhunter, please give it another shot.
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...