From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Thu Apr 23 1998 - 00:43:34 PDT
Hierarchical names must state how the following are defined and referenced:
<p>BAD MSG:
1995> Escaped identifiers
995> Parallel root modules
1998> Generated instances
1995> Arrayed-instance identifiers
1998> Multidimensional arrays
1998> Recursive tasks and functions (shall not be hierarchically referenced)
X-Lines: 249
Content-Type: text/plain; charset="us-ascii"
Content-Length: 10213
X-Status: $$$$
X-UID: 0000000404
Status: RO
[] - Adam Krolnik's proposed changes
{} - Cliff Cummings' proposed changes
12.4 Hierarchical names
Every identifier in a Verilog HDL description shall have a unique
hierarchical path name. The hierarchy of modules and the definition of
items such as tasks and named blocks within the modules shall define these
names. The hierarchy of names can be viewed as a tree structure, where each
module instance, task, function or named begin-end or fork-join block
defines a new hierarchical level, or scope, in a particular branch of the
tree.
At the top of the name hierarchy are the names of {one or more root}
modules for which no instances have been created.
Was>> It is the root of the hierarchy.
Proposal 1a >> {This root or these parallel roots module make up one or
more hierarchies in a "design description" or "description".} <<
Proposal 1b >> It is the root {or parallel roots} of the hierarchy. <<
Inside any module, each module instance {(including an arrayed or generated
instance)} , task definition, function definition, and named begin-end or
fork-join block shall define a new branch of the hierarchy. Named blocks
within named blocks and within tasks and functions shall create new
branches. {Only non-recursively referenced automatic tasks and/or functions
create visible branches that can be referenced. Recursively called tasks
and functions, declared using the automatic keyword and recursively called
from within the same task or function, do not create visible branches that
can be referenced. See section ??? for a discussion of automatic tasks and
functions.}
Each node in the hierarchical name tree shall be a separate scope with
respect to identifiers. A particular identifier can be declared at most
once in any scope. See section 12.5 for a discussion of scope rules and
section 3.11 for a discussion of name spaces.
Any named Verilog object {or "hierarchical name reference"} can be
referenced uniquely in its full form by concatenating the names of the
modules, {module instance names,} tasks, functions, or blocks that contain
it. The period character shall be used to separate each of the names in the
hierarchy {, except for escaped identifiers embedded in the hierarchical
name reference, which are followed by white space and period-character
separators} . The complete path name to any object shall start at a
top-level {(root)} module. This path name can be used from any level in the
{hierarchy >>delete:description(hierarchy is used two paragraphs up)<<} {or
from a parallel hierarchy} . The first node name in a path name can also be
the top of a hierarchy that starts at the level where the path is being
used. [This type of name allows downward referencing of items.]
Examples:
Example 1 - The code in this example defines a hierarchy of module
instances and named blocks. Figure 12-1 illustrates the hierarchy implicit
in this Verilog code. Figure 12-2 is a list of the hierarchical forms of
the names of all the objects defined in the code.
<p><p> wave
|
+-----+-----+
| |
a wave1
| |
+---+---+ |
| | |
amod bmod innerwave
| |
keep keep
Figure 12-1 - Hierarchy in a model
wave wave.a.bmod
wave.stim1 wave.a.bmod.in
wave.stim2 wave.a.bmod.keep
wave.stim1 wave.a.bmod.keep.hold
wave.a.stim1 wave.wave1
wave.a.stim2 wave.wave1.innerwave
wave.a.amod wave.wave1.innerwave.hold
wave.a.amod.in
wave.a.amod.keep
wave.a.amod.keep.hold
Figure 12-2 - Hierarchical path names in a model
Hierarchical name referencing allows free data access to any object from
any level in the {same or parallel} hierarchy. If the unique hierarchical
path name of an item is known, its value can be sampled or changed from
anywhere within the description.
Example 2 - The next example shows how a pair of named blocks can refer to
items declared within each other.
begin
fork: mod_1
reg x;
mod_2.x = 1;
join
fork: mod_2
reg x;
mod_1.x = 0;
join
end
12.4.1 Upwards name referencing
A lower-level module can reference items in a module above it in the
hierarchy if the name of the higher-level module is known. The syntax for
an upward reference is given in Syntax 12-5.
upward_name_reference ::=
module_identifier.item_name
item_name ::=
port_identifier
| reg_identifier
| net_identifier
| parameter_identifier
| function_identifier
| task_identifier
| named_block_identifier
Syntax 12-5 - Syntax for upward name referencing
Upwards name references can also be done with names of the form
module_instance_name.item_name
A name of this form shall be resolved as follows:
a) Look in the current module for a module instance name
module_instance_name.
If found, this name reference shall be treated as a downward
reference, and
the item name shall be resolved in the corresponding module.
b) Look in the parent module for a module instance named
module_instance_name.
If found, the item name shall be resolved from that instance, which is
the
sibling of the module containing the reference.
c) Repeat step b), going up the hierarchy.
There shall be no spaces within the hierarchical name reference {, except
for escaped identifiers embedded in the hierarchical name reference, which
are followed by white space and period-character separators} .
Example:
In this example, there are four modules, a, b, c, and d. Each module
contains an integer i. The highest-level modules in this segment of a model
hierarchy are a and d. There are two copies of module b because module a
and d instantiate b. There are four copies of c.i because each of the two
copies of b instantiates c twice.
/* Adam's
The name of a module [or instance] is sufficient to identify the module and
its location in the hierarchy. A lower-level module can reference items in
a module above it in the hierarchy[. For variables they can be referenced]
if the name of the higher-level module [or it's instance name] is known.
[For tasks, functions and named blocks, Verilog will look in the enclosing
module for the name, until it is found {or until} the root of the hierarchy
is reached. It will only search in higher enclosing modules for the name,
not instances.] The syntax for a [hierarchical] reference is as follows:
<name_of_module[_or_instance]>.<name_of_item>
There can be no spaces within the reference. Example 12-11 demonstrates
upward referencing. In this example, there are four modules, mod_a, mod_b,
mod_c and mod_d. Each module contains an integer x. The highest level
modules in this segment of a model hierarchy are mod_a and mod_d. There are
two copies of module mod_b.x because both mod_a and mod_d both instantiate
mod_b.X. There are four copies of mod_c.x because each of the two copies of
mod_b.x instantiates mod_c.x twice.
*/ Adam's
<p>12.5 Scope rules
The following four elements define a new scope in Verilog:
- Modules
- Tasks
- Function
- Named blocks
An identifier shall be used to declare only one item within a scope. This
rule means it is illegal to declare two or more variables that have the
same name, or to name a task the same as a variable within the same module,
or to give a gate instance the same name as the name of the net connected
to its output.
If an identifier is referenced directly (without a hierarchical path)
within a task, function or named-block, it shall be declared either locally
within the task, function or named block, or within a module, task or named
block that is higher in the same branch of the name tree that contains the
task, function, or named block. If it is declared locally, then the local
item shall be used; if not, the search shall continue upward until an item
by that name is found or until a module boundary is encountered. [If the
item is a variable, it will stop at a module boundary; if the item is a
task, function, or named block it continues to search higher-level modules
until found.] The search [for variables] shall cross named block, task and
function boundaries but not module boundaries. This fact means that tasks
and functions can use and modify the variables within the containing module
by name, without going through their ports.
[If an identifier is referenced with a hierarchical name, the
path can start with an module name, instance name, task, function, or named
block. The names will be searched first at the current level, then in
higher-level modules until found. Since both module names and instance
names can be used, precedence is given to instance names if there is a
module named the same as an instance name.]
Because of the upward searching, path names that are not strictly on a
downward path can be used.
Example:
Example 1 - In Figure 12-3, each rectangle represents a local scope. The
scope available to upward searching extends outward to all containing
rectangles - with the boundary of the module A as the outer limit. Thus
block G can directly reference identifiers in F, E, and A; it cannot
directly reference identifiers in H, B, C and D.
<Figure 12-3>
Figure 12-3 - Scopes available to upward name referencing
Example 2 - The following example shows an incompletely defined downward
reference that can be accessed.
task t;
reg r, s;
begin: b
// redundant assignments to reg r
t.b.r = 0; // poorly defined but found by upward search
t.s = 0; // fully defined downward reference
end
endtask
*** TYPO ***
//********************************************************************//
// Cliff Cummings E-mail: cliffc@sunburst-design.com //
// Sunburst Design Phone: 503-579-6362 / FAX: 503-579-7631 //
// 15870 SW Breccia Dr., Beaverton, OR 97007 //
// //
// Verilog & Synthesis Training / On-Site Training //
// Verilog, VHDL, Synopsys, LMG, FPGA, Consulting and Contracting //
//********************************************************************//
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:52:50 PDT
and
sponsored by Boyd Technology, Inc.