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

My main priority is addressing the name resolution issue and I'll
support a wide range of solutions.

My preference is to provide an optional form of inline constraint that
provides for disabling the name resolution in the randomize class scope.

There are a couple of uses for inline constraints:
1) To add a constraint for a specific randomization call. Here is it
convenient to the User to not have to prefix random variables with the
class instance. The current semantics are good.
2) Specify constaints that based on values in the local scope. Here it
is required to at least be able to reliably reference a local variable.
It would be convenient if each local reference didn't have extra syntax.
Here we need additional syntax/semantics.

I believe Gord's syntax to optionally specify a parenthesized list of
class property names (disabling the class scope resolution) is the
simplest (most convenient) solution. The semantics of disabling the
class socpe resolution if the "local::name" syntax is used would also
work.

- Ray


> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Mark Hartoog
> Sent: Thursday, November 08, 2007 2:15 PM
> To: Vreugdenhil, Gordon; Mark Hartoog
> Cc: Michael Burns; SV_EC List
> Subject: 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.
> 
> 
> 

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