Subject: Re: Proposal: Implicit Port Instantiation in SystemVerilog
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Mon Dec 17 2001 - 11:05:37 PST
> From alec@fintronic.com Mon Dec 17 09:46:48 2001
>
> I agree with Kris that the .* will greatly improve both writeability
> and readability. The semantics should be those of inherit/export as Kevin
> suggested. However, do we really need the additional inherit/export
> keywords?
>
> Perhaps just writing the rules for inheritance (precisely how the
> signals should be searched in the parent scope(s)) may be sufficient.
>
> Or, perhaps the inherit/export may only be necessary for the Vss/Vdd
> signals to be searched in subscopes of the parent, but not the regular
> signals which must be found (or else an error shall be reported) only
> in the scope of where the module is instantiated. So, we could have
> different rules for signals declared with inherit/export than for the
> others.
>
> The combination of both port association by name and .* seems the most
> attractive to me.
>
> Alec
The .* syntax covers downward declared connection (any input
in the child can be connected to [?]). "Inherit" would handle
upward connection, i.e. when a module is instantiated with signals
declared with inherit you would search straight up the instance
hierarchy until you find a matching exported signal. The keyword
"inherit" would be required (and would be like "input" syntactically),
and the keyword "export" is desirable to avoid false connection in
modules that are unaware of inheritance.
Since inheritance skips levels in the hierarchy, it may be worth
using the "export" syntax for the same purpose downwards since the
.* syntax only works over a single port boundary, e.g. any signal
declared "export" would match an otherwise unbound port of the same
name in lower levels (not declared "inherit").
NB: my main reason for wanting this is kind of thing is for the
connection of signals like Vdd/Vss, substrate and thermal modelling
connections that are left off logic/RTL modules but are needed by
analog models of library cells in a mixed analog/digital flow. How
useful it is in general I'm not sure.
Regards,
Kev.
> > Sender: owner-vlog-pp@eda.org
> > Precedence: bulk
> >
> > I think your perspective on this comes much from
> > your application domain. In microprocessor design, we
> > have a large number of leaf blocks (with cells and
> > macro blocks instantiated with "traditional" connectivity).
> > Above that, the hierarchies are created for logical
> > verification purposes with the occasional multiple
> > instantiations. These hierarchies also assist in
> > encapsulation logic to reduce the debug complexity
> > of large models. But, for the most part, the signals
> > are not redundant, and the expectation is that
> > above that "leaf" level, signals are all unique.
> >
> > It is not uncommon to see blocks with hundreds to
> > thousands of signals (not vector expanded!). Today, we
> > create these lists and instantiations through a
> > generation program vs. typing the signal in at
> > those levels. The .* will allow large block
> > instantiation without the pain of creating large,
> > redundant signal lists.
> >
> > Thanks,
> > KRis
> >
> > -----Original Message-----
> > From: Kevin Cameron x3251 [mailto:dkc@galaxy.nsc.com]
> > Sent: Friday, December 14, 2001 2:07 PM
> > To: vlog-pp@eda.org
> > Cc: Kris@ichips.intel.com; mmaidmen@ichips.intel.com
> > Subject: Re: Proposal: Implicit Port Instantiation in SystemVerilog
> >
> >
> >
> > Apart from reducing keystrokes, I'm not sure what problem this solves.
> > Typing mechanisms in Verilog seem lax enough to me as it is. Why add
> > another opportunity to make non-obvious errors?
> >
> > Having said that, you could consider including a solution for the
> > Verilog-AMS problem of how to wire up power & ground for analog modules
> > in mixed design hierarchies, and "kill two birds with one stone".
> >
> > Specifically; the problem in Verilog-AMS is that A/D conversion modules
> > need to connect into the nearest Vss/Vdd to get accurate results, but don't
> > know where in the parent hierarchy those signals are declared.
> > Personally I would go for something an "inherit <signal>" declaration
> > in the child module, and maybe a matching "export <signal>" in the parent
> > - but I'm open to suggestions.
> >
> > Regards,
> > Kev.
> >
>
>
This archive was generated by hypermail 2b28 : Mon Dec 17 2001 - 11:07:14 PST