RE: [sv-ec] Clarification of the random stability in object instances

-----Original Message-----
From: eugene zhang [mailto:eugene@jedatechnologies.com]
Sent: Tuesday, September 07, 2004 11:08 PM
To: 'Arturo Salz'; 'sv-ec@eda.org'
Subject: RE: [sv-ec] Clarification of the random stability in object
instances

 
Arturo,

I think probably you misunderstood the problem we described.

We understand the mechanism of RNG initialization per object using
another RNG per thread ( hierarchical object seeding )

We are talking about object stability, what's in 3.1a spec may not be
what users expect.
 
we described two issues. One for 'randc' and another for 'rand'.

The best way to understand it is through some example code:

First, we'll explain the 'randc' issue again, as this is simpler. We
take a class with a 'ranc' variable 'dest'.

     class foo_cls
        randc bit [7:0] dest ;
     endclass

As this variable 'dest' is 8-bit, 256 times of randmize() call should
cover all the possible patterns. But the following code
(though it seems a natural way of coding) won't guarantee that.

     foo_cls foo ;
     int success ;
     // you are wrong if you expect the following code to hit all values
of 0-255
     for( int i = 0 ; i < 256 ; i++ ) begin
       foo = new ;
       success = foo.randomize() ;
       send_data( foo ) ;
       ..
     end

Because a new object get initialized with a new seed from RNG (and
obviously we can't expect the sequence of new seeds to be 8-bit cyclic,

as we want object independence.), the variable 'dest' will be
randomized independently, and non-cyclic nature won't be satisfied in
the code above. To accomplished it, we need to code as below:
 
     foo_cls foo , ppp;
     int success ;
     
     // the following code will guarantee to hit all values of 0-255
     // but it's costly, just to get around the definition of object
stability??
     foo = new;
     for( int i = 0 ; i < 256 ; i++ ) begin
       success = foo.randomize() ;
       ppp = new foo; // copy whole object, costly operation
       send_data( ppp ) ;
       ..
     end

Second issue is about 'rand'. Here, we consider the performance of RNG,

especially the length of period. To understand this issue, it is
important to note that RNG initialization and RNG generation are
independent operations. Usually RNG performance is guaranteed over
generation operations, not over initialization operations. If we are
using one RNG of period N, then we assume that calling randomize() will

guarantees that the period of N on each 'rand' member variable. But if
you are using one RNG per thread to initialize instances of multiple
classes, or multiple 'rand' members, the period that is used as a seed
for one 'rand' member variable may be shorter than N. In the example
in our errata, the randomness of the 'rand' member variable 'id' is
purely rely on the randomness of the seeds at initialization and it
won't guarantee the period performance of the RNG if the RNG (per
thread) is used for other initialization.

The randomness we discussed here is the quality level required for a
Monte Carlo simulation. It may not be a big issue for hardware
verification environment. But we are providing a language system that
should be able to handle system level modeling. So we believe that
providing a clean, high quality random generation mechanism is very
important.

In summary, we believe random stability at a class level is more likely
what Users want.

Best,
-Eugene

-----Original Message-----
From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
Sent: Monday, September 06, 2004 1:07 AM
To: eugene zhang; sv-ec@eda.org
Subject: Re: [sv-ec] Clarification of the random stability in object
instances

Eugene,

Per-object random stability only guarantees that objects are randomized
independently of one another (and of other randomization functions). It
does not require that all objects be initialized with the same seed. In
order to avoid generating random sequences that are strongly correlated
(the
problem you describe), SystemVerilog uses a "hierarchical object
seeding"
mechanism. Section 12.14 states:

"When an object is created, its random number generator (RNG) is seeded
using the next value from the RNG of the thread that creates the object.
This
process is called hierarchical object seeding."

Therefore, the problem you describe will only occur when users
specifically
choose the same seed for all objects (by manually seeding each object),
not when the default (or automatic) seeding mechanism is used. I believe
that tying an object's random stability to its class declaration is the
wrong way to specify such behavior. Instead, when some correlation is
desired, each
object can be seeded manually, thus, overriding the default.

    Arturo

----- Original Message -----
From: "eugene zhang" <eugene@jedatechnologies.com>
To: <sv-ec@eda.org>
Sent: Sunday, September 05, 2004 2:25 PM
Subject: [sv-ec] Clarification of the random stability in object
instances

Title:
   Clarification of the random stability in object instances

Description:
   In section 12.13, it is claimed that each object (class instance) has

an independent RNG. This mechanism could cause a misuse of generating
random objects by user.
   It is very commonly seen in may testbenches that a new class instance

is created and used per each test-sequence. In such case, multiple
class instances are created and sent to the testing subsystem. For
example, a class 'packet' can be created and sent to the testing
subsystem as:

   // commonly used OOP coding style
   packet pkt ;
   int i ;

   for( i = 0 ; i < 1000 ; i++ ) begin
     pkt = new ;
     packet_driver.send( pkt ) ;
     ..
   end

This coding style can not be used with randomize() function due to the
random object stability. If the 'packet' class is declared as:

   class packet ;
     rand int id ;
     randc bit [3:0] dest ;
     ..
   endclass ;

And the code above is modified to call 'randomize()' as:

   // code uses random class but not in a single random sequence
   for( i = 0 ; i < 1000 ; i++ ) begin
     pkt = new ;
     success = pkt.randomize() ;
     packet_driver.send( pkt ) ;
     ..
   end

Because a new RNG is created on each packet instance, and the random
stability among instances, this code won't satisfy the non-repeating
nature of 'dest' variable, and the distribution of 'id' is
questionable. (In a cense that the distribution of 'id' purely relies
on the RNG initialization mechanism, and not utilize the
distribution-safeness of the RNG mechanism itself.)

In order to satisfy the randomness that a user may expect, the code
must be written as:

   // the follow coding style is required to get a random sequence
   packet pkt, ppp ;
   int i, success ;

   pkt = new ;
   for( i = 0 ; i < 1000 ; i++ ) begin
     success = pkt.randmize() ;
     ppp = new pkt ; // create a copy for actual testing
     packet_driver.send( ppp ) ;
     ..
   end

To avoid the confusion and possible testing error by users, a detailed
explanation like above should be placed in the specifictation.

Also, it is desirable to have a mechanism to declare a random variable
without the instance level stability in the same class. This allows to
write the code in more intuitive way, and avoid many copy-object
operation which is possibly costly. This can be done with a new
property qualifier. For a possible implementation, the example here
uses 'cross' as an additional qualifier.

   <BNF>
     property_qualifier ::=
       [ 'cross' ] 'rand'
       |
       [ 'cross' ] 'randc'
       |
       class_item_qualifier

   Example:

     class packet ;
       cross rand int id ; // RNG is per class, not per object
       cross randc bit [3:0] dest ; // per class cyclic
       ..
     endclass ;

Note: non-terminal symbol in BNF is encapsulated in ' ' (single quote),

as bold characters can not be used in plain text.
Received on Tue Sep 7 23:10:15 2004