Attached are the minutes from the last meeting. Also attached are 4 IRs: 2070 Analyzed Chuck Support for floating point denormal numbers 2073 Analyzed Chuck Index constraints and discrete range conversions from universal_integer 2074 Analyzed Chuck & Ajay Problem with direct/select visibility in formal part 2078 Analyzed Chuck Allow attribute declaration/specification in package body 2078 has a new analysis, there have not been changes to the other IRs. Please review these and vote by email. If you have any issues, then send me an email, and we'll discuss them at the next meeting. Chuck Swart VOTE on IRs: 2070 -------------Approve _____________ Dont' Approve 2073 -------------Approve _____________ Dont' Approve 2074 -------------Approve _____________ Dont' Approve 2078 -------------Approve _____________ Dont' Approve -------------BEGINNING OF IR---------------- VHDL Issue Number: 2070 Language_Version VHDL-2002 Classification LRM Terminology, Grammar and Typographical Errors Summary Support for floating point denormal numbers Relevant_LRM_Sections Section 7.2.7 paragraph 3 and 3.1.4 paragraph 6 conflict with one another. Related_Issues Key_Words_and_Phrases IEEE 854, 754, floating point, denormal Authors_Name David Bishop Authors_Phone_Number 585-726-6788 Authors_Fax_Number Authors_Email_Address dbishop@vhdl.org Authors_Affiliation Eastman Kodak Authors_Address1 2400 Mt Read Blvd Authors_Address2 Rochester NY 14650-3006 Authors_Address3 Current Status: Analyzed Superseded By: ------------------------ Date Submitted: 28 July 2005 Date Analyzed: 26 October 2005 Author of Analysis: Chuck Swart Revision Number: 2 Date Last Revised: 17 November 2005 Description of Problem ---------------------- In some simulators 2.0**-1025 results in 2**-1025 (a denormal 64 bit IEEE 754 (854) floating point number. In others, it becomes zero. Note that this is very similar to the famous "Pentium bug", which is now built into the IEEE 1076-2002 LRM.... In a floating point number, if the exponent is zero, by IEEE 854 the number can become "denormal". This is a mechanism in floating point which allows you to express very small numbers (3.1.4 paragraph 6). However, in 7.2.7 paragraph 6 it says "if the exponent is negative then the result is the reciprocal of that obtained with the absolute value of the exponent." Proposed Resolution ------------------- Modify section 7.2.7 to refer to IEEE 854 on how to treat an exponent. VASG-ISAC Analysis & Rationale ------------------------------ First, Clause 3.1.4 states that VHDL uses "a representation for all floating_point types except for universal_real that conforms either to IEEE std 754 or to IEEE Std 854..." Note that only the representation is specified. An implementation is not required to use 754 arithmetic. This was intentional, since VHDL does not give access to INF, NAN, etc. Also, its not clear that every computer architecture/OS fully supports all arithmetic requirements imposed by 754/854. Second, the IEEE 754 (and 854) standards require support for +,-,*,/ and square root, but not exponentiation. This means that exponentiation may be implemented by a function, not by hardware. The accuracy of such a function is implementation dependent. Finally, the ISAC interprets the words in clause 7.2.7, including: "if the exponent is negative, then the result is the reciprocal of that obtained with the absolute value of the exponent." as the mathematical description of the operation, not as the specification of the algorithm for implementing exponentiation. If this wording were interpreted literally, then, since 2.0**1025 produces overflow the result would have to be zero. Also, note that Annex C of the LRM specifically identifies as nonportable: -- The comparison of floating point values -- Events on floating-point-vlaued signals -- The use of explicit type conversion to convert floating point values to integer values In conclusion, the ISAC believes that the results of the exponentiation operator are implementation dependent. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change to the language is needed. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- No change to the language is needed. -------------END OF IR---------------- -------------BEGINNING OF IR---------------- VHDL Issue Number: 2073 Language_Version VHDL-2002 Classification Language Definition Problem Summary Index constraints and discrete range conversions from universal_integer Relevant_LRM_Sections 3.2.1.1 Index constraints and discrete ranges Related_Issues Key_Words_and_Phrases range, type, universal_integer 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: 24 August 2005 Date Analyzed: 31 October 2005 Author of Analysis: Chuck Swart Revision Number: 1 Date Last Revised: 31 October 2005 Description of Problem ---------------------- The above section makes such a code invalid: for i in 0 to 2 ** N - 1 loop ... However, the user may like to use such constructs, and I don't think there is rational to deny them. The work-around is to write: for i in integer range ... But this is more verbose. I think this is a real issue, since even the IEEE vital code use such invalid construct. (Of course, VITAL use other invalid construct, but this is not for VASG). Proposed Resolution ------------------- Replace "an implicit conversion to the predefined type INTEGER is assumed if each bound is either a numeric literal or an attribute, and if the type of both bounds (prior to the implicit conversion) is the type universal_integer." by "an implicit conversion to the predefined type INTEGER is assumed if the type of both bounds (prior to the implicit conversion) is the type universal_integer." VASG-ISAC Analysis & Rationale ------------------------------ This is a famous problem inherited from Ada 83. In Ada 83 the expression for I in -1 to 100 loop ... is illegal for the same reason as reported by the submitter. The solution for Ada 95 was to add two new anonymous types: root_integer and root_real from which all other integer or real types derive. In addition, the Ada 95 Rationale document states that "The overload resolution rules of Ada 83 were confusing and unclear and this section of the reference manual has been completely rewritten." To change VHDL in the same way would require considerable effort, which is probably not justified. We should point out that many implementations already accept the submitter's code, although it is technically illegal. To understand the basic problem let's first look at a simpler example: CONSTANT c1: integer := 3+5; The fundamental problem is to determine which + operator is used. The two potential candidates are INTEGER + and universal_integer +. From a practical perspective, it seldom makes any difference which + is used, but there is a theoretical issue. If the INTEGER + were overloaded, perhaps to form some sort of absorbing operator, then the choice of operator would be significant. Clause 7.3.5 deals with this issue: "An implicit conversion of an operand of type universal_integer to another integer type,...,can only be applied if the operand is either a numeric literal or an attribute, or if the operand is an expression consisting of the division of a value of a physical type by a value of the same type. [Such a conversion] is applied if and only if the innermost complete context determines a unique (numeric) target type for the implicit conversion, and there is no legal interpretation of this context without this conversion." This clause implies that implicit conversions occur as far down as possible in the expression tree. Therefore, in the constant expression in the above example there is an implicit conversion of each literal to type INTEGER, and then the INTEGER + operation is performed. With this as background we can better understand the original issue. It appears that the LRM in clause 3.2.1.1 allows only numeric literals or attributes of type universal_integer, in order to prevent any ambiguity about which operator applies. (As a side issue, the LRM should have also allowed division of two physical types as in Clause 7.3.5). If we accept the proposed solution, then the ** operator will be that of universal_integer, not that of INTEGER, i.e., function "**" ( anonymous: universal_integer; anonymous: INTEGER) return universal_integer; instead of the more natural: function "**" ( anonymous: INTEGER: anonymous: INTEGER) return INTEGER; Although this is a problem theoretically, in practice this is acceptable. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- Interpret the LRM as if the submitter's suggestion were in effect. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Adopt the submitter's suggestion. Change clause 3.2.1.1 as indicated. -------------END OF IR---------------- VHDL Issue Number: 2074 Language_Version: VHDL-2002 Classification: Language Definition Problem Summary: Problem with direct/select visibility in formal part Relevant_LRM_Sections: 4.3.2.2, 10.3 Related_Issues: 0006 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: Analyzed Superseded By: ------------------------ Date Submitted: 12 September 2005 Date Analyzed: Author of Analysis: Chuck Swart and Ajayharsh Varikat Revision Number: 2 Date Last Revised: 10 November 2005 Description of Problem ---------------------- Consider the following two VHDL code fragments: A) LIBRARY ieee; USE ieee.std_logic_1164.ALL; -- X01 becomes visible as a subtype ENTITY e1... ... ARCHITECTURE a1 OF e1 IS COMPONENT c1 IS PORT(X01: IN std_logic); BEGIN instance1: c1 PORT MAP ( X01(X01)=> s1); END a1; B) PACKAGE p2 IS constant X01: integer := 1; subtype bv1 is bit_vector(1 TO 1); END p2; LIBRARY ieee; USE work.p2.ALL; --X01 and bv1 become visible ENTITY e2... ... ARCHITECTURE a2 OF e2 IS COMPONENT c1 IS PORT(X01: IN bv1); BEGIN instance1: c1 PORT MAP ( X01(X01)=> s2); END a2; Are either of these legal VHDL? In example A) there are two possible interpretations: 1. The leftmost X01 is a type mark (with direct visibility) and the X01 inside the parentheses is a formal designator. This expression is legal. 2. The leftmost X01 is a port name (with visibility by selection) indexed by a subtype, which in this case is illegal. In example B) there are also two possible interpretations, with the legal/illegal cases reversed from example A) with respect to direct visibility and visibility by selection: 1. The leftmost X01 is a constant name (with direct visibility) and the expression inside the parentheses is a port name. This construct is clearly illegal. 2. The entire term is a formal designator, which reduces to an indexed name. The leftmost X01 is a port name (with visibility by selection) and the X01 inside the parentheses is an index expression. The grammar allows formal_part ::= formal_designator |<function>_name ( formal_designator) | type_mark ( formal_designator ) The name of the formal designator is visible by selection while the name of the type_mark (and the index expression in example B) are directly visible. So the question reduces to what visibility rules are used to analyze: X01(X01) which can be interpreted syntactically as either type_mark ( formal_designator) or simple formal_designator? Given the visibility rules of 10.3, it is hard to tell if directly visible names take priority over names visible by selection, or vice-versa. If direct visibility has priority then interpretation 1 applies to both examples, making example A) legal and example B) illegal. If selected visibility has priority, then interpretation 2 applies, making example B) legal and example A) illegal. If one were to argue that interpretation 1 applies to example A) and interpretation 2 applies to example B) then the visibility rules would be context dependent (or even more context dependent than current rules). The syntactic ambiguity in the formal_part rule is the major area (if not the only area) in which the rules for direct visibility conflict with those for visibility by selection. The closest analogy is the potential conflict between selected names and expanded names described in IR0006. This conflict is resolved by adopting the expanded name interpretation. I believe that different simulators interpret the two test cases in different ways, so this issue should be resolved to improve portability of the language. Proposed Resolution ------------------- Adopt a rule stating that in formal parts selected names hide directly visible names ( or vice-versa). This would make both examples illegal. Other solutions are possible, but the important thing is to not make the visibility rules context sensitive. In particular, interpretations A 1 and B 2 should not both be legal. VASG-ISAC Analysis & Rationale ------------------------------ The specific places at which such a conflict could occur are (from clause 10.3 of the LRM) "h) For a formal parameter declaration of a given subprogram declaration: at the place of the formal designator in a formal part (before the compound delimiter =>) of a named parameter association element of a corresponding subprogram call. i) For a local generic declaration of a given component declaration: at the place of the formal designator in a formal part ( before the compound delimiter =>) of a named generic association element of a corresponding component instantiation statement: similarly, at the place of the actual designator in an actual part (after the compound delimiter =>, if any) of a generic association element of a corresponding binding indication. j) For a local port declaration of a given component declaration: at the place of the formal designator in a formal part (before the compound delimiter =>) of a named port association element of a corresponding component instantiation statement; similarly, at the place of the actual designator in an actual part (after the compound delimiter =>, if any) of a port association element of a corresponding binding indication. k) For a formal generic declaration of a given entity declaration: at the place of the formal designator in a formal part (before the compound delimiter =>) of a named generic association element of a corresponding binding indication; similarly at the place of the formal designator in a formal part (before the compound delimiter => of a generic association element of a corresponding component instantiation statement when the instantiated unit is a design entity or a configuration declaration. l) For a formal port declaration of a given entity declaration: at the place of the formal designator in a formal part (before the compound delimiter =>) of a named port association element of a corresponding binding specification; similarly, at the place of the formal designator in a formal part (before the compound delimiter =>) of a port association element of a corresponding component instantiation statement when the instantiated unit is a design entity or a configuration declaration. m) For a formal generic declaration or a formal port declaration of a given block statement: at the place of the formal designator in a formal part( before the compound delimiter =>) of a named association element of a corresponding generic or port map aspect." The ISAC agrees that there should be a clear rule to determine visibility when there is a potential conflict between direct visibility and visibility by selection. It is preferable to choose visibility by selection over direct visibility because a declaration which is no longer directly visible can often be accessed by other mechanisms. In conclusion, the ISAC recommends that the syntactic ambiguity indicated in the problem description be resolved in favor of formal_designator, with a similar interpretation for actual_part. With this interpretation the leftmost X01 in example A) is interpreted as a port name, so the example is illegal. Example B) is legal: the leftmost X01 is a port name and the second X01 refers to the constant in the package. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- Interpret the LRM as if the Recommendation for Future Revisions were in effect. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Add wording similar to the following to clause 10.3 immediately after the existing paragraph that begins with "A declaration is said to be hidden...": "At a place in which a declaration is visible by selection every declaration with the same designator which would otherwise be directly visible is hidden." VHDL Issue Number: 2078 Language_Version VHDL-2002 Classification Language Modeling Enhancement or Deficiency Summary Allow attribute declaration/specification in package body Relevant_LRM_Sections 2.6 Package bodies 2.5 Package declarations Related_Issues Key_Words_and_Phrases Foreign subprograms Attribute definition/specification in package body Authors_Name Ernst Christen Authors_Phone_Number 503-547-6096 Authors_Fax_Number Authors_Email_Address Ernst.Christen@synopsys.com Authors_Affiliation Synopsys, Inc. Authors_Address1 2025 NW Cornelius Pass Rd. Authors_Address2 Hillsboro, OR 97124 Authors_Address3 Current Status: Analyzed Superseded By: ------------------------ Date Submitted: 21 November 2005 Date Analyzed: 02 December 2005 Author of Analysis: Chuck Swart Revision Number: 1 Date Last Revised: 02 December 2005 Description of Problem ---------------------- The definition of package_body_declarative_item does not include the productions attribute_declaration and attribute_specification for no apparent reason. This makes it impossible to declare a (public) subprogram in a package whose definition depends on a private foreign subprogram. The only way around this restriction is to make the foreign subprogram public, i.e. to include its declaration and the corresponding attribute specification in the package. This workaround unnecessarily exposes a part of the implementation of the original function, which is undesirable. Proposed Resolution ------------------- Allow attribute declarations and attribute specifications to occur as package body declarative items. VASG-ISAC Analysis & Rationale ------------------------------ The ISAC cannot think of any reason for not allowing attribute declarations and attribute specifications in package bodies. This is probably an oversight. Perhaps the early language authors thought that attribute declarations and specifications weren't needed or useful in package bodies. The problem that the author states is legitimate. Also, as a general principle, declarative parts should be as uniform as is reasonable. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- Under the assumption that this situation was an oversight, interpret the LRM as if the proposed resolution were in effect. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Adopt the proposed resolution. -------------END OF IR---------------- Minutes of ISAC meeting held via telecom on 01 December 2005 Present: Larry Soule, Chuck Swart, Ajay Verikat Absent: Peter Ashenden, Jim Lewis, Deepak Pant Next Meeting: Thursday January 12, 2006, 6 pm Pacific Standard Time (Friday January 13, 2006, 2 am GMT) TOPIC: IR 2077 Incorrect wording on some language constructs This IR reflects issues raised by Alex Zamfirescu in his recent vote on some ISAC IRs. ACTION: Larry to analyze TOPIC: IR 2078 Allow attribute declaration/specification in package body This request seems reasonable. ACTION: Chuck to analyze, then submit for a vote. TOPIC: IR 2079 Is TIME a locally static type? It was agreed that TIME'Value cannot be locally static, because of resolution limits. It was not agreed whether TIME'POS is locally static, and whether it returns a number of femtoseconds or returns a number of time units (adjusted by the resolution limit). It was also agreed that, for the most part, simulators "do the right thing" in this area. ACTION: Chuck to analyze. TOPIC: IR 2038 Minor semantic errors No progress. ACTION: Ajay to analyze. TOPIC: IR 2054 Individual assoc. rules for array formal are not valid James Unterburger supplied an analysis which pointed out flaws in the first part of the proposed solution, since, if all the formal names are indexed names instead of slice names, then there is no direction to use. ACTION: Larry to incorporate this into his analysis. TOPIC: IR 2070 Support for floating point denormal numbers The analysis was given to Dave Bishop. Here are his comments: "I see your point here, that we are implementation dependent. However, functionally, Floating point 754 is a standard. The LRM either sticks to it, or doesn't. The implementation doesn't have to be the same as 754 as long as it is functionally the same. After working with the problem, I can live with it either way." ACTION: All to vote on this IR. TOPIC: IR 2072 Allow static operations on "ranges" Some questions were sent to the submitter but he has not replied. ACTION: Chuck to forward as an enhancement request. TOPIC: IR 2073 Index constraints and discrete range conversions from universal_integer ACTION: All to vote on this IR. TOPIC: IR 2074 Problem with direct/select visibility in formal part ACTION: All to vote on this IR. TOPIC: IR 2075 Arrays with numeric and enumeration index types are not closely related Technical problems remain in the unconstrained case when the types are not closely related. One possibility is to prohibit type conversions in this case. ACTION: Ajay to finish analysis.Received on Fri Dec 2 09:05:23 2005
This archive was generated by hypermail 2.1.8 : Fri Dec 02 2005 - 09:05:29 PST