Subject: Re: Untimed behavioral Verilog-D & Connect modules
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Mon Feb 12 2001 - 18:15:56 PST
> From jons@cadence.com Mon Feb 12 16:53:13 2001
>
> 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
I don't see it as major functionality, rather a minor change to OOMRs. If I
ask for "^.clock" in a connect module, there had better be a "clock" in the
parent or the reference is illegal.
The reason that there is no symbolic name for a parent in the current Verilog
standard is simply that it isn't normally necessary and you can work around
the problem (as you describe).
I don't think it would be much of an issue if the "^" syntax was restricted
to connect modules. It'll be more of an issue if we have to write our modules
with extra sub-modules just to get at signals in the module itself.
NB: this was aimed more at timing than power-supply distribution and using
signals that are definitely present in the parent module.
Kev.
> 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 - 18:46:49 PST