Subject: Re: [sv-bc] Proposal for SV-BC-34A Namespaces
From: Dave Rich (David.Rich@synopsys.com)
Date: Mon Feb 10 2003 - 09:25:26 PST
Hi Jay, et. al.,
Like it or not, Verilog has seven name spaces, not three.
The purpose of my proposal was to describe the change needed to the
SystemVerilog LRM, which itself is a document that describes the changes
needed to be made to the Verilog LRM.
I copied most of my text directly from section 3.12 of the 1364-2001
LRM. What you ask for probably needs discussing in the ETF or other IEEE
committees, since SystemVerilog does not modify any of these concepts,
(like attribute and text name spaces)
I do agree that we could re-organize and simplify the whole name space
issue, but then people with think SystemVerilog is much more different
from Verilog than it really is.
Dave
Jay Lawrence wrote:
>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 name space 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
>>
>>
>>
>>
>>
>
>
>
>
-- -- 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 - 09:26:00 PST