Subject: Re: [sv-bc] Separate Compilation Meeting Monday 6/9/03
From: Randy Misustin (ram@model.com)
Date: Mon Jun 16 2003 - 09:42:41 PDT
Hi Peter,
Peter Flake wrote:
> Hi Randy,
>
> This is an interesting proposal, and I have a few questions:
>
> 1) Is there any reason not to allow modules, macromodules, interfaces
> and primitives in the namespace?
I briefly considered it, but in the end decided that there were probably
many things folks would want in a namespace that I wasn't going to be
able to think through adequately. I wound up taking the minimalist
route, including those items I knew to be important.
Specifically to your point of modules, etc., it seems to me that if they
are allowed to be nested inside other modules, there aren't any
fundamentally different issues to putting them inside namespaces.
> 2) How is the memory allocation of namespace variables handled for
> separate compilation?
My view was that namespaces would be elaborated just prior to the module
that first references it (although, I guess this is simply the latest it
should be elaborated). Other than that, memory allocation within
namespaces should behave much like within a module. Note that the import
statement is a visibility tool-- it doesn't imply any responsibility on
the scope doing the importing to perform any management of the objects
being imported.
> 3) Surely an import statement before a module is effectively in $root,
> and is similar to declarations in $root (apart from the wild card
> behavior)?
No, I actually intended it as I wrote. Remember that this proposal
replaces $root declarations. In it's current form, exports in this area
are quite similar to "use lib.pkg.all" in VHDL. Such clauses outside an
entity/architecture/configuration essentially set the starting
visibility when the following region is entered. In SystemVerilog this
feels more important syntactically, since you really want to set the
visibility prior to the ANSI style parameter and port definitions of a
module.
If we grapple with declarations in $root and define a reasonable
behavior for them in the separately compiled world, then this visibility
issue will have to dealt with then.
> Regards,
>
> Peter.
>
> At 22:42 15/06/2003 -0700, Randy Misustin wrote:
>
>> All,
>>
>> Here's the writeup on the namespace proposal as promised. Sorry for
>> the delay...couldn't break away any time until this weekend.
>>
>> I wound up proposing a strict replacement of $root for namespace. I
>> played around a bit on paper trying to find some kind of hybrid, but
>> didn't like how any of it was turning out, so kept it to a strict
>> replacement. Perhaps someone else who likes declarations outside of
>> scopes can propose something.
>>
>> -randy.
>>
>> Karen Pieper wrote:
>>
>>> Hi, all,
>>>
>>> We will have a separate compilation meeting Monday 6/9 at 9am
>>> Pacific Time. We will resume
>>> our discussion by reviewing all of the current proposals against the
>>> characteristics we agreed to last
>>> time (see
>>> http://www.eda.org/sv-bc/sep_comp/Requirements_for_Separate_Compilation.htm
>>> ). The
>>> phone numbers are:
>>>
>>> In the US: 888-635-9997
>>> Internationally: 763-315-6815
>>>
>>> See you there!
>>>
>>> Karen
>>
>>
>>
>>
>>
>> Namespaces
>>
>>
>>
>>
>> Introduction
>>
>>
>>
>> SystemVerilog Namespaces provide a mechanism for sharing data, type,
>> task, and function declarations amongst multiple SystemVerilog
>> modules and interfaces. A Namespace is a formalism and limitation to
>> SystemVerilog 3.0 and 3.1 $root declarations.
>>
>> Namespaces are explicitly named scopes appearing at the outer level
>> of the source text (at the same level as modules, primitives,
>> interfaces, etc.). Types, variables, tasks, and functions may be
>> declared within a namespace. Such declarations may be referenced
>> within modules, macromodules, interfaces, and other namespaces by
>> either import or hierarchical name.
>>
>>
>> Namespace Syntax
>>
>>
>>
>>
>> namespace_declaration ::=
>> { attribute_instance } namespace namespace_identifier
>> { namespace_item } endnamespace [ : namespace_identifier ]
>> namespace_item ::=
>> net_declaration
>> | data_declaration
>> | task_declaration
>> | function_declaration
>> | dpi_import_export
>> | namespace_import_declaration
>> | class_declaration
>>
>> The namespace declaration creates a top-level region to contain
>> declarations intended to be shared amongst one or more modules,
>> macromodules, or interfaces. Items within namespaces are generally
>> type definitions, tasks, and functions. It is also possible to
>> populate namespaces with variables and nets. This may occasionally be
>> useful for globals that aren't conveniently passed down through the
>> hierarchy.
>>
>> The following is an example of a namespace:
>> namespace ComplexPkg;
>> typedef struct {
>> float i, r;
>> } Complex;
>>
>> function Complex add(input Complex a, b)
>> add.r = a.r + b.r;
>> add.i = a.i + b.i;
>> endfunction
>> function Complex mul(input Complex a, b)
>> mul.r = (a.r * b.r) + (a.i * b.i);
>> mul.i = (a.r * b.i) + (a.i * b.r);
>> endfunction
>> endnamespace : ComplexPkg
>>
>> Certainly, one of the ways to utilize declarations made in
>> namespaces, is to reference them hierarchically:
>>
>> ComplexPkg.Complex cout = ComplexPkg.mul(a, b);
>>
>>
>> Import Syntax
>>
>>
>>
>> namespace_import_declaration ::=
>> { attribute_instance } import namespace_import_item { ,
>> namespace_import_item } ;
>> namespace_import_item ::=
>> namespace_identifier . identifier
>> | namespace_identifier . *
>>
>> The import statement provides direct visibility of symbols within
>> namespaces. It allows those symbols declared within namespaces to be
>> visible within the current scope by its declared simple name. Two
>> forms of the import statement are provided. The first form is an
>> explicit import and allows control over precisely which symbols are
>> imported:
>>
>> import ComplexPkg.Complex;
>> import ComplexPkg.add;
>>
>> The second form of import is a wildcard import and allows all symbols
>> defined within a namespace to be imported as a group:
>>
>> import ComplexPkg.*;
>>
>> Explicit imports are treated similarly to a declaration. An explicit
>> import is illegal if another symbol by the same name has already been
>> declared or imported into the same scope. Similarly, after importing
>> a symbol by a given name, it's illegal to then declare a symbol by
>> that same name within the same scope.
>>
>> Wildcard imports have somewhat different restrictions. All the
>> symbols within a namespace implied by a wildcard import are
>> candidates for import. They in fact become imported only if there are
>> no other symbols by the same name declared or imported in the same
>> scope. Similarly, their visibility may be limited by a subsequent
>> declaration of the same name in the same scope. It is also possible
>> for two symbols in two wildcard imports to "hide" each other.
>>
>> Import statements usually affect the scope in which they appear. The
>> exception to this policy is when one or more import statements
>> appears immediately prior to a module or interface declaration. In
>> these cases, the import statement(s) affect the subsequent module or
>> interface scope. Thus:
>>
>> import ComplexPkg.*;
>> module cadder(input Complex a, b, output Complex z);
>> assign z = add(a, b);
>> endmodule
>
>
This archive was generated by hypermail 2b28 : Mon Jun 16 2003 - 09:50:53 PDT