Jump to content
sas73

Constrained Random Performance

Recommended Posts

While trying out UVM/SystemVerilog with a very simple transaction/constraint

  class transaction extends uvm_sequence_item;
    rand int value;
    
    constraint c {
      value inside {[10:20]};
    }
  endclass

 I found that there is a significant performance difference if I randomize a transaction like this

void'(t.randomize());

or if I do

t.value = $urandom_range(20, 10);

The first approach is 15x to 25x slower depending on simulator! In my case I have a dummy testbench only consisting of a producer sending a large number of transaction to a consumer. Will this also be a concern when scaling up to real-life designs? Are there situation where it's recommended to use $urandom for simple constraints? If not, why?

Share this post


Link to post
Share on other sites

For starters, you need to read section 18.14 of the SystemVerilog manual on the topic of Random Stability because $urandom_range() and t.trandomize() have very different seeds and simulation characteristics. This may affect your ability to validate bug fixes.

As to why you saw such differences, did you try different simulators? Please do not disclose which simulators if you did since this would violate licensing agreements issued by EDA vendors to prevent simulator bashing. The reason I ask is that there can be a significant difference between vendors due to the constraint solver implementations.

$urandom_range does not have to undergo constraint solver issues. Admittedly, your constraints look similar in effect, but the implications can be more complex.

 

Share this post


Link to post
Share on other sites

Thanks for your reply David. The two approaches behave differently but is there a reason why one is better than the other provided I'm aware of these differences and know how and when code changes affects my ability to repeat a test?

I tried several different simulators and the performance hit was between 15x and 25x. This seems to be a problem inherent to all constraint solvers. If that is the case wouldn't I be better off using randomization system calls when possible?

Share this post


Link to post
Share on other sites

You always incur overhead for automation. Performance rapidly deteriorates as you introduce dependencies with other random variables. For example, suppose you need 8 unique values between 10 and 20. You are going be calling $urandom_range many extra times throwing away values that don't meet the constraints. And it becomes very difficult to know when there are no solutions, and you end up in infinite loops looking for solutions that are very hard to find or don't exist. This is what a constraint solver does for you. 

Since constraints are tied to the class inheritance system, they provide another key benefit: you can add to or override them easily. It's very difficult to override constraints embedded within procedural code (this includes using in-line constraints).

 

Share this post


Link to post
Share on other sites

Dave, I'm not trying to replace the constraint solver but rather find the situations where the constraint is simple enough and performance important enough to favor the procedural approach. I'm learning SV constraint but I think your example of selecting 8 unique values between 10 and 20 can be expressed as

  class transaction;
    rand int arr[8];
    
    constraint c {
      foreach(arr[i]) arr[i] inside {[10:20]};
      unique {arr};
    }
  endclass

A procedural implementation of this based on $urandom_range will indeed result in extra calls when the unique constraint is added but only a factor 1.6x on average in this particular case. The execution time in my test increase a bit more, 1.8x, due to the overhead of determining if an extra call is needed.

What is interesting is that the constraint solver in the only simulator I tested became 5x slower when the unique constraint was added.

What's even more interesting was that the procedural approach was 37x faster without the unique constraint and 104x faster with that constraint included.

Declarative constraints are very compact and elegant but it seems that there will be cases when the procedural approach is worth the extra effort.

Share this post


Link to post
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...