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.Received on Thu Sep 20 10:34:37 2007
This archive was generated by hypermail 2.1.8 : Thu Sep 20 2007 - 10:35:56 PDT