YES NO ---- ---- 2079 Analyzed Chuck Is TIME a locally static type? ---- ---- 2083 Analyzed Chuck Generate index specification should be of same subtype as generate parameter -------------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: Analyzed Superseded By: ------------------------ Date Submitted: 21 November 2005 Date Analyzed: 11 January 2006 Author of Analysis: Chuck Swart Revision Number: 1 Date Last Revised: 11 January 2006 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 ------------------------------ There is a genuine problem here. Time values cannot be locally static, since the value of an expression like if( 0 ns = .99 ns) depend on the resolution limit. Clause 3.1.3.1 mentions that "An implementation may allow a given execution of a model (see 12.6) to select a secondary unit of type TIME as the resolution limit." This could be interpreted as saying that the resolution limit is a simulation property. However, 7.4.2 states that a literal of type TIME is globally static, and, in practice, all implementations determine time values during elaboration. So the value of the above expression cannot be known during analysis, but is certainly known during elaboration. Since the time literal 100 ns is not locally static, expression TIME'VALUE("100 ns") cannot be locally static even though the STRING "100 ns" is locally static. The easiest way to remedy this problem is to create a special rule for TIME'VALUE in 7.4.1. 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 --------------------------------------------- Change 7.4.1 f) to read: A predefined attribute that is a function, other than the predefined attribute 'VALUE with prefix of base type TIME, and other than the predefined attributes 'EVENT, 'ACTIVE,..." There is no need to change 7.4.2 which defines globally static primaries, because section k) still applies: -------------END OF IR---------------- -------------BEGINNING OF IR---------------- VHDL Issue Number: 2083 Language_Version VHDL-2002 Classification Language Definition Problem Summary Generate index specification should be of same subtype as generate parameter Relevant_LRM_Sections 1.3.1 Block configuration 9.7 Generate statements 12.4.2 Generate statements Related_Issues Key_Words_and_Phrases generate parameter, block configuration, index specification Authors_Name Peter Ashenden Authors_Phone_Number +61 414 709 106 Authors_Fax_Number Authors_Email_Address peter@ashenden.com.au Authors_Affiliation Ashenden Designs Authors_Address1 Authors_Address2 Authors_Address3 Current Status: Analyzed Superseded By: ------------------------ Date Submitted: 31 January 2006 Date Analyzed: 15 March 2006 Author of Analysis: Chuck Swart Revision Number: 2 Date Last Revised: 16 march 2006 Description of Problem ---------------------- I've just been looking at generate statements, and am having trouble finding rules that I thought should exist. A for-generate statement specifies values for the generate parameter with a discrete range. The implicit type of the generate parameter is the base type of the discrete range. In a block configuration for the generate statement, you can write a block specification that determines which occurrences of the generate get configured. The block specification can be either a discrete range or an expression. I would expect the type of the discrete range or expression to be that of the generate parameter, and that values in the discrete range or the value of the expression be in the discrete range of the generate statement. However, I can't find rules that state this. Proposed Resolution ------------------- If no such rule exists anywhere, add a rule to 1.3.1 specifying that the value or values of the index specification be of the type of the corresponding generate parameter and lie within the discrete range specified for the generate parameter. VASG-ISAC Analysis & Rationale ------------------------------ The submitter is correct. The rules he describes do not exist in the LRM. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- Interpret the LRM as if the Recommendation for Future Revisions had been adopted. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- In clause 1.3.1 there is a paragraph which reads: "If the block specification of a block configuration contains a generate statement label, and if this label contains an index specification, the it is an error if the generate statement denoted by the label does not have a generation scheme including the reserved word for." Add to the end of this paragraph: "In addition, the value (or values) of the index specification must be of the type of the corresponding generate parameter and this value (or these values) must belong to the discrete range specified for the generate parameter." -------------END OF IR----------------Received on Thu Mar 16 22:45:57 2006
This archive was generated by hypermail 2.1.8 : Thu Mar 16 2006 - 22:45:58 PST