VHDL Issue Number:        2055      

Language_Version          VHDL-2002
Classification            Language Definition Problem
Summary                   Prohibition on assignment of protected types not normative
Relevant_LRM_Sections     3, 4.3, 8.4, 8.5
Related_Issues            
Key_Words_and_Phrases     protected types, assignment
Authors_Name              Peter Ashenden
Authors_Phone_Number      +61 (8) 8339 7532
Authors_Fax_Number        +61 (8) 8339 2616
Authors_Email_Address     peter@ashenden.com.au
Authors_Affiliation       Ashenden Designs
Authors_Address1          PO Box 640
Authors_Address2          Stirling, SA 5152
Authors_Address3          Australia

Current Status:           VASG-Approved

Superseded By:

------------------------
Date Submitted:           19 January 2005
Date Analyzed:            21 January 2005
Author of Analysis:       Chuck Swart
Revision Number:          4
Date Last Revised:        09 May 2005

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

Clause 3 defines a basic operation and includes assignment (in
assignment statements and initializations).
    
    Clause 4.3 prohibits initialization of objects of protected types:
    
    - in 4.3.1.1, by virtue of a constant not being of a protected type;
    
    - in 4.3.1.2, by virtue of a signal not being of a protected type;
    
    - in 4.3.1.3, by virtue of a variable of a protected type not
      being allowed to have an initial value expression in its
      declaration;
    
    - in 4.3.2, by virtue of a default expression being illegal if the
      subtype indication of the interface declaration denotes a
      protected type.
    
    The informative notes in clause 8.4 specify that the target of a
    signal assignment statement must not be of a protected type.  This
    is a ramification of the requirement that signals not be of
    protected types.
    
    Similarly, the informative notes in 8.5 specify that the target of
    a variable assignment statement must not be of a protected type.
    However, this does not follow as a ramification of any normative
    specification.

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

The text of notes 2 and 3 in 8.5 should be moved to the normative text of 8.5.

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

The submitter is correct that the prohibition on assigning to a
protected type should be normative. However, both notes 2 and 3
contain references to subelements of protected types which are
illegal. So the notes need to be rewritten to make clear that such
subelements are already forbidden.

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

Interpret the LRM as if Notes 2 and 3 in 8.5 were normative.

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

Add to clause 8.5:

    "For a variable assignment whose target is a name, it is an error
    if the type of the target is a protected type."

Change note 2 to:

    "2-For a signal assignment whose target is a name, no subelement
    of the target can be of a protected type (see 3.2)."

Change note 3 to:

    "3-For a variable assignment whose target is in the form of an
    aggregate, no element of the target can be of a protected type,
    nor can any subelement of any element of the target be of a
    protected type (see 3.2)."





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