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

First, a minor clarification but one that could confuse
people.

My original example missed the import line.  I meant to have:
     module m #(parameter type T);
        import p::*;                    // <<<<< oops
        T c = new;
        initial c.randomize with {x < y} ;
        int x;
     endmodule
Otherwise no imports are in play.


On to your question:

Arturo Salz wrote:
> Gord,
> 
> I believe we have consensus regarding (1) and (2), but the situation you
> propose  in (3) is likely to create further inconsistencies. This
> problem is not limited to inline constraints, and has more to do with
> the fragility of the wildcard import mechanism when coupled with the
> dependencies on the elaborated model created by type parameters. I
> believe the issue is that module type parameters create an explicit
> dependency on the elaborated model. For example, how would you propose
> we handle the following modified version of your example:
> 
>     package p;
>        int x;
>     endpackage
> 
>     module m #(parameter type T);

          import p::*;          // <<<< same thing

> 	 class D extends T;
> 	    constraint c1 { x < y; }
> 	    function void F(); $display( x ); endfunction
> 	 endclass
>        int x;
>     endmodule
> 
> I believe this example creates the very same problem as the inline
> constrait. 

Yes it does.

> If the base class (T) has no property "x" then are you proposing that it
> should trigger an error instead of importing "x" from package "p" ?


Yes.

The error in this case would not happen until elaboration time
and would be a latent error with the *later declaration of x*
due to the effect of the late import.

There is a tradeoff here -- in either case you can get errors
at elaboration time.  For example, using my original example:

     module m #(parameter type T);
        import p::*;
        T c = new;
        initial c.randomize with {x < y} ;
        // no declaration here
     endmodule

If the expectation is that "x" binds to the wildcard import
and not to the class, I would contend that the code SHOULD
use "local::" or "p::" to make the intent clear.  If the
intent is for "x" to bind into the object, then just "x"
is Ok but not finding "x" breaks an implied invariant.


I would be fine with this in the parameterized class scenario
as well -- the name should not be able to cause a latent
error due to a "late" wildcard import.

Gord.

> 
> 	Arturo
> 
> -----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.