ISAC: Review IR 2062 range staticness

I wasn't able to access eda.org, so please review the attached copy.

Chuck Swart


VHDL Issue Number:        2062 

Language_Version          VHDL-2002
Classification            Language Definition Problem
Summary                   range staticness 
Relevant_LRM_Sections     7.4.1 Locally static primaries
                          7.4.2 Globally static primaries

Related_Issues            Note: there are many related issues with definition 
                          of type staticness.

Key_Words_and_Phrases     type static
Authors_Name              Gingold
Authors_Phone_Number      
Authors_Fax_Number        
Authors_Email_Address     tgingold@free.fr
Authors_Affiliation       
Authors_Address1          
Authors_Address2          
Authors_Address3          

Current Status:           ISAC-Approved

Superseded By:

------------------------
Date Submitted:           19 February 2005
Date Analyzed:            6 April 2005
Author of Analysis:       Ajayharsh Varikat and Chuck Swart
Revision Number:          4
Date Last Revised:        17 March 2006

Description of Problem
----------------------

What does "imposing" means in the following sentence:

    "A locally static array subtype is a constrained array subtype
    formed by imposing on an unconstrained array type a locally static
    index constraint".
    
    The problem arise with interfaces:
    [...]
      generic (a :
    bit_vector);
    [...]
      sub: for i in a'range generate
    [...]
    
    A generate statement requires the discrete range to be static.  Is
    the range in this example static ?  Since the type of object "a"
    is not constrained at analysis time, the answer is no.  However,
    since it is constrained at elaboration time, the answer may be
    yes.

Proposed Resolution
-------------------

Replaces " A globally static range is either [...], or a range of the
first form whose prefix denotes either a globally static subtype or an
object that is of a globally static subtype."

    by

    "A globally static range is either [...], or a range of the first
    form whose prefix denotes either a globally static subtype or a
    globally static object."

VASG-ISAC Analysis & Rationale
------------------------------

   A reviewer of an earlier analysis pointed out that the following
   should also be legal:

    [...]
      port (a :
    bit_vector);
    [...]
      sub: for i in a'range generate
    [...]
    
This observation, although reasonable, requires a reconsideration
of the technical definition of global staticness.

Intuitively, a globally static expression is one which can be evaluated
at elaboration.

Such an expression must have three properties:

1.  It does not denote a dynamically elaborated named entity.

This requirement is covered in clause 7.4.2 by "a globally static
primary is a primary that, if it denotes an object or a function, does
not denote a dynamically elaborated named entity..."

(It could be possible to extend the notion of globally static expressions
to include dynamically elaborated expressions which do not depend on
subprogram parameters, but this IR does not address that issue.)

2.  The calculation of the expression depends on values which are
known at elaboration (although it might depend on non-globally static values).

So, for example, a constant declared in a process and initialized with
a call to am impure function is globally static. No expression that
depends on a signal value is globally static. But there is no
fundamental reason why an expression that depends on the size of a
signal could not be globally static.

3.  Multiple evaluations of the expression produce the same result.

This is why calls to impure functions are not globally static, but constants
declared using impure functions are globally static.

Using these three properties it is possible to extend the definition
of globally static expressions to a larger set of expressions that include
some references to type information involving signals and variables.

To insure that property 3 is not violated we must not allow certain
references to access types with unconstrained designated types.

VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------

No change.


VASG-ISAC Recommendation for Future Revisions
---------------------------------------------

Make the following changes in section 7.4.2.

Add the following:

    A prefix is "appropriate for a globally static attribute" if it
    denotes

    a) a signal 

    b) a constant 

    c) a type or subtype

    d) a globally static function call

    e) a variable which is not of an access type

    f) a variable of an access type whose designated (sub)type is
      constrained.

Change item (j) to something like:

      j1) one of the predefined attributes 'SIMPLE_NAME,
      'INSTANCE_NAME, or PATH_NAME

      j2) a predefined attribute that is a value and whose prefix is
      appropriate for a globally static attribute


Change item (k) to:

    k) 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
       actual parameter (if any) is a globally static expression, and
       whose prefix is appropriate for a globally static attribute

Change the sentence

    "A globally static range is either a range of the second form (see
     3.1 ) whose bounds are globally static expressions, or a range of
     the first form whose prefix denotes either a globally static
     subtype or an object that is of a globally static subtype."

to the following.

    "A globally static range is either a range of the second form (see
    3.1 ) whose bounds are globally static expressions, or a range of
    the first form whose prefix is appropriate for a globally static
    attribute."


Also, several minor errors were found in Clause 14.1 "Predefined attributes"
when preparing this analysis.

Make the following LRM changes to 14.1:

T'POS(X)

add the statement

    Restrictions: It is an error if the parameter does not belong to
    the subtype implied by the prefix.

A'LENGTH[(N)]

Change 

    Kind: Value.

to

    Kind: Function.

A'ASCENDING[(N)]

Change

    Kind: Value.

to

    Kind: Function.