Jump to content

Random Stability when changing Verbosity


Recommended Posts

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 4 weeks later...

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by mszabo
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 3 weeks later...

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 4 weeks later...

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

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.

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