Subject: [sv-bc] Proposal: Namespace (and deemphasizing $root)
From: Randy Misustin (ram@model.com)
Date: Tue Mar 04 2003 - 23:16:26 PST
Karen et al,
Here's the start of a proposal to address some of the $root issues we
discussed a couple of weeks back. Sorry for the late entry. I'd be
curious if Peter has given this any further thought.
-randy
=================
Problem:
'$root', meaning the root of the hierarchical tree, gets populated with
2 kinds of objects: global declarations and toplevel modules. The global
declarations, in particular, creates the following issues:
1. Name Collisions: Populating a single flat declaration scope with
names from a multitude of sources is a recipe for problems. We've
already seen this in Verilog with the flat namespace for modules, where
we use the `uselib directive and Verilog 2001 configurations to try and
manage it.
2. Separate compilation: SystemVerilog seems to be going more and more
down the path of not requiring definition prior to use and $root seems
to add considerably to this trend. Arguably, there may have already been
too many compromises of modularity and the ability to locally reason in
favor of economy of expression. None the less, each such tradeoff winds
up deferring the tool's ability to reason about statements and
expressions. At the extreme of where SystemVerilog seems to be heading,
only trivial syntax and semantic checks will be possible locally at
compile time and much of the error checking will be deferred to
elaboration time.
3. Mixing of Implementation Language: Location and use of $root in a
mixed representation is unclear. Many shops bring together pieces of IP
and implementation from a variety of sources in a variety of languages:
Verilog, VHDL, AMS variants of these, C, C++, etc. Assuming an arbitrary
mix and match of such portions of IP throughout a hierarchy, where is
$root? Ostensibly, $root is at the top of the hierarchy. Quite possibly
$root may not even contain any SystemVerilog modules (i.e., the
SystemVerilog portion(s) of the design may be much lower in the
hierarchy). Since we have to wait until elaboration to generate code for
much of the SystemVerilog portions of the design (see point 2 above),
this seems to imply that code generation needs to sit right in the
middle of a mixed language elaboration.
4. Utility functions/tasks: The raising of the bar in terms of
abstraction and testbench will probably lead to a greater desire for
utility libraries. This will aggravate the name collision problem and
raise the issue of how does a 3rd party (company or group) package such
a set of functions.
Proposal
Much of this can be addressed by separating the 2 uses of $root. We can
leave $root as the top of the hierarchy, but let's place declarations
that are required to reach more than one module someplace else.
Additionally, if we allow that "someplace else" to be an explicit region
like the rest of Verilog, then that region can have a name and go a long
way toward resolving the name collision issues (or at least make it
manageable by the same constructs that control module name selection in
the face of name collision).
I'd like to propose that we define a top-level region similar to a
module or interface that contains types, functions/tasks, and variables
that are intended to be shared amongst multiple modules (this replaces
$root's current role for this purpose). This region could be known as a
'namespace' (C++) or a 'package' (VHDL, Java, Ada), depending on one's
sensitivities to other HDL concepts ('interface' serves a strangely
similar purpose in SystemVerilog, but I'll leave the commonization
debate to others). Except as noted below as a possible embellishment,
shared definitions should appear only within namespaces (or packages).
Working hand in hand with such a region is a construct that selects
which regions (and/or symbols within said regions) are to be made
visible. Such a construct might be a 'using' clause (C++), an 'import'
statement (Java, Modula-2), or a 'use' clause (VHDL, Ada).
An interesting embellishment of the above might be to have a default
package, either "per file" or "per compilation". This would be a place
to gather globals defined outside an enclosing module/interface/package.
This default package, say '$defaultpkg', would be visible within the
file/compilation by default so you wind up with similar visibility as
the current definition, just with more structure around it.
Syntax/Semantics
<To be provided if there's sufficient interest.>
This archive was generated by hypermail 2b28 : Tue Mar 04 2003 - 23:22:26 PST