Analysis of IR 2079

From: Chuck Swart <cswart_at_.....>
Date: Wed Jan 11 2006 - 17:42:36 PST
2079    Analyzed        Chuck           Is TIME a locally static type?


-------------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----------------
Received on Wed Jan 11 17:42:49 2006

This archive was generated by hypermail 2.1.8 : Wed Jan 11 2006 - 17:42:52 PST