I am attaching 6 updated IRs which I have not yet added to the ISAC data base. Please review them. IR2020, 2031 and 2061 have rewording which you might want to improve. IR2029, 2044 and 2059 are very straightforward. Note that Peter updated IR2053 during the ballot phase. If I don't receive any suggestions in the next couple of days, I'll put them into the database. I have a question about IR2031: "mod" function needed for TIME The IR states: The units of the result of a mod operation are left to the implementation as long as the result satisfies the above relation. and The units of the result of a mod operation are left to the implementation as long as the result satisfies the above relation. My question is: Are these statements really necessary? We don't make any statements about other expressions involving time, such as 5ns + 2ps. Why do we need to say anything in the LRM about units for 5ns mod 2ps? Technically, all these values are computed using either the primary unit (fs) or using the resolution limit, so why do we need to say anything more? Chuck Swart VHDL Issue Number: 2020 Language_Version: VHDL-2002 Classification: Language Definition Problem Summary: keyword REPORT is over-used Relevant_LRM_Sections: 8.2 Assertion statement 8.3 Report statement Related_Issues: Changes to the LRM such as making a final ; optional in port and generic declarations makes me nervous. I'm afraid of unexpected consequences. Key_Words_and_Phrases: assert, report, ; Authors_Name: Paul Butler Authors_Phone_Number: 512 683 8743 Authors_Fax_Number: Authors_Email_Address: Paul.Butler@ni.com Authors_Affiliation: National Instruments Authors_Address1: 11500 N. MoPac Authors_Address2: Austin, TX 78759 Authors_Address3: Current Status: ISAC-Approved Superseded By: ------------------------ Date Submitted: 20 February 2003 Date Analyzed: 1-Nov-04 Author of Analysis: Peter Ashenden Revision Number: 3 Date Last Revised: 10 May 2005 Description of Problem ---------------------- In 1076-1987, the following VHDL would not compile. In 1076-1993, it produces unexpected results: assert true; report "failure detected" severity error; Because report is both an optional word in an assertion statement and the first word in a report statement, the above code must compile with or without the semicolon following the assertion expression. Extra semicolons, especially at a natural end-of-line, are a common typing mistake. Proposed Resolution ------------------- While the report statement is handy, it enables a simple typo like the one above to wreak debugging havoc. The typical complaint from local engineers starts something like, "Modelsim claims that 5 < 2!" when, in fact, the writer has accidentally created an assertion that passes followed by a report statement! In the future, please watch out for LRM enhancements that enable typos to compile without warning but result in undesirable behavior. VASG-ISAC Analysis & Rationale ------------------------------ The submitter is correct in identifying poor syntax design. However, to change the syntax to avoid the problem would not be backward compatible. Hence, we must live with the poor design for the report statement. Reviewers of future changes should be aware of the importance of good syntax design. Issues such as this can be avoided by more extensive prototyping and validation of proposed language changes before they are set in stone in a revision of the LRM. Where resources permit, such validation should be done. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Add a note to clause 8.2 Assertion Statement which reads something like: Note: If a semicolon is inadvertently placed between the assert condition and the REPORT keyword in an assertion statement then no error will be detected. Instead, the intended assertion will be interpreted as an assertion statement with no report expression or severity expression, followed by a report statement. -------------END OF IR---------------- VHDL Issue Number: 2029 Language_Version: VHDL-93 Classification: LRM Terminology, Grammar and Typographical Errors Summary: Non-relevant words and paragraph. Relevant_LRM_Sections: 4.3.1.1 Constant Declaration 4.3.1.2 Signal Declaration 4.3.2 Interfaces Declaration 3.4 File Types Proposed_Resolution: Remove the phrases and paragraph. Related_Issues: Key_Words_and_Phrases: file type, alias Authors_Name: Gingold Tristan Authors_Phone_Number: 0 Authors_Fax_Number: 0 Authors_Email_Address: tgingold@free.fr Authors_Affiliation: none Authors_Address1: - Authors_Address2: - Authors_Address3: - Current Status: ISAC-Approved Superseded By: ------------------------ Date Submitted: 12 July 2003 Date Analyzed: 10 August 2004 Author of Analysis: Ajayharsh Varikat Revision Number: 03 Date Last Revised: 10 May 2005 Description of Problem ---------------------- At several places, the LRM states "It is an error if a [...] is of a file type or, an access type, or a composite type which has a subelement that is a file type or an access type." This suggests that a composite type can have a subelement of a file type. But this is explicitly invalid, per clause 3.2, "a composite type may only contain elements that are of scalar, composite, or access types; elements of file types are not allowed in a composite type." Therefore, the precision is not relevant and should be removed (or moved into a note). For a similar reason, this paragraph of clause 4.3.3.2 (Nonobject aliases) can be removed: d) Alternatively, if the name denotes a physical type [...] Indeed, physical types are always anonymous. This is due to clause 3.1.3 (Physical types): A physical type definition defines both a type and a subtype of that type. The type is an anonymous type, [...] As a consequence, the use of a nonobject alias is certainly more limited than expected (export feature described in LCS-0008). Proposed Resolution ------------------- Remove the phrases and paragraph. VASG-ISAC Analysis & Rationale ------------------------------ The second issue in this IR about the name of a physical type is covered by IR 2038. We analyze the first issue here. Section 3.2 of the LRM specifies that a composite type may not have a subelement that is of a file type or a protected type. There are several other sections (3.3, 3.5.1, 4.3.1.1, 4.3.1.2, 4.4) where the LRM forbids subelements of file types and protected types in specific contexts. This is redundant, and could potentially cause confusion about whether subelements of these types are allowed in other contexts. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change is needed, since the net effect is to remove correct but confusing language. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Make the following changes in the LRM. Section 3.3 The last sentence of the last paragraph on page 45 of the LRM should be changed from "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." to the following: "The designated type must not be a file type or a protected type." Section 3.5.1 The last two sentences of the second paragraph on page 51 of the LRM should be changed from "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 or a file type. Additionally, in the case of a function subprogram, the return type of the function must not be of an access type of a file type; moreover, it must not have a subelement that is an access type or a file type." to the following: "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." Section 4.3.1.1: The last sentence in this section before the note should be changed from "It is an error if a constant declaration declares a constant that is of a file type, an access type, or a composite type that has a subelement that is a file type, an access type, or a protected type." to the following: "It is an error if a constant declaration declares a constant that is of a file type, an access type, or a composite type that has a subelement that is an access type." Section 4.3.1.2 The first sentence of the sixth paragraph in this section should be changed from "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." to the following: "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 an access type." Section 4.3.2 The last sentence in the first paragraph on page 64 of the LRM should be changed from "Moreover, the subtype indication must not denote a composite type with a subelement that is a file type, an access type, or a protected type." to the following: "Moreover, the subtype indication must not denote a composite type with a subelement that is an access type." Section 4.4 The first sentence in the first paragraph on page 72 should be changed from "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." to following: "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." VHDL Issue Number: 2031 Language_Version: VHDL-2002 Classification: Language Modeling Enhancement or Deficiency Summary: "mod" function needed for TIME Relevant_LRM_Sections: 7.2.4 Multiplying Operators Proposed_Resolution: Add predefined functions "mod" and/or "rem" for physical types. Related_Issues: 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: ISAC-Approved Superseded By: ------------------------ Date Submitted: 24 September 2003 Date Analyzed: 12 August 2004 Author of Analysis: Deepak Pant Revision Number: 04 Date Last Revised: 10 May 2005 Description of Problem ---------------------- For designs involving cyclic behavior, a "mod" or "rem" function for type time would be very useful. Such a function cannot be easily written in VHDL because representations of type time are usually larger than those of type INTEGER so the conversion from TIME to INTEGER causes loss of data. However, it should not be particularly difficult to support these functions within a VHDL implementation. Proposed Resolution ------------------- Add predefined functions "mod" and/or "rem" for physical types. VASG-ISAC Analysis & Rationale ------------------------------ This is a useful request. Multiplying operators already exist for physical types and hence supporting mod & rem as builtin operators for physical types should be possible. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Section 7.2.6 of the 2002 LRM will need to be updated: a) The statement "the operators mod and rem are predefined for any integer type" should be changed to "the operators mod and rem are predefined for any integer type and any physical type". b) The following two rows should be added to the second table in this section: Operator|Operation |Left Operand |Right Operand| Result Type | | | Type | Type | | ------------------------------------------------------------- mod | Modulus |Any physical | The same | The same | | | type | type | type | ------------------------------------------------------------- rem | Remainder|Any physical | The same | The same | | | type | type | type | ------------------------------------------------------------- c) The following text should be added after the definition of the division operation for physical types: For two operands A and B, where A is an object of physical type Tp and has a value P1 and B is an object of the same type with value P2, the predefined remainder and the modulus operations are defined as: 1. The remainder operation (A rem B) is defined as: Tp 'Val(Tp 'Pos(P1) rem Tp 'Pos(P2) ) This operation should satisfy the following relation: A = Tp 'Val((A/B)*Tp 'Pos(P2)) + (A rem B) The units of the result of a mod operation are left to the implementation as long as the result satisfies the above relation. 2. The modulus operation (A mod B) is defined as: Tp 'Val(Tp ' Pos (P1) mod Tp 'Pos(P2)) This operation should satisfy the following relation: A = B * N + (A mod B) The units of the result of a mod operation are left to the implementation as long as the result satisfies the above relation. c) The following examples should be added to the list of examples at the end of the section: 5 ns rem 3 ns = 2 ns 5 ns mod 3 ns = 2 ns 5 ns mod 3 ps = 2 ps (-5 ns) rem 3 ns = -2 ns (-5 ns) mod 3 ns = 1 ns -------------END OF IR---------------- -------------BEGINNING OF IR---------------- VHDL Issue Number: 2044 Language_Version: VHDL-2002 Classification: LRM Examples, Notes and Appendices Summary: Deprecation of linkage ports affects boundary scan description language Relevant_LRM_Sections: Annex E: Features under consideration for removal Related_Issues: Key_Words_and_Phrases: linkage ports, deprecated features, BSDL Authors_Name: Peter Ashenden Authors_Phone_Number: +61 8 8339 7532 Authors_Fax_Number: +61 8 8339 2616 Authors_Email_Address: peter@ashenden.com.au Authors_Affiliation: Ashenden Designs Authors_Address1: PO Box 640 Authors_Address2: Stirling, SA 5152 Authors_Address3: Australia Current Status: VASG-Approved Superseded By: ------------------------ Date Submitted: 11 October 2004 Date Analyzed: 28 October 2004 Author of Analysis: Chuck Swart Revision Number: 3 Date Last Revised: 10 May 2005 Description of Problem ---------------------- Annex E lists the linkage ports feature as under consideration for removal and recommends against using the feature. IEEE Std 1149.1 defines the Boundary Scan Description Language (BSDL) that is widely used in test applications. BSDL uses a subset of VHDL to describe the pin connections to a device under test. The subset includes use of linkage ports for power supply, ground and not-connected pins. Should linkage ports be removed from VHDL, BSDL specifications would no longer be valid VHDL descriptions. Proposed Resolution ------------------- Do not remove linkage ports from the language. Remove the feature from the list in Annex E and remove the notes in 1.1.1.2 and 4.3.2. Add a note or note in relevant places cross referencing 1149.1. VASG-ISAC Analysis & Rationale ------------------------------ The author's description of the problem is correct and the proposed solution should be adopted. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change is needed. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Linkage ports should not be removed from the language. Remove the feature from the list in Annex E and remove the notes in 1.1.1.2 and 4.3.2. In addition, notes should be added in relevant places indicating that linkage ports are used in 1149.1. -------------END OF IR---------------- -------------BEGINNING OF IR---------------- VHDL Issue Number: 2059 Language_Version VHDL-2002 Classification Language Definition Problem Summary Upper/lower case character mapping is not clear Relevant_LRM_Sections 13.1 Character set 13.3.1 Basic identifiers Related_Issues Key_Words_and_Phrases Authors_Name James Unterburger Authors_Phone_Number 503-685-0860 Authors_Fax_Number Authors_Email_Address jamesu@model.com Authors_Affiliation Model Technology Inc. Authors_Address1 Authors_Address2 Authors_Address3 Current Status: ISAC-Approved Superseded By: ------------------------ Date Submitted: 25 January 2005 Date Analyzed: 7 February 2005 Author of Analysis: Peter Ashenden Revision Number: 3 Date Last Revised: 10 May 2005 Description of Problem ---------------------- The descriptions of upper_case_letter and lower_case_letter list out the graphic character members of each set. As basic identifiers are made up of these characters (among others), and since "[b]asic identifiers differing only in the use of corresponding uppercase and lowercase letters are considered the same", an indication of what "corresponding uppercase and lowercase letters" means would be helpful. Proposed Resolution ------------------- The ISO8859-1 might have this information, but it would be helpful to repeat this information in the VHDL LRM. VASG-ISAC Analysis & Rationale ------------------------------ The submitter is correct that the LRM assumes a correspondence between uppercase and lowercase letters. Unfortunately, neither ISO/IEC 8859-1 (the Latin-1 standard) nor ISO/IEC 10646-1 (the multi-byte character standard) explicitly give a mapping between upper- and lowercase letters. 10646 does imply a mapping, by virtue of the words "capital" and "small" in forming the names for characters, but this is not normative. 10646 is based on the Unicode standard (www.unicode.org), which explicitly defines case properties and case mapping for characters. However, the Unicode Consortium is not an accredited standards development organization, so it would be inappropriate to reference its specification in the LRM. The most straightforward thing to do would be to explicitly define the case correspondence in 1076. This could be done in terms of a mapping of position numbers, but the clearest specification would be an explicit table of correspondences. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- Assume the correspondence specified below for future revisions. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- In 13.1, after list item f), insert the following: For each uppercase letter there is a corresponding lowercase letter; and for each lowercase letter except ÿ and ß, there is a corresponding uppercase letter. The pairs of corresponding uppercase and lowercase letters are: A a B b C c D d E e F f G g H h I i J i K k L l M m N n O o P p Q q R r S s T t U u V v W w X x Y y Z z À à Á á Â â Ã ã Ä ä Å å Æ æ Ç ç È è É é Ê ê Ë ë Ì ì Í í Î î Ï ï Ð ð Ñ ñ Ò ò Ó ó Ô ô Õ õ Ö ö Ø ø Ù ù Ú ú Û û Ü ü Ý ý Þ þ -------------END OF IR---------------- -------------BEGINNING OF IR---------------- VHDL Issue Number: 2061 Language_Version VHDL-2002 Classification Language Definition Problem Summary Default actions on severity flags is different between simulators Relevant_LRM_Sections 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: ISAC-Approved Superseded By: ------------------------ Date Submitted: 10 February 2005 Date Analyzed: 18 February 2005 Author of Analysis: Chuck Swart Revision Number: 4 Date Last Revised: 10 May 2005 Description of Problem ---------------------- Both users and standards groups (those developing packages) are hampered by the fact different simulators do different things with severity error. It appears that some simulators stop on severity error and some do not. In the package numeric_std there are some things that are currently severity warning that should have been severity error. There is resistance to changing them to severity error because this would make the package execute differently under some simulators. This is a problem. As engineers, we need one definition of what these flags do by default. Proposed Resolution ------------------- By default, all simulators shall print messages of severity error but not stop. By default all simulators shall stop on severity failure. VASG-ISAC Analysis & Rationale ------------------------------ Different default behaviors between simulators have created problems with package design. The ISAC suggests that the LRM recommend that the default action for simulators is to continue execution for severity messages error and below. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Clause 0.2 Structure and terminology of this standard add: The word <i>should</i> is used to indicate a recommendation. Clause 8.2 Assertion statement After the paragraph starting "The error message consists of at least..." Add a paragraph: An implementation should continue execution of a model after occurrence of an assertion violation in which the severity level is NOTE, WARNING or ERROR. Add the note: NOTE: An implementation may choose whether or not to continue execution of a model after occurrence of assertion violations with various severity levels. It may also give tool users ability to control simulator actions for assertions of various severity levels via mechanisms not specified by this document. Similarly, Clause 8.3 Report statement After the paragraph starting "The report message consists of at least..." Add a paragraph: An implementation should continue execution of a model after displaying a report message in which the severity level is NOTE, WARNING or ERROR. Add the note: NOTE: An implementation may choose whether or not to continue execution of a model after occurrence of an report statements with various severity levels. It may also give tool users ability to control simulator actions for assertions of various severity levels via mechanisms not specified by this document. -------------END OF IR----------------Received on Tue May 10 13:03:47 2005
This archive was generated by hypermail 2.1.8 : Tue May 10 2005 - 13:03:49 PDT