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 Mon Sep 6 01:29:38 2004
This archive was generated by hypermail 2.1.8 : Mon Sep 06 2004 - 01:30:08 PDT