Random Stability

Hello,

I’ve found in our testbench some code that uses $random to create some delay inside a module, I have read about random stability when creating objects and that you should use $urandom_range, std::random, .randomize() to keep random stability, I personally know little about the topic (specially in modules) so I’d like to get some advice to come with an argument on why this code should changed (if this is the case)

Keep in mind I do understand this implementation can be improved (you can use a function instead of using a module and the its function call, I could use $urandom_range), the correctness of the code is not what I’m asking it is about why you shouldnt (if that is the case) use $random


`timescale 1ns/10ps

module a_module
(
   // Inputs
   input  logic clk,
   input  logic reset,
   input  logic valid,
   output logic delay;
);


   delay_gen_module delay_gen();

   always @(posedge clk_in) begin
      if (~reset_L) begin
       //do reset stuff   
      end 
      else begin
         if(valid) begin
           delay <=  delay_gen.create_delay();
           //do some stuff with delay        
         end
      end
   end

endmodule

// delay gen module
module delay_gen_module();

   function integer create_delay;

      input a;
      input b;
      integer a;
      integer b;
      integer aux;
      begin
      aux = $random;
      //do some stuff and return a delay
   end
   endfunction

endmodule

Thanks,
-R

In reply to rgarcia07:

The motivation behind SystemVerilog’s random stability is giving testbench writers a mechanism for repeating the same sequence of random number generation (RNG) in a test while allowing for some controlled modifications to the environment for debugging and fixing the bug. That could be adding statements to aid debug as well as certain modifications to the design or testbench.

SystemVerilog facilitates this by managing the RNG seeding of $urandom, randomize(), etc. for threads and class objects. Because of backward compatibility issues with Verilog, this RNG seeding could not be applied to $random. I’ve seen cases where people freely mix $urandom and $random without understanding the ramifications. They should have marked $random for depreciation.

Another problem with $random is its seed must be manually managed, something most people never do. Then you can have the opposite problem of always generating the exact sequence of RNGs. SystemVerilog has a master RNG seeding that can easily be managed from the command line so you can easily run the same test with different RNG sequences.

This is not to say SystemVerilog has perfected random stability. It would be wise to study it further. Here’s a very good paper.

In reply to dave_59:

Brillant as usual Dave, many thanks for the quick response :)