RE: [sv-ec] Re: Arguments to "randomize" method calls

Gord,

 

I see your point. Yes, this is the same old ambiguity due to
hierarchical

references. This type of ambiguity is typically resolved by deferring
the 

code generation until after elaboration (or by generating generic code
to 

be interpreted at run time). But in the case of the randomize method
this 

seems more severe because it involves different name binding semantics

so it's harder to either defer or interpret at run-time. Do you have any
ideas 

that may alleviate this problem?

 

            Arturo

 

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Tuesday, March 07, 2006 9:36 AM
To: Arturo Salz
Cc: SV_EC List
Subject: Re: [sv-ec] Re: Arguments to "randomize" method calls

 

 

 

Arturo Salz wrote:

 

 > Gord,

 >

 > My expectation as to the legality of your example is the same as
yours:

 > It should be illegal. And, b.randomize(c) is legal. Hence, the name

 > binding is static and not at run-time.

 >

 > By "nasty" I assume you mean problems related to a separately
compiled

 > unit that does not include the full class declaration. But, I assume
the

 > same problems exist with the rand_mode and constraint_mode methods,

 > right?

 

rand_mode and constraint_mode are different in that they don't

require you to ignore normal lexical binding for actuals

in a call.

 

randomize is not an issue when you have inline constraints

since you can use that to disambiguate the nature of the call

("randomize" must mean the method when there are inline

constraints).

 

The nastiness is that you can't determine in a separately

compiled module whether a simple call to randomize is to the class

method randomize (requiring "pass by name") or to a non-class task

(requiring normal actual evaluation).

 

Example:

 

module D;

    int x;

    initial a.b.randomize(x);

endmodule

 

If D is a separately compiled module, what do you do?

You can't determine what to do with "x" in the call.

 

Context 1:

    module top;

       A a();

       D d();

    endmodule

    module A;

       begin : b;  // generate block

           task randomize(int arg);

           endtask

       end

    endmodule

 

 

Context 2:

     module top;

        A a();

        D d();

     endmodule

     module A;

        class B;

            rand int x;

        endclass

        B b = new;

     endmodule

 

 

I believe that both "Context 1" and "Context 2" are legal

contexts for instance d.  But the meaning of "x" in

the a.b.randomize(x) is vastly different and there is no

way to determine which one is required until elaboration.

In fact, to be more nasty, I could merge Context 1 and

Context 2 with some renaming and create two different

contexts in which a.b.randomize(x) would mean two

very different things in different instantiations of D.

 

Gord.

 

 

>          Arturo

> 

> -----Original Message-----

> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of

> Gordon Vreugdenhil

> Sent: Tuesday, March 07, 2006 7:49 AM

> To: Gordon Vreugdenhil

> Cc: SV_EC List

> Subject: [sv-ec] Re: Arguments to "randomize" method calls

> 

> 

> 

> Gordon Vreugdenhil wrote:

> 

> 

>>In 1800-2005, 13.10 we have:

>>   The scope of the arguments to the randomize method is the object

>>   class. Arguments are limited to the names of properties of the

>>   calling object; expressions are not allowed.

>> 

>>I just want to clarify whether the name binding is static based on

>>the type of the reference or dynamic based on the actual object.

>>Specifically, is the following legal:

>> 

>>   class A;

>>   endclass

>>   class B extends A;

>>     rand int c;

>>   endclass

>>   A a;

>>   B b;

>>   initial begin

>>      b = new;

>>      a = b;

>>      a.randomize(c);   // randomize member "c" - legal?

>>   end

>> 

>>For a normal reference "a.c" is illegal but the text in 13.10

>>talks about both the "object class" and the "calling object".

>>At this point, I'm assuming that this example should be illegal.

>> 

>>BTW, there are some very nasty separate compilation issues

>>involving randomize since the formals of the class method

> 

>                                  ^^^^^^^

> Should be "actuals" of course.

> 

> Gord

> 

> 

>>randomize are member names while in a hierarchical call

>>to a task randomize they would be normal actuals.

>> 

>>Gord.

> 

> 

 

-- 

--------------------------------------------------------------------

Gordon Vreugdenhil                                503-685-0808

Model Technology (Mentor Graphics)                gordonv@model.com