Subject: RE: [sv-bc] Separate Compilation Meeting Monday 6/9/03
From: Jay Lawrence (lawrence@cadence.com)
Date: Fri Jun 20 2003 - 04:44:23 PDT
Note, Randy changed this from plain-text mail to HTML in his last reply,
therefore I'm replying in color instead of >>>. I hope others can still
read it....
Comments in blue.
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?
In the case of program blocks and interfaces a la SV 3.1, they are still
hierarchical objects which have ports, parameters, declarations, and
behaviors. The kinds of behaviors allowed have been arbitrarily limited
based on the "intended use" of the instance (as a verification model or
to model interconnect). I see these as a hammer being used to whack
different kinds of nails, not a knife.
If namespaces are truly limited to declarations then a new type of unit
may be warranted. No ports, parameters, behaviors, just declarations. I
went down the unification w/ module path partly due to the fact that
variable declarations are allowed and this has been nasty in the VHDL
world getting them to be deterministic, and the questions from others on
why not allow initial/always and instances.
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.)
Yes, this is exactly what I was suggesting and has been proposed in the
Verilog-AMS committee. It is also already used by many Cadence IC
customers. A signal at one level declares that it is available for
inheritance further down the hierarchy (with an attribute). Often when
playing with the low-level cells you end up needing one extra
power/ground on some specific node and you haven't wired it all the way
down the hierarchy. This lets you just reach up and grab it. It is hard
with todays hierarchical identifiers because there is no "up"/".." in a
path name.
This 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).
Yes, I agree completely. Any import on a module would just make it
impossible to produce any error message on undeclared identifiers. There
are some (Cliff!) who have argued that all declarations are superfluous
and might actually applaud this. I'm not one of them BTW.
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?
This is a feature I've wanted for years to explicitly indicate that a
module is intended at the top-level rather than just relying on the
elaboration process to figure out that it is not instantiated.
IF
- namespaces are clearly differentiated (no parameters, ports,
behaviors, hierarchy)
- import does not create a compilation order dependency
- users can deal with no error messages (or we eliminate the wildcard
import)
Then I might be convinced that namespaces are justified in the same way
VHDL packages are if it also eliminates $root.
-randy.
Jay
This archive was generated by hypermail 2b28 : Fri Jun 20 2003 - 04:46:58 PDT