Fixed some doc issues, added doc for hierarchical compare.

This commit is contained in:
Matthias Koefferlein 2019-08-26 18:55:35 +02:00
parent db9ea27324
commit 3a12714593
3 changed files with 52 additions and 4 deletions

View File

@ -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."
) +

View File

@ -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."

View File

@ -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>