Next Meeting: Thursday December 1, 2005, 6 pm Pacific Standard Time (Friday December 2, 2005, 2 am GMT) 1. New ISAC Issues: 2077 Submitted Incorrect wording on some language constructs 2078 Submitted Allow attribute declaration/specification in package body 2079 Submitted Is TIME a locally static type? (2078 and 2079 are attached. 2077 was sent previously) 2. Open ISAC issues: 2038 Submitted Ajay Minor semantic errors 2054 Analyzed 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 3. Categorization of Old IRs: Currently done: Status 1002 Open Ambiguity as to when parameter subtype indications are elaborated. 1003 Open Non-commutative and non-associative resolution functions are a source of non-determinism 1004 Enhancement-Analysis needed Are deferred constants still deferred after their full declaration? 1008 Resolved Function NOW is undefined during static elaboration. 1009 Open Unclear context of evaluation for formal part of block map aspects. 1013 Open Reference to a generate loop parameter in a configuration is unclear 1014 Open The LENGTH attribute is ill-defined. 1017 Open Why must a name in a wait stmt. sens. list be static? 1019 ??Compare with 2028 The signal updating steps of the simulation cycle is incorrect. 1024 Open VPI Issue 20 -- Primary units with same name 4. Status of Web Based IR System 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: Submitted Superseded By: ------------------------ Date Submitted: 21 November 2005 Date Analyzed: Author of Analysis: Revision Number: 0 Date Last Revised: 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 ------------------------------ TBD VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD -------------END OF IR---------------- -------------BEGINNING OF IR---------------- VHDL Issue Number: 2079 Language_Version VHDL-2002 Classification Language Definition Problem Summary Is TIME a locally static type? Relevant_LRM_Sections 7.4.1 Locally static primaries 14.1 Predefined attributes 3.1.3.1 Predefined physical types Related_Issues Key_Words_and_Phrases Locally static primaries type TIME and staticness 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: Submitted Superseded By: ------------------------ Date Submitted: 21 November 2005 Date Analyzed: Author of Analysis: Revision Number: 0 Date Last Revised: Description of Problem ---------------------- LRM 7.4.1 defines a locally static primary to be, among other things: a) A literal of any type other than type TIME f) A predefined attribute that is a function, other than the predefined attributes 'EVENT, 'ACTIVE, 'LAST_EVENT, 'LAST_ACTIVE, 'LAST_VALUE, 'DRIVING, and 'DRIVING_VALUE, whose prefix is either a locally static subtype or is an object that is of a locally static subtype, and whose actual parameter (if any) is a locally static expression. LRM 7.4.1 also defines that "A locally static subtype is either a locally static scalar subtype, ...", and finally "A locally static scalar subtype is either a scalar base type or a scalar subtype formed by imposing on a locally static subtype a locally static range constraint." We conclude that according to these rules, TIME is a locally static subtype since TIME is a scalar type and therefore a scalar base type. Consequently, the expression TIME'VALUE("100 ns") is a locally static primary since TIME is a locally static subtype, 'VALUE is not on the exclusion list in item f) listed above, and the parameter of TIME'VALUE is a locally static expression. Conversely, the expression 100 ns is not a locally static primary according to item a) listed above. The reason for literals of type TIME not being locally static primaries appears to be related to the possibility of selecting a secondary unit of type TIME as the resolution limit for a given execution of a model. LRM 3.1.3.1 states in this context that "It is an error if a given unit of type TIME appears anywhere within the design hierarchy defining a model to be executed, and if the position number of that unit is less than that of the secondary unit selected as the resolution limit for type TIME during the execution of the model, unless that unit is part of a physical literal whose abstract literal is either the integer value zero or the floating-point value zero." This rule can only be enforced when the secondary unit of type TIME selected as the resolution limit is known, which is the reason why literals of type TIME are globally static primaries. It seems that the same should be true for the primary TIME'VALUE("100 ns"). Proposed Resolution ------------------- Three possible resolutions come to mind: a) define TIME to be a globally static type. This would have the consequence that primaries like TIME'POS would no longer be locally static. b) include 'VALUE in the exclusion list in 7.4.1.f). This seems to be overkill as for all types other than TIME no exception is necessary c) create a special rule for TIME'VALUE in 7.4.1 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 Tue Nov 29 18:01:12 2005
This archive was generated by hypermail 2.1.8 : Tue Nov 29 2005 - 18:01:17 PST