[doc] some documentation cleanup
Signed-off-by: Scott Johnson <scottdj@google.com>
diff --git a/doc/project/_index.md b/doc/project/_index.md
index 80452af..e466b9e 100644
--- a/doc/project/_index.md
+++ b/doc/project/_index.md
@@ -12,6 +12,7 @@
The current status of different IP is reflected in the [HW Development Stages Dashboard]({{< relref "hw_dashboard" >}}).
The final state for developed IP is *Signed Off*, indicating that design and verification is complete, and the IP should be bug free.
To make it to that stage, a [Hardware Signoff Checklist]({{< relref "checklist.md" >}}) is used to confirm completion.
+[Here](https://github.com/lowRISC/opentitan/blob/master/doc/project/ip_checklist.md.tpl) is a template that can be used as a checklist item.
## Governance
diff --git a/doc/project/hw_stages.md b/doc/project/hw_stages.md
index b887bcf..2ff51a8 100644
--- a/doc/project/hw_stages.md
+++ b/doc/project/hw_stages.md
@@ -43,6 +43,7 @@
Once accepted, it results in creating a new version and return a design to the appropriate life stage, based upon the size of the change.
See the _Versioning_ section of the document for more discussion.
Signed off fully-functioning (read: not buggy) designs stay in the Signoff stage as an available complete IP, with an associated revision ID.
+[Here](https://github.com/lowRISC/opentitan/blob/master/doc/project/ip_checklist.md.tpl) is a template that can be used as a checklist item.
| **Stage** | **Name** | **Definition** |
diff --git a/doc/ug/_index.md b/doc/ug/_index.md
index 825352e..224c268 100644
--- a/doc/ug/_index.md
+++ b/doc/ug/_index.md
@@ -42,9 +42,3 @@
* Reviews
* Filing Issues
* Pending Work Items
-* *Validation Methodology* (TODO)
- * How to download bit stream
- * What tests exist today
- * How to run tests
- * How does this differ from verification
- * How to add tests
diff --git a/doc/ug/design.md b/doc/ug/design.md
index 3ef0e4f..3cf1659 100644
--- a/doc/ug/design.md
+++ b/doc/ug/design.md
@@ -166,3 +166,32 @@
These are discussed in the [Getting Started with a Design]({{< relref "getting_started_design.md" >}}) document.
## FPGA vs Silicon
+
+One output of the OpenTitan project will be silicon instantiations of hardware functionality described in this open source repository.
+The RTL repository defines design functionality at a level satisfactory to prove the hardware and software functionality in an FPGA (see [user guides]({{< relref "doc/ug" >}})).
+That level is so-called "tapeout ready".
+Once the project reaches that milestone, the team will work with a vendor or vendors to ensure a trustworthy, industry-quality, fully functional OpenTitan chip is manufactured.
+
+It is important that any IP that *can* be open *is* open to ensure maximal trustworthiness and transparency of the final devices.
+
+To that end, OpenTitan will define compliance collateral that ensures correctness - that the FPGA and the eventual silicon work the same.
+Due to fundamental economic and technical limitations, there may, and likely will, be differences between these incarnations.
+Some examples include the following:
+
+* Silicon versions by definition use different technologies for fundamental vendor collateral, including memories, analog designs, pads, and standard cells.
+* Some of the silicon collateral is beyond the so-called "foundry boundry" and not available for open sourcing.
+
+Some IP blocks will undergo hardening of designs to protect them against physical attack to meet security and certification requirements.
+Some of this hardening, for instance in fuses, may be of necessity proprietary.
+These changes will not impact the functionality of the design, but are described in processes unique to an ASIC flow vs. the emulated flow of an FPGA.
+
+Even with these differences, the overriding objective is compliance equivalence between the FPGA and silicon versions.
+This may require instantiation-specific differences in the software implementation of the compliance suite.
+
+Consider the embedded flash macro.
+This design is highly dependent upon the silicon technology node.
+In the open source repository, the embedded flash macro is emulated by a model that approximates the timing one would typically find in silicon.
+It lacks the myriad timing knobs and configuration points required to control the final flash block.
+This necessitates that the compliance suite will have initialization sections for flash that differ between FPGA and silicon.
+
+We consider this demonstration of "security equivalence" to be an open, unsolved problem and committed to clearly delimiting any differences in the compliance suite implementation.
