Attached are the meeting minutes from the ISAC telecom on 10 November 2005. The following IRs were updated: 2020, 2029,2031,2053,2054, 2059,2061,2070,2071,2076, 2077 I am attaching the following IRs 2054 Individual assoc. rules for array formal are not valid 2071 Indexed name in case expression 2077 Incorrect wording on some language constructs 2054 is pretty technical. Please review it carefully for discussion/vote at our next meeting. 2071 seems straightforward. Please vote on it via email. _____ Approve _____ Disapprove 2077 Is a new IR, issued as a result of discussions at our meeting. Chuck Swart Revised 17 November 2005 Number Status Responsible Description Notes Active IRs 2038 Submitted Ajay Minor semantic errors 2054 Submitted Larry Individual assoc. rules for array formal are not valid 2070 Analyzed Chuck Support for floating point denormal numbers 2071 Analyzed Chuck Indexed name in case expression 2072 Submitted Allow static operations on "ranges" 2073 Analyzed Chuck Index constraints and discrete range conversions from universal_integer 2074 Analyzed Chuck & Ajay Problem with direct/select visibility in formal part 2075 Submitted Ajay Arrays with numeric and enumeration index types are not closely related 2077 Submitted Incorrect wording on some language constructs Resolved IRs 1044 VASG-Approved Definition of 'HIGH and 'LOW in a null range 2000 VASG-Approved Where may/must deferred constant declaration appear 2001 VASG-Approved Resize not working in numeric_std.vhd (1076.3 2002 VASG-Approved Resize(R.2) function in numeric_std.vhd does improper array length check 2003 Forwarded Specification of multi-cycle paths 2004 VASG-Approved Definition of SLA doesn't make sense 2005 Duplicate sla operator behavior does not match typical hardware behavior 2006 Forwarded "else" in "if generate"? 2007 Forwarded VHDL needs to be enhanced to allow the modeling of switches. 2008 VASG-Approved Source value of undriven, non-sourced INOUT, OUT or BUFFER port 2009 Forwarded New std package, containing compiler and target identification information 2010 VASG-Approved The description of type/subtype relationship could be better 2011 Forwarded A package body should be able to consist of several files 2012 Forwarded VHDL lacks inherent statements to describe the most basic hardware design equations 2013 VASG-Approved Exact subtype "matching" for port associations 2014 Forwarded Allowance of the keyword "all" in place of a sensitivity list is desirable 2015 Forwarded Generics should be able to incorporate other generics 2016 Duplicate Allowance of the keyword "all" in place of a sensitivity list is desirable 2017 Duplicate Generics should be able to incorporate other generics 2018 VASG-Approved Variable IN parameter should be no different than constant 2019 Forwarded Reading outputs from within architecture 2020 VASG-Approved Keyword REPORT is over-used 2021 Forwarded Dynamic hardware construct 2022 Forwarded Elements of constant composite to be locally static 2023 VASG-Approved Add predefined array types for integer, boolean, real and time 2024 Forwarded VHDL needs encryption support 2025 Forwarded "Generate" for sequential code 2026 Forwarded Upward propagating parameters 2027 Forwarded When loop index is static, drivers are created for each element of array 2028 ISAC-Approved Clarify simulation cycle. 2029 VASG-Approved Non-relevant words and paragraph. 2030 VASG-Approved What signature does a method have 2031 VASG-Approved "mod" function needed for TIME 2032 VASG-Approved Function "now" is not pure 2033 Forwarded Incremental operator and auto subtype boundary wrap 2034 Forwarded Introduce history attribute on signals to auto infer registers 2035 Forwarded new function "stages" automates pipelining 2036 VASG-Approved protected_type_declarative_item includes subprogram_specification 2037 VASG-Approved Typo wrt now in the index 2039 VASG-Approved Minor typos 2040 VASG-Approved Problems with OTHERS in aggregates 2041 Forwarded Association of members is too restricted 2042 VASG-Approved Architecture as a block causes problems 2043 ISAC-Approved Numeric VALUE attribute parameter can't have sign 2044 VASG-Approved Deprecation of linkage ports affects boundary scan description language 2045 VASG-Approved Add the ability to comment an entire block of code 2046 Forwarded Type independent ports and subprogram parameters 2047 VASG-Approved Backslash in extended identifiers 2048 VASG-Approved Miscellaneous errors 2049 VASG-Approved Circular definition of an event on a signal 2050 ISAC-Approved Definition of S'Last_Value was apparently broken in 1993 2051 VASG-Approved Path_name and instance_name do not allow for protected types 2052 VASG-Approved Path_name and instance_name don't deal with operator symbols 2053 VASG-Approved Minor Typos in VHDL 2002 part 2 2055 VASG-Approved Prohibition on assignment of protected types not normative 2056 VASG-Approved Can an attribute name that denotes a function be used where a name is required? 2057 VASG-Approved Access-typed parameters to predefined "=" and "/=" 2058 VASG-Approved Does USE of type name make operators and literals visible? 2059 VASG-Approved Upper/lower case character mapping is not clear 2060 Forwarded Include truth table for multi-input/multi-output logic. 2061 VASG-Approved Default actions on severity flags is different between simulators 2062 ISAC-Approved Range staticness 2064 ISAC-Approved Type conversion of unconstrained output in a port map 2063 Forwarded Unconstrained array formals should not get subtype from actuals 2065 ISAC-Approved OTHERS in aggregates too restrictive 2066 Forwarded Multidimensional array in IEEE Std 1076.6-2004 2067 Forwarded Enhancement: Logical link interface abstraction 2068 ISAC-Approved Entity instantiation with space before the entity name 2069 ISAC-Approved Visibility of generics in block configurations 2076 Forwarded A member attribute for records -------------BEGINNING OF IR---------------- VHDL Issue Number: 2054 Language_Version VHDL-2002 Classification Language Definition Problem Summary Individ. assoc. rules for array formal are not valid Relevant_LRM_Sections 3.2.1.1 Index constraints and discrete ranges Related_Issues Key_Words_and_Phrases individual association, unconstrained array formal Authors_Name James Unterburger Authors_Phone_Number 503.685.0860 Authors_Fax_Number 503.685.0921 Authors_Email_Address jamesu@model.com Authors_Affiliation Model Technology Authors_Address1 8005 SW Boeckman Road Authors_Address2 Wilsonville, OR 97070 Authors_Address3 Current Status: Analyzed Superseded By: ------------------------ Date Submitted: 6 January 2005 Date Analyzed: 03 March 2005 Author of Analysis: Larry Soule Revision Number: 3 Date Last Revised: 16 November 2005 Description of Problem ---------------------- The rules for determining the index ranges of an interface object (or member of an interface object) of an unconstrained array type and whose subelements are associated individually are given in 3.2.1.1: The directions of the index ranges of the formal [interface object] are those of the base type of the formal; the high and low bounds of the index ranges are respectively determined from the maximum and minimum values of the indices given in the association elements corresponding to the formal. It is then further ("followup") stated that: If the index ranges for an interface object or member of an interface object are obtained from the corresponding association element (when associating in whole) or elements (when associating individually), then they are determined either by the actual part(s) or by the formal part(s) of the association element(s), depending upon the mode of the interface object, as follows: [For a formal of mode IN, INOUT, or LINKAGE, if the actual part includes no conversion function or type conversion; likewise for a formal of mode OUT, BUFFER, INOUT, or LINKAGE, if the formal part includes no conversion function or type conversion, then] the index ranges are obtained from the object {or value} denoted by the actual designator(s). This "followup" does not make sense for individual associations because the actual designators do not have a corresponding index range, they are instead elements of the formal's array type; the index range(s) are already known as coming "from the maximum and minimum values of the indices given in the association elements corresponding to the formal". Also, the requirement that the result type of a conversion function or type mark of a type conversion (if present on the formal and/or actual parts) be a constrained array subtype is not applicable for individual association elements because they represent elements of the formal's array type, which is not necessarily of an array type itself. Proposed Resolution ------------------- 1) Clarify that the direction of the base type of an array type is in fact the direction of the index subtype of the array type at a given index position. 2) Remove the references to individual associations in the "followup" rules. 3) Clarify what the requirements are for individual associations that have formal and/or actual parts that include conversion functions and/or type conversions. VASG-ISAC Analysis & Rationale ------------------------------ The directions of the index ranges of the formal generic or formal port are that of the type of the formal; the high and low bounds of the index ranges are respectively determined from the maximum and minimum values of the indices given in the association elements corresponding to the formal. 1) The LRM says "The directions of the index ranges of the formal generic or formal port are that of the type of the formal". However, the direction of the base type of an unconstrained array is undefined (from 3.2.1). To define this, the sentence above should be removed and the sentence following it changed to: The directions of the index ranges of the formal generic or formal port are that of the type of the formal; The high bounds, low bounds, and directions of the index ranges are respectively determined from the maximum values, minimum values, and directions of the indices given in the association elements corresponding to the formal. 2) As the submitter says, in the case of individual associations, "the actual designators do not have a corresponding index range, they are instead elements of the formal's array type". Thus, the references to individual associations in the "followup" rules should be removed. The new language should be: If the index ranges for an interface object are obtained from the corresponding association element (when associating in whole), then they are determined either by the actual part or by the formal part of the association element, depending upon the mode of the interface object, as follows: 3) The rewording of #2 above will also remove the restriction that the result type of a conversion function or type mark of a type conversion be a constrained array subtype when associating individually since the new paragraph only applies when associating in whole. With this, the rules for obtaining the index ranges when associating individually should be clear (obtained from the maximum and minimum values of the indices given in the association elements corresponding to the formal). VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Revise section 3.2.1.1 as described in the analysis -------------END OF IR---------------- -------------BEGINNING OF IR---------------- VHDL Issue Number: 2071 Language_Version VHDL-2002 Classification Language Modeling Enhancement or Deficiency Summary Indexed name in case expression Relevant_LRM_Sections LRM 8.8 Case statement Related_Issues Key_Words_and_Phrases case, index, staticness Authors_Name Gingold Authors_Phone_Number 0 Authors_Fax_Number Authors_Email_Address tgingold@free.fr Authors_Affiliation Authors_Address1 Authors_Address2 Authors_Address3 Current Status: Analyzed Superseded By: ------------------------ Date Submitted: 16 August 2005 Date Analyzed: 17 November 2005 Author of Analysis: Chuck Swart Revision Number: 1 Date Last Revised: 17 November 2005 Description of Problem ---------------------- If the expression is a one dimensional array of character type and the expression is an indexed name, the indexes must be locally static expressions. As far as I can see, there is no need to require the expression to be static. Some users want to use non-static expressions or globally static expressions. Proposed Resolution ------------------- Remove "and whose indexing expressions are locally static expressions" VASG-ISAC Analysis & Rationale ------------------------------ If the case expression is an indexed name, then the indexing expressions do not need to be locally static expressions, but the element subtype must be locally static. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- Interpret the LRM as if the Recommendation for Future Revisions had been incorporated. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Change the part of Clause 8.8 which reads: "If the expression is of a one-dimensional character array type, then the expression must be one of the following: ... -- An indexed name whose prefix is one of the members of this list and whose indexing expressions are locally static expressions" to "If the expression is of a one-dimensional character array type, then the expression must be one of the following: ... -- An indexed name whose prefix is one of the members of this list and whose element subtype is locally static." -------------END OF IR---------------- -------------BEGINNING OF IR---------------- VHDL Issue Number: 2077 Language_Version: VHDL-2002 Classification: LRM Terminology, Grammar and Typographical Errors Summary: Incorrect wording on some language constructs Relevant_LRM_Sections: 3.3, 3.5.1, perhaps others Related_Issues: 2029, 2061 Key_Words_and_Phrases: Authors_Name: Chuck Swart Authors_Phone_Number: 503.685.0846 Authors_Fax_Number: 503.685.0921 Authors_Email_Address: cswart@model.com Authors_Affiliation: Model Technology Authors_Address1: 8005 SW Boeckman Road Authors_Address2: Wilsonville, OR 97070 Authors_Address3: Current Status: Submitted Superseded By: ------------------------ Date Submitted: 15 November 2005 Date Analyzed: Author of Analysis: Revision Number: 0 Date Last Revised: Description of Problem --------------------- (Submitted from comments by Alex Zamfirescu) In several places the LRM wording is inaccurate. Here are several examples: Section 3.3 "The designated type must not be a file type or a protected type; moreover it must not have a subelement that is a file type or a protected type." This should be: "...it must not have a subelement that is <of> a file type or a protected type." Section 3.5.1 "... moreover, they must not have a subelement that is an access type or a file type." This should be: "... moreover, they must not have a subelement that is <of> an access type or a file type." Also, "... moreover, it must not have a subelement that is an access type or a file type." This should be: "... moreover, it must not have a subelement that is <of> an access type or a file type." Section 4.3.1.1 "Such formal parameters must not be of an access type or a file type; moreover, they must not have a subelement that is an access type. Additionally, in the case of a function subprogram, the return type of the function must not be of an access type or a file type; moreover, it must not have a subelement that is an access type." This should be: "Such formal parameters must not be of an access type or a file type; moreover, they must not have a subelement that is <of> an access type. Additionally, in the case of a function subprogram, the return type of the function must not be of an access type or a file type; moreover, it must not have a subelement that is <of> an access type." Section 4.3.1.2 "It is an error if a signal declaration declares a signal that is of a file type, a protected type, or a composite type having a subelement that is a file type, an access type, or a protected type." This should be "It is an error if a signal declaration declares a signal that is of a file type, a protected type, or a composite type having a subelement that is <of> a file type, an access type, or a protected type." Section 4.4 "It is an error if the type mark denotes an access type, a file type, a protected type, or a composite type with a subelement that is an access type, a file type, or a protected type." This should be "It is an error if the type mark denotes an access type, a file type, a protected type, or a composite type with a subelement that is <of> an access type, a file type, or a protected type." Similar changes are needed to incorporate IR2029 Section 8.2 "Evaluation of an assertion statement consists of evaluation of the Boolean expression..." This should be "Execution of an assertion statement consists of evaluation of the Boolean expression..." Section 8.3 "The evaluation of a report statement consists of the evaluation of the report expression..." This should be "The execution of a report statement consists of the evaluation of the report expression..." Proposed Resolution ------------------- VASG-ISAC Analysis & Rationale ------------------------------ TBD VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD -------------END OF IR----------------Received on Thu Nov 17 15:33:11 2005
This archive was generated by hypermail 2.1.8 : Thu Nov 17 2005 - 15:33:23 PST