Subject: Re: [sv-bc] Separate Compilation Meeting Monday 6/9/03
From: Randy Misustin (ram@model.com)
Date: Thu Jun 19 2003 - 15:07:07 PDT
Hi Jay,
Jay Lawrence wrote:
>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...
>
>
As I said earlier, my personal feeling is that a module is too heavy and
general to be used with import.Of course, my distaste for importing
modules isn't as strong as my distaste for declarations in $root....
I'm always torn when I read your arguments between the desire to
economize new keywords (which I wholeheartedly support) and your seeming
belief that almost any proposal is just another special case of a
module. Yeah, one can build a Swiss Army knife and use it for
everything, but is this really the most productive tool when you have to
pound in 100 nails?
>>-----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.
>
>
Yeah, yeah, yeah, no one's going to argue as to their usefulness in
current codes. I've used it many times myself for more reasons than you
list here.
>>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:
>
>
I'm not sure what this diatribe is addressing. Perhaps you confuse my
wording "importing the symbols from one hierarchical region into
another" with hierarchical referencing. I'm using "import" in this
context to mean the import statement I propose rather than the concept
of hierarchically referencing objects in other instances. (Unless you're
suggesting that you'd bring in a 3V rail by importing it...I guess
that's a possibility...hmm.)
>>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.
>
OK, what's the difference between:
ComplexToplevelModule.Complex c1;
and
import ComplexPkg.*;
Complex c1;
In neither case can you figure out the size of c1, what it's field names
are (if it's a type that indeed has fields), or their types. The error
handling of nearly any operation involving c1 has to be deferred. The
fact you imported Complex out of a package instead of hierarchically
referencing it doesn't change. Without order of compilation guidelines
in either case (which I am not in anyway dictating by my humble
namespace proposal), we're creating a mess of deferred errors.
The only error handling difference I can see between importing and not
importing (ie, hierarchical referencing) is the reporting of undeclared
variables. If I mispell "foo" as "f00" and I don't have wildcard imports
in the language or in effect, I can many times get an error message at
compile time (but not always).
>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.
>
>
Again, nothing about the proposal changes legality of hierarchical
references. It simply offers a different view than $root as to how best
to share types, functions, tasks, etc.
>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.
>
>
I guess you like this because it uses an attribute on a module instead
of a new keyword?
-randy.
This archive was generated by hypermail 2b28 : Thu Jun 19 2003 - 15:09:39 PDT