These are also available at the website. I am also attaching (a very slightly revised version of) IR 2128 which you need to vote on. -- 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 07 February 2008 Present: Peter Ashenden, Larry Soule, Chuck Swart, Ajay Verikat Absent: Jim Lewis, Lance Thompson Next Meeting Thursday, February 28, 8 pm Pacific Standard time (Friday, February 29, 4 am GMT) The primary activity of the next meeting will be to deal with open Bugzilla issues for VHDL-200X (under the assumption that Accellera approves D4.0 and passes it on to the IEEE). There are currently about 12 open or reopened issues. TOPIC: IR 2128 Shared Variable declarations in generate? Peter's analysis is accepted: 4.3.1.3 should be updated to include generate statements, but there is insufficient benefit to adding special terminology for concurrent and sequential declarative regions. Since this analysis was not placed on the website there will be a vote on this issue. ACTION: Chuck to update website. All to vote on IR 2128 TOPIC: IR 2129 Bad requirements to check exprs with access type sub exprs The LRM currently requires that a tool recognize the dereference of a null access value and report this as an error. Most other languages leave this behavior undefined and allow operating system action, usually termination, for performance reasons. The submitter suggests that VHDL also treat this as erroneous to improve performance. Ajay points out that a) recovery from tool crashing is very difficult for a designer b) the error detection here is useful, c) the negative performance effect of such tests is small compared to other actions of the simulator and d) if a tool implementer is still concerned about performance he could implement a non-compliant option to suppress this check. Therefore the LRM should not be changed. ACTION: Ajay to analyze. TOPIC: Open Bugzilla issues for version D4.0. Peter pointed out that there are several open issues for the D4.0 version of the LRM. Since the Accellera board will vote on this version on Feb 20, it is no longer appropriate for the Accellera LRM committee to deal with these issues. The obvious solution to this situation is to pass on this role to the ISAC. We may need VASG approval for this. ACTION: Chuck to work with Jim (VASG chair) to work out details and to set a time frame for IEEE LRM activities. TOPIC: IR 2123 Process resumption and callbacks IR 2124 Ordering of process execution and callbacks Francoise reports that the VHPI has met on these issues and hopes to resolve them within a week. ACTION: Awaiting response from VHPI. TOPIC: IR 2127 Possible LRM interpretation pitfall related to the predefined STANDARD package. Peter's analysis is accepted. This IR is ISAC-Approved. ACTION: Chuck to forward to VASG. TOPIC: IR 2126 Concatenation ambiguity. Chuck's analysis is a first step in resolving this issue. The general problem is that phrases like "independently of the context" do not have a clear meaning. The analysis suggests the intended interpretation of these phrases and proposes alternative wording in each instance in which similar phrases occur. However, the analysis is complicated and the potential consequences of LRM changes in this area are considerable, so everyone should review this analysis offline. ACTION: All to review within 2 weeks. VHDL Issue Number: 2128 Language_Version VHDL-2002 Classification Language Modeling Enhancement or Deficiency Summary Shared Variable declarations in generate? Relevant_LRM_Sections 4.3.1.3 Related_Issues Key_Words_and_Phrases Authors_Name Jim Lewis Authors_Phone_Number 503-590--4787 Authors_Fax_Number Authors_Email_Address jim@synthworks.com Authors_Affiliation Authors_Address1 Authors_Address2 Authors_Address3 Current Status: Analyzed Superseded By: ------------------------ Date Submitted: 13 January 2008 Date Analyzed: 15 January 2008 Author of Analysis: Peter Ashenden Revision Number: 1 Date Last Revised: 15 January 2008 Description of Problem ---------------------- Paragraph 2 of 4.3.1.3 contains the following: "Variables declared immediately within entity declarations, architecture bodies, packages, package bodies, and blocks must be shared variables." Proposed Resolution ------------------- Can shared variables be declared in a generate block declarative region? It would seem yes as it is a block declarative region which is also shared by a block statement, however, then the referenced sentence of 4.3.1.3 should also list generate statements. Going further why don't we have a term for declarative regions of constructs that contain concurrent statements (as this would seem to be a term that could be referenced numerous times). And a separate term for declarative regions of constructs that contain sequential statements (processes, subprograms, and protected types). VASG-ISAC Analysis & Rationale ------------------------------ The intention is that a variable declared immediately within a generate statement must be a shared variable. This assertion is supported by the following arguments. First, the syntax for a generate statement in 9.7 includes the nonterminal block_declarative_item for a declaration within a generate statement. The syntax for a block declarative item in 1.2.1 includes the nonterminal variable_declaration with the italicized prefix "shared". 0.2.1 g) specifies that the prefix conveys semantic information. Thus, the rule in 1.2.1 indicates that a variable declaration occurring as a block declarative item be a shared variable declaration. Second, 12.4.2 specifies that: Elaboration of a generate statement consists of the replacement of the generate statement with zero or more copies of a block statement whose declarative part consists of the declarative items contained within the generate statement and whose statement part consists of the concurrent statements contained within the generate statement. Thus, semantically, a generate statement is equivalent some number of occurrences of a block statement. Since, according to 4.3.1.3, a variable declared in a block statement must be a shared variable, a variable declared in a generate statement must also be a shared variable. The submitter's suggestion that 4.3.1.3 include generate statements in the list of places where a variable declaration must be a shared variable declaration is valid. The ISAC is not aware of any reason for the omission. The submitter suggests that terms be defined for declarative regions that contain only concurrent statements and sequential statements, respectively. The ISAC notes that the draft revision of the LRM, 1076-2007/D4.0, defines the term "concurrent region" in 6.7, External names: ... a concurrent region is defined recursively to be -- a block declarative region (including an external block and any block equivalent to a generate statement), or -- a package declarative region (including a generic-mapped package equivalent to a package instantiation) declared immediately within a concurrent region. This definition is used only within 6.7. The only additional places where it could be used are -- 4.3.1.3, as identified by the submitter -- Clause 9, last paragraph before 9.1 (although reference to package declarative regions would be superfluous in that case) A similar term, "sequential region," could be defined to refer to process and subprogram declarative regions. Places where this term could be used are -- 4.3.1.3 -- 6.7, Note 2 Given the small number of places that would benefit from use of such terminology and the increased cross-linkage that would result, pervasive use of the terms would appear unwarranted. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- Interpret the list of places in 4.3.1.3 where a variable declaration must be a shared variable declaration as including generate statements. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Add generate statements to the list of places in 4.3.1.3 where a variable declaration must be a shared variable declaration.Received on Thu Feb 7 22:38:26 2008
This archive was generated by hypermail 2.1.8 : Thu Feb 07 2008 - 22:38:29 PST