Subject: Re: [vhdl-200x] Transmission gate mechanism and new parameter mechanism wanted
From: vhdl-200x@grfx.com
Date: Thu Mar 20 2003 - 18:58:13 PST
> From: Jonas Nilsson <jonas@hardi.se>
>
> Hi,
>
> Two enhancement proposals that I can't find in the list:
>
> 1) Transmission gate
> The ability to connect two PORTS in an architecture, effectively
> making them the same net. This probably requires a change to the
> way PORTs are handled in 12.6 in the LRM. Maybe the addition of
> a new PORT mode?
It's not so much ports but how driver resolution is performed that needs
to be different if you want to do bi-directional signal flow - it needs
to be flat rather than hierarchical - you also need to add functionality
(maybe as implicit signals) to let a process interrogate the drivers of
a net so that it can differentiate it's own driver from others. (That's
if you want to do it as abstract functionality rather than add primitives.)
Regards,
Kev.
> 2) Upward propagation of values during elaboration.
> Currently elaboration is performed Top-down, and Generics are passed
> from the instantiating module to the instantated one. Sometimes it
> is advantageous to pass information "the other way": from the
> instantiated component/entity to the instantiating architecture.
> (A testbench could know the intended latency of a DUV, a datapath
> could adapt to the latency of an operational module, or an architecture
> could adapt to the bus width of an instantiated IP-block...)
> One method doing this today is by inluding packages that are created
> alongside with the entity, and USEd in instantiating designs. But this
> prevents propagation of these values through several levels of hierarchy.
> I would prefer another method, where the information is encapsulated in
> the ENTITY/ARCHITECTURE itself. For example, an ENTITY could declare
> attribute-like values, which would be visible from other design units by
> writing for instance
> constant latency: INTEGER := LIB.E(arc)'latency;
> The order and mechanism of parameter propagation has to be considered,
> since an attribute value could depend on a GENERIC parameter, which
> could in turn depend on an attribute value.
> This could perhaps be part of some OO extensions to design units?
>
>
> Jonas
> --
> Jonas Nilsson
> HARDI Electronics AB
> Dalbyvagen 22
> SE-224 60 LUND
> SWEDEN
>
> Phone : +46-46-16 29 00
> Fax : +46-46-16 29 01
>
This archive was generated by hypermail 2b28 : Thu Mar 20 2003 - 19:08:36 PST