-------------BEGINNING OF IR----------------

VHDL Issue Number:        2089

Language_Version          VHDL-93
Classification            Language Modeling Enhancement or Deficiency
Summary                   Directional records
Relevant_LRM_Sections     
Related_Issues            
Key_Words_and_Phrases     RECORD, PORT, IN, OUT
Authors_Name              Andreas Doering
Authors_Phone_Number      ++41 44 724 8679
Authors_Fax_Number        
Authors_Email_Address     ado@zurich.ibm.com
Authors_Affiliation       IBM Zurich Research Laboratory
Authors_Address1          
Authors_Address2          
Authors_Address3          

Current Status:           Forwarded

Superseded By:

------------------------
Date Submitted:           29 March 2006
Date Analyzed:
Author of Analysis:
Revision Number:          0
Date Last Revised:        06 April 2006

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

For many standard interfaces, for instance a bus, there are input and
signals. Both can be combined into a record type individually, but not
together.  Event though both belong together (e.g. request+address
from master to bus, ack+read_data in reverse direction) , they always
have to be listed separately.  The use of inout for ports is a bad
alternative.

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

I propose a keyword "reverse" or "backwards" or similar in record
definitions.  If such a record is used in a signal or variable
declaration, it is irrelevant.  However in a port declaration, the
"reversed" record components have the reverse direction.  In the
example it would be:
    
    
    entity CPU is 
    port(
         bus_master : out Tmybusmaster 
            ...
    );
    
    where Tmybusmaster is declared as 
    
    TYPE Tmybismaster is RECORD
                request : std_logic;
                address : std_logic_vector(31 downto 0);
                ack : BACK std_logic;
                error : BACK std_logic_vector(5 downto 0);       
    END RECORD; 

ack and error would be inputs, though they are part of an OUT-record.
The binding in an instantiation is not a problem I think, because we
could as well bind the input and output parts individually.  This is
just "syntactic sugar".

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

This enhancement request will be forwarded to the VASG.

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

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

Forward to the VASG.


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