ISSUE 113

Number 113
Category errata
Synopsis interaction of generate and scope definitions
State lrmdraft
Class errata-discuss
Arrival-DateSep 10 2002
Originator Gordon Vreugdenhil <gvreugde@synopsys.com>
Release 2001b: 12.1.3
Environment
I have added a PTF item #296 to deal with VPI changes that
are needed to support generate statements
Description
This is a multi-part message in MIME format.
--------------38C733949F21E69335609DE1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


--------------38C733949F21E69335609DE1
Content-Type: text/plain; charset=us-ascii;
name="generate_scope.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="generate_scope.txt"


Errata request

Topic: generate scopes
Complexity: high


The following is intended to capture a running discussion from a few
months ago and to summarize my thoughts on the problems involved in
dealing with scoping issues that arise in the context of generates.
This is not trivial and I apologize for both the length and
complexity. I would certainly welcome any other simpler proposal
that covers all the cases in an unambiguous manner. There are a
bunch of examples after the proposals that demonstrate the effect
of my proposals.


I think that the overall intent of scoping is that you unroll the
design and the resulting hierarchical names define the scope into
which the names should have been elaborated. Unfortunately, capturing
that intent in the LRM is somewhat convoluted and brings up some edge
cases that are discussed later. There is also impact on pli access to
generated declarations and instances in the sense that in order to
fulfill the intent, there is now a new type of scope that must be
discussed.


PART I (true errata, easy)

Proposal:

Sect 12.1.3, par. 5:

... Generated variable declarations and instantiations can be multiply
instantiated into a design. Generated instances have unique identifier
names and can be referenced hierarchically as described in 12.4.

should read:

... Generated variable declarations and instantiations can be multiply
instantiated into a design. Generated VARIABLE DECLARATIONS AND
instances have unique identifier names and can be referenced
hierarchically as described in 12.4.

(differences in all caps)



PART II

Proposal:

Change Sect 12.6, par 1 from:

The following four elements define a new scope in Verilog:
Modules
Tasks
Functions
Named blocks

to:

The following FIVE elements define a new ELABORATED scope in Verilog:
Modules
Tasks
Functions
Named blocks
GENERATED NAMED BLOCKS

AN ELABORATED SCOPE IS A SCOPE THAT REMAINS IN THE DESIGN FOLLOWING
ELABORATION OF ALL GENERATE BLOCKS. NOTE THAT ALTHOUGH ALL GENERATE
BLOCKS ARE SCOPES PRIOR TO ELABORATION, ONLY NAMED GENERATE BLOCKS
REMAIN FOLLOWING ELABORATION.


Comment/Impact:


The remainder of 12.6 can probably be left alone.

The fundamental issue is that we need to have a "generated named
block" become a real object in the LRM (similar to a named block). I
don't think we can/should just reuse "named block" since that is
fundamentally a sequential construct and allowing a named block to
contain non-sequential constructs (continuous assigns, instantiations,
etc) for the purpose of generate is asking for confusion.

This change is required in order to give the pli a "hook" into the LRM
to be able to describe iteration across a module where you can
actually get a "generated named block" that contains non-sequential
constructs.



PART III

Comment: relies on PART II above

Proposal:

Add the following to the end of 12.1.3 or, alternatively,
add a new section 12.1.3.5 entitled "Scope of elaborated names"
containing the text:

----
The resolution of references to named generated items (such as
variables, nets, instantiations, etc) requires one to distinguish
between an "unelaborated scope" and an "elaborated scope".
An "elaborated scope" is a scope in the design that results after
the processing of all generate blocks. An "unelaborated scope"
is a unnamed scope that is treated as a scope only prior to the
elaboration of the scope. We call the set of scopes prior
elaboration the "pre-elaboration scopes" and the set of elaborated
scopes the "post-elaboration scopes".

Unnamed generate blocks always introduce unelaborated scopes into
the design while named generate blocks introduce elaborated scopes
into the design. All name references that resolve to genvars in the
pre-elaboration scopes are replaced by the value of the genvar at
the time that the reference is elaborated. All name references in
expressions evaluated during elaboration are resolved in the
pre-elaboration scopes. All other names are resolved in the post-
elaboration scopes following the normal Verilog rules as described
in 12.6.

All elaborated instantiations, declarations, etc. are elaborated into
the nearest enclosing elaborated named scope. This scope will either
be a generated named block or a module. Genvar declarations are never
members of an elaborated named scope. In essence this means that one
must consider the pre-elaborated scope and elaborated scope of a named
generate block or module as being distinct with the process of
elaboration populating the elaborated scope from the pre-elaborated
scopes.

------

Examples:

module m;
reg x;
genvar x;
endmodule

Conflicts since both names appear in the same pre-elaborated scope.

----

module m;
reg x;
generate
genvar x;
endgenerate
endmodule

No conflict since "genvar x" does not appear in the elaborated
scope of "m". The elaborated design is:

module m;
reg x;
endmodule

----

module m;
reg x;
generate
if (0) wire x;
endgenerate
endmodule

No conflict since the "wire x" declaration is not elaborated.

----

module m;
reg x;
generate
if (1) wire x;
endgenerate
endmodule

Conflicts *during elaboration* since the elaborated design is:

module m;
reg x;
wire x;
endmodule

----

module m;
reg x;
generate
begin: b
if (1) wire x;
end
endgenerate
endmodule

No conflict since the elaborated design is:

module m;
reg x;

begin: b // this is a generated named block
wire x;
end
endmodule

Note that this is a *representation* of the elaborated design
only and is *not* valid Verilog.

----

module m;
generate
begin
wire w1;
end
begin
assign w1 = 1;
end
endgenerate
endmodule

Valid. The elaborated design is:

module m;
wire w1;
assign w1 = 1;
endmodule

----

module m;
generate
begin:b
wire w1;
end
begin
assign w1 = 1;
end
endgenerate
endmodule

The elaborated design is:

module m;
begin: b
wire w1;
end

// wire w1 -- implicit declaration
assign w1 = 1;
endmodule

The wire declaration is not visible in to the continuous
assign since it belongs to a different elaborated scope. Thus
the continuous assign will create an implicit net "w1" in
module m.

----

module x;
reg y;
generate
reg bit;
genvar i;
for (i = 0; i < 10; i = i + 10) begin: bit
end
endgenerate
endmodule

Conflicts. The named block "bit" conflicts with the "reg bit"
declaration in the pre-elaborated scope.

----

module x;
reg y;
generate
genvar i;
for (i = 0; i < 10; i = i + 10) begin: bit
end
endgenerate

generate
genvar i;
for (i = 0; i < 10; i = i + 10) begin: bit
end
endgenerate
endmodule


Conflicts at elaboration time since there are duplicate
names in module x for the elaborated named scopes: bit[0],
bit[1], ...

----


module x;
reg y;
wire bit;
generate
genvar i;
for (i = 0; i < 5; i = i + 10) begin: bit
end
endgenerate

generate
genvar i;
for (i = 5; i < 10; i = i + 10) begin: bit
end
endgenerate
endmodule


No conflicts since each elaborated scope name is unique.
Note that this differs from an "arrayed instance" in
that the entire name including the index portion is
considered to be part of the name rather than just the
base name.

----
generate
genvar i;
for (i = 0; i < P; i = i + 1) : begin b1

reg x = i;

genvar i;
for (i = 0; i < 10; i = i + 1) : begin b2
....
end
end
endgenerate


No conflicts. The "i" referred to in the "reg x"
initialization is the outer "i". Requires "P" to be
a parameter of the module.

The only other option that I can see would be to disallow a
redeclaration of a genvar within any scope contained by the block
in which the original declaration occurs. That could really cause
problems for people that `include parts of their design.


----

module some_module;
wire x;
endmodule

module m;
generate
if (condition)
some_module M;

assign M.x = 1;
endgenerate
endmodule

The resolution of M.x occurs in the post-elaboration scopes.
If "condition" is true, M.x will be resolved downwards into
"some_module M". If "condition" is false, M.x will be resolved
upwards using normal upwards resolution rules.


----

module some_module;
parameter x = 5;
endmodule

module m;
generate
if (condition)
some_module M;

defparam M.x = 1;
endgenerate
endmodule

If "condition" is true, the defparam is a downwards defparam
into M and is valid. If "condition" is false, the defparam
is upwards across a generate and is illegal.


--------------38C733949F21E69335609DE1--

Fix
We did not get this officially into the database:

The proposal can be found at

http://boydtechinc.com/etf/archive/etf_2004/2566.html
Audit-Trail
From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.com
Cc:
Subject: re: errata/113: generate
Date: Tue, 20 May 2003 14:28:47 +0300

I resend Gord's 'progress report' to get it into the database:

There are numerous issues that the Verilog2001 ETF sub-group
on "generate" has been dealing with. The following is a
summary of a few of the main ideas that the committee is
working on formalizing. Any additional input to the process
would be appreciated since we would like to end up with
a broadly acceptable and consistent interpretation.

Some of the issues in the current LRM are related to the
fact that there isn't really a well-described model for
the post-elaboration design and how the pre-elaboration
structures map to the final elaborated design. This is
particularly evident in the fact that there is no defined
mechanism in VPI to access "generated" structures. The
generate sub-group is working with the PLI group to resolve
all issues simultaneously so that we end up with a consistent
model.

The current members of the sub-group are:
Gord Vreugdenhil (Synopsys)
Steven Sharp (Cadence)
Dennis Marsa (Xilinx)
Shalom Bresticker (Motorola)

with the following also tracking the discussion:
Michael McNamara (Verisity)
Charles Dawson (Cadence)


Please note that the description and proposals that follow
are preliminary and subject to change. There is still
ongoing discussion within the sub-group about various
aspects but due to the nature of the proposals, a wider
discussion was deemed to be valuable.

--------------------

One important issue to be aware of when understanding generate,
is that generate constructs cannot be considered as compile
time only preprocessing of the design. The handling of
generate constructs is an elaboration time activity due
to the interactions between defparam statements, parameter
resolution, and name resolution.


1) Elaboration sequencing and hierarchical name resolution

In the presence of conditionally generated identifiers,
it is possible for implementations to incorrectly resolve
hierarchical names. The main issue, particularly for
defparams, is that there may be an upwards resolution of
a hierarchical name and a *possible* downwards resolution
depending on elaboration. The elaboration sequencing
must commit to either an upwards or downwards resolution
without knowing whether the resolution will be correct.

Example:

module top;
Mid m();
endmodule;

module Mid();
parameter p = 2;

defparam m.p = 1;

generate
if (p == 1)
Mid2 m();
endgenerate
endmodule

module Mid2();
parameter p = 1;
endmodule

In such a case, the name "m.p" might resolve downwards but
there is also an upwards resolution possible. In this case,
committing to the upwards resolution would lead to the
elaboration of top.m.m in which case the resolution is
incorrect since the LRM requires downwards resolution in
such cases. However, committing to the possible downwards
resolution is also incorrect since top.m.m would not exist
without the upwards resolution.

Although the above case is constructed to expose the worst
possible situation, upwards/downwards resolution choices
can exist in real designs.

The sub-group's current position on this is that non-defparam
hierarchical names must be resolved in the post-elaboration
context. defparam hierarchical names are to be resolved in
as early as possible -- as soon as a possible resolution
exists during elaboration, one must choose that resolution.
Then, following elaboration, each defparam hierarchical
name must be checked to see if the elaboration time selected
resolution is consistent with the post-elaboration design.
If the resolution in the post-elaboration design is different,
the implementation must report an error and the design is
considered to be erroneous.

The requirement to report an error is not definite yet; the
sub-group is still considering that issue.


--------------------

2) Data model and syntax for generate for statements

The data model and interaction of "genvar" declarations
and generate-for loops is not very clean in the current LRM,
both in terms of any possible VPI model and name resolution
and scoping issues.

A reasonable way to resolve the issues is to take two
steps:
a) a closer relationship between "genvar" and the
generate-for loop
b) a better model for generated blocks in the post-elaboration
design


For (a), the sub-group is recommending the that generate-for
loops have the following general form:

for (localparam i = 0; i < 10; i = i + 1) begin : b
end

The "localparam" would (likely) be optional. The post-elaboration
model is closer to the VHDL model -- the name "i" is introduced
as a localparam declaration within each instance of block
"b" with the value of the localparam being the iteration value.
There would be no restriction on the value (negatives would
be permitted) other than requiring that index values be unique.

The group had discussed retaining "genvar" in place of
"localparam" in the syntax, but since "localparam" expresses
exactly the desired semantics, there didn't seem to be any
value in keeping the keyword "genvar", particularly since
that keyword would conflict with its use in the Verilog-AMS
standard.

For backwards compatibility, the group is currently recommending
that the current form of genvar declarations remain legal
(deprecated) syntax but that such declarations be completely
ignored. Making the "localparam" optional then ensures that
virtually any currently legal design would remain legal.

The advantage of this model is that it is easier to explain,
reduces issues in terms of detemining the validity of
hierarchical references to genvar declarations, and eliminates
potentially strange name resolution issues.

Examples:
generate
genvar i;
for (i = 0; i < 5; i = i + 1) begin:b
reg i;
end
endgenerate

In the current LRM, such an example would likely be legal although
opinions in the sub-group vary on that. Even more strange would
be:
for (i = 0; i < 5; i = i + 1) begin:b
reg i = i;
end
which could use the "genvar" value of i for the RHS.

Both examples would be illegal in the new form since the
for-loop iterator "i" becomes an implicit declaration
with block "b".


For part (b), the VPI data model, the group is recommending
that we adopt a "sparse instance array" model for named blocks
generated by a generate-for loop. The idea is that the base
name of the block ("b" in the above case) becomes the name
of an array of scopes. One would then iterate over the
scopes and could ask for the indexExpr of each block. This
model also resolves numerous issues that arise in terms of the
current LRM's description of names such as "b[0]" as a special
kind of identifier rather than an indexed scope. Instance
arrays and indexed scopes are then essentially symmetric in
the LRM other than the requirement that in VPI one must iterate
to find the index expressions of a scopes in a generated
scope array.

--------------------

3) Scoping and conditional names

This issue is one that is still undergoing consideration
in the committee. It is partly driven by efficiency concerns,
particularly once future language extensions (SystemVerilog
constructs in particular) come into play. The issue is whether
to disallow named object declarations within an unnamed
generated block. This is a harder issue to have a strong
rationale for other than the fact that implementors across
a number of companies and product lines agree that not naming
the blocks makes things more difficult and irregular in
terms of implementing generate.



Consider the following:
generate
if (c)
wire x;
else
reg x;
endgenerate

initial $monitor(x);

It is not possible to bind "x" to a definition until elaboration
time. Conceptually, if one thinks of "x" as a prefix-free
hierarchical name, then the rules presented in issue (1)
apply and everything falls out.

The concern is that we now have to treat *every* simple
identifier that doesn't have a binding in the immediate scope
as a hierarchical name and defer its resolution. In
SystemVerilog, simple identifiers can bind to "$root" names
which means that such binding issues may happen significantly
more often and impact performance.

The proposal is to require named blocks for conditionally
instantiated names. There are a couple of options the group
is considering:

a) require a named block on each branch of a conditional
generate statement (case or if). The names could be
duplicated as long as only one was elaborated.

if (c) begin:b
wire x;
end
else begin:b
reg x;
end

b) introduce new syntax to "label" the statment.

if:b (c)
wire x;
else
reg x;


Requiring scope names for declarations ensures that all such
name references end up being hierarchical references and you
only end up "paying" for conditional binding when necessary.





--------------------

4) Minor clarifications and Interpretations

a) Recursive instantiations are permitted

b) A "top module" is a module that **does not have an
instantiation statement** versus a module that is
not instantiated. The latter (current LRM wording)
leads to contradictions. The new definition does imply
that, in absence of configurations, etc, that a design
that consists solely of a recursive module (or recursive
clique) would not have a top module and would thus be
invalid.

c) Name conflicts within the same immediate scope
cause errors even if the scope is not elaborated

ie: if (0) begin
reg x;
reg x;
end

d) Two generate-for constructs are not permitted to have
same named block identifier even if their generate index
values are distinct.

e) The sub-group is also considering whether to make the
generate and endgenerate keywords optional (or to remove
them) since they provide no semantic meaning or scoping.

From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: Karen Pieper <Karen.Pieper@synopsys.com>
Cc: etf-bugs@boyd.com
Subject: errata/113: Interaction of generate and scope definitions
Date: Thu, 18 Mar 2004 12:49:08 +0200

I approve, with the following comments:

- In 12.4.1, Example 2, on the line

assign bin[i] = ^gray[SIZE-1:i];

there was supposed to be a comment as follows:

// i refers to the implicitly defined localparam whose value in each instance
// of the generate block is the value of the genvar when it was elaborated.


- (Mar 12, Sharp): On page 12 of the new text pdf (section 12.4.2), it says that
the name of the gate is test.u1.x1, when it is actually test.u1.g1. This was fixed in
the Generates_draft61.pdf document, but not in 1364-2005_generate_new31.pdf


The following are issues to be discussed in the future:

- (Mar 11, Gord):
1) the concept of external name in 12.4.3 doesn't seem
complete enough. If a declaration does not have a
hierarchical name but instead just an implicit external
name, is the external name the one to be used in a
VCD dump? What about a pli by-name lookup? Does
a $display with %m in an unnamed block produce the
implicit name? I think that it would be valuable
to explicitly define the interactions/requirements
with respect to other aspects of the LRM.

2) 13.1 clarifies (by implication) that a configuration
cannot create a design root from a module that would
not otherwise be a "top module". I disagree with this.
If a self recursive model is *defined to be* a design root
by a configuration, we should respect that. Forcing
a user to create an additional level of hierarchy for
the purpose of using a configuration does not make sense
to me. The restriction on the *automatic determination*
of top modules is absolutely necessary, but in the
context of configurations we shouldn't try to second
guess the designer.

3) 10.3.5 removes generated functions from the list of
constant functions. I don't understand the rationale
for this. Since the visibility rules and locality
rules guarantee that a function would be elaborated before
any possible use as a constant function, I don't see
why this is restricted and parameter dependent functions
are not.

- Need to finish and add 12.8 Elaboration.

- Defparam restrictions, two kinds, explanation too complex (Sharp, Feb 17; Shalom, Feb 1).
How can user decide whether defparam is legal or not? Update the 1st para. in 12.2.1.

- Add more examples

- (Params in constant functions (Sharp, Feb 3))

- xref in 10.3.5 should be to 12.8 after 12.8 is added.

- Should there be attributes within genvar_expression? See its BNF.

Shalom


> > As we discussed in today's ETF meeting, we are now holding an email vote for the proposal
> >in the attached Generates_draft6.pdf document. Voting will close in a week and a half on Friday
> >March 19 at 3:00 PM PST. We need 7 affirmative votes for the proposal to pass via email voting,
> >so please vote.
> >
> >__ I approve the passage of the proposal in the attached file Generates_draft6.pdf
> >__ I abstain on the vote for Generates_draft6.pdf
> >__ I oppose the passage of the proposal in the attached file Generates_draft6.pdf

From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.com
Cc:
Subject: errata/113: generate
Date: Mon, 29 Mar 2004 18:55:08 +0200

In the generate proposal, Example 5 at the end of 12.4.1 contains a generate-if,

which is discussed only in 12.4.2.

From: Shalom.Bresticker@freescale.com
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/113: generate
Date: Wed, 5 May 2004 14:48:12 +0300 (IDT)

The following are the edits I am making to the generate proposal,
based on the April 5 ETF mmeting minutes, as follows:

> From the email vote on the generate proposal:
> The generate proposal passed. Shalom had comments. Stu
> opposed on the basis of more discussion required.
>
> Steven moves that we ammend the passed generate proposal in the
> following way:
> In the new proposal:
>
> - In 12.4.1, Example 2, on the line
>
> assign bin[i] = ^gray[SIZE-1:i];
>
> add a comment as follows:
>
> // i refers to the implicitly defined localparam whose value in each instance
> // of the generate block is the value of the genvar when it was elaborated.

Done.


> - On page 12 of the new text pdf (section 12.4.2), change
> the name of the gate from test.u1.x1, to test.u1.g1.


Done.


> Charles seconds. No opposed. No abstain. Passes.

> Cliff's concerns:
> 12.4.1:
> Make the example 1 more complete by wrapping a module
> declarations and genvar i declarations around them,
> so it isn't code snippets any more. 3 modules.
>
> Add a comment that generate..endgenerate is no longer
> required.

OK.


> Page 12:
> Should the example have a number? The committee
> agrees it should. Also add comments, as indicated in
> Cliff's attached document:
>
> http://boydtechinc.com/etf/archive/att-2437/02_Example_12_4_2_formatted.pdf

This will be Example 6. The example numbers of the examples following this one
in 12.4 will be incremented by 1.

I will change the instance comments to something like:

if (q == 0) begin : u1 // if p is 1 and q is 0 then instantiate an and
and g1 (a, b, c); // gate with hierarchical instance name test.u1.g1


> Page 15:
> Add an example number... And update formatting
> according to Cliff's attached document:
>
> http://boydtechinc.com/etf/archive/att-2437/03_Example_12_4_3_formatted.pdf
> The comment about genblk3 is incorrect because genblk3
> is named.
>
> Francoise will modify the example in 12_4_3 to have
> it more accurately reflect what was intended.

This will be Example 10.
I will use Francoise's revised version.


> Page 16: "Each such" seems awkward...

No change.


> "refer instance arrays" should be "refer to instance
> arrays"

OK.


> Page 19: The scope searching algorithm needs to be
> rewritten.
> Steven took the action item to do that.

No change. Issue #570.


> Page 20: A little indentation would help the
> examples.

Instead of indentation, I will add some blank lines, e.g,

module a;
integer i;

b a_b1();

endmodule


> Page 21: Reword sentence starting "If an identifier
> is referenced directly"
> Steven took the action item to do that.

No change. Issue #570.

>
> 12.7 Consider changing example spacing.

As discussed in issue #334, the example needs to be rewritten.
The text refers to an "incompletely defined downward reference",
but there is no downward reference, and the term "incompletely
defined" is itself not defined. If you are looking at the version
with a comment about redundant assignments, that is also incorrect.
The t.b.r reference is illegal and t.s is not a downward reference.
So I intend to simply delete the example until someone suggests
something better. As I said, this is issue #334 in the databse, so it
should not be forgotten.


> Given the number of changes recommended above, the committee
> agreed to update the document with the changes passed and
> discussed today. We should also vote on the amended document.
>
> The amendments that need to happen are:
>
> 1) The two typos Shalom had indicated that we passed this
> meeting.

Done.


> 2) Address Cliff's issues
> a) the first example in 12.4.1
>
> b) update the example on page 12 with Cliff's update
>
> c) use Francoise's update to the example in 12.4.3
>
> d) address "refer instance arrays" typo

a to d: OK


> e) Add Steven's rewrite on page 19
>
> f) Add Steven's rewrite on page 21

e,f: No change.


Other changes I am making:

P. 1: In 3.10.1, change cross-reference from 12.4 to 12.4.1.

Some font and upper vs. lower case corrections.

Shalom

From: Shalom.Bresticker@freescale.com
To: Gordon Vreugdenhil <gvreugde@comcast.net>
Cc: etf-bugs@boyd.com
Subject: Re: errata/113: BInterpretation -- external names of directly nested
generate constructs
Date: Fri, 7 May 2004 09:35:38 +0300 (IDT)

On Thu, 6 May 2004, Gordon Vreugdenhil wrote:

> Section 12.4.2 says:
> The generate blocks of the directly nested construct are
> treated as if they belong to the outer construct, and
> therefore can have the same name as the generate blocks
> of the outer construct.
>
> Given that, do all the alternatives in the following
> have the same implicit external name?

Undoubtedly yes, in my opinion.

> module top;
> parameter p = 7;
>
> if (p == 1) // genblk1
> reg a;
> else if (p == 2) // genblk1 or genblk2 ???
> wire a;
> else // same name as the "p == 2" scope
> integer a;
>
> endmodule
>
> I think that it makes sense to say that all parts of a
> directly nested conditional construct are treated as a
> single generate construct for the purposes of assigning
> genblk numbers. It might be worthwhile to add an explicit
> statement like this to the LRM.

Do you have a specific suggestion?

Shalom

From: Shalom.Bresticker@freescale.com
To: Jason Woolf <jasonw@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/113: revised generate proposal
Date: Thu, 8 Jul 2004 17:19:51 +0300 (IDT)

Hi, Jason,

I think I need a minor edit of the generate document.

While working on the proposal for issue #17, which uses the term
"generate scope" in a forward reference, and I wanted to add a
cross-reference to its definition, I found that it does not seem to be
explicitly defined.

The term is also used in the new 12.4 a number of times. Although when I
reviewed it, I know I found and understand its meaning, I think it would
be good to add a sentence which explicitly defines it, of the sort,
"A generate scope is ...".

Can you do that?

Thanks,
Shalom

--
Shalom Bresticker Shalom.Bresticker @freescale.com
Design & Reuse Methodology Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

[ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary


From: Jason Woolf <jasonw@cadence.com>
To: Shalom.Bresticker@freescale.com
Cc: etf-bugs@boyd.com
Subject: Re: errata/113: revised generate proposal
Date: Thu, 8 Jul 2004 12:23:38 -0400 (EDT)

Shalom,

My initial document did not use that term. I suspect this is because the
LRM does not define a similar term for module scopes. Since there are only
a couple of places with "generate scope" has been used, perhaps the best
way to go is to replace each use of "generate scope" with a term that is
more consistent with pre-existing language.

For example, in section 10.3.5, where it now says,

-- They shall not be declared inside a generate scope.

we could use "generate block" instead. In the text following Example 4 in
section 12.4.1, where it now says,

... These generate scope names can be used in hierarchical path names

we could remove "generate scope" from this sentence without diminishing the
meaning of the sentence. Or replace it with "indexed".

Can you do something similar with issue #17?

-Jason



> From: Shalom.Bresticker@freescale.com
> Date: Thu, 8 Jul 2004 17:19:51 +0300 (IDT)
> To: Jason Woolf <jasonw@cadence.com>
> cc: etf-bugs@boyd.com
> Subject: Re: errata/113: revised generate proposal
>
> Hi, Jason,
>
> I think I need a minor edit of the generate document.
>
> While working on the proposal for issue #17, which uses the term
> "generate scope" in a forward reference, and I wanted to add a
> cross-reference to its definition, I found that it does not seem to be
> explicitly defined.
>
> The term is also used in the new 12.4 a number of times. Although when I
> reviewed it, I know I found and understand its meaning, I think it would
> be good to add a sentence which explicitly defines it, of the sort,
> "A generate scope is ...".
>
> Can you do that?
>
> Thanks,
> Shalom
>
> --
> Shalom Bresticker Shalom.Bresticker @freescale.com
> Design & Reuse Methodology Tel: +972 9 9522268
> Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
> POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478
>
> [ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary
>
>

From: Shalom.Bresticker@freescale.com
To: Jason Woolf <jasonw@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/113: revised generate proposal
Date: Mon, 26 Jul 2004 11:24:04 +0300 (IDT)

Jason,

I agree.

The use of "generate scope" in the original LRM was more in the sense of
"lexical scope", i.e., the statements enclosed by the generate-endgenerate
keywords, but that is not what we mean here.

We now use "generate block" or "generate construct" or "generate region",
as appropriate, for that usage, if necessary.

So let me suggest the following changes to 113:

1. In 10.3.5, CHANGE

"-- They shall not be declared inside a generate scope."

TO

"-- They shall not be declared inside a generate block (see 12.4)."


2. In 12.4.1, in the text after Example 4, CHANGE

"These generate scope names can be used in hierarchical path names"

TO


"These names can be used in hierarchical path names"

OR

"These generate block instance names can be used in hierarchical path names"


3. In 12.4.3, Example 10, CHANGE

"The following generate scope", wherever it occurs

TO

"The following generate block"

(A quibble with this is that these comments are followed by code such as

if (genblk2) reg a; // top.genblk1.a
else reg b; // top.genblk1.b

which is really one generate construct with two alternate generate blocks.)


Also, CHANGE

// Note that the previous generate construct would have been
// named genblk3 if it had not been explicitly named g1

TO

// Note that the previous generate block would have been
// named genblk3 if it had not been explicitly named g1


Also, CHANGE

// The following generate scope is implicitly named genblk1
// as the first nested scope of genblk4

TO

// The following generate block is implicitly named genblk1
// as the first nested generate block in genblk4


OK, now I'll get back to 17.

Shalom



On Thu, 8 Jul 2004, Jason Woolf wrote:

> My initial document did not use that term. I suspect this is because the
> LRM does not define a similar term for module scopes. Since there are only
> a couple of places with "generate scope" has been used, perhaps the best
> way to go is to replace each use of "generate scope" with a term that is
> more consistent with pre-existing language.
>
> For example, in section 10.3.5, where it now says,
>
> -- They shall not be declared inside a generate scope.
>
> we could use "generate block" instead. In the text following Example 4 in
> section 12.4.1, where it now says,
>
> ... These generate scope names can be used in hierarchical path names
>
> we could remove "generate scope" from this sentence without diminishing the
> meaning of the sentence. Or replace it with "indexed".
>
> Can you do something similar with issue #17?
>
> -Jason
>
> > From: Shalom.Bresticker@freescale.com
> > Date: Thu, 8 Jul 2004 17:19:51 +0300 (IDT)
> >
> > Hi, Jason,
> >
> > I think I need a minor edit of the generate document.
> >
> > While working on the proposal for issue #17, which uses the term
> > "generate scope" in a forward reference, and I wanted to add a
> > cross-reference to its definition, I found that it does not seem to be
> > explicitly defined.
> >
> > The term is also used in the new 12.4 a number of times. Although when I
> > reviewed it, I know I found and understand its meaning, I think it would
> > be good to add a sentence which explicitly defines it, of the sort,
> > "A generate scope is ...".
> >
> > Can you do that?

From: Shalom Bresticker <Shalom.Bresticker@freescale.com>
To: etf-bugs@boyd.com
Cc:
Subject: re: errata/113: generate
Date: Mon, 06 Sep 2004 15:36:22 +0300

In finally putting the generate fix into the next 1364 draft document, I found
an unclear wording:

In 3.5, the approved wording was:

"- If an identifier is used in the terminal list of a primitive instance or a
module instance, and that identifier has not been declared previously in the
scope where the instantiation appears or in any scope whose declarations can be
directly referenced from that scope (see 12.7), then an implicit scalar net of
default net type shall be assumed.

- If an identifier appears on the left-hand side of a continuous assignment
statement, and that identifier has not been declared previously in the scope
where the assignment statement appears or in any scope whose declarations can be
directly referenced from that scope (see 12.7), then an implicit scalar net of
default net type shall be assumed. See 6.1.2 for a discussion of continuous
assignment statements."


I found the phrase "that scope" where the cross-references ambiguous, so
I clarified the wording as follows:

"- If an identifier is used in the terminal list of a primitive instance or a
module instance, and that identifier has not been declared previously in the
scope where the instantiation appears or in any scope whose declarations can be
directly referenced from the scope where the instantiation appears (see 12.7),
then an implicit scalar net of default net type shall be assumed.

- If an identifier appears on the left-hand side of a continuous assignment
statement, and that identifier has not been declared previously in the scope
where the continuous assignment statement appears or in any scope whose
declarations can be directly referenced from the scope where the continuous
assignment statement appears (see 12.7), then an implicit scalar net of default
net type shall be assumed. See 6.1.2 for a discussion of continuous assignment
statements."

Wordier, but clearer.

Please yell if you object.

Thanks,
Shalom

--
Shalom Bresticker Shalom.Bresticker @freescale.com
Design & Reuse Methodology Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

[ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary




Fix replaced by Shalom.Bresticker@freescale.com on Sun Oct 24 01:52:58 2004

We did not get this officially into the database:

The proposal can be found at

http://boydtechinc.com/etf/archive/etf_2004/2566.html

Unformatted


Hosted by Boyd Technology