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

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.


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