IEEE 200X Fast Track Change Proposal

ID:	  FT-11

Status:       Proposed
Proposed:     8/03
Modified      03/21/05
Analyzed:     Date
Resolved:     Date

Enhancement Summary:     Allow expressions in port maps
Related issues:          
Relevant LRM section:    

Enhancement Detail:
----------------------------
Expressions in input port maps to create an implicit signal with 
an delta cycle delay.

Currently it is not anticipated to allow expressions in subprogram
port maps for signal class objects. 
   This is consistent with allowing entity/component ports to have 
   constant values mapped to them, but not subprograms 
   Expanding signal rules to subprogram would have to be carefully analyzed


U_UUT : UUT
  port map ( A, Y and C, B) ;

Semantics of expressions in port map:
    convert to equivalent concurrent signal assignment with delta cycle delay
    delta cycle -- prefer no delta cycle
    Note:  Type Conversion/Conversion Function = no delta cycle
    If expression = signal or constants, no delta cycle
    Interesting Cases: 
       "not"(A) no delta cycle, whereas, not A has a delta cycle

Issues relating to conversion functions:
What defines a conversion function:
  only one actual can be a signal
  Allow additional inputs if they are globally constant expressions.

if the entity/component ports are unconstrained, there
can be problematic issues with conversion functions that 
return unconstrained arrays 
   Requirement, the size of the port or conversion function 
   must be globally static.
   example:  to_unsigned(int, 5) returns unconstrained array.
   if port f is unconstrained:
     -- f     => to_unsigned(int, 32),  -- is illegal
     f(31:0)  => to_unsigned(int, 32),  -- legal

Conversion function restriction:  signal name in conversion function 
   must be a single signal name (slice, name, indexed, sig attribute)
      F => CF(A(3), B(3)) -- not a conversion function, has delta cycle delay
      F => CF(A(3), A(4)) -- not a conversion function, has delta cycle delay

If for any reason a function is determined not to be a conversion 
function, then a delta cycle delay will be incurred.

Association where the actual is an aggregate is always allowed on
ports of mode IN and in some cases it is allowed on ports of mode
INOUT, BUFFER, and OUT.  If the port is of IN, and every element of
the aggregate is either globally static signal name or a globally
static expression, scalar subelements of the port are considered
associated individually to the matching scalar subelement of the
aggregate. This results in no delta delay between the actuals and the
formals.  If the aggregate contains anything other than globally
static signal names, then the aggregate is treat just like any other
non-globally static expression.  That is an implicit signal is created
to replace that aggregate in the port map and the aggregate is
assigned to the implicit signal in a concurrent signal assignment. For
ports of mode INOUT, BUFFER, and OUT, only Aggregates that contain
globally static signal names are allowed.  They are treated as if the
scalar subelements are associated individual between the actual and
the formal.

For example:
PIN is a IN port of std_logic_vector(3 downto 0)
POUT is a OUT PORT of std_logic_vector(3 downto 0)
S1, S2, S3, and S4 are signals of std_logic_vector( 3 downto 0)
C1, C2, and C3 are globally static constants of std_logic_vector(3 downto 0)


PIN => ( S1(0), S2(0), S3(0), ‘0’) is the same as
PIN(3) => S1(0)
PIN(2) => S2(0)
PIN(1) => S3(0)
PIN(0) => ‘0’
   And the is no delta delay.

PIN => ( S1(TO_INTEGER(S2), ‘0’, ‘1’, ‘0’) is the same as

T1 <= ( S1(TO_INTEGER(S2), ‘0’, ‘1’, ‘0’)) after 0 ns;
…
PIN => T1
  T1 is a anonymous signal because the aggregate has a non-globally static 
  signal name.  There is a delta between the aggregate and the formal.

POUT => ( C1(2 downto 0), S1(0)) –- illegal not all elements are globally static
--signal names
POUT => ( S1(1 downto 0), S2(1 downto 0)) –- legal same as saying
  POUT(3) => S1(1), POUT(2)=>S1(0), POUT(1)=>S2(1), POUT(0)=>S2(0)




Analysis:
----------------------------
[To be performed by the 200X Fast Track Working Group]


Resolution:
----------------------------
[To be performed by the 200X Fast Track Working Group]