Final review of IRs 2043 and 2062

From: Chuck Swart <cswart_at_.....>
Date: Thu Jul 28 2005 - 18:02:33 PDT
these attached IRs have received enough votes for ISAC approval.
Please give them a final review.
If there are no issues raised within the next few days,
I will mark them ISAC-Approved and forward them to the VASG.

Chuck Swart



VHDL Issue Number:      2043

Language_Version:       VHDL-2002
Classification:         Language Definition Problem
Summary:                numeric VALUE attribute parameter can't have sign
Relevant_LRM_Sections:  14.1 Predefined attributes, 13.4 Abstract literals
    
Related_Issues: 
Key_Words_and_Phrases:  predefined attribute, value, abstract literal
Authors_Name:           James Unterburger
Authors_Phone_Number:   503.685.0860
Authors_Fax_Number:     503.685.0921
Authors_Email_Address:  jamesu@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:         15 October 2004
Date Analyzed:          5 May 2005
Author of Analysis:     Deepak Pant
Revision Number:        2
Date Last Revised:      28 July 2005

Description of Problem
----------------------
The Result description of predefined attribute T'VALUE(X) states
that the parameter X be the string representation of a value of type T
as defined in Clause 13.  A value of a numeric type, when it contains
an abstract literal (as it must for integer and floating point types
and optionally for physical types), must use the syntax given in
"13.4 Abstract literals", which does not allow a sign "+" or "-" to
be part of the literal.  This makes it impossible easily to represent
negative numeric values:  INTEGER'VALUE("-123") is illegal.

Proposed Resolution
-------------------
Allow an optional sign in the abstract literal portion of the string
representation of a value of a numeric type.  This was stipulated thus
in "14.3 Package TEXTIO" for the string representation of INTEGER and
REAL values.

VASG-ISAC Analysis & Rationale
------------------------------
This is a valid request. The definition of T'Value needs to be updated 
on the lines of section 14.3.


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

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

The wording for the definition of T'Value as defined in section 14.1 should 
be modified from

"If T is a numeric type or subtype, the parameter may be expressed either 
as a decimal literal or as a based literal."

to

"If T is a numeric type or subtype, the parameter may be expressed either 
as decimal literal or a based literal, with the addition of an optional 
leading sign. No spaces can occur between the sign and the remainder of 
the value."



-------------END OF IR----------------


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
Revision Number:          2
Date Last Revised:        28 July 2005

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
------------------------------

Section 9.7 of the LRM specifies that the range in a for-generate statement
must be a static discrete range. 

Section 7.4.2 of the LRM specifies that:

    "A globally static discrete range is either a globally static subtype 
     or a globally static range."

and:

    "A globally static range is either a range of the second form 
     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."

where the terms "first form" and "second form" refer to the grammar
defining a range in section 3.1:

     range ::=
           range_attribute_name
         | simple_expression direction simple_expression

A static discrete range is either a locally static discrete range or
a globally static discrete range.

In the example of an unconstrained array type generic described in
this IR, A'range is not a static range, even though A itself is
globally static.  This is because the subtype of A is not globally
static.

However, as the submitter points out, the range of this generic is
known after it has been elaborated, and it is useful to be able to
refer to A'range in a generate scheme. In fact, the second paragraph
in section 7.4 indicates that the term "globally static" is used to
refer to something that is known after hierarchy elaboration. Hence it
makes sense to extend the definition of a static range along the lines
proposed and treat the range of a globally static object as a globally
static range.

Items (j) and (k) in section 7.4.2 specify predefined attributes that
are globally static. These also have similar issues, and should be
extended to allow globally static primaries as the prefix.

Similar problems also exist in the description of locally static
ranges and attribute names in section 7.4.1. However, there is a fast
track proposal (FT22) that requires a locally static constant to have
a locally static subtype. If that proposal is approved, the range of a
locally static object will always be locally static, and hence no
other changes are needed in section 7.4.1.



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.

Change item (j) to:

    j) A predefined attribute that is a value and whose prefix is one
       of the following.
       1) A globally static subtype
       2) An object or function call that is of a globally static subtype
       3) A globally static primary 

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 one of the following. 
       1) A globally static subtype
       2) An object or function call that is of a globally static subtype
       3) A globally static primary 

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 denotes either a globally static
     subtype or an object that is of a globally static subtype or
     whose prefix is a globally static primary."


If the requirement that locally static constants must have locally
static subtypes (part of FT22) is not approved, then similar changes
have to be made in section 7.4.1 for locally static ranges and
attributes.
Received on Thu Jul 28 18:02:37 2005

This archive was generated by hypermail 2.1.8 : Thu Jul 28 2005 - 18:02:38 PDT