Subject: [sv-bc] Re: Proposal: Namespace (and deemphasizing $root)
From: Peter Flake (Peter.Flake@synopsys.com)
Date: Tue Mar 11 2003 - 11:28:51 PST
Hi Randy,
I apologize for the time to get back to you. I was at DATE last week.
Can you please explain what the namespace provides that an "include" file
does not?
An include file can be included at any level in the hierarchy to avoid name
collisions.
An include file can be included with each separate compilation. This can
be conditional to prevent duplication.
Peter.
At 23:16 04/03/2003 -0800, Randy Misustin wrote:
>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 11 2003 - 11:30:42 PST