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.