The minutes have been placed at eda.org. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Minutes of ISAC meeting held via telecom on 12 April 2007 Present: Peter Ashenden, Chuck Swart, Ajay Verikat Absent: Jim Lewis, Larry Soule, Lance Thompson Next Meeting (tentative) Wednesday May 2, 2007, 8 pm Pacific Daylight Time (Thursday, May 3, 2007, 2 am GMT ) TOPIC: IR 1000 Accumulated typographical and terminology errors Several minor issues were discussed and resolved. We agreed to refer to the draft standard as P1076-2007-D3.0. It was also discovered that there were differences between the hard copy of VHDL-2002 and the pdf version. ACTION: Peter to make final revisions (done) then ISAC to vote. TOPIC: IR 1070 VPI Issue 14 -- Prefixes in USE clauses The issue concerns legality of a package, pkg, that contains a type named "work" along with use work.pkg.all,work.definework; The issue is whether work.definework is legal here because of the possibility that "work" now refers to the type in the package. Peter's initial analysis was that the example is legal because the visibility associated with the use clause takes effect at the end of the use clause. However, this analysis implies that use work.pkg.all; use work.definework; would be illegal. Chuck argued that the second example is also legal. The clause use.work.pkg.all makes the type "work" potentially visible. However, it does not become directly visible because the type "work" is a homograph of the visible library name "work". Discussion also revealed some issues with clause 11.2, Design libraries. The LRM states: "...each logical name defined by the library clause is directly visible, except where hidden in an inner declarative region by a homograph of the logical name according the the rules of 10.3" 10.3 defines "homograph", but 10.4 gives the rules for USE clauses, so it probably makes sense to refer to both 10.3 and 10.4. Also, homographs apply only to declarations and library names are not (technically) declarations. Wording should be added to treat library logical names as declarations for purposes of overload resolution. ACTION: Peter to revise his analysis. TOPIC: IR 2110 Implicit subtype conversions not defined Clause 7.3.5, Type conversions only deals with explicit conversions (and implicit conversions involving universal arithmetic types, which are not relevant for this issue). It would be good to expand this clause to refer to implicit type conversions as well. Analysis of this issue uncovered that fact that the semantics of array signal and variable assignments utilize the subtype of the array variable or signal. Although the intent is clear, and implementations do the right thing, there are at least two problematic cases. First, a slice does not have a subtype, although assignment to a slice is legal. Second, a formal parameter of an unconstrained type has a subtype (which is unconstrained), but the implicit conversion needs to use the index range of the actual. One possibility is to rewrite the rules for "sliding" in array assignments so that they don't use subtypes. Another possibility is to create some sort of implicit subtype for the relevant cases, and then to add implicit type conversions to clause 7.3.5. It was noted that Ada faced the same issue, but resolved it by adding a great deal of technical machinery (views, actual subtypes, nominal subtypes, etc). It is hoped that we can resolve these issues without adding as much to the language. ACTION: Chuck to analyze. TOPIC: IR 2111 Unknown term used: selector Chuck's analysis is accepted. ACTION: All to vote. TOPIC: IR 2112 Can attributes be applied to a signal on the entity within the architecture for that entity? Peter's analysis is accepted. It was observed that the attribute decorates the entity decl, not the entity instance. ACTION: All to vote.] TOPIC: IR 2099 Alias declarations introduce homographs There appears to be one remaining open issue related to EXAMPLE 5: Consider: package p1 is function "=" (a,b: ieee.std_logic_1164.std_logic ) return boolean; ... end package p1; package p_test is use work.p1.all; ... alias std_logic is ieee.std_logic_1164.std_logic; -- implicit "=" -- alias "=" is ieee.stdlogic_1164."=" (a,b: std_logic) return boolean; end package p_test; In a declarative region you: use p_test.all; Which, if any, "=" operator for std_logic is visible in that declarative region? It shouldn't be the overloaded "=" from p1, since visibility isn't transitive through packages. It seemed to Chuck to be strange that the implicitly declared "=" would be visible, since that operator isn't visible within the package p_test. Peter pointed out that the implicitly declared "=" operator is visible in p_test, although its not directly visible. So p_test."=" refers to the implicitly declared operator. ACTION: Chuck to consult with John Ries and to update analysis as appropriate. TOPIC: Review of IRs incorporated into D3.0 2081 2006-040 Larry 2082 2006-046 Larry 2083 2006-042 Lance 2084 2006-043 Lance 2086 2006-047 Lance 2087 2006-044 Ajay OK 2090 2006-045 Ajay OK 2092 2006-048 Ajay OK 2093 2006-049 Chuck OK 2094 2006-050 Chuck OK 2095 2006-051 Chuck OK ACTION: IRs to be examined for next meeting: 2081 2006-040 Larry 2082 2006-046 Larry 2083 2006-042 Lance 2084 2006-043 Lance 2086 2006-047 Lance TOPIC: Review of Pre-2002 IRs 1055 Larry 1056 Larry 1057 Lance 1058 Lance 1059 Ajay Open Issues 1060 Ajay Open Issues 1062 Chuck Open Issues 1063 Chuck All Issues Resolved 1064 Peter Open Issues 1066 Peter Open Issues 1069 Peter Open Issues 1070 Peter Open Issues ACTION: Pre-2002 IRs to be examined for next meeting: 1055 Larry 1056 Larry 1057 Lance 1058 Lance 1071 Ajay 1072 Ajay 1074 Ajay 1075 Chuck 1076 Chuck 1077 Chuck 1079 Peter 1081 Peter 1082 PeterReceived on Thu Apr 12 22:36:53 2007
This archive was generated by hypermail 2.1.8 : Thu Apr 12 2007 - 22:36:54 PDT