Subject: RE: [sv-bc] Proposal for SV-BC-34A Namespaces
From: Jay Lawrence (lawrence@cadence.com)
Date: Mon Feb 10 2003 - 04:29:35 PST
Dave,
Please clarify your intent using the term "name space". I think a
leading definition would be nice (Neither 1364 or SystemVerilog LRM has
one).
I'm confused because there are 2 possible meanings, "unique identifier
name space" vs. "regions of text in which a declaration can occur"
(declarative regions). This may just be my bias from lots of other
languages but when I think of the term "name space" I think of the
different kinds of names that can be declared and how they are unique.
For instance. There are 3 in Verilog:
- Macros - begin with backtick
- System Tasks and Functions - begin with dollar sign
- Identifiers - begin with a letter
These 3 name spaces are guaranteed never to collide. 'C' for instance
reserves the namespace beginning with '_' for use by the linker, and
'__' for use by the OS. Users can not declare names in these name
spaces.
Your writeup defines Macros as a unique name space but does not mention
$tasks.
The rest of your writeup talks about declarative regions. The issues
with declarative regions are which kind objects can be declared there,
which your writeup covers, but also the relative scope and visibility
rules for each. You touch on this for port regions, but not the others.
Please clarify the intent of this section. Once your use of "name space"
is clarified a more thorough review can be done.
Thanks,
Jay
===================================
Jay Lawrence
Architect - Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================
> -----Original Message-----
> From: Dave Rich [mailto:David.Rich@synopsys.com]
> Sent: Monday, February 10, 2003 2:54 AM
> To: sv-bc@eda.org
> Subject: [sv-bc] Proposal for SV-BC-34A Namespaces
>
>
> Replace Section 12.9 with
>
> SystemVerilog has five namespaces for identifiers. Verilog's global
> definitions name space collapses onto the module name space
> and exists
> as the top-level scope, $root. Module, primitive, and interface
> identifiers are local to the module name space where there
> are defined.
> The five namespaces are described as follows:
>
> 1. The /text macro name space/ is global. Since text macro
> names are
> introduced and used with a leading ' character, they remain
> unambiguous with any other name space. The text macro names are
> defined in the linear order of appearance in the set of input
> files that make up the description of the design unit.
> Subsequent
> definitions of the same name override the previous
> definitions for
> the balance of the input files.
> 2. The /module name space/ is introduced by $root and the module,
> macromodule, interface, and primitive constructs. It unifies the
> definition of functions, tasks, named blocks, instance names,
> parameters, named events, net type of declaration, variable type
> of declaration and user defined types.
> 3. The /block name space/ is introduced by named or unnamed blocks,
> the specify, function, and task constructs. It unifies the
> definitions of the named blocks, functions, tasks, parameters,
> named events, variable type of declaration and user
> defined types.
> 4. The /port name space/ is introduced by the module, macromodule,
> interface, primitive, function, and task constructs. It
> provides a
> means of structurally defining connections between two objects
> that are in two different name spaces. The connection can be
> unidirectional (either input or output) or
> bi-directional (inout).
> The port name space overlaps the module and the block
> name spaces.
> Essentially, the port name space specifies the type of
> connection
> between names in different name spaces. The port type of
> declarations includes input, output, and inout. A port name
> introduced in the port name space may be reintroduced in the
> module name space by declaring a variable or a wire
> with the same
> name as the port name.
> 5. The /attribute name space/ is enclosed by the (* and *)
> constructs
> attached to a language element (see 2.8). An attribute
> name can be
> defined and used only in the attribute name space. Any
> other type
> of name cannot be defined in this name space.
>
> --
> --
> Dave Rich
> Principal Engineer, CAE, VTG
> Tel: 650-584-4026
> Cell: 510-589-2625
> DaveR@Synopsys.com
>
>
>
This archive was generated by hypermail 2b28 : Mon Feb 10 2003 - 04:30:20 PST