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.Received on Tue Nov 6 19:40:04 2007
This archive was generated by hypermail 2.1.8 : Tue Nov 06 2007 - 19:40:40 PST