From: Gordon Vreugdenhil (gvreugde@synopsys.com)
Date: Thu Jun 20 2002 - 10:14:19 PDT
Precedence: bulk
Clarification of what constitutes a "top module"
The LRM (12.1.1) defines a top module as one that is not
instantiated. In the face of "generate" that becomes
a very difficult problem. Consider the following:
module top;
parameter P = 2;
generate
if(!P) child c();
endgenerate
initial $display(P);
endmodule
module child;
defparam top.P = 0;
endmodule
If child is instantiated as top.c it illegally contains an
upwards defparam within a generate. If it isn't instantiated
we must consider its defparam since child is a top module and
we must apply the defparam to top. This is an irresolvable
dependency loop.
One possible resolution is to change the definition of a
top module to be a module that has no instantiation statement.
Implications:
module top;
generate
if(0)
top topInst();
endgenerate
endmodule
This becomes an empty design since it has no top module. If
one wants to instantiate such a module, one must create an
unconditional top module that does so.
Discussion:
There are alternative solutions. One alternative is to
create three class of modules: "known top", "known non-top",
and "unknown". The "known top" modules are ones with no
possible instantiations, the "known non-top" modules are ones
with at least one instantiation outside of a generate block,
and the "unknown" modules are the remainder. One then elaborates
based on the "known top" modules. That initial elaboration
may move some modules from "unknown" into either "known top"
or "known non-top". If there are any additional "known top"
modules, elaborate them. Finally, we may end up with having
some "unknown" modules and no additional "known top" modules
(ie. we have a clique of modules that form a generate-dependency
loop). The most trivial such case is the example above. We would
then pick the textually first module and make it a top module
and continue elaboration.
The benefit of the proposed solution is in clarity -- it is
much more clear to both the implementor and to the designer.
Arguing about the correctness of design elaboration in the
face of iterative determinations of "top module" candidacy
adds a significant degree of complexity. Given the very low
design cost (an additional unconditional instantiation),
it seems beneficial to define top modules in the form that
is proposed.
This problem is likely to also be an issue in terms of the
definition of an implicit instantiation in SystemVerilog.
Adopting the same approach makes it clear that in cases such
as the given example, the $root module would need to contain
an explicit instantiation statement.
Gord.
-- ---------------------------------------------------------------------- Gord Vreugdenhil gvreugde@synopsys.com Staff Engineer, VCS (Verification Tech. Group) (503) 547-6054 Synopsys Inc., Beaverton OR
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:37 PDT
and
sponsored by Boyd Technology, Inc.