zinn Posted May 12, 2011 Report Share Posted May 12, 2011 Hi folks, we have faced a strange behavior when using UVM the first time. It seems that changing the verbosity level has an impact on the random stability. In other words when running a simulation with verbosity HIGH it creates a different scenario compared to a simulation with verbosity LOW. We are pretty sure, that we do not have written code that evaluates the verbosity level and that could have impact on the random stability. So the question is if there is something already in the UVM base clases that may cause this problem? Since we have never seen this problem with OVM, it may be caused by a new feature, e.g. the report catcher? Has anyone seen this as well? Any ideas? Thanks for feedback Andreas Quote Link to comment Share on other sites More sharing options...
Roman Posted May 12, 2011 Report Share Posted May 12, 2011 Hi zinn, I had tried this in the ubus example. The results are the same when setting either verbosity HIGH or verbosity Low. Would you give us some more detailed info for reference? Quote Link to comment Share on other sites More sharing options...
uwes Posted May 12, 2011 Report Share Posted May 12, 2011 hi andreas, there have been a few issues with random stability in the base classes related to cmdline switches for instance: http://eda.org/svdb/view.php?id=3403 http://eda.org/svdb/view.php?id=3139 also to note is that random stability is not easy to maintain in SV and very simple changes can cause unexpected differences. anyway if the only change you do is changing the arg of +UVM_VERBOSITY and you do not create instances/behaviour upon the severity level yourself its most likely in the UVM core. if your issue is related to http://eda.org/svdb/view.php?id=3403 it should be fixed and you can try with a more recent snapshot. /uwe Quote Link to comment Share on other sites More sharing options...
Sean Posted June 7, 2011 Report Share Posted June 7, 2011 I'm seeing this too. It's pretty scary (and annoying) to change the verbosity to debug an issue to find that the testcase changes. I'm using: uvm 1.0ea ius 10.20 Has this issue been resolved? Simulator issue? UVM issue? Thanks! -Sean Quote Link to comment Share on other sites More sharing options...
mszabo Posted June 7, 2011 Report Share Posted June 7, 2011 I initially had that problem as well. I'll check to see if I'm still having it in 1.0. I'd be tempted to suggest going to 1.0 anyway as migrating from EA to 1.0 in itself takes a fair amount of work depending on how much code you have (and if your meticulous about needing warning free code). I think 1.0 does come already installed with the 10.20 release but for some reason isn't the default. Quote Link to comment Share on other sites More sharing options...
Sean Posted June 7, 2011 Report Share Posted June 7, 2011 Thanks mszabo. I've been holding off on moving to 1.0 specifically because of the migration issue. I've heard rummors of phase method warnings. What a nightmare. I only have about 100k lines of dv code or so. How hard could that be? The bug filed here implies that its still an issue in 1.0: http://eda.org/svdb/view.php?id=3403 -Sean Quote Link to comment Share on other sites More sharing options...
mszabo Posted June 7, 2011 Report Share Posted June 7, 2011 (edited) Yeah that sounds like fun. We made the mistake of assuming that UVM 1.0 was the default library with 10.20 and started our first UVM project a couple of months ago. I then joined the project and started trying to get the register model going (which isn't in EA) and discovered that everyone else was mistakenly using EA. That was a fun couple of days. I just checked and I am still seeing my testcases change whenever I change the verbosity in 1.0. To make it even more interesting my case isn't quite the same as the bug you reference. I ALWAYS pass every environment flag that I am going to use on the command line, A few years back someone had a similar issue so its been hanging around in our makefiles ever since. So my command line has +verbosity=UVM_LOW or +verbosity=UVM_HIGH. So its not the case of one test having to process some command line argument and another not having to. Edited June 7, 2011 by mszabo Quote Link to comment Share on other sites More sharing options...
dave_59 Posted June 8, 2011 Report Share Posted June 8, 2011 Random stability in SV is easy to maintain if you are aware of the issue, know what causes instabilities, and have a test plan for detecting it. That needs to become a higher priority for the UVM than adding new features. Quote Link to comment Share on other sites More sharing options...
uwes Posted June 8, 2011 Report Share Posted June 8, 2011 hi, the issue you mention should be fixed in UVM11 according to the mantis. /uwe Quote Link to comment Share on other sites More sharing options...
uwes Posted June 8, 2011 Report Share Posted June 8, 2011 hi, random stability issues are usually not simulator issues. unfortunately the SV LRM makes it too easy to disturb the random stability. Quote Link to comment Share on other sites More sharing options...
uwes Posted June 8, 2011 Report Share Posted June 8, 2011 Random stability in SV is easy to maintain if you are aware of the issue, know what causes instabilities, and have a test plan for detecting it. That needs to become a higher priority for the UVM than adding new features. hi dave, normally i would expect to fix the "issue" or "root cause" before i go an teach everyone howto to avoid it. random stability issues are unexpected and are (to me) too easily introduced into the code base. /uwe Quote Link to comment Share on other sites More sharing options...
Sean Posted June 8, 2011 Report Share Posted June 8, 2011 Random stability in SV is easy to maintain if you are aware of the issue, know what causes instabilities, and have a test plan for detecting it. That needs to become a higher priority for the UVM than adding new features. Agreed! Fixes before features. Quote Link to comment Share on other sites More sharing options...
dave_59 Posted June 10, 2011 Report Share Posted June 10, 2011 Uwe, Random stability issues are a natural part of any testbench environment that one has to deal with, just like race conditions, and process synchronization. Any language has to balance “stability” with “randomness”, i.e. you don’t want every object generating the same series of random numbers. It's difficult for a compiler to know a priori which is needed. A similar problem exists when performing a deep-copy: the user needs provide knowledge about whether references are to remain references, or need to be cloned. There is a simple, brute force way of dealing with this in the UVM when you don’t want a method to disturb the random generation. A push/pop of the internal random state inside every method call using the get_randstate/set_randstate functions can preserve stability. Doing that inside every method would be a lot of overkill, so it would best to understand what conditions disturb the random state and only apply it where needed. Dave Rich Quote Link to comment Share on other sites More sharing options...
uwes Posted June 10, 2011 Report Share Posted June 10, 2011 dave, i agree with your points that very often two contradicting requirements have to be met. however i'd like to see that SV is making the decision between "stable" OR "random" much simpler. >Random stability issues are a natural part of any testbench environment that one has to deal with, just like race conditions, and process synchronization. This might be true for SV/UVM/OVM BUT i havent seen these kind of issues in the Specman world. So to me its not necessarily a TB specific problem its rather a language+semantic issue. /uwe Quote Link to comment Share on other sites More sharing options...
zinn Posted June 28, 2011 Author Report Share Posted June 28, 2011 Hi folks, I just have tried UVM 1.1. Unfortunately, I still see the problem. Anyone else how faces instability with UVM 1.1? (By the way, we use Questa 10.0b) Best regards Andreas Quote Link to comment Share on other sites More sharing options...
adielkhan Posted July 4, 2011 Report Share Posted July 4, 2011 Andreas, Perhaps you are encountering a different random-stability issue than has been fixed in the past. Can you upload your testcase so we can have a look at it. -adiel. Quote Link to comment Share on other sites More sharing options...
zinn Posted July 4, 2011 Author Report Share Posted July 4, 2011 Hi Adiel, thanks for the offer, but unfortunately I cannot share a testcase with you. First of all, we do not know where exactly the problem comes from. Second we face it only with a complete cpu testbench. Third the cpu is part of a secure design that cannot be shared with anybody else. Best regards Andreas Quote Link to comment Share on other sites More sharing options...
dave_59 Posted July 5, 2011 Report Share Posted July 5, 2011 Perhaps this is a different UVM bug. See http://www.eda.org/svdb/view.php?id=3666 Quote Link to comment Share on other sites More sharing options...
zinn Posted July 5, 2011 Author Report Share Posted July 5, 2011 Hi Dave, I can confirm that the root cause is the bug mentioned by you. At least the fix as suggested by Avidan ("To work around this problem until it is fixed, you can comment lines 285-288 in src/base/uvm_report_server.svh") solved the issue for us. Many thanks to Avidan, Adam, and whoever was involved. When will it be fixed officially in the UVM? Best regards Andi Quote Link to comment Share on other sites More sharing options...
dave_59 Posted July 5, 2011 Report Share Posted July 5, 2011 The next scheduled release of UVM is slated to occur sometime before DVCon’12. If enough bugs accumulate, they may issue an interim release, but right now the committee is not at that point yet. Quote Link to comment Share on other sites More sharing options...
Sean Posted August 3, 2011 Report Share Posted August 3, 2011 So.. is there a way to 'vote' for bugs in the mantis system that ya'll are using for the UVM development? Or is there a way to see what's going to be fixed for the next release in the timeline -- specifically that *this* issue will be corrected? I recently saw the same issue by turning on the objection trace with the plusarg (UVM_OBJECTION_TRACE). Quote Link to comment Share on other sites More sharing options...
uwes Posted August 3, 2011 Report Share Posted August 3, 2011 hi, there is no "formal" thing for that. all mantis items are discussed in the weekly tsc call - and this is the place to raise your voice. 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.