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

That's easy to deal with for the 'without (thing)' case. Just make
another exception to the prefix rules (prefix with obj. except if
prefixed with :: or this.)

For the 'with (thing)' case, you are being explicit that 'this' refers
to 'obj'. If you are doing 

this.randomize with (this) {this.x < this.y}

That would be equivalent to 

randomize with {x < y}

But now you could do

randomize with (this) {this.x < this.y + z}

and you would be explicit that z binds locally.


Dave



> -----Original Message-----
> From: Neil.Korpusik@Sun.COM [mailto:Neil.Korpusik@Sun.COM]
> Sent: Tuesday, October 23, 2007 6:35 PM
> To: Rich, Dave
> Cc: Michael Burns; sv-ec@eda.org
> Subject: 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.