Subject: Re: Untimed behavioral Verilog-D & Connect modules
From: Jonathan Sanders (jons@cadence.com)
Date: Mon Feb 12 2001 - 16:09:08 PST
Kevin,
Looks like you are looking for support for what we at Cadence
call inherited connections. This is major functionality and not
a trivial problem, we know because we added support for this in
our flow. Most people do this via netlisting but it is hard to add an
extra pin to behavioral modules. So yes, in order to support this
some mechanism to look out of a connect module or any behavioral
module would be needed.
Now of course you can still do a form of this by having a global module
that contains your supply signals and then in the connect modules use
a OOMR to connect to the global signal. This is easy to do and is
supported by the language. Inherited Connections or multiple supplies
and grounds are not and not likely to be something to put quickly in
if you want vendors to support it as it has big time implementation issues.
Jon
At 12:47 PM 2/12/01, Kevin Cameron x3251 wrote:
> > From owner-verilog-ams@eda.org Mon Feb 12 09:57:06 2001
> >
> > Quoting Kevin Cameron x3251 (Kevin.Cameron@nsc.com):
> > >
> > > > Kevin,
> > > >
> > > > As far as I can tell all OOMRs must be given a full hierarchical path.
> > > > Thus the reason that we create a second top level block for these
> > > > references as we can then from any block give the path as shown
> > > > in my previous email on this.
> > > >
> > > > Jon
> > >
> > > I would suggest a syntax for "parent" if I could think of a good one
> > > ('..' looks too much like a typo) - maybe '*' for a wildcard match?
> > >
> >
> > There is already a mechanism in P1364 Verilog for "parent" references.
> > They are called upward relative references. The first component can
> > be either a module name or an instance name. The search rule is start
> > by assumidesign first component is upward instance searching upward
> until root
> > is seen. If not found, assume first component of name is module type name
> > and repeat process, but again this feature is mostly avoided since it
> > makes it harder for modules to be re-usable, i.e. the module needs to
> > know the design context in which it is instantiated.
> > /Steve
> >
> > <removed old messages>
> >
> > Steve Meyer
>
>The problem is slightly more subtle in that automatically inserted (connect)
>modules don't have a name for their parent module (assuming they are
>instantiated
>under the driver/receiver process's module), they therefore need a
>symbolic name
>for it.
>
>Having thought about it, I would suggest "^", so "^.clock" from a connect
>module
>refers to the signal "clock" in the parent. A blunter approach would be to
>allow
>wildcards e.g. '*', as in '*.vdd' to connect the first instance of a
>signal vdd
>in the hierarchy above.
>
>Personally I would be happy with just "^" working only in connect modules.
>
>
>This is a real problem at NSC, one of our mixed-signal simulation guys spent
>weeks trying to create IEs in Opus that would change switch levels
>depending on
>a varying VDD.
>
>[Note: if connect modules are not attached under the module whose
>drivers/receivers
>they serve then a symbolic name that refers to that module is required.]
>
>Kev.
***********************************************************
Jonathan L. Sanders
Product Engineering Director
Mixed Signal and Physical Verification Solutions
Cadence Design Systems, Inc.
555 River Oaks Pkwy
San Jose, CA. 95134
INTERNET:jons@cadence.com Tel: (408) 428-5654 Fax : (408) 944-7265
***********************************************************
This archive was generated by hypermail 2b28 : Mon Feb 12 2001 - 16:17:21 PST