Re: [sv-ec] Re: Feedback from Freescale on name resolution issues

Hi Dave,

I had also considered using 'this' but came to the conclusion that it would
lead to possible confusion. Consider the following example:

   class A;
      rand int x;
      rand int y;
   endclass

   class B;
      rand int x;
      rand int y;
      A   obj;
      function f1();
         obj.randomize with {this.x < this.y};   <---- which x and y?
      endfunction
   endclass

Neil


Rich, Dave wrote On 10/23/07 06:19 PM,:
> Mike,
> 
> You've come full circle, so maybe you seen the world now.
> 
> The problem has always been that if the compiler also expects to bind
> into the object, wouldn't the user expect to get an error message if it
> didn't find it, and not start searching upwards for some irrelevant
> variable?
> 
> Here is a possible compromise to suggestion (7) that might have the
> least backwards compatibility issues. 
> 
> Without (thing),
> 
> obj.randomize with {x < y}; 
> 
> This prefixes x and y with obj. (or this.) except if they are already
> prefixed by name::. That means that if x or y were not in obj, it would
> be an error. 
> 
> With (thing)
> 
> obj.randomize with (thing) {x < thing.y};
> 
> This assumes x will be searched with standard name binding rules
> (whenever we finish that) and that y is inside obj. I hope that 'thing'
> would allow 'this' or 'obj'.
> 
> Dave
> 
> 
> 
>>-----Original Message-----
>>From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
> 
> On
> 
>>Behalf Of Michael Burns
>>Sent: Tuesday, October 23, 2007 5:13 PM
>>To: Burns Michael-RA4884
>>Cc: Vreugdenhil, Gordon; Neil.Korpusik@Sun.com; Jonathan Bromley; sv-
>>ec@server.eda.org
>>Subject: Re: [sv-ec] Re: Feedback from Freescale on name resolution
> 
> issues
> 
>>
>>Following on to my own message, I should reiterate that our users
> 
> _expect_
> 
>>to
>>bind preferentially into the object. They like the way things work
> 
> today;
> 
>>they
>>just want a way, when writing reusable VIP with type parameters or
> 
> other
> 
>>kind of
>>opaque types, to "bulletproof" the VIP so that it's impossible to get
> 
> any
> 
>>unintended binding. Note that the problematic case is pretty narrow;
> 
> the
> 
>>vast
>>majority of our inline constraint usage today and in the so-called
>>foreseeable
>>future is not problematic.
>>
>>I'm also less enamored of the std::randomize() approach than I was
> 
> last
> 
>>week;
>>we've put a lot of effort into managing our random stability and I
> 
> don't
> 
>>want to
>>mess it up. Plus, there's no reason why our need for disambiguation
> 
> should
> 
>>be
>>indivisibly bound with how random seeds are managed (thread vs object)
> 
> -
> 
>>the two
>>should be orthogonal.
>>
>>--Mike
>>
>>Burns Michael-RA4884 wrote:
>>
>>>Hi folks,
>>>
>>>In our methodology, I think it would be quite rare to have a
> 
> cumbersome
> 
>>>select
>>>prefix - we're going to do our inline constraining in some kind of
>>>testcase-specific driver object and the object we're randomizing
> 
> will be
> 
>>>a local
>>>data member of that driver class or a function automatic which we
> 
> access
> 
>>>using a
>>>simple name. Our testbench people expect to use Neil's syntax, and
> 
> don't
> 
>>>see a
>>>problem with it.
>>>
>>>The real issue I'm concerned about is not how to explicitly specify
>>>binding into
>>>the object, but how to explicitly specify binding into the local
> 
> lexical
> 
>>>scope.
>>>I think that's where we need the enhancement.
>>>
>>>--Mike
>>>
>>>Gordon Vreugdenhil wrote:
>>> >
>>> >
>>> > Neil Korpusik wrote:
>>> >> Jonathan Bromley wrote On 10/23/07 01:45 AM,:
>>> >>> (7) In a modification of suggestion (2):  instead of putting
>>> >>>     a list of names in the parens, provide just one identifier,
>>> >>>     freely chosen by the programmer, which is to be treated as
>>> >>>     an alias for the object being randomized:
>>> >>>       obj.randomize() with (thing) {thing.x < thing.y + x;};
>>> >>>
>>> >>
>>> >> Perhaps I am missing something here.
>>> >>
>>> >> Why can't we just use the following? Since obj is the thing
>>> >> being randomized, why can't we just use 'obj.' when we need to
>>> >> specify that the variables used in the with clause are within
> 
> obj?
> 
>>> >>
>>> >>    obj.randomize() with {obj.x < obj.y + x;};
>>> >
>>> > Neil, I think that this would effectively remove the current
>>> > special rules.  In addition,  this is painful if "obj" is a
> 
> general
> 
>>> > select prefix -- users would want/need to create a temporary
> 
> handle
> 
>>> > of the appropriate type to have manageable constraints.
>>> >
>>> > Gord.
>>> >
>>> >
>>> >
>>>
>>
>>--
>>This message has been scanned for viruses and
>>dangerous content by MailScanner, and is
>>believed to be clean.
> 
> 
> 

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-276-6385
Frontend Technologies (FTAP)                      Fax: 408-276-5092
Sun Microsystems                       email: neil.korpusik@sun.com
---------------------------------------------------------------------


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.