RE: [sv-ec] inline constraints -- things are not really quite right yet (perhaps)

I thought we had decided to not use the desperate
binding rules for variables/nets, only for hierarchical 
names.     

Maybe I don't understand what Gord is proposing.

package P;
  int a, b, c, d;
  class C;
     int x;
  endclass
endpackage

module m;
  inport P::*;

  C v = new;

  initial a = 1;

  function void foo();
     v.randomize with { x > a && x != b && x != c };
  endfunction

  initial b = 5;
endmodule

Now if I understand Gord's proposal, the 'a', 'b' and 'c'
will only bind to symbols that are already imported into the
module, but will not trigger a wild card import. Now both
'a' and 'b' have been wild card imported into this module,
although the import of 'b' is after the randomize with, so
I assume that 'a' and 'b' will resolve to P::a and P::b,
but 'c' will not resolve because 'c' was never wild card
imported. Is this correct?

This makes the resolution of names in the randomize with
clause depend on all the other code in the module.  How exactly
do you explain to a user that deleting a reference to 'a' in
some completely unrelated code somewhere in the module now
causes 'a' to fail to resolve in his randomize with clause?

Perhaps I do not understand this proposal, but this looks to
be adding more confusion, not making it simpler.


> -----Original Message-----
> From: Michael Burns [mailto:michael.burns@freescale.com] 
> Sent: Thursday, November 08, 2007 11:37 AM
> To: Mark Hartoog
> Cc: Gordon Vreugdenhil; SV_EC List
> Subject: Re: [sv-ec] inline constraints -- things are not 
> really quite right yet (perhaps)
> 
> 
> I'm not seeing how Gord's issue makes things much worse than 
> they are otherwise. 
> If you use bare names in an inline constraint of an object of 
> an opaque type, 
> you can get behavior that is both unintended and hard to find 
> (e.g., successful 
> but unintended binding off in the hierarchy somewhere). This 
> is just another 
> example of a reason to use our new feature to disambiguate 
> when writing such 
> constraints, not a reason to add more rules. local:: doesn't 
> remove _any_ 
> pitfalls; it just gives you a way to avoid them. If we feel 
> we need to remove 
> the wildcard import pitfall, then we should also go back and 
> try to remove the 
> pitfall with desperate binding.
> 
> --Mike
> 
> Mark Hartoog wrote:
> > I am extremely uncomfortable with this.
> > 
> > The wildcard import rules are already complicated and difficult
> > for users to understand. Now you are proposing to make a long
> > list of exceptions to the wild card import rules, places where
> > wild card imports do not work. 
> > 
> > This may make it easier to implement, but it does not simplify the 
> > language. It just makes the wild card import mechanism more 
> > complicated and difficult for users to understand. There now
> > are a set of rules for how it works, and then set of exceptions
> > to the rules where wild card import will not work.
> > 
> > I think this is moving in the wrong direction.  
> > 
> >> -----Original Message-----
> >> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On 
> >> Behalf Of Gordon Vreugdenhil
> >> Sent: Tuesday, November 06, 2007 7:40 PM
> >> To: SV_EC List
> >> Subject: [sv-ec] inline constraints -- things are not really 
> >> quite right yet (perhaps)
> >>
> >>
> >> In the discussion regarding inline constraints, I am now Ok 
> >> with the fact that there exists a mechanism for forcing a 
> >> reference to resolve in an outwards manner.
> >>
> >> That isn't really very "tight" though.
> >>
> >> Given the following:
> >>
> >>     package p;
> >>        int x;
> >>     endpackage
> >>     module m #(parameter type T);
> >>        T c = new;
> >>        initial c.randomize with {x < y} ;
> >>        int x;
> >>     endmodule
> >>
> >>
> >> We still have the latent error problem that I am pretty 
> unhappy about.
> >>
> >> Yes, the user *could* (if aware of the possible issue), write 
> >> the constraint as either:
> >>        initial c.randomize with {local::x < y} ; or
> >>        initial c.randomize with {local::c.x < y} ; depending 
> >> on which way "x" is supposed to resolve.
> >>
> >> However, the bare "x < y" is still legal but only if "x" 
> >> binds as c.x.  If "x" doesn't bind in that manner, too bad, 
> >> you get a latent import error at elaboration time.
> >>
> >> This still disturbs me in terms of how robust separately 
> >> compiled designs can be without a huge level of paranoia on 
> >> the part of the author.
> >>
> >> Since most users indicated at least some level of preference 
> >> for fairly static handling, could we refine things a bit?
> >>
> >> How about the following:
> >>    1) local::x  resolves outside the constraint and is sufficient
> >>       for wildcard import
> >>    2) local::c.x  (indirectly) forces resolution into the object
> >>    3) a bare "x" binds either way but is not sufficient for a
> >>       wildcard import.
> >>
> >> (3) is kind of like what we do with .* references -- it can 
> >> bind to something that is there, but can't impact import 
> >> relationships.
> >> This means that a separate compilation cannot have later 
> >> declarations be invalidated by latent imports -- if the user 
> >> wants to allow a "both ways" resolution, they can do a direct 
> >> import of the name.  Any conflicting declaration errors are 
> >> then caught early.
> >> Otherwise, the name must resolve into the object.  
> >> Fortunately, that can even be quite easily checked (for 
> >> non-hierarchical references) and warned about by an implementation.
> >>
> >> Since "local::x" would be sufficient for wildcard import, I 
> >> think we can then cover all the bases.
> >>
> >> I realize that this might be slightly incompatible, but I 
> >> don't think it is sufficiently incompatible to prevent 
> >> serious consideration.
> >>
> >> I don't know if any real users are relying on assumed import 
> >> behavior right now.  If so, that would definitely be good 
> >> input to hear.
> >>
> >> This direction would certainly satisfy my desire for avoiding 
> >> latent import conflicts while posing (I think) a fairly 
> >> minimal compatibility issue.
> >>
> >> Gord.
> >> --
> >> 
> --------------------------------------------------------------------
> >> Gordon Vreugdenhil                                503-685-0808
> >> Model Technology (Mentor Graphics)                gordonv@model.com
> >>
> >>
> >> -- 
> >> 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.