VHDL Issue Number:      0127
Classification:         Language Definition Problem
Language Version:       VHDL-87
Summary:                Assuming that a type conversion function will be employed
                        to convert a value of one type to that of another.  In fact,
                        type conversion functions can be used to shift a value of
                        one type within that type.  Passage from LRM precludes this use.
Related Issues:         ?
Relevant LRM Sections:  12.6.1
Key Words and Phrases:  Composite Types, Type Conversion Function, Association Elements
Current Status:         Submitted
1076-1993 Disposition:  Superseded (ISAC Issues Outstanding)
Disposition Rationale:  
Superseded By:          1066
-----------------------
Date Submitted:         1989/06/21
Author of Submission:   Ken Scott
Author's Affiliation:   Vantage Analysis Systems, Inc.
Author's Post Address:  42840 Christy St., Suite 201
                        Fremont, CA   94538
Author's Phone Number:  (415) 659-0901
Author's Fax Number:    
Author's Net Address:   N/A
-----------------------
Date Analyzed:          TBD
Author of Analysis:     TBD
Revision Number:        $Revision: 1.8 $
Date Last Revised:      $Date: 1995/05/13 19:34:42 $


Description of Problem
----------------------
   In the 6th paragraph of chapter 12.6.1 (starts with "If a signal of a given..."),
   there is an error.
   
   The first statement reads:
     "If a signal of a given composite type has a
      source that is of a different type (and
      therefore a type conversion function appears
      in the corresponding association element), then
      each scalar subelement of that signal is
      considered to be active if the source itself
      is active."

   The problem with this text is that it does not take care of the
   strange but legal case where the user has inserted a "type conversion
   function" whose parameter and return value are of the same type:
      function SIMPLE_TCF( SOURCE : TM ) return TM;
   
   This function does not translate between types, but nonetheless
   may translate the actual value of the source to something the user
   wants.  The correct thing to do would be to consider each scalar
   subelement of the formal or actual to be active whenever its
   source is active.  This is not implied in the LRM.
   
   There is a similiar statement that has the same error later on in
   the same paragraph concerning "port of a given composite type".

Proposed Resolution
-------------------
   The following modified paragraph will fix the problem:
     "If a signal of a given composite type has a 
      source WHICH GETS TRANSLATED BY A CONVERSION
      FUNCTION APPEARING IN A PORT ASSOCIATION
      ELEMENT, then each scalar subelement is 
      considered to be active if the source itself
      is active.  Similiarly, if a port of a given
      composite type is associated with a signal WHOSE
      VALUE GETS TRANSLATED BY A CONVERSION FUNCTION
      APPEARING IN THE CORRESPONDING PORT ASSOCIATION
      ELEMENT, then each scalar subelement of that
      port is considered to be active if the actual
      signal itself is active."

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


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


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