RE: [vhdl-200x-ft] proposal submission

Karl and colleagues,

This request is very closely related to an issue considered recently by
ISAC. I have attached the draft ISAC analysis for your information. The
(yet to be approved) resolution was to forward the issue as an enhancement
request for VHDL-200x consideration, either for the FT revision or as a
Modeling and productivity issue for a subsequent revision.

If the rules of 1.1.1.2 are changed, those of 4.3.2.2 would need to be
changed consistently, and vice versa.

Cheers,

PA

--
Dr. Peter J. Ashenden                        peter@ashenden.com.au
Ashenden Designs Pty. Ltd.                   www.ashenden.com.au
PO Box 640                                   Ph:  +61 8 8339 7532
Stirling, SA 5152                            Fax: +61 8 8339 2616
Australia                                    Mobile: +61 414 70 9106
> -----Original Message-----
> From: owner-vhdl-200x-ft@eda.org 
> [mailto:owner-vhdl-200x-ft@eda.org] On Behalf Of Karl Eisenhofer
> Sent: Tuesday, 19 October 2004 04:31
> To: vhdl-200x-ft@eda.org
> Subject: [vhdl-200x-ft] proposal submission
> 
> 
> IEEE 200X Fast Track Change Proposal
> 
> ID:      FT-28 (?)
> 
> Proposer:     Karl Eisenhofer
> email:        karl@terasystems.com
> 
> Status:       Open
> Proposed:     10/18/2004
> Analyzed:     Date
> Resolved:     Date
> 
> Enhancement Summary:
> 
>         Relex restrictions on unassociated and unconnected 
> subelements of
>         ports to allow unassociated and unconnected subelements of
>         non-resolved composite types.
> 
> Related issues:         
> Relevant LRM section:
> 
>      1.1.1.2 
> 
> Enhancement Detail:
> ----------------------------
> 
>     Change the final sentance of section 1.1.1.2 from
> 
>     "It is an error if some of the subelements of composite 
> formal port are
>     connected and others are either unconnected or unassociated."
> 
>     To:
> 
>     "It is an error if some of the subelements of a resolved 
> composite type
>     on a port are connected and other subelements of that 
> type are either
>     unconnected or unassociated."
> 
>     Note that a std_logic_vector for example is not a 
> resolved composite 
> type, but
>     rather is composite of resolved types.
> 
>     Several synthesis tools already permit this kind of specification 
> and the
>     implementation implications of this are well understood.  
> The additional
>     analysis complexity associated with this is minimal.
> 
> Analysis:
> ----------------------------
> [To be performed by the 200X Fast Track Working Group]
> 
> 
> Resolution:
> ----------------------------
> [To be performed by the 200X Fast Track Working Group]
> 
> 
> 
>