Subject: [sv-bc] Re: Proposal: Namespace (and deemphasizing $root)
From: Randy Misustin (ram@model.com)
Date: Tue Mar 11 2003 - 12:14:43 PST
Hi Peter,
Welcome back.
I think I agree with you, at least to a point. Many of the problems
created by $root can be solved by merely eliminating $root as a valid
context for anything but the top-level modules. I only get interested in
what's left over after you've moved everything that makes sense out of
$root. Assuming there is something left over (i.e., something that we
agree should have something other than local scope), then I have my set
of concerns and issues about their placement.
If we can agree that nothing's left over (is that what you're suggesting
in your mail?), then I'd be supportive of simply removing $root from the
language (or, at least, limiting it's use to being the place where
toplevels go).
I guess I'm being a little tongue in cheek, because I do see needs for a
reasonable place to put groups of related utilities and/or declarations.
We could put them in a module, like Verilog currently supports, but that
has always felt like a hack to me and will feel even more so if this is
the mechanism by which you share anything other than variables and
tasks/functions. I guess the point is that there's a very useful
share/use model that needs a good support mechanism. I don't believe
$root is a very good one (for the reasons I listed in the earlier mail).
I hope this clarifies my thinking.
-randy.
Peter Flake wrote:
> 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.>
>>
>>
>
-- Randy Misustin Model Technology ram@model.com 8005 SW Boeckman Road Phone: (503) 685-0873 Wilsonville, OR 97070
This archive was generated by hypermail 2b28 : Tue Mar 11 2003 - 12:15:33 PST