- Previous message: Karen Pieper: "ETF meeting today"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
I apparently neglected to send this out to ETF members; my apologies.
The following has gone out to Cliff and to a rep. of MTI for comment.
Any errors, ommissions, etc. are mine.
Gord.
-- ---------------------------------------------------------------------- Gord Vreugdenhil gvreugde@synopsys.com Staff Engineer, VCS (Verification Tech. Group) (503) 547-6054 Synopsys Inc., Beaverton OR
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.
- Next message: Stuart Sutherland: "Amendment to ETF-9"
- Previous message: Karen Pieper: "ETF meeting today"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
This archive was generated by hypermail 2.1.4
: Mon Apr 21 2003 - 08:44:23 PDT
and
sponsored by Boyd Technology, Inc.