adielkhan Posted February 22, 2014 Report Share Posted February 22, 2014 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: http://www.eda.org/svdb/my_view_page.php If you want to view the code for a particular branch from sourceforge you can do so from your browser. http://sourceforge.net/p/uvm/code/ref/master/branches/ On the left click ""More Branches" UVM 1.2 will be built from the UVM_1_2 branch: http://sourceforge.net/p/uvm/code/ci/UVM_1_2/tree/ At the time of writing the latest HTML docs are generated from RC4 branch: http://sourceforge.net/p/uvm/code/ci/UVM_1_2_RELEASE_RC4_WITHHTMLDOC/tree/ 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. thanks, Quote Link to comment Share on other sites More sharing options...
dave_59 Posted February 23, 2014 Report Share Posted February 23, 2014 An easy link to look at the exact list of issues address http://www.eda.org/svdb/search.php?project_id=10&sticky_issues=on&fixed_in_version=1.2&sortby=last_updated&dir=DESC&hide_status_id=-2 and Release Notes. Quote Link to comment Share on other sites More sharing options...
chiggs Posted February 26, 2014 Report Share Posted February 26, 2014 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. Quote Link to comment Share on other sites More sharing options...
David Black Posted May 3, 2014 Report Share Posted May 3, 2014 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?). Quote Link to comment Share on other sites More sharing options...
vishnuprasanthv Posted June 4, 2014 Report Share Posted June 4, 2014 Hi David, Can you please list what are the list of features that are not documented in "UVM What's New and what's Next - UVM 1.2 Introduction" Presentation. Thanks, Vishnu Quote Link to comment Share on other sites More sharing options...
chiggs Posted June 16, 2014 Report Share Posted June 16, 2014 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?! Thanks, Chris Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.