Question on Randomization N Inheritance

SystemVerilog
,
1

Hi all ,

I have a few questions

[I] Achieving sum() more than 32-bits


  Since   32'hFFFF_FFFF  +  32'hFFFF_FFFF  +  32'hFFFF_FFFF  is  36'h2_FFFF_FFFD 

       class  ADD ; 

   rand  bit [31:0]  a[3] ;

   constraint  SUM  {  
                         `ifdef  M1 
                            a.sum()  with (  int'( item )  )   ==  36'h2_FFFF_FFFD ;
                         `elsif  M2    
                            a.sum()  with (  32'( item )  )   ==  36'h2_FFFF_FFFD ;
                         `endif 
                    }
  endclass

With both defines I observe Randomization Failure !!

Isn’t the Constrained expression unrolled to ::


          int'( a[0] )  +  int'( a[1] )  +   int'( a[2] )  ==  36'h2_FFFF_FFFD ; 
                                        OR
          32'( a[0] )   +  32'( a[1] )   +   32'( a[2] )  ==  36'h2_FFFF_FFFD ;

[Q1] Shouldn’t the LHS ( All 3 Indexes of a ) be extended to 36-bits too so that Randomization is a Success ??

[II] Constraining characters


  class  STRING ; 

   rand  byte  a[3] ;
   
   string  str ;

   constraint  CHARAC  {          foreach( a[i] ) 
                             a[i]  inside { ["a":"z"] , ["A":"Z"] , [0:10] } ;  //  Legal  ??
                       } 

   function  void   post_randomize()  ;

     str  =  {  >> { a } }  ;  //  {  a[0]  ,  a[1]  , a[2]  }  
      
     $display(" str is %0s",str); 

   endfunction

  endclass

[Q2] Is above Constraint Considered Legal in LRM ??

**[Q3] String variables can’t be constrained directly since it’s neither integral type OR class data type .

  Is  string  data  type  considered   as  an  aggregate  type  ??**

[III] Inheritance



     class  base  ;

    rand  bit [3:0]  A[2] ;

    constraint  VALUE  {     foreach( A[i] )  
                              A[i] == i ; 
                       }        
 
   function  void  post_randomize() ;

     $display("A.size() is %0d",$size(A));
     $display("A is %0p",A);

   endfunction

  endclass

  class  Ext  extends base  ;

    rand  bit [3:0]  A[4] ;  //  Overridden  property .  Ext  has  2  properties  named  A  !!

    constraint  VALUE  {     foreach( A[i] )  
                              A[i] == 'hF ; 
                       }        

  endclass

  Ext  ext  ;

  initial   begin 

       ext  = new() ;

       if ( ! ext.randomize() )
         $display("Fails"); 
     
  end

I observe Output ::

**A.size() is 2
   A is '{'h2, 'hd}**

[Q4] Since post_randomize() would be inherited shouldn’t the extended property A of size 4 be displayed ??

2

In reply to Have_A_Doubt:

The sum() method of an array returns a value whose type is the same as each element. So if you want a 36-bit result, you need to cast each element to 36 bits. Even though the method gets effectively unrolled, the rules for evaluation have to be the same in a constraint as anywhere else.

 a.sum()  with (  36'( item )  )   ==  36'h2_FFFF_FFFD ;

String types are illegal in a constraint, but string literals are not string types. That are integral packed arrays of bits, 8-bits per character. So your constraint is legal.

String types are not strictly aggregates, but they are not integral either.

Overriding properties/methods does not eliminate what exists in the base class. It hides what is in the base class from the extended class. The post_randomize() method can only access what is in the base class.

3

In reply to dave_59:

Thanks for the explanation Dave .

I have an additional question

Is there a difference between following 2 Constraints ?



 rand bit[3:0] b ;

 constraint ONE_HOT1 { ( b[0] + b[1] + b[2] + b[3] ) ==  1 ; }  //  Won't  LHS  be  calculated  using  1-bit  precision  ??

 constraint ONE_HOT2 {  b[0] + b[1] + b[2] + b[3]  ==  1 ; }  //  LHS  is  Size  cast  to  32-bits  .  Each  Operand  is  32-bits

For ONE_HOT1 ::

Due to parenthesis LHS :: b[0] + b[1] + b[2] + b[3] would be evaluated first .

In that case won’t the resultant sum be calculated using 1-bit precision ,
giving possibility of Three / Single one(s) in b ?

4

In reply to Have_A_Doubt:

No. Bit widths of operands and any intermediate expressions are determined before applying any operators.

5

In reply to dave_59:

I expected ONE_HOT1 to be same as following ::


 
   rand  bit  b[4] ;

   constraint  SUM  {  b.sum() ==  1 ;  }   //  Possibility  of  one / Three  Ones  !!

SUM constraint is reduced to :: ( b[0] + b[1] + b[2] + b[3] ) == 1 ;

I am still confused how come this is different than ONE_HOT1 Constraint above ?

6

In reply to Have_A_Doubt:

As I said above, even though the the sum function is unrolled, it still has to evaluate the same as the function call. That means it gets reduced with a cast

1'(a[0]+a[1]+a[2]) == 1;
7

In reply to dave_59:

In your presentation “Verilog Basics for SystemVerilog Constrained Random Verification”

**Evaluating an expression consists of

— Context
— Precedence
— Casting**

Is the above the actual order in which an expression is solved ?
( rather than the steps involved )
i.e First Operands are sized based on expression context followed by operator precedence



  rand  bit  [15:0]  a  ,  b  ,  c  ;
  rand  bit  [16:0]  d ; 

  constraint  ADDITION  {  d  ==  (  a  +  b )  +  c  ;  }

[1] Since Max Operand size is 17-bits ,
the other 3 operands first are sized to 17-bits .
( Including the Operands in parenthesis i.e a and b )

[2] Due to parenthesis ( a + b ) is solved first and then the 17-bit result is added to c .

8

In reply to ABD_91:

No. The steps involved with evaluating an expression have nothing to do with solving order. As my paper explains, think of the constraint solver as exhaustively trying every possible combination of values for all the random variables, then evaluating the constraint expression using the steps for evaluating the expression for each set of those values. It builds a list of all sets that satisfy the constraint. The randomness only comes into play in picking one solution from the list. In this way, values for all random variables are picked in one step uniformly

Note that this is only a conceptual algorithm for your understanding. To exhaustively try all possible value combinations would be impractical. But any actual implementation must produce solutions approaching the same uniform distribution.