We recently added the transaction recording capability to our OVM environments, and found that changing the recording_detail of ovm_components affects the random stability. That is, when we enable transaction recording using recording_detail, we get different output from our randomized portions of the environment. Specifically, we get different results for random fields within some (but maybe not all?) sequences.
Q: Is this a known issue with recording_detail? I certainly did not expect to encounter this.
Q: Could this be a symptom of another problem… something that we are doing incorrectly with regards to random stability?
Q: Are there any whitepapers on random stability with SV/OVM? My experience to date is that it’s horribly unstable. I think we must be doing something wrong.
I believe OVM suffers from more random stability issues than it should. Certainly when using
Questa with our “instrumented OVM” (the pre-compiled OVM with transaction recording), you will suffer from random instability.
The random stability issue has been addressed in the UVM in two ways:
The Accellera Committee has fixed a number of random stability issues in uvm-1.1a. (soon to be released).
When using Questa with the UVM in debug mode, it is randomly stable. We worked hard to make sure when transaction recording was turned on, that you got the same random behavior.
*As for your questions:
*Q: Is this a known issue with recording_detail? I certainly did not expect to encounter this.
A: Yes. Generally, turning on debug can cause random stability issues. But, it appears that the act of using ‘set_config_int’ may be the culprit in the simple case of turning recording_detail on or off. Try two simulations:
In my little experiment, random stability was preserved, and transaction recording was either on (Sim1) or off (Sim2). If I simulate without a ‘set_config_int’, my random numbers change.
*Q: Could this be a symptom of another problem… something that we are doing incorrectly with regards to random stability?
*A: No, I don’t think you are doing anything wrong.
*Q: Are there any whitepapers on random stability with SV/OVM? My experience to date is that it’s horribly unstable. I think we must be doing something wrong.
*A: There’s one coming at DVCON in Feburary 2012. It should be good. It may be UVM focused, but should apply to OVM too.