I think, but am not sure, that the "forward" for a property or sequence is not quite the same. In particular, I don't think that there is upwards resolution through the instance tree. Hopefully someone from AC can give a better explanation of the intent on this part. Gord. Bresticker, Shalom wrote: > Gord, > > Re item (3), do references to properties and sequences use the same > rules as references to tasks and sequences? The LRM says that 'forward' > references work. Beyond that, it is not clear. If they are like tasks > and functions, then a non-dotted reference would find them in an upwards > hierarchical scope, for example. > > Thanks, > Shalom > >> -----Original Message----- >> From: owner-sv-bc@server.eda.org >> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Gordon Vreugdenhil >> Sent: Thursday, September 20, 2007 7:34 PM >> To: SV_BC List; SV_EC List >> Subject: [sv-bc] Name resolution - questions and issues review >> >> All, >> >> Francoise asked for a summary of some of the name resolution >> issues. I don't want to try to capture all of the issues >> here since at least the very contentious issues were >> discussed exhaustively on the reflector. >> >> Here are some of the more basic issues that need clarification: >> 1) how "static" is :: ? Can you have "::" on a forward type? >> 2) how package like is $unit? Are later declarations visible? >> Is it even possible (as with a hierarchical reference in >> a module) to create a forward reference? >> 3) we need to agree on a statement regarding "declaration before >> use" to make things more explicit and explain exactly how >> exceptions (functions, etc) work. >> 4) when does a dotted name become a select versus a hierarchical >> name? Can you forward reference a struct variable member >> just because the reference contains a dot? >> 5) Is a clocking blocks a scope? If so, does that imply that all >> "cb.a" forms are inherently hierarchical and always bind using >> the hierarchical resolution rules? >> 6) we need to discuss forward visibility in non-opaque classes >> 7) management of $unit and package lookup during hierarchical >> name resolution >> 8) handling of package imports for bind >> 9) basic discussion of issues related to modports >> >> There are certainly more issues here, but the above is >> probably a fair sampling of issues for which the LRM should >> be much more clear. >> >> >> Here are some links to relevant reflector discussion between >> Mark and I: >> () Gord's very early (incomplete, etc) algorithm for >> basic resolution in June, 2006: >> http://www.eda-stds.org/sv-bc/hm/4623.html >> () a later form of Gord's basic approach in more of a rule form >> http://www.eda-stds.org/sv-ec/hm/4346.html >> () Mark's basic approach to name resolution >> http://www.eda-stds.org/sv-bc/hm/6472.html >> () a summary related to how type parameters interact >> http://www.eda-stds.org/sv-bc/hm/6567.html >> () a summary of some of the issues related to type referencing >> http://www.eda-stds.org/sv-bc/hm/6667.html >> >> There are many other issues and examples floating about. >> Here are a few that Mark and I have raised very early on. >> I'd have to re-evaluate where we both are on all of these. >> http://www.eda-stds.org/sv-bc/hm/6017.html >> http://www.eda-stds.org/sv-bc/hm/6029.html >> >> >> I am working on a powerpoint agenda for Monday and am >> planning on including the 9 basic issues above as well as a >> shorter summary of the long back-and-forth that Mark and I have had. >> >> If anyone has substantial questions that don't appear to be >> covered in 1-9, please let me know and I'll add them to my >> questions and issues list. >> >> >> 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. >> > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > -- -------------------------------------------------------------------- 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 Thu Sep 20 13:40:38 2007
This archive was generated by hypermail 2.1.8 : Thu Sep 20 2007 - 13:42:39 PDT