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

> With my approach you tend to get errors "closer" to the 
> origin -- changes in the target object won't cause new 
> problems to exist.  Changes in the module containing the 
> inline constraint could cause problems but that is "closer" 
> to the source of the problem ....

This is not true if the user has done the import in $unit.
When the import is in $unit a change in any module any place
in the compilation unit can effect the resolution of a
randomize with clause in another module. If each module is
a single compilation unit, this is not an issue, but if the
whole design is a single compilation unit, then any change 
anywhere in the design can cause name resolution to fail
in a randomize with block in a completely unrelated module.


> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
> Sent: Thursday, November 08, 2007 1:29 PM
> To: Mark Hartoog
> Cc: Michael Burns; SV_EC List
> Subject: Re: [sv-ec] inline constraints -- things are not 
> really quite right yet (perhaps)
> 
> Mark, you are understanding my suggestion correctly.
> 
> As I said initially,  my suggestion does not *eliminate* the 
> reverse problem (which is what Mark is raising).
> 
> The benefit is that you don't get errors due to *later* 
> declarations that previously compiled cleanly and only pose 
> conflicts due to bindings that *would have happened*.
> 
> It is generally much harder for users to deal with errors 
> that occur late and are due to things that would have 
> happened differently in the original compile.
> 
> With my approach you tend to get errors "closer" to the 
> origin -- changes in the target object won't cause new 
> problems to exist.  Changes in the module containing the 
> inline constraint could cause problems but that is "closer" 
> to the source of the problem and the solution -- use 
> "local::".  In the opposite approach, changes to the target 
> object type can cause problems and that can be arbitrarily 
> far away (in time and ownership).
> 
> Gord.
> 
> 
> 
> 
> Mark Hartoog wrote:
> > 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.
> >>>>
> >>>>
> >>
> 
> -- 
> --------------------------------------------------------------------
> 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.