Subject: RE: [sv-bc] Separate Compilation Meeting Monday 6/9/03
From: Jay Lawrence (lawrence@cadence.com)
Date: Thu Jun 19 2003 - 06:52:58 PDT
Don't get me wrong Randy, I applaud any attempt to get rid of $root. It
causes more problems than it solves. It's just that top-level modules
already provide everything you propose with namespaces with the
exception of 'import' and 'import' assumes compilation order. More
comments embedded below...
> -----Original Message-----
> From: Randy Misustin [mailto:ram@model.com]
> Sent: Thursday, June 19, 2003 12:47 AM
> To: Adam Krolnik
> Cc: sv-bc@eda.org
> Subject: Re: [sv-bc] Separate Compilation Meeting Monday 6/9/03
>
>
> Hi Adam,
>
> Adam Krolnik wrote:
>
> > Hi Randy;
> >
> > On the surface, namespaces look like modules. It may be helpful in
> > analyzing
> > this to see a comparison between modules and namespaces.
>
> Yeah, this certainly occurred to me many times while putting the
> proposal together. The main distinction, in the end, is that
> namespaces
> are a vehicle intended to allow sharing without occupying a
> place in the
> hierarchy. Modules occupy hierarchy. It seems a historical hack that
> one might use secondary toplevel modules to achieve this effect in
> classic Verilog and, I would imagine, is what led to the use
> of $root as
> a repository for declarations in Superlog/SystemVerilog
> (which is what
> I'm trying to fix with this proposal).
>
Multiple top-level modules may be a historical hack, but they are
extremely useful and widely used. Routinely, the are used for
- global power and ground signals routed through a design
- tasks and functions needed throughout a design
- a place to put defparams as an annotation facility
They do frequently occur accidentally when someone says ./dir/*.v on the
command line instead of -y ./dir, but usually they are intended and
useful.
> I was trying to provide a scope from which to import symbols. If one
> wishes to substitute a module for this usage, then one would
> presumably
> import a hierarchical path rather than the name of a
> declarative region.
> The notion of importing the symbols from one hierarchical region into
> another is abhorrent (at least to me). This all led me to want the
> target of the import to be something different than anything
> that exists
> today in Verilog.
>
Referencing signals today from a top-level model is using a hierarchical
path. It is just that the hierarchical path begins with a module name at
the top of the hierarchy because there is no instance name. It may be a
nit, but this is not simply declarative region it is a module
instantiated at top of the hierarchy whose name is the module name.
Referencing signals from a scope other than the top level is actually
very useful. Verilog-AMS has discussed the concept of "inherited
connections" that allow rewiring power and ground for a full
sub-hierarchy by binding a local signal to another signal further up the
hierarchy. This is very useful when twiddling with low-level cells in a
design and adjusting the number of power/ground pins and not having to
wire them through a whole design. They are useful from other than the
top-level because some hierarchies contain entire blocks that run off of
different power supplies so you don't want to wire a single global power
supply, you want the 3v power supply for this sub-hierarchy, not the 3v
power supply for another part of the design.
Changing to a different email you said:
> This same problem exists in a much more fractured sense with the same
declarations
> existing in $root instead of a namespace. Similarly, this same problem
exists if you put > the declarations in a module at the toplevel and
reference them hierarchically. That
> said, I really appreciate you drawing attention to this whole issue of
the tradeoff
> between structured order of analysis/compilation and the ability of
the compiler to
> generate sensible messages earlier in the process. This has long been
a problem in
> Verilog and looks to be getting worse if it's not addressed.
Yes, as I said $root creates the order of analysis problem in spades.
The problem of compilation order does not exist with hierarchical
references to modules. You simply have to admit that any name containing
a '.' has to be deferred. This can lead to deferred error messages, but
not to imposing a compilation order.
I don't believe Verilog user's view this as a "problem". They view
hierarchical references of this sort as an inheritent, powerful feature
of Verilog without which they could not get their designs done. Any
attempt at restricting hierarchical reference or requiring a compilation
order will be soundly trashed by the users.
FYI, I know this from personal experience. In the early days of
NC-Verilog development (circa 1994) a bunch of VHDL developers from
Leapfrog (including me) set out to do a Verilog tool set. We imposed a
compilation order for hierarchical references and were severely beaten
about the head and neck by our Beta sites until we eliminated the
requirement.
I'ld prefer to see a mechanism whereby we provide an indication that a
module is intended to be a top-level module of this type. For instance:
module (* $top *) foo;
...
endmodule
A module with the $top attribute would always be placed as a top-level
module and it would be an error to instantiate it. A users trying to
declare global objects would put them in such a module and reference
them hierarchically.
Jay
This archive was generated by hypermail 2b28 : Thu Jun 19 2003 - 07:00:03 PDT