ISAC: two new IRS 2088 and 2089

From: Chuck Swart <cswart_at_.....>
Date: Fri Mar 31 2006 - 16:52:04 PST
Most likely both of these will be forwarded as enhancements requests.
Chuck Swart


2088    Submitted                       Formatted I/O
2089    Submitted                       Directional records


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

VHDL Issue Number:        2088

Language_Version          VHDL-2002
Classification            Language Modeling Enhancement or Deficiency
Summary                   Formatted I/O
Relevant_LRM_Sections     
Related_Issues            
Key_Words_and_Phrases     
Authors_Name              Amal Khailtash
Authors_Phone_Number      (613) 271-1101
Authors_Fax_Number        
Authors_Email_Address     Amal.Khailtash@edgewater.ca
Authors_Affiliation       
Authors_Address1          
Authors_Address2          
Authors_Address3          

Current Status:           Submitted

Superseded By:

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

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

Verilog has had great formatted I/O similar to C for a long time. In
FT5A, why not provide formatted I/O for all the built-in types and
also std_logic_vector, (un)signed values.  Something similar SNUG 2002
contribution for C-Library functions.

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



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

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

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


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

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

Superseded By:

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

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

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

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


-------------END OF IR----------------
Received on Fri Mar 31 16:52:08 2006

This archive was generated by hypermail 2.1.8 : Fri Mar 31 2006 - 16:52:10 PST