[sv-ec] Issues regarding SV-BC 211 (randomize clarifying example)

Below are some responses to the issues raised about SV-EX 211 (see
rand_example_comments1.doc
<http://www.eda.org/svdb/file_download.php?file_id=87&type=bug>
attached to the erratta )
 

Issue 1:

"I don't think that the constraint on c2.addr[1:0] is considered to be a
checker. The LRM 12.10.1 explicitly states that checkers only apply to
scope randomize calls with a null argument."

The usage of the 'checker' terminology is not necessary, the text
" ... Note that since c2.addr is a state variable the constraint on
c2.addr[1:0] is a 'checker' constraint. If the value of c2.addr does not
meet the constraint, the randomization fails and the values of the
random variable are not updated. ... "

could be changed to read

" ... Note that since c2.addr is a state variable the constraint on
c2.addr[1:0] is only verified. If the value of c2.addr does not meet the
constraint, the randomization fails and the values of the random
variable are not updated. ... "

Issue 2:

There were a number of issues/questions regarding the random variables
and constraints that apply to scope randomize. Highlighting of some of
these issues was one of the intents of adding this example. My
understanding of the scope randomize method is:

 - Scope randomize provide the ability to randomize variables other
there than class variables, but is NOT restricted to non-class
variables.

- Conceptually, scope randomize can be thought of as temporarily
creating a instance of a class that contains the scope randomize
arguements as class members and the inline constraints as class
constraints. The class randomize method of that class is then called. If
the arguements (ie members of the temporary class) are instances of
other classes, the random variables and constraints of the class are
accumulated using the rules of 12.4.8 Global constraints. That is, the
rand and randc variables are included, along with any active constraints
within the class.

Issue 3: Regarding the paragraph:

In this example, the class randomize method cannot be used to
simultaneously randomize both c1 and c2. That is, "c1.randomize(c2)" is
not allowed. The arguments to the builtin class randomize are limited to
properties of the calling class. So 'data', 'addr' and 'base' are the
only legal arguments to c1.randomize().

I don't know why this paragraph is here - the example is not a call to
'c1.randomize(c2)', which is illegal simply because c1 is not in the
scope of c1. Also this phrase in third sentence of this paragraph, "...
the builtin class randomize...", should be 'the builtin method
randomize'- but I think this paragraph should be removed or put
somewhere else

This entire example is intended to state observations, conclusions,
restrictions when applying the LRM to a specific example. The statements
illustrate issues that have come up during implementation. Although to
some this statement may be 'obvious' to others this wasn't initially
obvious. I do agree that 'class' should be changed to 'method'.

 
Received on Sat Nov 20 12:48:37 2004