Subject: RE: [vhdl-200x] Transmission gate mechanism and new parameter mechanismwanted
From: Jay Lawrence (lawrence@cadence.com)
Date: Thu Mar 20 2003 - 16:25:37 PST
The major issue is how to define this without introducing circular
generic resolution. As defined, VHDL is very "clean" in that you can
start at the top and elaborate. Once you introduce an "upward" generic,
then a child can influence the elaboration of a parent. For instance,
imagine an architecture with a generate statement. If the generate index
is determined by a child instance, then the parent can not be elaborated
until the child is elaborated. In the worst (sickest) case, the child
passing the generic "up" would be one (or more) of the instances in the
generate itself.
This introduces a whole new "order of evaluation" into the computation
of globally static expressions and what they mean. Considering that this
is one of the most confusing and controversial parts of the existing
language further extension unless radically constrained would be very
difficult.
Simple rules like "an out mode generic can not be used in a globally
static expression" would be needed. This would satisfy the kind of need
specified early where a delay could be passed out of a module.
Jay Lawrence
> -----Original Message-----
> From: Farrell Ostler [mailto:Farrell.Ostler@xilinx.com]
> Sent: Thursday, March 20, 2003 4:50 PM
> To: vhdl-200x@eda.org
> Subject: Re: [vhdl-200x] Transmission gate mechanism and new
> parameter mechanismwanted
>
>
> I agree with Jonas that there are cases where it is
> desireable for a model to pass static information to its
> environment.
>
> When I've thought (fantisized?) of this it has been in terms of
> generics of mode out.
>
> Farrell Ostler
>
>
> Jonas Nilsson wrote:
>
> > 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?
> >
> > 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 - 16:31:44 PST