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

Mike,

I was thinking about the class randomize using the object RNG and
std::randomize using the thread RNG. Attached is an example where
changing to the thread RNG has a unwanted result. In the example, the
random sequences in the two instances become the identical - which is
likely not what is wanted.

But to me, the real issue is that you (Freescale) see a need to develop
a methodology that doesn't use the class randomize method - because you
don't want unexpected behavior. That in itself says to me that the class
randomize is broken - and needs to be fixed. 

Regards,
Ray



> -----Original Message-----
> From: Michael Burns [mailto:michael.burns@freescale.com] 
> Sent: Thursday, October 18, 2007 2:43 PM
> To: Ryan, Ray
> Cc: Vreugdenhil, Gordon; sv-ec@eda.org; sv-bc@eda.org
> Subject: Re: [sv-ec] Re: [sv-bc] Re: Feedback from Freescale 
> on name resolution issues
> 
> 
> Hi Ray,
> 
> Thanks - yeah, that was obvious. I intended to call std::randomize().
> 
> So, it's looking to me like, if I change my randomize call to 
> actually use std::randomize like I intended, then I get what 
> I want - a way to always be able to explicitly reference 
> either the local scope (via simple names) or object scope 
> (selecting through the object), thus removing the possibility 
> of having an unfortunate specialization hijack my local name 
> references, and of typos causing inadvertent references into 
> the object when the local scope was intended. 
> However, doing this means I'll have to deal with using the 
> thread seed rather than the object seed. I'm not sure if that 
> will matter to the testbench author or not; I'll have to look 
> into that.
> 
> Otherwise, though, does everything else work the same? 
> Specifically, do I still get all the active constraints in obj?
> 
> Thanks,
> Mike
> 
> Ryan, Ray wrote:
> >  Mike,
> > 
> > In your example, you are not using std::randomize(). You 
> are calling 
> > the randomize method of the class Foo (ie 
> this.randomize(obj)...). So 
> > the reference to 'x' in the with clause will resolve to the 
> local 'x'
> > parameter only if there is not an 'x' declared in class Foo.
> > 
> > You would need to call:
> > 	std::randomize(obj) with {obj.a - x > a - obj.x};
> > 
> > When std::randomize(obj) is called, there is no parent 
> object class, 
> > so the scope for name resolution starts with automatic and 
> local variables.
> > 
> > Additional note: Using std::randomize also changes the random 
> > stability (17.14). The std::randomize method uses the RNG (Random 
> > Number
> > Generator) of the executing  thread. The randomize method 
> of a class 
> > uses the RNG of the class instance.
> > 
> > The following all randomize 'obj'
> > 
> > 1)	obj.randomize() with { ... }
> > 
> > Here the scope for name resolution is first 'obj', then 
> automatic and 
> > local variables, ... . The randomization uses the RNG of the class 
> > instance 'obj'.
> > 
> > 2)	par.randomize(obj) with { ... }
> > 
> > Here 'obj' must be a property of 'par'. In addition to the 'with'
> > clause, all the active constraints in 'par' are included. The scope 
> > for name resolution is first 'par', then automatic and 
> local variables, ...
> > .  The randomization uses the RNG of the class instance 'par'.
> > 
> > 3)	std::randomize(obj) with { ... }
> > 
> > Here the scope for name resolution starts with the 
> automatic and local 
> > variables (there is no class scope). The randomization uses 
> the RNG of 
> > the executing thread.
> > 
> > 
> > - Ray
> > 
> > 
> >> -----Original Message-----
> >> From: owner-sv-ec@server.eda.org
> >> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Michael Burns
> >> Sent: Thursday, October 18, 2007 9:35 AM
> >> To: Vreugdenhil, Gordon
> >> Cc: sv-ec@server.eda.org; sv-bc@server.eda.org
> >> Subject: [sv-ec] Re: [sv-bc] Re: Feedback from Freescale on name 
> >> resolution issues
> >>
> >>
> >> Hi Folks,
> >>
> >> In Monday's meeting, Arturo mentioned a technique using
> >> "std::randomize() with" 
> >> - would something like the following allow us to 
> unambiguously bind 
> >> names locally when we want to?
> >>
> >> class Foo (#type T = int);
> >>    T obj; // member object of opaque type parameter class
> >>    int a;
> >> ...
> >>    function bar(input int x);
> >>          // a and x bind locally even though they are expected to 
> >> appear in T,
> >>          // and we can explicitly refer to members of obj using 
> >> obj.<whatever>?
> >> 	randomize (obj) with {obj.a - x > a - obj.x;};
> >>    endfunction
> >> endclass
> >>
> >> --Mike
> >>
> >> Gordon Vreugdenhil wrote:
> >>> Mike,
> >>>
> >>> I don't believe there is any direct manner of resolving 
> this in the 
> >>> LRM currently.
> >>>
> >>> I've raised this direct issue in the past -- here is the
> >> prototypical
> >>> example that I've used:
> >>>
> >>>    function automatic void f (int x);
> >>>        some_obj.randomize with (y < x);
> >>>    endfunction
> >>>
> >>> I've suggested that we allow a new syntactic form for this:
> >>>    some_obj.randomize with (y) (x < y); which I read as 
> "randomize 
> >>> with y in obj such that x < y"
> >>>
> >>> So "y" would bind following the special "into the object first"
> >>> rules and "x" would bind using the normal rules.  The
> >> current syntax
> >>> would continue to follow the special resolution rules that are 
> >>> currently required.
> >>>
> >>>
> >>> There are other potential solutions in this space but they would 
> >>> impact general name resolution rules.  It seems that the local 
> >>> syntactic solution that I have proposed would work well and would 
> >>> almost certainly compose well with other independent 
> issues in name 
> >>> resolution.
> >>>
> >>> Gord.
> >>>
> >>>
> >>>
> >>> Michael Burns wrote:
> >>>> Hi again folks,
> >>>>
> >>>> It turns out that there is a case where it is not possible to 
> >>>> disambiguate the simple name reference in a "randomize()
> >> with" - when
> >>>> the lexical scope contains locals/automatics, there's no way to 
> >>>> explicitly say that you intend a name to bind to the 
> local rather 
> >>>> than into the opaque randomized object.
> >>>>
> >>>> This clearly seems dangerous, and I can't see any way in
> >> the current
> >>>> standard to protect ourselves from it without resorting to
> >> annoying,
> >>>> fragile naming conventions. Does anyone have a good solution? If 
> >>>> there isn't a good way to deal with this using what we
> >> have, I'd like
> >>>> to see a fix added in the 2008 standard.
> >>>>
> >>>> Thanks,
> >>>> --Mike
> >>>>
> >>>> Michael Burns wrote:
> >>>>> Hi sv-ec and sv-ac,
> >>>>>
> >>>>> Here's some feedback from Freescale on the name
> >> resolution issues w/
> >>>>> opaque types raised in the face-to-face meeting a few
> >> weeks ago. I
> >>>>> believe the vendors were asking for some direction from 
> users - I 
> >>>>> hope this helps. We address three areas - "randomize() with" on 
> >>>>> opaque type objects, deriving from opaque type classes, and the 
> >>>>> overall issue of static vs. dynamic typing.
> >>>>>
> >>>>> For constraints in "randomize() with" on opaque type 
> objects, we 
> >>>>> feel that the binding rules on simple names are scary
> >> enough that we
> >>>>> just won't use them - we'd rather use our internal coding
> >> standards
> >>>>> to mandate explicit disambiguation either into the opaque type 
> >>>>> object being randomized or into the enclosing lexical
> >> scope. As long
> >>>>> as the LRM provides for disambiguation, we don't see 
> the need to 
> >>>>> make any LRM changes to address this issue.
> >>>>>
> >>>>> We aren't as interested in deriving from opaque types -
> >> not because
> >>>>> it isn't useful, but simply because we don't see it being 
> >>>>> implemented widely enough soon enough to be on our 
> radar yet. We 
> >>>>> would use this feature if it were available, but we
> >> aren't pushing
> >>>>> it. We would not want to see a delay in the standard to
> >> straighten
> >>>>> it out, but would expect to see it working properly in the next 
> >>>>> revision (if it isn't working already today, which isn't
> >> yet clear). 
> >>>>> We would expect the name resolution to work as it appears
> >> to today -
> >>>>> preferentially into the opaque base class. We would avoid
> >> unexpected
> >>>>> name binding by using internal coding standards to
> >> prevent the use
> >>>>> of simple names in the enclosing lexical scope that are also 
> >>>>> expected to be present in the opaque base class.
> >>>>>
> >>>>> Overall, we are interested in the robustness of static 
> typing and 
> >>>>> would like to know more about Mentor's proposals for 
> "specs" for 
> >>>>> type parameters, but again, we aren't in favor of delaying the 
> >>>>> standard to get it included this time around.
> >>>>>
> >>>>> --Mike Burns
> >>>>>   Freescale
> >>>>>
> >>>>
> >>
> >> --
> >> 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.