Subject: RE: [vhdl-200x] Transmission gate mechanism and new parameter mechanism wanted
From: Erich Marschner (erichm@cadence.com)
Date: Thu Mar 20 2003 - 15:22:26 PST
Steve,
| > 2) Upward propagation of values during elaboration.
...
| This is a new request. Can I ask you to fill out an IR at ...
In fact, it is a very old request. This was proposed in 1987-88. There was quite a bit of discussion about it during the original standardization effort, as I recall. Might be good to review that discussion again to see why it wasn't adopted then, and whether the reasons still apply. (I've got my notes around here somewhere ... )
Regards,
Erich
-------------------------------------------
Erich Marschner, Cadence Design Systems
Senior Architect, Advanced Verification
Phone: +1 410 750 6995 Email: erichm@cadence.com
Vmail: +1 410 872 4369 Email: erichm@comcast.net
| -----Original Message-----
| From: Stephen Bailey [mailto:stephen@srbailey.com]
| Sent: Thursday, March 20, 2003 3:18 PM
| To: Jonas Nilsson; VHDL-200X
| Subject: Re: [vhdl-200x] Transmission gate mechanism and new
| parameter
| mechanism wanted
|
|
| Hi Jonas,
|
| > 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?
|
| Actually, this one is already in the request list, it just
| wasn't termed
| "transmission gate". In the presentation, it was called
| "bidirectional
| connections (simple switch, jumper)". But, the idea is the same: A
| physical connection is made and no resolution of the value
| is imposed.
|
| > 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?
|
| This is a new request. Can I ask you to fill out an IR at
| www.eda.org/pub/vasg/bugrep.htm? That will help us track the request
| better. I will ask Jim Lewis's modeling & productivity team to take
| responsibility for this request.
|
| Thanks for submitting your requests.
|
| -Steve Bailey
| Chair, VASG
|
|
This archive was generated by hypermail 2b28 : Thu Mar 20 2003 - 15:37:39 PST