BE18 19981030

From: Cliff Cummings (cliffc@sunburst)
Date: Fri Oct 30 1998 - 11:56:10 PST

Next message: Eli Sternheim: "Re: BE18 19981030"
Previous message: Adam Krolnik: "Re: Proposal Two for ANSI style port declarations"
Next in thread: Eli Sternheim: "Re: BE18 19981030"
Maybe reply: Eli Sternheim: "Re: BE18 19981030"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

<x-html><HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.04 [en] (X11; I; SunOS 5.5.1 sun4m) [Netscape]">
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#FF0000">
Hierarchical names must state how the following are defined and referenced:
 1995> Escaped identifiers
 1995> Parallel root modules
 1998> Generated instances
 1995> Arrayed-instance identifiers
 1998> Multidimensional arrays
 1998> Recursive tasks and functions (shall not be hierarchically referenced)
 
 {} - proposed changes
 
<H2>
12.4 Hierarchical names</H2>

 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 <TT>begin-end</TT> or <TT>fork-join</TT>
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.
<STRIKE>It is the root of the hierarchy.</STRIKE>
{This root or these parallel root modules make up
one or more hierarchies in a "design description" or "description".} Inside
any module, each module instance {(including an arrayed
or generated instance)} , task definition, function definition,
and named <TT>begin-end </TT>or <TT>fork-join</TT> 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 separators composed of white space and a period-character}
. 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 <STRIKE>description</STRIKE>
{hierarchy 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. {The
latter allows and enables 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.
 
 
 <TT>
wave</TT>
 <TT>
|</TT>
 <TT> +-----+-----+</TT>
 <TT> |
|</TT>
 <TT> a
wave1</TT>
 <TT> |
|</TT>
 <TT> +---+---+
|</TT>
 <TT> | |
|</TT>
 <TT>amod bmod
innerwave</TT>
 <TT> | |</TT>
 <TT>keep keep</TT>
 
 Figure 12-1 - Hierarchy in a model

<TT>wave
wave.a.bmod</TT>
 <TT>wave.stim1
wave.a.bmod.in</TT>
 <TT>wave.stim2
wave.a.bmod.keep</TT>
 <TT>wave.stim1
wave.a.bmod.keep.hold</TT>
 <TT>wave.a.stim1
wave.wave1</TT>
 <TT>wave.a.stim2
wave.wave1.innerwave</TT>
 <TT>wave.a.amod
wave.wave1.innerwave.hold</TT>
 <TT>wave.a.amod.in</TT>
 <TT>wave.a.amod.keep</TT>
 <TT>wave.a.amod.keep.hold</TT>
 
 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.
 
 <TT> begin</TT>
 <TT> fork: mod_1</TT>
 <TT> reg x;</TT>
 <TT> mod_2.x = 1;</TT>
 <TT> join</TT>
 <TT> </TT>
 <TT> fork: mod_2</TT>
 <TT> reg x;</TT>
 <TT> mod_1.x = 0;</TT>
 <TT> join</TT>
 <TT> end</TT>
 
 
<H3>
12.4.1 Upwards name referencing</H3>

 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 referen
 ce is given in Syntax 12-5.
 
 <TT>upward_name_reference ::=</TT>
 <TT> module_identifier.item_name</TT>
 <TT>item_name ::=</TT>
 <TT> port_identifier</TT>
 <TT> | reg_identifier</TT>
 <TT> | net_identifier</TT>
 <TT> | parameter_identifier</TT>
 <TT> | function_identifier</TT>
 <TT> | task_identifier</TT>
 <TT> | named_block_identifier</TT>
 
 Syntax 12-5 - Syntax for upward name referencing

Upwards name references can also be done with names of the form
 
 <TT> module_instance_name.item_name</TT>
 
 A name of this form shall be resolved as follows:
 a) Look in the current module for a module instance named
<TT>module_instance_name</TT>. 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 <TT>module_instance_name</TT>.
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 separators composed of white space and a period-character}
.

Example:
 
 In this example, there are four modules, <TT>a</TT>, <TT>b</TT>, <TT>c</TT>,
and <TT>d</TT>. Each module contains an integer <TT>i</TT>. The highest-level
modules in this segment of a model hierarchy are <TT>a</TT> and <TT>d</TT>.
There are two copies of module <TT>b</TT> because module a
and <TT>d</TT> instantiate <TT>b</TT>. There are four copies of <TT>c.i</TT>
because each of the two copies of <TT>b</TT> instantiates <TT>c</TT> twice.
 
 {The name of a module or module 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 its 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,
except for escaped identifiers embedded in the hierarchical name 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. }
 
 
 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 a vailable 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.
 
 <TT> task t;</TT>
 <TT> reg r, s;</TT>
 <TT> begin: b</TT>
 <TT> // redundant assignments
to reg r</TT>
 <TT> t.b.r = 0; //
poorly defined but found by upward search</TT>
 <TT> t.<STRIKE>s</STRIKE>{r}
= 0; // fully defined downward reference</TT>
 <TT> end</TT>
 <TT> endtask </TT>
 
</BODY>
</HTML>
</x-html>

Next message: Eli Sternheim: "Re: BE18 19981030"
Previous message: Adam Krolnik: "Re: Proposal Two for ANSI style port declarations"
Next in thread: Eli Sternheim: "Re: BE18 19981030"
Maybe reply: Eli Sternheim: "Re: BE18 19981030"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

This archive was generated by hypermail 2.1.4 : Mon Jul 08 2002 - 12:53:01 PDT and
sponsored by Boyd Technology, Inc.