Re: [vhdl-200x-ft] FT11: Comment on complexity of aggregates in port maps

The fact that FT 11 allows for non-globally static expressions
in port maps automatically allows for aggregates as actuals in port maps.

The aggregates can be handled either as expressions with no special handling
and insert a delta delay OR we can treat them special.

Why treat them special?

1) We already have left hand aggregates which allow you to create a composite
signal out of other signals.
2) If we define aggregates special, we have the ability to allow aggregates
    on ports of mode other than IN.
3) In the case where all the aggregate elements are signals, the aggregate
provides a very straight forward mapping from scalar actuals to scalar formals.
Since this very similar to subelement associates there is no need for deltas.


Why treat them like any other expression?

1) Simple rules.


The big issue is that if we adopt the simple rules then we can't allow aggregates
on non-IN port ever.

A compromise would be if the aggregate contains only signals with globally static names
or globally static expressions then the formal is connected element wise to the matching
elements of the aggregate.  Those matches which are signals have no delta delay inserted.
If the aggregate contains anything else then the aggregate is is considered to be the right
hand side of a signal assignment where the target is a anonymous signal that replaces the
aggregate in the port map.

Examples:

u1: C port map ( p => ( a, b, c, d) ); --- a, b, c, d are signals
->
u1: C port map ( p(3)=>a, p(2)=>b, p(1)=>c, p(0)=>d);

u2: C port map ( p => ( a, b, c, '0') ); --- a, b, c are signals
->
u2: C port map ( p(3)=>a, p(2)=>b, p(1)=>c, p(0)=>'0');

u3: C port map ( p => ( NOT a, b, c, d) ); --- a, b, c, d are signals
->
t1 <= (NOT a, b, c, d);
u3: C port map ( p=>t1);

u4: C port map ( p => (  a(idx) , b, c, d) ); a,b c,d, idx are signals
->
t2 <=   (a(idx) , b, c, d) ; -- delay because a(idx) is not a globally static name,
u4: C port map( p=>t2);



As for aggregates on the formal, this seams of marginal use.  The only
case I could see it used is if you have a type conversion on the actual where
the result must be split to two inputs. Something like

u1: C port map ( (addr_high, addr_low)=> to_std_logic(int_addr,32) );

So I'm not against dropping this feature.

My vote is to use the compromise rule and drop aggregates for modes other than OUT and
and on the formals


Regards,
    John

Peter Ashenden wrote:
> Folks,
> 
> I'm looking at FT11, expressions including signals in port maps.  There are
> really three different sub-proposals rolled together in this proposal:
> 
> (FT11a): Allowing conversion functions to have more than one parameter
> 
> (FT11b): Allowing a non-static expression including signals as an actual
> designator for an in-mode port
> 
> (FT11c): Allowing aggregates of formal or actual designators
> 
> FT11a and FT11b are relatively straightforward.  However, I have real
> problems with FT11c.  It introduces significant complexity in the LRM
> description, especially if the aggregate is allowed to include (recursively
> down into subaggregates) a mixture of signal names, static expressions and
> non-static expressions as elements.  Are there common use cases that justify
> the complexity?  I'm sceptical, and would prefer not to venture down that
> path.
> 
> Comments?
> 
> 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
> 
> 


-- 
-- mailto: johnr@model.com     phone: (503)685-0864
--   http://www.model.com        fax: (503)685-0921
--