Re: [vhdl-200x-mp] Out mode generics

One thing to consider is how out mode generics are treated by the
binding indications found in configuration declarations. Would you need
the ability to override the architecture body's setting of
PIPELINE_LATENCY via a configuration (like a back-annotation)?

I've received a number of suggestions based on pipeline examples. Are
there other ways out mode generics might get used?

Something similar to out-mode generics would be to allow a constrained
array type formal(signal) port to be associated with an unconstrained
array type 'actual' signal. Similar in the sense that the lower (leaf)
level instance is constraining its enclosing environment rather then the
other way around. Currently this isn't permitted because the signal
declaration must have a constrained type.

(Ryan, are you signed up for the vhdl-200x-mp reflector?)

--
Aspen Logic, Inc.
By: Tim Davis, President
Farrell Ostler wrote:
>  
> Andy D Jones wrote:
>
>> This may already be obvious, but the value should be able to be 
>> defined in the architecture (somewhat like a deferred constant in a 
>> package body) as well as the entity, such that it can be different 
>> for multiple implementations of the same entity.
>>  
>
> I agree that an important usage class is for an implementation 
> (architecture) to be able to communicate some of its properties to the 
> environment.
>
> In an effort to illustrate this, the following contrivance came to 
> mind. The environment that instantiates widget, declared below, gets 
> information from widget about its pipelining, so that the environment 
> can be adapted to that pipeline latency.
>  
>
> entity widget is
> generic (WIDTH : natural;
>          PIPELINE_LATENCY : out natural
>         );
> port    (inp : in  std_logic_vector(WIDTH-1 downto 0);
>          outp: out std_logic_vector(WIDTH-1 downto 0)
>         )
> end widget;
>
> architecture throughput of widget is
>     PIPELINE_LATENCY := 2; -- Two-deep pipelined implementation for 
> throughput
> begin
>     ... The high Fmax implementation
>
> end throughput;
>
> architecture lowcost of widget is
>     PIPELINE_LATENCY := 0; -- Combinatorial implementation for low cost
> begin
>     ... The lower cost, lower Fmax implementation
> end lowcost;
>  
>
> Regards,
> Farrell Ostler
>  
>