diff --git a/src/db/db/gsiDeclDbCell.cc b/src/db/db/gsiDeclDbCell.cc
index a68571bfe..fa1031472 100644
--- a/src/db/db/gsiDeclDbCell.cc
+++ b/src/db/db/gsiDeclDbCell.cc
@@ -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."
   ) +
diff --git a/src/gsi/gsi/gsiDeclTl.cc b/src/gsi/gsi/gsiDeclTl.cc
index 2874f388f..9243cbcfb 100644
--- a/src/gsi/gsi/gsiDeclTl.cc
+++ b/src/gsi/gsi/gsiDeclTl.cc
@@ -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."
diff --git a/src/lay/lay/doc/manual/lvs_compare.xml b/src/lay/lay/doc/manual/lvs_compare.xml
index 1908fd2a1..72e60825e 100644
--- a/src/lay/lay/doc/manual/lvs_compare.xml
+++ b/src/lay/lay/doc/manual/lvs_compare.xml
@@ -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>