Jump to content

UVM 1.2 feedback required

Recommended Posts

Dear all,


As we close in on delivering UVM 1.2 to the engineering community now is the time for you to read the docs, review the code, test the functionality.

Or as they say forever hold your peace.....

Once approved changing documentation requires another full review so really please do give your feedback ASAP.


As a UVM user it is in your interest that UVM meets your requirements and your opinion is considered.


There is a list of issues we know about within the Mantis database:



If you want to view the code for a particular branch from sourceforge you can do so from your browser.


On the left click ""More Branches"


UVM 1.2 will be built from the UVM_1_2 branch:



At the time of writing the latest HTML docs are generated from RC4 branch:



It is just as easy to grab the latest code for you to run with your own projects for testing.

A simple script can look like:

#!/bin/csh -f
mkdir $1; cd $1 ;
git clone git://git.code.sf.net/p/uvm/code ;
cd code ;
git branch --track $1 origin/$1 ;
git checkout $1 ;

By passing in your branch name to the script it will checkout that particular branch for you.

 git_uvm.csh UVM_1_2 ;

You can give feedback via your Accellera representation or local EDA person or provide feedback here.


Time is of the essence so act today.



Link to comment
Share on other sites

There are some issues with the following file: code/distrib/src/dpi/uvm_dpi.cc

  • It includes a .cc file inside an extern "C" { block which is misleading
  • It includes everything into a single file which is not generally considered best practice for software development since it will pollute the namespace
  • It breaks a build systems ability to correctly determine dependencies

I recommend that this file should be removed from the distribution since it is superfluous and problematic for the reasons described above.  The only possible advantage of this mechanism would be a slight speed increase due to reduced file IO, however for such a small amount of code this is negligible.

Link to comment
Share on other sites

  • 2 months later...

Comparing a recent PowerPoint  "UVM What's New and what's Next - UVM 1.2 Introduction" to the UVM 1.2 reference manual (draft), I notice that quite a few features are not documented. Looking into the code, I see the features, but they are not advertised. If I am to use these features, I expect them to be documented; otherwise, I would simply be using internal artifacts, which is technically an incorrect approach to using the library. It is my expectation that every feature shown in an official presentation should appear in the documentation with appropriate recommendations (e.g. am I allowed to use the direct calls or am I required to use the macros?).

Link to comment
Share on other sites

  • 1 month later...
  • 2 weeks later...

Further comments on the code in distrib/src/dpi:


1. The splitting of vendor implementations for uvm_hdl into separate files is a step backwards.


There is now no default implementation, and no attempt at all to keep a common code-base or feature set.  Since PLI is a long established standard, there shouldn't be much need for vendor specific tweaks, and those that are should be minimal enough to be handled with #ifdefs in the single file.  There's now much duplication, which is bad.


Long term the goal should be to minimise the vendor specific hacks and converge on one universal implementation.  Splitting out the files into vendor does makes this unachievable.



2. Part-select in path names should be universally supported using vpi_handle_by_name.  


See this question on StackOverflow: http://stackoverflow.com/questions/24212081/how-do-you-define-backdoor-access-for-fields-which-span-two-registers



And finally a meta-comment, is there ever going to be any feedback on the feedback?  Is anybody reading this?!





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...