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

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);
	 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. 
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" ?

	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.


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