mirror of https://github.com/KLayout/klayout.git
Fixed some doc issues, added doc for hierarchical compare.
This commit is contained in:
parent
db9ea27324
commit
3a12714593
|
|
@ -3960,7 +3960,7 @@ Class<db::Instance> decl_Instance ("db", "Instance",
|
|||
"\n"
|
||||
"If the instance is a PCell instance, this method will convert the cell into a static cell and "
|
||||
"remove the PCell variant if required. A new cell will be created containing the PCell content "
|
||||
"but begin a static cell. If the instance is not a PCell instance, this method will not do anything.\n"
|
||||
"but being a static cell. If the instance is not a PCell instance, this method won't do anything.\n"
|
||||
"\n"
|
||||
"This method has been introduced in version 0.24."
|
||||
) +
|
||||
|
|
|
|||
|
|
@ -681,7 +681,7 @@ static Recipe_Impl *make_recipe (const std::string &name, const std::string &des
|
|||
}
|
||||
|
||||
Class<Recipe_Impl> decl_Recipe_Impl ("tl", "Recipe",
|
||||
gsi::constructor ("new", &make_recipe, gsi::arg ("name"), gsi::arg ("description", std::string ()),
|
||||
gsi::constructor ("new", &make_recipe, gsi::arg ("name"), gsi::arg ("description", std::string (), "\"\""),
|
||||
"@brief Creates a new recipe object with the given name and (optional) description"
|
||||
) +
|
||||
gsi::method ("name", &Recipe_Impl::name,
|
||||
|
|
@ -690,7 +690,7 @@ Class<Recipe_Impl> decl_Recipe_Impl ("tl", "Recipe",
|
|||
gsi::method ("description", &Recipe_Impl::description,
|
||||
"@brief Gets the description of the recipe."
|
||||
) +
|
||||
gsi::method ("make", &Recipe_Impl::make, gsi::arg ("generator"), gsi::arg ("add_params", std::map<std::string, tl::Variant> ()),
|
||||
gsi::method ("make", &Recipe_Impl::make, gsi::arg ("generator"), gsi::arg ("add_params", std::map<std::string, tl::Variant> (), "{}"),
|
||||
"@brief Executes the recipe given by the generator string.\n"
|
||||
"The generator string is the one delivered with \\generator.\n"
|
||||
"Additional parameters can be passed in \"add_params\". They have lower priority than the parameters "
|
||||
|
|
@ -700,7 +700,7 @@ Class<Recipe_Impl> decl_Recipe_Impl ("tl", "Recipe",
|
|||
"@brief Delivers the generator string from the given parameters.\n"
|
||||
"The generator string can be used with \\make to re-run the recipe."
|
||||
) +
|
||||
gsi::callback ("execute", &Recipe_Impl::execute, &Recipe_Impl::execute_cb,
|
||||
gsi::callback ("execute", &Recipe_Impl::execute, &Recipe_Impl::execute_cb, gsi::arg ("params"),
|
||||
"@brief Reimplement this method to provide the functionality of the recipe.\n"
|
||||
"This method is supposed to re-run the recipe with the given parameters and deliver the "
|
||||
"the intended output object."
|
||||
|
|
|
|||
|
|
@ -125,6 +125,54 @@ same_device_classes("NMOS_IN_LAYOUT", "NMOS_IN_SCHEMATIC")</pre>
|
|||
|
||||
<pre>min_caps(1e-16)</pre>
|
||||
|
||||
<h2>Compare and netlist hierarchy</h2>
|
||||
|
||||
<p>
|
||||
Good layouts are built hierarchically and the netlist compare can make use
|
||||
of hierarchy. "Hierarchically" means that a circuit is built from cells
|
||||
which itself map to subcircuits of the schematic netlist. The netlist
|
||||
extractor tries hard to maintain the hierarchy and the netlist compare
|
||||
will utilize the hierarchy to provide more meaningful reports and enable
|
||||
a bottom-up design approach.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Given a hierarchical layout and schematic netlist, the compare algorithm
|
||||
will work bottom-up: it will first compare the leaf circuits (circuits without
|
||||
subcircuit calls) and if those match, it will continue with the calling
|
||||
circuits. This approach is more efficient and fosters a clean relationship
|
||||
between layout and schematic netlist.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To enable hierarchical extraction, you must use "deep" mode (<a href="/about/drc_ref_global.xml#deep">deep</a>).
|
||||
If the deep mode statement is missing, the layout netlist will be flat (i.e. without
|
||||
subcircuits).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The second useful feature is "align" (<a href="/about/lvs_ref_global.xml#align">align</a>).
|
||||
This statement will remove circuits from the layout or schematic netlist which are
|
||||
unknown in the other netlist. Often, layouts contain helper cells which are not
|
||||
corresponding to a circuit (e.g. via cells). These are removed in this step. Eventually,
|
||||
this step will also flatten the schematic netlist if the layout has been extracted
|
||||
in a flat way.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In general, it's a good idea to include "align" before the "compare" step.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A very useful side effect of "align" is this: it will remove circuits above the
|
||||
top level circuit of either side. So it will eventually render a sub-tree from
|
||||
the circuit tree and use that for compare. This enables <b>subcell verification</b>:
|
||||
by selecting a subcell in the layout hierarchy, an "align"-enabled LVS script will
|
||||
compare this cell against the corresponding subcircuit in the schematic netlist.
|
||||
It will ignore the parent hierarchy of this subcircuit. This way, you can work yourself
|
||||
upwards in the hierarchy and fix LVS errors cell by cell with the same schematic netlist.
|
||||
</p>
|
||||
|
||||
<h2>How the compare algorithm works</h2>
|
||||
|
||||
<p>
|
||||
|
|
|
|||
Loading…
Reference in New Issue