47 files changed, 2482 insertions, 709 deletions

diff --git a/docs/README.md b/docs/README.md
index dfc7f934..2a34fc45 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -8,8 +8,7 @@ as part of the PR CI checks,
 forcing the documentation to remain current with the codebase.
 The `src` folder contains the source from which these are generated.
 
-Previous Wiki documentation, now hosted by the website, is contained in the `src/wiki-deprecated` directory.
-We are in the process of converting this documentation into the four categories as described in
+Our documentation is organized into the four categories as described in
 [Divio's documentation system](https://documentation.divio.com/).
 
 The four documentation types are:
@@ -22,9 +21,7 @@ Our documentation strategy for this repository is as follows:
  * Any new public API requires reference documentation.
  * Any new user-facing feature requires explanation documentation.
  * Any bugfixes, corner-cases, or answers to commonly asked questions requires a how-to guide.
- * For now, tutorials are kept in a separate repository. We are working hosting them here.
- * Old documentation is contained in the `src/wiki-deprecated` directory and is being incrementally converted to these
- categories.
+ * Tutorials are kept in a separate repository.
 
 This documentation is hosted on the Chisel [website](https://www.chisel-lang.org).
 
diff --git a/docs/src/appendix/appendix.md b/docs/src/appendix/appendix.md
new file mode 100644
index 00000000..0efedbfe
--- /dev/null
+++ b/docs/src/appendix/appendix.md
@@ -0,0 +1,14 @@
+---
+layout: docs
+title:  "Appendix"
+section: "chisel3"
+---
+
+# Appendix
+
+This section covers some less-common Chisel topics.
+
+* [Differences between Chisel3 and Chisel2](chisel3-vs-chisel2)
+* [Experimental Features](experimental-features)
+* [Upgrading from Scala 2.11](upgrading-from-scala-2-11)
+* [Versioning](versioning)
diff --git a/docs/src/wiki-deprecated/chisel3-vs-chisel2.md b/docs/src/appendix/chisel3-vs-chisel2.md
index bfd20348..cafd29e3 100644
--- a/docs/src/wiki-deprecated/chisel3-vs-chisel2.md
+++ b/docs/src/appendix/chisel3-vs-chisel2.md
@@ -5,6 +5,9 @@ section: "chisel3"
 ---
 
 # Chisel3 vs Chisel2
+```scala mdoc:invisible
+import chisel3._
+```
 
 ## Chisel2 Migration
 For those moving from Chisel2, there were some backwards incompatible changes
@@ -12,55 +15,66 @@ and your RTL needs to be modified to work with Chisel3. The required
 modifications are:
 
  - Wire declaration style:
-   ```scala
-   val wire = UInt(width = 15)
-   ```
+```scala
+  val wire = UInt(width = 15)
+```
    becomes (in Chisel3):
-   ```scala
-   val wire = Wire(UInt(15.W))
-   ```
+```scala mdoc:compile-only
+  val wire = Wire(UInt(15.W))
+```
 
  - I/O declaration style:
-   ```scala
+```scala
    val done = Bool(OUTPUT)
-   ```
+```
    becomes (in Chisel3):
-   ```scala
+```scala mdoc:compile-only
    val wire = Output(Bool())
-   ```
+```
 
  - Sequential memories:
-   ```scala
+```scala mdoc:invisible
+import chisel3._
+val enable = Bool()
+```
+
+```scala
    val addr = Reg(UInt())
    val mem = Mem(UInt(8.W), 1024, seqRead = true)
    val dout = when(enable) { mem(addr) }
-   ```
+```
    becomes (in Chisel3):
-   ```scala
+```scala mdoc:compile-only
    val addr = UInt()
    val mem = SyncReadMem(1024, UInt(8.W))
    val dout = mem.read(addr, enable)
-   ```
+```
 
    Notice the address register is now internal to the SyncReadMem(), but the data
    will still return on the subsequent cycle.
 
- - Generating Verilog with
-   ```scala
+ - Generating Verilog for a module:
+```scala mdoc:invisible
+import chisel3._
+class Hello extends RawModule
+```
+
+```scala
    object Hello {
      def main(args: Array[String]): Unit = {
        chiselMain(Array("--backend", "v"), () => Module(new Hello()))
      }
    }
-   ```
+```
    becomes (in Chisel3):
-   ```scala
+```scala mdoc:compile-only
+   import chisel3.stage.ChiselStage
    object Hello {
      def main(args: Array[String]): Unit = {
-       chisel3.Driver.execute(Array[String](), () => new Hello())
+       (new ChiselStage).emitVerilog(new Hello())
      }
    }
-   ```
+```
 
  - Package changes:
    - Chisel.log2Ceil -> chisel3.util.log2Ceil
@@ -143,14 +157,14 @@ hardware objects), based on specific imports.
 This allows designs to move from less strict front end checks (largely compatible with Chisel2), to stricter checking,
 on a file by file basis, by adjusting specific import statements.
 
-```scala
-    import chisel3.core.ExplicitCompileOptions.Strict
+```scala mdoc:compile-only
+    import chisel3.ExplicitCompileOptions.Strict
 ```
 
 enables stricter connection and usage checks, while
 
-```scala
-    import chisel3.core.ExplicitCompileOptions.NotStrict
+```scala mdoc:compile-only
+    import chisel3.ExplicitCompileOptions.NotStrict
 ```
 
 defers these checks to the `firrtl` compiler.
diff --git a/docs/src/appendix/experimental-features.md b/docs/src/appendix/experimental-features.md
new file mode 100644
index 00000000..4b1208aa
--- /dev/null
+++ b/docs/src/appendix/experimental-features.md
@@ -0,0 +1,372 @@
+---
+layout: docs
+title:  "Experimental Features"
+section: "chisel3"
+---
+
+Chisel has a number of new features that are worth checking out.  This page is an informal list of these features and projects.
+
+- [FixedPoint](#fixed-point)
+- [Module Variants](#module-variants)
+- [Module Variants](#bundle-literals)
+- [Interval Type](#interval-type)
+- [Loading Memories for simulation or FPGA initialization](#loading-memories)
+
+### FixedPoint  <a name="fixed-point"></a>
+FixedPoint numbers are basic *Data* type along side of UInt, SInt, etc.  Most common math and logic operations
+are supported. Chisel allows both the width and binary point to be inferred by the Firrtl compiler which can simplify
+circuit descriptions. See [FixedPointSpec](https://github.com/freechipsproject/chisel3/tree/master/src/test/scala/chiselTests/FixedPointSpec.scala)
+
+### Module Variants <a name="module-variants"></a>
+The standard Chisel *Module* requires a `val io = IO(...)`, the experimental package introduces several
+new ways of defining Modules
+- BaseModule: no contents, instantiable
+- BlackBox extends BaseModule
+- UserDefinedModule extends BaseModule: this module can contain Chisel RTL. No default clock or reset lines. No default IO. - User should be able to specify non-io ports, ideally multiple of them.
+- ImplicitModule extends UserModule: has clock, reset, and io, essentially current Chisel Module.
+- RawModule: will be the user-facing version of UserDefinedModule
+- Module: type-aliases to ImplicitModule, the user-facing version of ImplicitModule.
+
+### Bundle Literals <a name="bundle-literals"></a>
+
+Bundle literals can be constructed via an experimental import:
+
+```scala mdoc
+import chisel3._
+import chisel3.experimental.BundleLiterals._
+
+class MyBundle extends Bundle {
+  val a = UInt(8.W)
+  val b = Bool()
+}
+
+class Example extends RawModule {
+  val out = IO(Output(new MyBundle))
+  out := (new MyBundle).Lit(_.a -> 8.U, _.b -> true.B)
+}
+```
+
+```scala mdoc:verilog
+chisel3.stage.ChiselStage.emitVerilog(new Example)
+```
+
+Partial specification is allowed, defaulting any unconnected fields to 0 (regardless of type).
+
+```scala mdoc
+class Example2 extends RawModule {
+  val out = IO(Output(new MyBundle))
+  out := (new MyBundle).Lit(_.b -> true.B)
+}
+```
+
+```scala mdoc:verilog
+chisel3.stage.ChiselStage.emitVerilog(new Example2)
+```
+
+Bundle literals can also be nested arbitrarily.
+
+```scala mdoc
+class ChildBundle extends Bundle {
+  val foo = UInt(8.W)
+}
+
+class ParentBundle extends Bundle {
+  val a = UInt(8.W)
+  val b = new ChildBundle
+}
+
+class Example3 extends RawModule {
+  val out = IO(Output(new ParentBundle))
+  out := (new ParentBundle).Lit(_.a -> 123.U, _.b -> (new ChildBundle).Lit(_.foo -> 42.U))
+}
+```
+
+```scala mdoc:verilog
+chisel3.stage.ChiselStage.emitVerilog(new Example3)
+```
+
+### Vec Literals
+
+Vec literals are very similar to Bundle literals and can be constructed via an experimental import.
+They can be constructed in two forms, with type and length inferred as in: 
+
+```scala mdoc
+import chisel3._
+import chisel3.experimental.VecLiterals._
+
+class VecExample1 extends Module {
+  val out = IO(Output(Vec(2, UInt(4.W))))
+  out := Vec.Lit(0xa.U, 0xbb.U)
+}
+```
+```scala mdoc:verilog
+chisel3.stage.ChiselStage.emitVerilog(new VecExample1)
+```
+
+or explicitly as in:
+
+```scala mdoc
+import chisel3._
+import chisel3.experimental.VecLiterals._
+
+class VecExample1a extends Module {
+  val out = IO(Output(Vec(2, UInt(4.W))))
+  out := Vec(2, UInt(4.W)).Lit(0 -> 1.U, 1 -> 2.U)
+}
+```
+
+```scala mdoc:verilog
+chisel3.stage.ChiselStage.emitVerilog(new VecExample1a)
+```
+
+The following examples all use the explicit form.
+With the explicit form partial specification is allowed.
+When used with as a `Reg` `reset` value, only specified indices of the `Reg`'s `Vec`
+will be reset
+
+```scala mdoc
+class VecExample2 extends RawModule {
+  val out = IO(Output(Vec(4, UInt(4.W))))
+  out := Vec(4, UInt(4.W)).Lit(0 -> 1.U, 3 -> 7.U)
+}
+```
+
+```scala mdoc:verilog
+chisel3.stage.ChiselStage.emitVerilog(new VecExample2)
+```
+
+Registers can be initialized from Vec literals
+
+```scala mdoc
+class VecExample3 extends Module {
+  val out = IO(Output(Vec(4, UInt(8.W))))
+  val y = RegInit(
+    Vec(4, UInt(8.W)).Lit(0 -> 0xAB.U(8.W), 1 -> 0xCD.U(8.W), 2 -> 0xEF.U(8.W), 3 -> 0xFF.U(8.W))
+  )
+  out := y
+}
+```
+
+```scala mdoc:verilog
+chisel3.stage.ChiselStage.emitVerilog(new VecExample3)
+```
+
+Vec literals can also be nested arbitrarily.
+
+```scala mdoc
+class VecExample5 extends RawModule {
+  val out = IO(Output(Vec(2, new ChildBundle)))
+  out := Vec(2, new ChildBundle).Lit(
+    0 -> (new ChildBundle).Lit(_.foo -> 42.U),
+    1 -> (new ChildBundle).Lit(_.foo -> 7.U)
+  )
+}
+```
+
+```scala mdoc:verilog
+chisel3.stage.ChiselStage.emitVerilog(new VecExample5)
+```
+
+### Interval Type <a name="interval-type"></a>
+
+**Intervals** are a new experimental numeric type that comprises UInt, SInt and FixedPoint numbers.
+It augments these types with range information, i.e. upper and lower numeric bounds.
+This information can be used to exercise tighter programmatic control over the ultimate widths of
+signals in the final circuit.  The **Firrtl** compiler can infer this range information based on
+operations and earlier values in the circuit. Intervals support all the ordinary bit and arithmetic operations
+associated with UInt, SInt, and FixedPoint and adds the following methods for manipulating the range of
+a **source** Interval with the IntervalRange of **target** Interval
+
+#### Clip -- Fit the value **source** into the IntervalRange of **target**, saturate if out of bounds
+The clip method applied to an interval creates a new interval based on the argument to clip,
+and constructs the necessary hardware so that the source Interval's value will be mapped into the new Interval.
+Values that are outside the result range will be pegged to either maximum or minimum of result range as appropriate.
+
+> Generates necessary hardware to clip values, values greater than range are set to range.high, values lower than range are set to range min.
+
+#### Wrap -- Fit the value **source** into the IntervalRange of **target**, wrapping around if out of bounds
+The wrap method applied to an interval creates a new interval based on the argument to wrap,
+and constructs the necessary
+hardware so that the source Interval's value will be mapped into the new Interval.
+Values that are outside the result range will be wrapped until they fall within the result range.
+
+> Generates necessary hardware to wrap values, values greater than range are set to range.high, values lower than range are set to range min.
+
+> Does not handle out of range values that are less than half the minimum or greater than twice maximum
+
+#### Squeeze -- Fit the value **source** into the smallest IntervalRange based on source and target.
+The squeeze method applied to an interval creates a new interval based on the argument to clip, the two ranges must overlap
+behavior of squeeze with inputs outside of the produced range is undefined.
+
+> Generates no hardware, strictly a sizing operation
+
+##### Range combinations
+
+| Condition | A.clip(B) | A.wrap(B) | A.squeeze(B) |
+| --------- | --------------- | --------------- | --------------- |
+| A === B   | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  |
+| A contains B   | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  |
+| B contains A   | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  |
+| A min < B min, A max in B  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  |
+| A min in B, A max > B max  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  |
+| A strictly less than B   | error               | error               | error               |
+| A strictly greater than B   | error               | error               | error               |
+
+
+#### Applying binary point operators to an Interval
+
+Consider a Interval with a binary point of 3: aaa.bbb
+
+| operation | after operation | binary point | lower | upper | meaning |
+| --------- | --------------- | ------------ | ----- | ----- | ------- |
+| setBinaryPoint(2) | aaa.bb |  2 | X | X  | set the precision |
+| shiftLeftBinaryPoint(2) | a.aabbb |  5 | X | X  | increase the precision |
+| shiftRighBinaryPoint(2) | aaaa.b |  1 | X | X  | reduce the precision |
+
+## Loading Memories for simulation or FPGA initialization <a name="loading-memories"></a>
+
+Chisel supports multiple experimental methods for annotating memories to be loaded from a text file containing hex or binary data. When using verilog simulation it uses the `$readmemh` or `$readmemb` verilog extension. The treadle simulator can also load memories using the same annotation.
+
+### Inline initialization with external file
+
+Memories can be initialized by generating inline `readmemh` or `readmemb` statements in the output Verilog.
+
+The function `loadMemoryFromFileInline` from `chisel3.util.experimental` allows the memory to be initialized by the synthesis software from the specified file. Chisel does not validate the file contents nor its location. Both the memory initialization file and the Verilog source should be accessible for the toolchain.
+
+```scala mdoc:silent
+import chisel3._
+import chisel3.util.experimental.loadMemoryFromFileInline
+
+class InitMemInline(memoryFile: String = "") extends Module {
+  val width: Int = 32
+  val io = IO(new Bundle {
+    val enable = Input(Bool())
+    val write = Input(Bool())
+    val addr = Input(UInt(10.W))
+    val dataIn = Input(UInt(width.W))
+    val dataOut = Output(UInt(width.W))
+  })
+
+  val mem = SyncReadMem(1024, UInt(width.W))
+  // Initialize memory
+  if (memoryFile.trim().nonEmpty) {
+    loadMemoryFromFileInline(mem, memoryFile)
+  }
+  io.dataOut := DontCare
+  when(io.enable) {
+    val rdwrPort = mem(io.addr)
+    when (io.write) { rdwrPort := io.dataIn }
+      .otherwise    { io.dataOut := rdwrPort }
+  }
+}
+```
+
+The default is to use `$readmemh` (which assumes all numbers in the file are in ascii hex),
+but to use ascii binary there is an optional `hexOrBinary` argument which can be set to `MemoryLoadFileType.Hex` or `MemoryLoadFileType.Binary`. You will need to add an additional import.
+
+By default, the inline initialization will generate the memory `readmem` statements inside an `ifndef SYNTHESIS` block, which suits ASIC workflow.
+
+Some synthesis tools (like Synplify and Yosys) define `SYNTHESIS` so the `readmem` statement is not read when inside this block.
+
+To control this, one can use the `MemoryNoSynthInit` and `MemorySynthInit` annotations from `firrtl.annotations`. The former which is the default setting when no annotation is present generates `readmem` inside the block. Using the latter, the statement are generated outside the `ifndef` block so it can be used by FPGA synthesis tools.
+
+Below an example for initialization suited for FPGA workflows:
+
+```scala mdoc:silent
+import chisel3._
+import chisel3.util.experimental.loadMemoryFromFileInline
+import chisel3.experimental.{annotate, ChiselAnnotation}
+import firrtl.annotations.MemorySynthInit
+
+class InitMemInlineFPGA(memoryFile: String = "") extends Module {
+  val width: Int = 32
+  val io = IO(new Bundle {
+    val enable = Input(Bool())
+    val write = Input(Bool())
+    val addr = Input(UInt(10.W))
+    val dataIn = Input(UInt(width.W))
+    val dataOut = Output(UInt(width.W))
+  })
+
+  // Notice the annotation below
+  annotate(new ChiselAnnotation {
+    override def toFirrtl =
+      MemorySynthInit
+  })
+
+  val mem = SyncReadMem(1024, UInt(width.W))
+  if (memoryFile.trim().nonEmpty) {
+    loadMemoryFromFileInline(mem, memoryFile)
+  }
+  io.dataOut := DontCare
+  when(io.enable) {
+    val rdwrPort = mem(io.addr)
+    when (io.write) { rdwrPort := io.dataIn }
+      .otherwise    { io.dataOut := rdwrPort }
+  }
+}
+```
+
+#### SystemVerilog Bind Initialization
+
+Chisel can also initialize memories by generating a SV bind module with `readmemh` or `readmemb` statements by using the function `loadMemoryFromFile` from `chisel3.util.experimental`.
+
+```scala mdoc:silent
+import chisel3._
+import chisel3.util.experimental.loadMemoryFromFile
+
+class InitMemBind(val bits: Int, val size: Int, filename: String) extends Module {
+  val io = IO(new Bundle {
+    val nia = Input(UInt(bits.W))
+    val insn = Output(UInt(32.W))
+  })
+
+  val memory = Mem(size, UInt(32.W))
+  io.insn := memory(io.nia >> 2);
+  loadMemoryFromFile(memory, filename)
+}
+```
+
+Which generates the bind module:
+
+```verilog
+module BindsTo_0_Foo(
+  input         clock,
+  input         reset,
+  input  [31:0] io_nia,
+  output [31:0] io_insn
+);
+
+initial begin
+  $readmemh("test.hex", Foo.memory);
+end
+endmodule
+
+bind Foo BindsTo_0_Foo BindsTo_0_Foo_Inst(.*);
+```
+
+### Notes on files
+
+There is no simple answer to where to put the `hex` or `bin` file with the initial contents. It's probably best to create a resource directory somewhere and reference that through a full path or place the file beside the generated Verilog. Another option is adding the path to the memory file in the synthesis tool path. Because these files may be large, Chisel does not copy them.
+> Don't forget there is no decimal option, so a 10 in an input file will be 16 decimal
+
+See: [ComplexMemoryLoadingSpec.scala](https://github.com/freechipsproject/chisel-testers/blob/master/src/test/scala/examples/ComplexMemoryLoadingSpec.scala) and
+[LoadMemoryFromFileSpec.scala](https://github.com/freechipsproject/chisel-testers/blob/master/src/test/scala/examples/LoadMemoryFromFileSpec.scala)
+for working examples.
+
+
+### Aggregate memories
+
+Aggregate memories are supported but in bit of a clunky way. Since they will be split up into a memory per field, the following convention was adopted.  When specifying the file for such a memory the file name should be regarded as a template. If the memory is a Bundle e.g.
+
+```scala mdoc:compile-only
+class MemDataType extends Bundle {
+  val a = UInt(16.W)
+  val b = UInt(32.W)
+  val c = Bool()
+}
+```
+
+The memory will be split into `memory_a`, `memory_b`, and `memory_c`. Similarly if a load file is specified as `"memory-load.txt"` the simulation will expect that there will be three files, `"memory-load_a.txt"`, `"memory-load_b.txt"`, `"memory-load_c.txt"`
+
+> Note: The use of `_` and that the memory field name is added before any file suffix. The suffix is optional but if present is considered to be the text after the last `.` in the file name.
diff --git a/docs/src/wiki-deprecated/upgrading-from-scala-2-11.md b/docs/src/appendix/upgrading-from-scala-2-11.md
index 26e2d252..26e2d252 100644
--- a/docs/src/wiki-deprecated/upgrading-from-scala-2-11.md
+++ b/docs/src/appendix/upgrading-from-scala-2-11.md
diff --git a/docs/src/appendix/versioning.md b/docs/src/appendix/versioning.md
new file mode 100644
index 00000000..8c5ef91c
--- /dev/null
+++ b/docs/src/appendix/versioning.md
@@ -0,0 +1,35 @@
+---
+layout: docs
+title:  "Versioning"
+section: "chisel3"
+---
+
+# Chisel Project Versioning
+
+Chisel and related projects follow a versioning scheme similar to [PVP](https://pvp.haskell.org/).
+Project versions are of the form `A.B.C` where `A.B` specifies the _Major_ version and `C` specifies the _Minor_ version.
+Projects maintain _binary compatibility_ between minor versions of the same major version.
+For example, a project compiled against Chisel3 version 3.4.0 can be used with Chisel3 version 3.4.2 or 3.4.15 without recompilation.
+
+# Compatible Versions
+
+Historically, due to a mistake in versioning with chisel-iotesters as well as some projects originating later than others,
+the compatible versions of Chisel-related projects has not been obvious.
+We are taking steps to improve the situation by bringing the major versions more in line (the `B` part in `A.B.C`),
+but the inconsistencies remain in previously published versions.
+
+Please use the following table to determine which versions of the related projects are compatible.
+In particular, versions of projects in this table were compiled against the version of any dependencies listed in the same row.
+For example, `chisel-iotesters` version 1.4 was compiled against `chisel3` version 3.3.
+
+| chisel3 | chiseltest | chisel-iotesters | firrtl | treadle | diagrammer | firrtl-interpreter<sup>2</sup> |
+| ------- | ---------- | ---------------- | ------ | ------- | ---------- | ----- |
+| 3.4     | 0.3        | 1.5              | 1.4    | 1.3     | 1.3        | 1.4 |
+| 3.3     | 0.2        | 1.4              | 1.3    | 1.2     | 1.2        | 1.3 |
+| 3.2     | 0.1<sup>1</sup>  | 1.3        | 1.2    | 1.1     | 1.1        | 1.2 |
+| 3.1     | -          | 1.2              | 1.1    | 1.0     | 1.0        | 1.1 |
+| 3.0     | -          | 1.1              | 1.0    | -<sup>3</sup> | -    | 1.0 |
+
+<sup>1</sup> chiseltest 0.1 was published under artifact name [chisel-testers2](https://search.maven.org/search?q=a:chisel-testers2_2.12) (0.2 was published under both artifact names)    
+<sup>2</sup> Replaced by Treadle, in maintenance mode only since version 1.1    
+<sup>3</sup> Treadle was preceded by the firrtl-interpreter    
diff --git a/docs/src/wiki-deprecated/cookbook.md b/docs/src/cookbooks/cookbook.md
index 9a10a689..ce49b668 100644
--- a/docs/src/wiki-deprecated/cookbook.md
+++ b/docs/src/cookbooks/cookbook.md
@@ -1,19 +1,23 @@
 ---
 layout: docs
-title:  "Cookbook"
+title:  "General Cookbook"
 section: "chisel3"
 ---
 
-Welcome to the Chisel cookbook. This cookbook is still in early stages. If you have any requests or examples to share, please [file an issue](https://github.com/ucb-bar/chisel3/issues/new) and let us know!
+# General Cookbook
 
-Please note that these examples make use of [Chisel's scala-style printing](printing#scala-style).
 
-* Converting Chisel Types to/from UInt
+Please note that these examples make use of [Chisel's scala-style printing](../explanations/printing#scala-style).
+
+* Type Conversions
   * [How do I create a UInt from an instance of a Bundle?](#how-do-i-create-a-uint-from-an-instance-of-a-bundle)
   * [How do I create a Bundle from a UInt?](#how-do-i-create-a-bundle-from-a-uint)
+  * [How can I tieoff a Bundle/Vec to 0?](#how-can-i-tieoff-a-bundlevec-to-0)
   * [How do I create a Vec of Bools from a UInt?](#how-do-i-create-a-vec-of-bools-from-a-uint)
   * [How do I create a UInt from a Vec of Bool?](#how-do-i-create-a-uint-from-a-vec-of-bool)
+  * [How do I connect a subset of Bundle fields?](#how-do-i-connect-a-subset-of-bundle-fields)
 * Vectors and Registers
+  * [Can I make a 2D or 3D Vector?](#can-i-make-a-2D-or-3D-Vector)
   * [How do I create a Vector of Registers?](#how-do-i-create-a-vector-of-registers)
   * [How do I create a Reg of type Vec?](#how-do-i-create-a-reg-of-type-vec)
 * [How do I create a finite state machine?](#how-do-i-create-a-finite-state-machine-fsm)
@@ -24,8 +28,10 @@ Please note that these examples make use of [Chisel's scala-style printing](prin
   * [How do I get Chisel to name signals properly in blocks like when/withClockAndReset?](#how-do-i-get-chisel-to-name-signals-properly-in-blocks-like-whenwithclockandreset)
   * [How do I get Chisel to name the results of vector reads properly?](#how-do-i-get-chisel-to-name-the-results-of-vector-reads-properly)
   * [How can I dynamically set/parametrize the name of a module?](#how-can-i-dynamically-setparametrize-the-name-of-a-module)
+* Directionality
+  * [How do I strip directions from a bidirectional Bundle (or other Data)?](#how-do-i-strip-directions-from-a-bidirectional-bundle-or-other-data)
 
-## Converting Chisel Types to/from UInt
+## Type Conversions
 
 ### How do I create a UInt from an instance of a Bundle?
 
@@ -44,6 +50,10 @@ class Foo extends RawModule {
   bundle.foo := 0xc.U
   bundle.bar := 0x3.U
   val uint = bundle.asUInt
+  printf(p"$uint") // 195
+
+  // Test
+  assert(uint === 0xc3.U)
 }
 ```
 
@@ -62,9 +72,45 @@ class MyBundle extends Bundle {
 class Foo extends RawModule {
   val uint = 0xb4.U
   val bundle = uint.asTypeOf(new MyBundle)
+  
+  printf(p"$bundle") // Bundle(foo -> 11, bar -> 4)
+
+  // Test
+  assert(bundle.foo === 0xb.U)
+  assert(bundle.bar === 0x4.U)
 }
 ```
 
+### How can I tieoff a Bundle/Vec to 0?
+
+You can use `asTypeOf` as above. If you don't want to worry about the type of the thing
+you are tying off, you can use `chiselTypeOf`:
+
+```scala mdoc:silent:reset
+import chisel3._
+
+class MyBundle extends Bundle {
+  val foo = UInt(4.W)
+  val bar = Vec(4, UInt(1.W))
+}
+
+class Foo(typ: Data) extends RawModule {
+  val bundleA = IO(Output(typ))
+  val bundleB = IO(Output(typ))
+  
+  // typ is already a Chisel Data Type, so can use it directly here, but you 
+  // need to know that bundleA is of type typ
+  bundleA := 0.U.asTypeOf(typ)
+  
+  // bundleB is a Hardware data IO(Output(...)) so need to call chiselTypeOf,
+  // but this will work no matter the type of bundleB:
+  bundleB := 0.U.asTypeOf(chiselTypeOf(bundleB)) 
+}
+
+class Bar extends RawModule {
+  val foo = Module(new Foo(new MyBundle()))
+}
+```
 ### How do I create a Vec of Bools from a UInt?
 
 Use [`VecInit`](https://www.chisel-lang.org/api/latest/chisel3/VecInit$.html) given a `Seq[Bool]` generated using the [`asBools`](https://www.chisel-lang.org/api/latest/chisel3/UInt.html#asBools():Seq[chisel3.Bool]) method.
@@ -75,6 +121,14 @@ import chisel3._
 class Foo extends RawModule {
   val uint = 0xc.U
   val vec = VecInit(uint.asBools)
+
+  printf(p"$vec") // Vec(0, 0, 1, 1)
+
+  // Test
+  assert(vec(0) === false.B)
+  assert(vec(1) === false.B)
+  assert(vec(2) === true.B)
+  assert(vec(3) === true.B)
 }
 ```
 
@@ -88,11 +142,67 @@ import chisel3._
 class Foo extends RawModule {
   val vec = VecInit(true.B, false.B, true.B, true.B)
   val uint = vec.asUInt
+
+  printf(p"$uint") // 13
+
+  // Test
+  // (remember leftmost Bool in Vec is low order bit)
+  assert(0xd.U === uint)
+
 }
 ```
 
+### How do I connect a subset of Bundle fields?
+
+See the [DataView cookbook](dataview#how-do-i-connect-a-subset-of-bundle-fields).
+
 ## Vectors and Registers
 
+### Can I make a 2D or 3D Vector?
+
+Yes. Using `VecInit` you can make Vectors that hold Vectors of Chisel types. Methods `fill` and `tabulate` make these multi-dimensional Vectors.
+
+```scala mdoc:silent:reset
+import chisel3._
+
+class MyBundle extends Bundle {
+  val foo = UInt(4.W)
+  val bar = UInt(4.W)
+}
+
+class Foo extends Module {
+  //2D Fill
+  val twoDVec = VecInit.fill(2, 3)(5.U)
+  //3D Fill
+  val myBundle = Wire(new MyBundle)
+  myBundle.foo := 0xc.U
+  myBundle.bar := 0x3.U
+  val threeDVec = VecInit.fill(1, 2, 3)(myBundle)
+  assert(threeDVec(0)(0)(0).foo === 0xc.U && threeDVec(0)(0)(0).bar === 0x3.U)
+
+  //2D Tabulate
+  val indexTiedVec = VecInit.tabulate(2, 2){ (x, y) => (x + y).U }
+  assert(indexTiedVec(0)(0) === 0.U)
+  assert(indexTiedVec(0)(1) === 1.U)
+  assert(indexTiedVec(1)(0) === 1.U)
+  assert(indexTiedVec(1)(1) === 2.U)
+  //3D Tabulate
+  val indexTiedVec3D = VecInit.tabulate(2, 3, 4){ (x, y, z) => (x + y * z).U }
+  assert(indexTiedVec3D(0)(0)(0) === 0.U)
+  assert(indexTiedVec3D(1)(1)(1) === 2.U)
+  assert(indexTiedVec3D(1)(1)(2) === 3.U)
+  assert(indexTiedVec3D(1)(1)(3) === 4.U)
+  assert(indexTiedVec3D(1)(2)(3) === 7.U)
+}
+```
+```scala mdoc:invisible
+// Hidden but will make sure this actually compiles
+import chisel3.stage.ChiselStage
+
+ChiselStage.emitVerilog(new Foo)
+```
+
+
 ### How do I create a Vector of Registers?
 
 **Rule!  Use Reg of Vec not Vec of Reg!**
@@ -299,76 +409,11 @@ class ModuleWithOptionalIO(flag: Boolean) extends Module {
 
 ### How do I get Chisel to name signals properly in blocks like when/withClockAndReset?
 
-To get Chisel to name signals (wires and registers) declared inside of blocks like `when`, `withClockAndReset`, etc, use the [`@chiselName`](https://www.chisel-lang.org/api/latest/chisel3/experimental/package$$chiselName.html) annotation as shown below:
-
-```scala mdoc:silent:reset
-import chisel3._
-import chisel3.experimental.chiselName
-
-@chiselName
-class TestMod extends Module {
-  val io = IO(new Bundle {
-    val a = Input(Bool())
-    val b = Output(UInt(4.W))
-  })
-  when (io.a) {
-    val innerReg = RegInit(5.U(4.W))
-    innerReg := innerReg + 1.U
-    io.b := innerReg
-  } .otherwise {
-    io.b := 10.U
-  }
-}
-```
-
-Note that you will need to add the following line to your project's `build.sbt` file.
-
-```scala
-addCompilerPlugin("org.scalamacros" % "paradise" % "2.1.0" cross CrossVersion.full)
-```
-
-If we compile this module *without* `@chiselName`, Chisel is not able to name `innerReg` correctly (notice the `_T`):
-
-```scala mdoc:passthrough
-import chisel3.stage.{ChiselStage, ChiselGeneratorAnnotation}
-import firrtl.annotations.DeletedAnnotation
-import firrtl.EmittedVerilogCircuitAnnotation
+Use the compiler plugin, and check out the [Naming Cookbook](#naming) if that still does not do what you want.
 
-class TestModWithout extends Module {
-  override val desiredName = "TestMod"
-  val io = IO(new Bundle {
-    val a = Input(Bool())
-    val b = Output(UInt(4.W))
-  })
-  when (io.a) {
-    val innerReg = RegInit(5.U(4.W))
-    innerReg := innerReg + 1.U
-    io.b := innerReg
-  } .otherwise {
-    io.b := 10.U
-  }
-}
-
-(new ChiselStage)
-  .execute(Array("-X", "verilog"), Seq(ChiselGeneratorAnnotation(() => new TestModWithout)))
-  .collectFirst{ case DeletedAnnotation(_, a: EmittedVerilogCircuitAnnotation) => a.value.value }
-  .foreach(a => println(s"""|```verilog
-                            |$a
-                            |```""".stripMargin))
-```
-
-However, if we use `@chiselName` then the register previously called `_T` is now `innerReg`:
-```scala mdoc:passthrough
-(new ChiselStage)
-  .execute(Array("-X", "verilog"), Seq(ChiselGeneratorAnnotation(() => new TestMod)))
-  .collectFirst{ case DeletedAnnotation(_, a: EmittedVerilogCircuitAnnotation) => a.value.value }
-  .foreach(a => println(s"""|```verilog
-                            |$a
-                            |```""".stripMargin))
-```
 ### How do I get Chisel to name the results of vector reads properly?
 Currently, name information is lost when using dynamic indexing. For example:
-```scala
+```scala mdoc:silent
 class Foo extends Module {
   val io = IO(new Bundle {
     val in = Input(Vec(4, Bool()))
@@ -455,16 +500,65 @@ class Salt extends Module {
 }
 ```
 
-Elaborating the Chisel module `Salt` yields our "desire name" for `Salt` and `Coffee` in the output Verilog:
-```scala mdoc:passthrough
-import chisel3.stage.{ChiselStage, ChiselGeneratorAnnotation}
-import firrtl.annotations.DeletedAnnotation
-import firrtl.EmittedVerilogCircuitAnnotation
-
-(new ChiselStage)
-  .execute(Array("-X", "verilog"), Seq(ChiselGeneratorAnnotation(() => new Salt)))
-  .collectFirst{ case DeletedAnnotation(_, a: EmittedVerilogCircuitAnnotation) => a.value.value }
-  .foreach(a => println(s"""|```verilog
-                            |$a
-                            |```""".stripMargin))
+Elaborating the Chisel module `Salt` yields our "desired names" for `Salt` and `Coffee` in the output Verilog:
+```scala mdoc:silent
+import chisel3.stage.ChiselStage
+
+ChiselStage.emitVerilog(new Salt)
+```
+
+```scala mdoc:verilog
+ChiselStage.emitVerilog(new Salt)
+```
+
+## Directionality
+
+### How do I strip directions from a bidirectional Bundle (or other Data)?
+
+Given a bidirectional port like a `Decoupled`, you will get an error if you try to connect it directly
+to a register:
+
+```scala mdoc:silent
+import chisel3.util.Decoupled
+class BadRegConnect extends Module {
+  val io = IO(new Bundle {
+    val enq = Decoupled(UInt(8.W))
+  })
+  
+  val monitor = Reg(chiselTypeOf(io.enq))
+  monitor := io.enq
+}
+```
+
+```scala mdoc:crash
+ChiselStage.emitVerilog(new BadRegConnect)
+```
+
+While there is no construct to "strip direction" in Chisel3, wrapping a type in `Output(...)`
+(the default direction in Chisel3) will
+set all of the individual elements to output direction.
+This will have the desired result when used to construct a Register:
+
+```scala mdoc:silent
+import chisel3.util.Decoupled
+class CoercedRegConnect extends Module {
+  val io = IO(new Bundle {
+    val enq = Flipped(Decoupled(UInt(8.W)))
+  })
+  
+  // Make a Reg which contains all of the bundle's signals, regardless of their directionality
+  val monitor = Reg(Output(chiselTypeOf(io.enq)))
+  // Even though io.enq is bidirectional, := will drive all fields of monitor with the fields of io.enq
+  monitor := io.enq
+}
+```
+
+<!-- Just make sure it actually works -->
+```scala mdoc:invisible
+ChiselStage.emitVerilog(new CoercedRegConnect {
+  // Provide default connections that would just muddy the example
+  io.enq.ready := true.B
+  // dontTouch so that it shows up in the Verilog
+  dontTouch(monitor)
+})
 ```
diff --git a/docs/src/cookbooks/cookbooks.md b/docs/src/cookbooks/cookbooks.md
new file mode 100644
index 00000000..ee6f5e45
--- /dev/null
+++ b/docs/src/cookbooks/cookbooks.md
@@ -0,0 +1,15 @@
+---
+layout: docs
+title:  "Cookbooks"
+section: "chisel3"
+---
+
+# Cookbooks
+
+Welcome to the Chisel Cookbooks, where we capture frequently-used design patterns or troubleshooting questions.
+If you have any requests or examples to share,
+please [file an issue](https://github.com/chipsalliance/chisel3/issues/new) and let us know!
+
+* [General Cookbooks](cookbook)
+* [Naming Cookbook](naming)
+* [Troubleshooting Guide](troubleshooting)
diff --git a/docs/src/cookbooks/dataview.md b/docs/src/cookbooks/dataview.md
new file mode 100644
index 00000000..ed969ca1
--- /dev/null
+++ b/docs/src/cookbooks/dataview.md
@@ -0,0 +1,179 @@
+---
+layout: docs
+title:  "DataView Cookbook"
+section: "chisel3"
+---
+
+# DataView Cookbook
+
+* [How do I view a Data as a UInt or vice versa?](#how-do-i-view-a-data-as-a-uint-or-vice-versa)
+* [How do I create a DataView for a Bundle has a type parameter?](#how-do-i-create-a-dataview-for-a-bundle-has-a-type-parameter)
+* [How do I create a DataView for a Bundle with optional fields?](#how-do-i-create-a-dataview-for-a-bundle-with-optional-fields)
+* [How do I connect a subset of Bundle fields?](#how-do-i-connect-a-subset-of-bundle-fields)
+    * [How do I view a Bundle as a parent type (superclass)?](#how-do-i-view-a-bundle-as-a-parent-type-superclass)
+    * [How do I view a Bundle as a parent type when the parent type is abstract (like a trait)?](#how-do-i-view-a-bundle-as-a-parent-type-when-the-parent-type-is-abstract-like-a-trait)
+
+## How do I view a Data as a UInt or vice versa?
+
+Subword viewing (using concatenations or bit extractions in `DataViews`) is not yet supported.
+We intend to implement this in the future, but for the time being, use regular casts
+(`.asUInt` and `.asTypeOf`).
+
+## How do I create a DataView for a Bundle has a type parameter?
+
+Instead of using a `val`, use a `def` which can have type parameters:
+
+```scala mdoc:silent:reset
+import chisel3._
+import chisel3.experimental.dataview._
+
+class Foo[T <: Data](val foo: T) extends Bundle
+class Bar[T <: Data](val bar: T) extends Bundle
+
+object Foo {
+  implicit def view[T <: Data]: DataView[Foo[T], Bar[T]] = {
+    DataView(f => new Bar(f.foo.cloneType), _.foo -> _.bar)
+    // .cloneType is necessary because the f passed to this function will be bound hardware
+  }
+}
+```
+
+```scala mdoc:invisible
+// Make sure this works during elaboration, not part of doc
+class MyModule extends RawModule {
+  val in = IO(Input(new Foo(UInt(8.W))))
+  val out = IO(Output(new Bar(UInt(8.W))))
+  out := in.viewAs[Bar[UInt]]
+}
+chisel3.stage.ChiselStage.emitVerilog(new MyModule)
+```
+If you think about type parameterized classes as really being a family of different classes
+(one for each type parameter), you can think about the `implicit def` as a generator of `DataViews`
+for each type parameter.
+
+## How do I create a DataView for a Bundle with optional fields?
+
+Instead of using the default `DataView` apply method, use `DataView.mapping`:
+
+```scala mdoc:silent:reset
+import chisel3._
+import chisel3.experimental.dataview._
+
+class Foo(val w: Option[Int]) extends Bundle {
+  val foo = UInt(8.W)
+  val opt = w.map(x => UInt(x.W))
+}
+class Bar(val w: Option[Int]) extends Bundle {
+  val bar = UInt(8.W)
+  val opt = w.map(x => UInt(x.W))
+}
+
+object Foo {
+  implicit val view: DataView[Foo, Bar] =
+    DataView.mapping(
+      // First argument is always the function to make the view from the target
+      f => new Bar(f.w),
+      // Now instead of a varargs of tuples of individual mappings, we have a single function that
+      // takes a target and a view and returns an Iterable of tuple
+      (f, b) =>  List(f.foo -> b.bar) ++ f.opt.map(_ -> b.opt.get)
+                                   // ^ Note that we can append options since they are Iterable!
+
+    )
+}
+```
+
+```scala mdoc:invisible
+// Make sure this works during elaboration, not part of doc
+class MyModule extends RawModule {
+  val in = IO(Input(new Foo(Some(8))))
+  val out = IO(Output(new Bar(Some(8))))
+  out := in.viewAs[Bar]
+}
+chisel3.stage.ChiselStage.emitVerilog(new MyModule)
+```
+
+## How do I connect a subset of Bundle fields?
+
+Chisel 3 requires types to match exactly for connections.
+DataView provides a mechanism for "viewing" one `Bundle` object as if it were the type of another,
+which allows them to be connected.
+
+### How do I view a Bundle as a parent type (superclass)?
+
+For viewing `Bundles` as the type of the parent, it is as simple as using `viewAsSupertype` and providing a
+template object of the parent type:
+
+```scala mdoc:silent:reset
+import chisel3._
+import chisel3.experimental.dataview._
+
+class Foo extends Bundle {
+  val foo = UInt(8.W)
+}
+class Bar extends Foo {
+  val bar = UInt(8.W)
+}
+class MyModule extends Module {
+  val foo = IO(Input(new Foo))
+  val bar = IO(Output(new Bar))
+  bar.viewAsSupertype(new Foo) := foo // bar.foo := foo.foo
+  bar.bar := 123.U           // all fields need to be connected
+}
+```
+```scala mdoc:verilog
+chisel3.stage.ChiselStage.emitVerilog(new MyModule)
+```
+
+### How do I view a Bundle as a parent type when the parent type is abstract (like a trait)?
+
+Given the following `Bundles` that share a common `trait`:
+
+```scala mdoc:silent:reset
+import chisel3._
+import chisel3.experimental.dataview._
+
+trait Super extends Bundle {
+  def bitwidth: Int
+  val a = UInt(bitwidth.W)
+}
+class Foo(val bitwidth: Int) extends Super {
+  val foo = UInt(8.W)
+}
+class Bar(val bitwidth: Int) extends Super {
+  val bar = UInt(8.W)
+}
+```
+
+`Foo` and `Bar` cannot be connected directly, but they could be connected by viewing them both as if
+they were instances of their common supertype, `Super`.
+A straightforward approach might run into an issue like the following:
+
+```scala mdoc:fail
+class MyModule extends Module {
+  val foo = IO(Input(new Foo(8)))
+  val bar = IO(Output(new Bar(8)))
+  bar.viewAsSupertype(new Super) := foo.viewAsSupertype(new Super)
+}
+```
+
+The problem is that `viewAs` requires an object to use as a type template (so that it can be cloned),
+but `traits` are abstract and cannot be instantiated.
+The solution is to create an instance of an _anonymous class_ and use that object as the argument to `viewAs`.
+We can do this like so:
+
+```scala mdoc:silent
+class MyModule extends Module {
+  val foo = IO(Input(new Foo(8)))
+  val bar = IO(Output(new Bar(8)))
+  val tpe = new Super { // Adding curly braces creates an anonymous class
+    def bitwidth = 8 // We must implement any abstract methods
+  }
+  bar.viewAsSupertype(tpe) := foo.viewAsSupertype(tpe)
+}
+```
+By adding curly braces after the name of the trait, we're telling Scala to create a new concrete
+subclass of the trait, and create an instance of it.
+As indicated in the comment, abstract methods must still be implemented.
+This is the same that happens when one writes `new Bundle {}`,
+the curly braces create a new concrete subclass; however, because `Bundle` has no abstract methods,
+the contents of the body can be empty.
diff --git a/docs/src/cookbooks/hierarchy.md b/docs/src/cookbooks/hierarchy.md
new file mode 100644
index 00000000..91d99aa6
--- /dev/null
+++ b/docs/src/cookbooks/hierarchy.md
@@ -0,0 +1,204 @@
+---
+layout: docs
+title:  "Hierarchy Cookbook"
+section: "chisel3"
+---
+
+# Hierarchy Cookbook
+
+* [How do I instantiate multiple instances with the same module parameterization, but avoid re-elaboration?](#how-do-i-instantiate-multiple-instances-with-the-same-module-parameterization)
+* [How do I access internal fields of an instance?](#how-do-i-access-internal-fields-of-an-instance)
+* [How do I make my parameters accessable from an instance?](#how-do-i-make-my-parameters-accessable-from-an-instance)
+* [How do I reuse a previously elaborated module, if my new module has the same parameterization?](#how-do-i-reuse-a-previously-elaborated-module-if-my-new-module-has-the-same-parameterization)
+
+## How do I instantiate multiple instances with the same module parameterization?
+
+Prior to this package, Chisel users relied on deduplication in a FIRRTL compiler to combine
+structurally equivalent modules into one module (aka "deduplication").
+This package introduces the following new APIs to enable multiply-instantiated modules directly in Chisel.
+
+`Definition(...)` enables elaborating a module, but does not actually instantiate that module.
+Instead, it returns a `Definition` class which represents that module's definition.
+
+`Instance(...)` takes a `Definition` and instantiates it, returning an `Instance` object.
+
+Modules (classes or traits) which will be used with the `Definition`/`Instance` api should be marked
+with the `@instantiable` annotation at the class/trait definition.
+
+To make a Module's members variables accessible from an `Instance` object, they must be annotated
+with the `@public` annotation. Note that this is only accessible from a Scala sense—this is not
+in and of itself a mechanism for cross-module references.
+
+In the following example, use `Definition`, `Instance`, `@instantiable` and `@public` to create
+multiple instances of one specific parameterization of a module, `AddOne`.
+
+```scala mdoc:silent
+import chisel3._
+import chisel3.experimental.hierarchy.{Definition, Instance, instantiable, public}
+
+@instantiable
+class AddOne(width: Int) extends Module {
+  @public val in  = IO(Input(UInt(width.W)))
+  @public val out = IO(Output(UInt(width.W)))
+  out := in + 1.U
+}
+
+class AddTwo(width: Int) extends Module {
+  val in  = IO(Input(UInt(width.W)))
+  val out = IO(Output(UInt(width.W)))
+  val addOneDef = Definition(new AddOne(width))
+  val i0 = Instance(addOneDef)
+  val i1 = Instance(addOneDef)
+  i0.in := in
+  i1.in := i0.out
+  out   := i1.out
+}
+```
+```scala mdoc:verilog
+chisel3.stage.ChiselStage.emitVerilog(new AddTwo(10))
+```
+
+## How do I access internal fields of an instance?
+
+You can mark internal members of a class or trait marked with `@instantiable` with the `@public` annotation.
+The requirements are that the field is publicly accessible, is a `val` or `lazy val`, and is a valid type.
+The list of valid types are:
+
+1. `IsInstantiable`
+2. `IsLookupable`
+3. `Data`
+4. `BaseModule`
+5. `Iterable`/`Option `containing a type that meets these requirements
+6. Basic type like `String`, `Int`, `BigInt` etc.
+
+To mark a superclass's member as `@public`, use the following pattern (shown with `val clock`).
+
+```scala mdoc:silent:reset
+import chisel3._
+import chisel3.experimental.hierarchy.{instantiable, public}
+
+@instantiable
+class MyModule extends Module {
+  @public val clock = clock
+}
+```
+
+You'll get the following error message for improperly marking something as `@public`:
+
+```scala mdoc:reset:fail
+import chisel3._
+import chisel3.experimental.hierarchy.{instantiable, public}
+
+object NotValidType
+
+@instantiable
+class MyModule extends Module {
+  @public val x = NotValidType
+}
+```
+
+## How do I make my parameters accessible from an instance?
+
+If an instance's parameters are simple (e.g. `Int`, `String` etc.) they can be marked directly with `@public`.
+
+Often, parameters are more complicated and are contained in case classes.
+In such cases, mark the case class with the `IsLookupable` trait.
+This indicates to Chisel that instances of the `IsLookupable` class may be accessed from within instances.
+
+However, ensure that these parameters are true for **all** instances of a definition.
+For example, if our parameters contained an id field which was instance-specific but defaulted to zero,
+then the definition's id would be returned for all instances.
+This change in behavior could lead to bugs if other code presumed the id field was correct.
+
+Thus, it is important that when converting normal modules to use this package,
+you are careful about what you mark as `IsLookupable`.
+
+In the following example, we added the trait `IsLookupable` to allow the member to be marked `@public`.
+
+```scala mdoc:reset:silent
+import chisel3._
+import chisel3.experimental.hierarchy.{Definition, Instance, instantiable, IsLookupable, public}
+
+case class MyCaseClass(width: Int) extends IsLookupable
+
+@instantiable
+class MyModule extends Module {
+  @public val x = MyCaseClass(10)
+}
+
+class Top extends Module {
+  val inst = Instance(Definition(new MyModule))
+  println(s"Width is ${inst.x.width}")
+}
+```
+```scala mdoc:passthrough
+println("```")
+chisel3.stage.ChiselStage.elaborate(new Top)
+println("```")
+```
+
+## How do I look up parameters from a Definition, if I don't want to instantiate it?
+
+Just like `Instance`s, `Definition`'s also contain accessors for `@public` members.
+As such, you can directly access them:
+
+```scala mdoc:reset:silent
+import chisel3._
+import chisel3.experimental.hierarchy.{Definition, instantiable, public}
+
+@instantiable
+class AddOne(val width: Int) extends Module {
+  @public val width = width
+  @public val in  = IO(Input(UInt(width.W)))
+  @public val out = IO(Output(UInt(width.W)))
+  out := in + 1.U
+}
+
+class Top extends Module {
+  val definition = Definition(new AddOne(10))
+  println(s"Width is: ${definition.width}")
+}
+```
+```scala mdoc:verilog
+chisel3.stage.ChiselStage.emitVerilog(new Top())
+```
+
+## How do I parameterize a module by its children instances?
+
+Prior to the introduction of this package, a parent module would have to pass all necessary parameters
+when instantiating a child module.
+This had the unfortunate consequence of requiring a parent's parameters to always contain the child's
+parameters, which was an unnecessary coupling which lead to some anti-patterns.
+
+Now, a parent can take a child `Definition` as an argument, and instantiate it directly.
+In addition, it can analyze the parameters used in the definition to parameterize itself.
+In a sense, now the child can actually parameterize the parent.
+
+In the following example, we create a definition of `AddOne`, and pass the definition to `AddTwo`.
+The width of the `AddTwo` ports are now derived from the parameterization of the `AddOne` instance.
+
+```scala mdoc:reset
+import chisel3._
+import chisel3.experimental.hierarchy.{Definition, Instance, instantiable, public}
+
+@instantiable
+class AddOne(val width: Int) extends Module {
+  @public val width = width
+  @public val in  = IO(Input(UInt(width.W)))
+  @public val out = IO(Output(UInt(width.W)))
+  out := in + 1.U
+}
+
+class AddTwo(addOneDef: Definition[AddOne]) extends Module {
+  val i0 = Instance(addOneDef)
+  val i1 = Instance(addOneDef)
+  val in  = IO(Input(UInt(addOneDef.width.W)))
+  val out = IO(Output(UInt(addOneDef.width.W)))
+  i0.in := in
+  i1.in := i0.out
+  out   := i1.out
+}
+```
+```scala mdoc:verilog
+chisel3.stage.ChiselStage.emitVerilog(new AddTwo(Definition(new AddOne(10))))
+```
diff --git a/docs/src/wiki-deprecated/troubleshooting.md b/docs/src/cookbooks/troubleshooting.md
index 333adec4..f8a0cec1 100644
--- a/docs/src/wiki-deprecated/troubleshooting.md
+++ b/docs/src/cookbooks/troubleshooting.md
@@ -3,6 +3,10 @@ layout: docs
 title:  "Troubleshooting"
 section: "chisel3"
 ---
+
+# Troubleshooting
+
+
 This page is a starting point for recording common and not so common problems in developing with Chisel3.  In particular, those situations where there is a work around that will keep you going.
 
 ### `type mismatch` specifying width/value of a `UInt`/`SInt`
@@ -10,7 +14,7 @@ This page is a starting point for recording common and not so common problems in
 *I have some old code that used to work correctly in chisel2 (and still does if I use the `import Chisel._` compatibility layer)
 but causes a `type mismatch` error in straight chisel3:*
 
-```scala
+```scala mdoc:silent:fail
 class TestBlock extends Module {
 	val io = IO(new Bundle {
 		val output = Output(UInt(width=3))
@@ -31,7 +35,9 @@ It was felt these were too prone to error and made it difficult to diagnose erro
 In chisel3, the single argument to the `UInt`/`SInt` object/constructor specifies the *width* and must be a `Width` type.
 Although there are no automatic conversions from `Int` to `Width`, an `Int` may be converted to a `Width` by applying the `W` method to an `Int`.
 In chisel3, the above code becomes:
-```scala
+```scala mdoc:silent
+import chisel3._
+
 class TestBlock extends Module {
 	val io = IO(new Bundle {
 		val output = Output(UInt(3.W))
@@ -40,18 +46,19 @@ class TestBlock extends Module {
 ```
 `UInt`/`SInt` literals may be created from an `Int` with the application of either the `U` or `S` method.
 
-```scala
+```scala mdoc:fail
 UInt(42)
 ```
+
 in chisel2, becomes
-```scala
+```scala mdoc:silent
 42.U
 ```
 in chisel3
 
 A literal with a specific width is created by calling the `U` or `S` method with a `W` argument.
 Use:
-```scala
+```scala mdoc:silent
 1.S(8.W)
 ```
 to create an 8-bit wide (signed) literal with value 1.
diff --git a/docs/src/wiki-deprecated/developers.md b/docs/src/developers/developers.md
index 4c133c54..7072af6b 100644
--- a/docs/src/wiki-deprecated/developers.md
+++ b/docs/src/developers/developers.md
@@ -3,9 +3,11 @@ layout: docs
 title:  "Developers"
 section: "chisel3"
 ---
+
 # Developer Documentation
 
-Tips and tricks for Chisel developers.
+Tips and tricks for Chisel developers:
 
 * [Embedding Chisel as an sbt subproject](sbt-subproject)
 * [Test Coverage](test-coverage)
+* [Developers Style Guide](style)
diff --git a/docs/src/wiki-deprecated/sbt-subproject.md b/docs/src/developers/sbt-subproject.md
index 77273800..44d2916b 100644
--- a/docs/src/wiki-deprecated/sbt-subproject.md
+++ b/docs/src/developers/sbt-subproject.md
@@ -4,7 +4,7 @@ title:  "Developers"
 section: "chisel3"
 ---
 
-## Chisel as an sbt subproject
+# Chisel as an sbt subproject
 
 In order to use the constructs defined in the Chisel3 library, those definitions must be made available to the Scala
 compiler at the time a project dependent on them is compiled.
diff --git a/docs/src/wiki-deprecated/style.md b/docs/src/developers/style.md
index c845f7b4..80e1e083 100644
--- a/docs/src/wiki-deprecated/style.md
+++ b/docs/src/developers/style.md
@@ -1,10 +1,22 @@
-# Chisel Style Guide
+---
+layout: docs
+title:  "Style Guide"
+section: "chisel3"
+---
+
+# Chisel Developers Style Guide
+
+This document describes the syle used within the `chisel3`
+and related projects (`firrtl`, `treadle`, etc). It does not
+capture requirements for code which is written using these libraries,
+although projects may choose to adopt these guidelines.
 
 The Chisel style guide reflects the [Google Java style
 guide](http://google.github.io/styleguide/javaguide.html) and the [General Public Scala style
-guide](http://docs.scala-lang.org/style/). Specific rules below are to clarify
+guide](http://docs.scala-lang.org/style/). The specific rules below are to clarify
 the style used for the chisel3 repo and repos related to Chisel (Firrtl).
 
+
 **Goal:** Readability and consistency are the main purposes of the style guide.
 Writing your code so someone else (or yourself) can grok it later is important
 to code health and quality.
@@ -134,8 +146,14 @@ val queueOut = Queue(
 ## Naming Conventions
 
 Chisel follows the [Scala Naming Conventions](http://docs.scala-lang.org/style/naming-conventions.html).
-In general, Chisel code should use CamelCase for naming (ie. the first letter
-of each word is capitalized except sometimes the first word).
+In general, Chisel code should use `lowerCamelCase` for variable naming (ie. the first letter
+of each word is capitalized except for the first word) and `UpperCamelCase` for class names.
+
+> Using these guidelines can result in verilog which is noncompliant with common verilog coding standards, e.g.
+the [lowRISC verilog coding style](https://github.com/lowRISC/style-guides/blob/master/VerilogCodingStyle.md#naming).
+Authors of Chisel code that translates to hardware constructs might therefore prefer to use `snake_case`. However,
+generated code can always be transformed to meet various emitted code requirements, so the official Chisel style
+guide follows the Scala convention.
 
 ### Why CamelCase instead of Snake\_Case?
 
diff --git a/docs/src/wiki-deprecated/test-coverage.md b/docs/src/developers/test-coverage.md
index a3a622a2..099db4bb 100644
--- a/docs/src/wiki-deprecated/test-coverage.md
+++ b/docs/src/developers/test-coverage.md
@@ -4,6 +4,8 @@ title:  "Test Coverage"
 section: "chisel3"
 ---
 
+# Test Coverage
+
 ## Test Coverage Setup
 
 Chisel's sbt build instructions contain the requisite plug-in (sbt-scoverage) for generating test coverage information. Please see the [sbt-scoverage web page](https://github.com/scoverage/sbt-scoverage) for details on the plug-in.
diff --git a/docs/src/explanations/annotations.md b/docs/src/explanations/annotations.md
index 19d24605..510ebca5 100644
--- a/docs/src/explanations/annotations.md
+++ b/docs/src/explanations/annotations.md
@@ -4,6 +4,8 @@ title:  "Annotations"
 section: "chisel3"
 ---
 
+# Annotations
+
 `Annotation`s are metadata containers associated with zero or more "things" in a FIRRTL circuit.
 Commonly, `Annotation`s are used to communicate information from Chisel to a specific, custom FIRRTL `Transform`.
 In this way `Annotation`s can be viewed as the "arguments" that a specific `Transform` consumes.
@@ -132,10 +134,8 @@ class ModC(widthC: Int) extends Module {
 
 Compiling this circuit to Verilog will then result in the `InfoTransform` running and the added `println`s showing information about the components annotated.
 
-```scala mdoc
+```scala mdoc:compile-only
 import chisel3.stage.{ChiselStage, ChiselGeneratorAnnotation}
 
-// This currently doesn't work because of mdoc limitations. However, it will work
-// in your normal Scala code.
-//(new ChiselStage).execute(Array.empty, Seq(ChiselGeneratorAnnotation(() => new ModC(4))))
+(new ChiselStage).execute(Array.empty, Seq(ChiselGeneratorAnnotation(() => new ModC(4))))
 ```
diff --git a/docs/src/explanations/blackboxes.md b/docs/src/explanations/blackboxes.md
index a8d5fe03..4ecd1ea0 100644
--- a/docs/src/explanations/blackboxes.md
+++ b/docs/src/explanations/blackboxes.md
@@ -9,7 +9,7 @@ for hardware constructs that cannot be described in Chisel and for connecting to
 Modules defined as a `BlackBox` will be instantiated in the generated Verilog, but no code
 will be generated to define the behavior of module.
 
-Unlike Module, `BlackBox` has no implicit clock and reset. 
+Unlike Module, `BlackBox` has no implicit clock and reset.
 `BlackBox`'s clock and reset ports must be explicitly declared and connected to input signals.
 Ports declared in the IO Bundle will be generated with the requested name (ie. no preceding `io_`).
 
@@ -34,7 +34,7 @@ class IBUFDS extends BlackBox(Map("DIFF_TERM" -> "TRUE",
 }
 
 class Top extends Module {
-  val io = IO(new Bundle{})
+  val io = IO(new Bundle {})
   val ibufds = Module(new IBUFDS)
   // connecting one of IBUFDS's input clock ports to Top's clock signal
   ibufds.io.I := clock
@@ -52,12 +52,14 @@ IBUFDS #(.DIFF_TERM("TRUE"), .IOSTANDARD("DEFAULT")) ibufds (
 ```
 
 ### Providing Implementations for Blackboxes
+
 Chisel provides the following ways of delivering the code underlying the blackbox.  Consider the following blackbox that
  adds two real numbers together.  The numbers are represented in chisel3 as 64-bit unsigned integers.
+
 ```scala mdoc:silent:reset
 import chisel3._
 class BlackBoxRealAdd extends BlackBox {
-  val io = IO(new Bundle() {
+  val io = IO(new Bundle {
     val in1 = Input(UInt(64.W))
     val in2 = Input(UInt(64.W))
     val out = Output(UInt(64.W))
@@ -66,6 +68,7 @@ class BlackBoxRealAdd extends BlackBox {
 ```
 
 The implementation is described by the following verilog
+
 ```verilog
 module BlackBoxRealAdd(
     input  [63:0] in1,
@@ -73,39 +76,43 @@ module BlackBoxRealAdd(
     output reg [63:0] out
 );
   always @* begin
-  out <= $realtobits($bitstoreal(in1) + $bitstoreal(in2));
+    out <= $realtobits($bitstoreal(in1) + $bitstoreal(in2));
   end
 endmodule
 ```
 
 ### Blackboxes with Verilog in a Resource File
-In order to deliver the verilog snippet above to the backend simulator, chisel3 provides the following tools based on the chisel/firrtl [annotation system](../explanations/annotations).  Add the trait ```HasBlackBoxResource``` to the declaration, and then call a function in the body to say where the system can find the verilog.  The Module now looks like
-```mdoc scala:silent:reset
+
+In order to deliver the verilog snippet above to the backend simulator, chisel3 provides the following tools based on the chisel/firrtl [annotation system](../explanations/annotations).  Add the trait `HasBlackBoxResource` to the declaration, and then call a function in the body to say where the system can find the verilog.  The Module now looks like
+
+```scala mdoc:silent:reset
+import chisel3._
+import chisel3.util.HasBlackBoxResource
+
 class BlackBoxRealAdd extends BlackBox with HasBlackBoxResource {
-  val io = IO(new Bundle() {
+  val io = IO(new Bundle {
     val in1 = Input(UInt(64.W))
     val in2 = Input(UInt(64.W))
     val out = Output(UInt(64.W))
   })
-  setResource("/real_math.v")
+  addResource("/real_math.v")
 }
 ```
-The verilog snippet above gets put into a resource file names ```real_math.v```.  What is a resource file? It comes from
+
+The verilog snippet above gets put into a resource file names `real_math.v`.  What is a resource file? It comes from
  a java convention of keeping files in a project that are automatically included in library distributions. In a typical
  chisel3 project, see [chisel-template](https://github.com/ucb-bar/chisel-template), this would be a directory in the
- source hierarchy
-```
-src/main/resources/real_math.v
-```
+ source hierarchy: `src/main/resources/real_math.v`.
 
 ### Blackboxes with In-line Verilog
-It is also possible to place this verilog directly in the scala source.  Instead of ```HasBlackBoxResource``` use 
- ```HasBlackBoxInline``` and instead of ```setResource``` use ```setInline```.  The code will look like this.
+It is also possible to place this verilog directly in the scala source.  Instead of `HasBlackBoxResource` use
+ `HasBlackBoxInline` and instead of `setResource` use `setInline`.  The code will look like this.
+
 ```scala mdoc:silent:reset
 import chisel3._
 import chisel3.util.HasBlackBoxInline
 class BlackBoxRealAdd extends BlackBox with HasBlackBoxInline {
-  val io = IO(new Bundle() {
+  val io = IO(new Bundle {
     val in1 = Input(UInt(64.W))
     val in2 = Input(UInt(64.W))
     val out = Output(UInt(64.W))
@@ -123,15 +130,16 @@ class BlackBoxRealAdd extends BlackBox with HasBlackBoxInline {
     """.stripMargin)
 }
 ```
-This technique will copy the inline verilog into the target directory under the name ```BlackBoxRealAdd.v```
+
+This technique will copy the inline verilog into the target directory under the name `BlackBoxRealAdd.v`
 
 ### Under the Hood
 This mechanism of delivering verilog content to the testing backends is implemented via chisel/firrtl annotations. The
-two methods, inline and resource, are two kinds of annotations that are created via the ```setInline``` and
-```setResource``` methods calls.  Those annotations are passed through to the chisel-testers which in turn passes them
+two methods, inline and resource, are two kinds of annotations that are created via the `setInline` and
+`setResource` methods calls.  Those annotations are passed through to the chisel-testers which in turn passes them
 on to firrtl.  The default firrtl verilog compilers have a pass that detects the annotations and moves the files or
 inline test into the build directory.  For each unique file added, the transform adds a line to a file
-black_box_verilog_files.f, this file is added to the command line constructed for verilator or vcs to inform them where
+`black_box_verilog_files.f`, this file is added to the command line constructed for verilator or vcs to inform them where
 to look.
 The [dsptools project](https://github.com/ucb-bar/dsptools) is a good example of using this feature to build a real
 number simulation tester based on black boxes.
@@ -144,4 +152,4 @@ construct scala implementations of the black boxes.  The scala implementation co
 passed down to the interpreter by the execution harness.  The interpreter is a scala simulation tester.  Once again the
 dsptools project uses this mechanism and is a good place to look at it.
 > It is planned that the BlackBoxFactory will be replaced by integration with the annotation based blackbox methods
->stuff soon.
+> stuff soon.
diff --git a/docs/src/explanations/bundles-and-vecs.md b/docs/src/explanations/bundles-and-vecs.md
index dcac31cd..78626c42 100644
--- a/docs/src/explanations/bundles-and-vecs.md
+++ b/docs/src/explanations/bundles-and-vecs.md
@@ -3,14 +3,12 @@ layout: docs
 title:  "Bundles and Vecs"
 section: "chisel3"
 ---
-```
-
-```
 
 `Bundle` and `Vec` are classes that allow the user to expand the set of Chisel datatypes with aggregates of other types.
 
 Bundles group together several named fields of potentially different types into a coherent unit, much like a `struct` in
 C. Users define their own bundles by defining a class as a subclass of `Bundle`.
+
 ```scala mdoc:silent
 import chisel3._
 class MyFloat extends Bundle {
@@ -25,24 +23,12 @@ class ModuleWithFloatWire extends RawModule {
 }
 ```
 
-> Currently, there is no way to create a bundle literal like ```8.U``` for ```UInt```s. Therefore, in order to create
->literals for bundles, we must declare a [[wire|Combinational-Circuits#wires]] of that bundle type, and then assign
->values to it. We are working on a way to declare bundle literals without requiring the creation of a Wire node and
->assigning to it.
+You can create literal Bundles using the experimental [Bundle Literals](../appendix/experimental-features#bundle-literals) feature.
 
-```scala mdoc:silent
-class ModuleWithFloatConstant extends RawModule {
-  // Floating point constant.
-  val floatConst = Wire(new MyFloat)
-  floatConst.sign := true.B
-  floatConst.exponent := 10.U
-  floatConst.significand := 128.U
-}
-```
-
-A Scala convention is to capitalize the name of new classes and we suggest you follow that convention in Chisel too.
+Scala convention is to name classes using UpperCamelCase, and we suggest you follow that convention in your Chisel code.
 
 Vecs create an indexable vector of elements, and are constructed as follows:
+
 ```scala mdoc:silent
 class ModuleWithVec extends RawModule {
   // Vector of 5 23-bit signed integers.
@@ -63,6 +49,7 @@ superclass, `Data`.  Every object that ultimately inherits from
 
 Bundles and Vecs can be arbitrarily nested to build complex data
 structures:
+
 ```scala mdoc:silent
 class BigBundle extends Bundle {
  // Vector of 5 23-bit signed integers.
@@ -77,7 +64,7 @@ Note that the builtin Chisel primitive and aggregate classes do not
 require the `new` when creating an instance, whereas new user
 datatypes will.  A Scala `apply` constructor can be defined so
 that a user datatype also does not require `new`, as described in
-[Function Constructor](../wiki-deprecated/functional-module-creation).
+[Function Constructor](../explanations/functional-module-creation).
 
 ### Flipping Bundles
 
@@ -152,6 +139,7 @@ Note that in the vast majority of cases, **this is not required** as Chisel can
 automatically.
 
 Here is an example of a parametrized bundle (`ExampleBundle`) that features a custom `cloneType`.
+
 ```scala mdoc:silent
 class ExampleBundle(a: Int, b: Int) extends Bundle {
     val foo = UInt(a.W)
diff --git a/docs/src/explanations/chisel-enum.md b/docs/src/explanations/chisel-enum.md
new file mode 100644
index 00000000..a390aea4
--- /dev/null
+++ b/docs/src/explanations/chisel-enum.md
@@ -0,0 +1,228 @@
+---
+layout: docs
+title:  "Enumerations"
+section: "chisel3"
+---
+
+# ChiselEnum
+
+The ChiselEnum type can be used to reduce the chance of error when encoding mux selectors, opcodes, and functional unit operations.
+In contrast with `Chisel.util.Enum`, `ChiselEnum` are subclasses of `Data`, which means that they can be used to define fields in `Bundle`s, including in `IO`s.
+
+## Functionality and Examples
+
+```scala mdoc
+// Imports used in the following examples
+import chisel3._
+import chisel3.util._
+import chisel3.stage.ChiselStage
+import chisel3.experimental.ChiselEnum
+```
+
+```scala mdoc:invisible
+// Helper to print stdout from Chisel elab
+// May be related to: https://github.com/scalameta/mdoc/issues/517
+import java.io._
+import _root_.logger.Logger
+def grabLog[T](thunk: => T): (String, T) = {
+  val baos = new ByteArrayOutputStream()
+  val stream = new PrintStream(baos, true, "utf-8")
+  val ret = Logger.makeScope(Nil) {
+   Logger.setOutput(stream)
+   thunk
+  }
+  (baos.toString, ret)
+}
+```
+
+Below we see ChiselEnum being used as mux select for a RISC-V core. While wrapping the object in a package is not required, it is highly recommended as it allows for the type to be used in multiple files more easily.
+
+```scala mdoc
+// package CPUTypes {
+object AluMux1Sel extends ChiselEnum {
+  val selectRS1, selectPC = Value
+}
+// We can see the mapping by printing each Value
+AluMux1Sel.all.foreach(println)
+```
+
+Here we see a mux using the AluMux1Sel to select between different inputs.
+
+```scala mdoc
+import AluMux1Sel._
+
+class AluMux1Bundle extends Bundle {
+  val aluMux1Sel = Input(AluMux1Sel())
+  val rs1Out     = Input(Bits(32.W))
+  val pcOut      = Input(Bits(32.W))
+  val aluMux1Out = Output(Bits(32.W))
+}
+
+class AluMux1File extends Module {
+  val io = IO(new AluMux1Bundle)
+
+  // Default value for aluMux1Out
+  io.aluMux1Out := 0.U
+
+  switch (io.aluMux1Sel) {
+    is (selectRS1) {
+      io.aluMux1Out := io.rs1Out
+    }
+    is (selectPC) {
+      io.aluMux1Out := io.pcOut
+    }
+  }
+}
+```
+
+```scala mdoc:verilog
+ChiselStage.emitVerilog(new AluMux1File)
+```
+
+ChiselEnum also allows for the user to directly set the Values by passing an `UInt` to `Value(...)`
+as shown below. Note that the magnitude of each `Value` must be strictly greater than the one before
+it.
+
+```scala mdoc
+object Opcode extends ChiselEnum {
+    val load  = Value(0x03.U) // i "load"  -> 000_0011
+    val imm   = Value(0x13.U) // i "imm"   -> 001_0011
+    val auipc = Value(0x17.U) // u "auipc" -> 001_0111
+    val store = Value(0x23.U) // s "store" -> 010_0011
+    val reg   = Value(0x33.U) // r "reg"   -> 011_0011
+    val lui   = Value(0x37.U) // u "lui"   -> 011_0111
+    val br    = Value(0x63.U) // b "br"    -> 110_0011
+    val jalr  = Value(0x67.U) // i "jalr"  -> 110_0111
+    val jal   = Value(0x6F.U) // j "jal"   -> 110_1111
+}
+```
+
+The user can 'jump' to a value and continue incrementing by passing a start point then using a regular Value definition.
+
+```scala mdoc
+object BranchFunct3 extends ChiselEnum {
+    val beq, bne = Value
+    val blt = Value(4.U)
+    val bge, bltu, bgeu = Value
+}
+// We can see the mapping by printing each Value
+BranchFunct3.all.foreach(println)
+```
+
+## Casting
+
+You can cast an enum to a `UInt` using `.asUInt`:
+
+```scala mdoc
+class ToUInt extends RawModule {
+  val in = IO(Input(Opcode()))
+  val out = IO(Output(UInt()))
+  out := in.asUInt
+}
+```
+
+```scala mdoc:invisible
+// Always need to run Chisel to see if there are elaboration errors
+ChiselStage.emitVerilog(new ToUInt)
+```
+
+You can cast from a `UInt` to an enum by passing the `UInt` to the apply method of the `ChiselEnum` object:
+
+```scala mdoc
+class FromUInt extends Module {
+  val in = IO(Input(UInt(7.W)))
+  val out = IO(Output(Opcode()))
+  out := Opcode(in)
+}
+```
+
+However, if you cast from a `UInt` to an Enum type when there are undefined states in the Enum values
+that the `UInt` could hit, you will see a warning like the following:
+
+```scala mdoc:passthrough
+val (log, _) = grabLog(ChiselStage.emitChirrtl(new FromUInt))
+println(s"```\n$log```")
+```
+
+(Note that the name of the Enum is ugly as an artifact of our documentation generation flow, it will
+be cleaner in normal use).
+
+You can avoid this warning by using the `.safe` factory method which returns the cast Enum in addition
+to a `Bool` indicating if the Enum is in a valid state:
+
+```scala mdoc
+class SafeFromUInt extends Module {
+  val in = IO(Input(UInt(7.W)))
+  val out = IO(Output(Opcode()))
+  val (value, valid) = Opcode.safe(in)
+  assert(valid, "Enum state must be valid, got %d!", in)
+  out := value
+}
+```
+
+Now there will be no warning:
+
+```scala mdoc:passthrough
+val (log2, _) = grabLog(ChiselStage.emitChirrtl(new SafeFromUInt))
+println(s"```\n$log2```")
+```
+
+## Testing
+
+The _Type_ of the enums values is `<ChiselEnum Object>.Type` which can be useful for passing the values
+as parameters to a function (or any other time a type annotation is needed).
+Calling `.litValue` on an enum value will return the integer value of that object as a
+[`BigInt`](https://www.scala-lang.org/api/2.12.13/scala/math/BigInt.html).
+
+```scala mdoc
+def expectedSel(sel: AluMux1Sel.Type): Boolean = sel match {
+  case AluMux1Sel.selectRS1 => (sel.litValue == 0)
+  case AluMux1Sel.selectPC  => (sel.litValue == 1)
+  case _                    => false
+}
+```
+
+The enum value type also defines some convenience methods for working with `ChiselEnum` values. For example, continuing with the RISC-V opcode
+example, one could easily create hardware signal that is only asserted on LOAD/STORE operations (when the enum value is equal to `Opcode.load`
+or `Opcode.store`) using the `.isOneOf` method:
+
+```scala mdoc
+class LoadStoreExample extends Module {
+  val io = IO(new Bundle {
+    val opcode = Input(Opcode())
+    val load_or_store = Output(Bool())
+  })
+  io.load_or_store := io.opcode.isOneOf(Opcode.load, Opcode.store)
+}
+```
+
+```scala mdoc:invisible
+// Always need to run Chisel to see if there are elaboration errors
+ChiselStage.emitVerilog(new LoadStoreExample)
+```
+
+Some additional useful methods defined on the `ChiselEnum` object are:
+
+* `.all`: returns the enum values within the enumeration
+* `.getWidth`: returns the width of the hardware type
+
+## Workarounds
+
+As of Chisel v3.4.3 (1 July 2020), the width of the values is always inferred.
+To work around this, you can add an extra `Value` that forces the width that is desired.
+This is shown in the example below, where we add a field `ukn` to force the width to be 3 bits wide:
+
+```scala mdoc
+object StoreFunct3 extends ChiselEnum {
+    val sb, sh, sw = Value
+    val ukn = Value(7.U)
+}
+// We can see the mapping by printing each Value
+StoreFunct3.all.foreach(println)
+```
+
+Signed values are not supported so if you want the value signed, you must cast the UInt with `.asSInt`.
+
+## Additional Resources
+
+The ChiselEnum type is much more powerful than stated above. It allows for Sequence, Vec, and Bundle assignments, as well as a `.next` operation to allow for stepping through sequential states and an `.isValid` for checking that a hardware value is a valid `Value`. The source code for the ChiselEnum can be found [here](https://github.com/chipsalliance/chisel3/blob/2a96767097264eade18ff26e1d8bce192383a190/core/src/main/scala/chisel3/StrongEnum.scala) in the class `EnumFactory`. Examples of the ChiselEnum operations can be found [here](https://github.com/chipsalliance/chisel3/blob/dd6871b8b3f2619178c2a333d9d6083805d99e16/src/test/scala/chiselTests/StrongEnum.scala).
diff --git a/docs/src/wiki-deprecated/combinational-circuits.md b/docs/src/explanations/combinational-circuits.md
index 813549c9..b9e5b8c6 100644
--- a/docs/src/wiki-deprecated/combinational-circuits.md
+++ b/docs/src/explanations/combinational-circuits.md
@@ -3,6 +3,9 @@ layout: docs
 title:  "Combinational Circuits"
 section: "chisel3"
 ---
+
+# Combinational Circuits
+
 A circuit is represented as a graph of nodes in Chisel.  Each node is
 a hardware operator that has zero or more inputs and that drives one
 output.  A literal, introduced above, is a degenerate kind of node
diff --git a/docs/src/wiki-deprecated/data-types.md b/docs/src/explanations/data-types.md
index e931247f..6ac6077b 100644
--- a/docs/src/wiki-deprecated/data-types.md
+++ b/docs/src/explanations/data-types.md
@@ -4,6 +4,8 @@ title:  "Data Types"
 section: "chisel3"
 ---
 
+# Chisel Data Types
+
 Chisel datatypes are used to specify the type of values held in state
 elements or flowing on wires.  While hardware designs ultimately
 operate on vectors of binary digits, other more abstract
@@ -17,7 +19,7 @@ format.  Boolean values are represented as type ```Bool```.  Note
 that these types are distinct from Scala's builtin types such as
 ```Int``` or ```Boolean```.
 
-> There is a new experimental type **Interval** which gives the developer more control of the type by allowing the definition of an IntervalRange.  See: [Interval Type](interval-type)
+> There is a new experimental type **Interval** which gives the developer more control of the type by allowing the definition of an IntervalRange.  See: [Interval Type](../appendix/experimental-features#interval-type)
 
 Additionally, Chisel defines `Bundles` for making
 collections of values with named fields (similar to ```structs``` in
diff --git a/docs/src/explanations/dataview.md b/docs/src/explanations/dataview.md
new file mode 100644
index 00000000..2f229bfc
--- /dev/null
+++ b/docs/src/explanations/dataview.md
@@ -0,0 +1,520 @@
+---
+layout: docs
+title:  "DataView"
+section: "chisel3"
+---
+
+# DataView
+
+_New in Chisel 3.5_
+
+```scala mdoc:invisible
+import chisel3._
+import chisel3.stage.ChiselStage.emitVerilog
+```
+
+## Introduction
+
+DataView is a mechanism for "viewing" Scala objects as a subtype of `chisel3.Data`.
+Often, this is useful for viewing one subtype of `chisel3.Data`, as another.
+One can think about a `DataView` as a mapping from a _Target_ type `T` to a _View_ type `V`.
+This is similar to a cast (eg. `.asTypeOf`) with a few differences:
+1. Views are _connectable_—connections to the view will occur on the target
+2. Whereas casts are _structural_ (a reinterpretation of the underlying bits), a DataView is a customizable mapping
+3. Views can be _partial_—not every field in the target must be included in the mapping
+
+## A Motivating Example (AXI4)
+
+[AXI4](https://en.wikipedia.org/wiki/Advanced_eXtensible_Interface) is a common interface in digital
+design.
+A typical Verilog peripheral using AXI4 will define a write channel as something like:
+```verilog
+module my_module(
+  // Write Channel
+  input        AXI_AWVALID,
+  output       AXI_AWREADY,
+  input [3:0]  AXI_AWID,
+  input [19:0] AXI_AWADDR,
+  input [1:0]  AXI_AWLEN,
+  input [1:0]  AXI_AWSIZE,
+  // ...
+);
+```
+
+This would correspond to the following Chisel Bundle:
+
+```scala mdoc
+class VerilogAXIBundle(val addrWidth: Int) extends Bundle {
+  val AWVALID = Output(Bool())
+  val AWREADY = Input(Bool())
+  val AWID = Output(UInt(4.W))
+  val AWADDR = Output(UInt(addrWidth.W))
+  val AWLEN = Output(UInt(2.W))
+  val AWSIZE = Output(UInt(2.W))
+  // The rest of AW and other AXI channels here
+}
+
+// Instantiated as
+class my_module extends RawModule {
+  val AXI = IO(new VerilogAXIBundle(20))
+}
+```
+
+Expressing something that matches a standard Verilog interface is important when instantiating Verilog
+modules in a Chisel design as `BlackBoxes`.
+Generally though, Chisel developers prefer to use composition via utilities like `Decoupled` rather
+than a flat handling of `ready` and `valid` as in the above.
+A more "Chisel-y" implementation of this interface might look like:
+
+```scala mdoc
+// Note that both the AW and AR channels look similar and could use the same Bundle definition
+class AXIAddressChannel(val addrWidth: Int) extends Bundle {
+  val id = UInt(4.W)
+  val addr = UInt(addrWidth.W)
+  val len = UInt(2.W)
+  val size = UInt(2.W)
+  // ...
+}
+import chisel3.util.Decoupled
+// We can compose the various AXI channels together
+class AXIBundle(val addrWidth: Int) extends Bundle {
+  val aw = Decoupled(new AXIAddressChannel(addrWidth))
+  // val ar = new AXIAddressChannel
+  // ... Other channels here ...
+}
+// Instantiated as
+class MyModule extends RawModule {
+  val axi = IO(new AXIBundle(20))
+}
+```
+
+Of course, this would result in very different looking Verilog:
+
+```scala mdoc:verilog
+emitVerilog(new MyModule {
+  override def desiredName = "MyModule"
+  axi := DontCare // Just to generate Verilog in this stub
+})
+```
+
+So how can we use our more structured types while maintaining expected Verilog interfaces?
+Meet DataView:
+
+```scala mdoc
+import chisel3.experimental.dataview._
+
+// We recommend putting DataViews in a companion object of one of the involved types
+object AXIBundle {
+  // Don't be afraid of the use of implicits, we will discuss this pattern in more detail later
+  implicit val axiView = DataView[VerilogAXIBundle, AXIBundle](
+    // The first argument is a function constructing an object of View type (AXIBundle)
+    // from an object of the Target type (VerilogAXIBundle)
+    vab => new AXIBundle(vab.addrWidth),
+    // The remaining arguments are a mapping of the corresponding fields of the two types
+    _.AWVALID -> _.aw.valid,
+    _.AWREADY -> _.aw.ready,
+    _.AWID -> _.aw.bits.id,
+    _.AWADDR -> _.aw.bits.addr,
+    _.AWLEN -> _.aw.bits.len,
+    _.AWSIZE -> _.aw.bits.size,
+    // ...
+  )
+}
+```
+
+This `DataView` is a mapping between our flat, Verilog-style AXI Bundle to our more compositional,
+Chisel-style AXI Bundle.
+It allows us to define our ports to match the expected Verilog interface, while manipulating it as if
+it were the more structured type:
+
+```scala mdoc
+class AXIStub extends RawModule {
+  val AXI = IO(new VerilogAXIBundle(20))
+  val view = AXI.viewAs[AXIBundle]
+
+  // We can now manipulate `AXI` via `view`
+  view.aw.bits := 0.U.asTypeOf(new AXIAddressChannel(20)) // zero everything out by default
+  view.aw.valid := true.B
+  when (view.aw.ready) {
+    view.aw.bits.id := 5.U
+    view.aw.bits.addr := 1234.U
+    // We can still manipulate AXI as well
+    AXI.AWLEN := 1.U
+  }
+}
+```
+
+This will generate Verilog that matches the standard naming convention:
+
+```scala mdoc:verilog
+emitVerilog(new AXIStub)
+```
+
+Note that if both the _Target_ and the _View_ types are subtypes of `Data` (as they are in this example),
+the `DataView` is _invertible_.
+This means that we can easily create a `DataView[AXIBundle, VerilogAXIBundle]` from our existing
+`DataView[VerilogAXIBundle, AXIBundle]`, all we need to do is provide a function to construct
+a `VerilogAXIBundle` from an instance of an `AXIBundle`:
+
+```scala mdoc:silent
+// Note that typically you should define these together (eg. inside object AXIBundle)
+implicit val axiView2 = AXIBundle.axiView.invert(ab => new VerilogAXIBundle(ab.addrWidth))
+```
+
+The following example shows this and illustrates another use case of `DataView`—connecting unrelated
+types:
+
+```scala mdoc
+class ConnectionExample extends RawModule {
+  val in = IO(new AXIBundle(20))
+  val out = IO(Flipped(new VerilogAXIBundle(20)))
+  out.viewAs[AXIBundle] <> in
+}
+```
+
+This results in the corresponding fields being connected in the emitted Verilog:
+
+```scala mdoc:verilog
+emitVerilog(new ConnectionExample)
+```
+
+## Other Use Cases
+
+While the ability to map between `Bundle` types as in the AXI4 example is pretty compelling,
+DataView has many other applications.
+Importantly, because the _Target_ of the `DataView` need not be a `Data`, it provides a way to use
+`non-Data` objects with APIs that require `Data`.
+
+### Tuples
+
+Perhaps the most helpful use of `DataView` for a non-`Data` type is viewing Scala tuples as `Bundles`.
+For example, in Chisel prior to the introduction of `DataView`, one might try to `Mux` tuples and
+see an error like the following:
+
+<!-- Todo will need to ensure built-in code for Tuples is suppressed once added to stdlib -->
+
+```scala mdoc:fail
+class TupleExample extends RawModule {
+  val a, b, c, d = IO(Input(UInt(8.W)))
+  val cond = IO(Input(Bool()))
+  val x, y = IO(Output(UInt(8.W)))
+  (x, y) := Mux(cond, (a, b), (c, d))
+}
+```
+
+The issue, is that Chisel primitives like `Mux` and `:=` only operate on subtypes of `Data` and
+Tuples (as members of the Scala standard library), are not subclasses of `Data`.
+`DataView` provides a mechanism to _view_ a `Tuple` as if it were a `Data`:
+
+<!-- TODO replace this with stdlib import -->
+
+```scala mdoc:invisible
+// ProductDataProduct
+implicit val productDataProduct: DataProduct[Product] = new DataProduct[Product] {
+  def dataIterator(a: Product, path: String): Iterator[(Data, String)] = {
+    a.productIterator.zipWithIndex.collect { case (d: Data, i) => d -> s"$path._$i" }
+  }
+}
+```
+
+```scala mdoc
+// We need a type to represent the Tuple
+class HWTuple2[A <: Data, B <: Data](val _1: A, val _2: B) extends Bundle
+
+// Provide DataView between Tuple and HWTuple
+implicit def view[A <: Data, B <: Data]: DataView[(A, B), HWTuple2[A, B]] =
+  DataView(tup => new HWTuple2(tup._1.cloneType, tup._2.cloneType),
+           _._1 -> _._1, _._2 -> _._2)
+```
+
+Now, we can use `.viewAs` to view Tuples as if they were subtypes of `Data`:
+
+```scala mdoc
+class TupleVerboseExample extends RawModule {
+  val a, b, c, d = IO(Input(UInt(8.W)))
+  val cond = IO(Input(Bool()))
+  val x, y = IO(Output(UInt(8.W)))
+  (x, y).viewAs[HWTuple2[UInt, UInt]] := Mux(cond, (a, b).viewAs[HWTuple2[UInt, UInt]], (c, d).viewAs[HWTuple2[UInt, UInt]])
+}
+```
+
+This is much more verbose than the original idea of just using the Tuples directly as if they were `Data`.
+We can make this better by providing an implicit conversion that views a `Tuple` as a `HWTuple2`:
+
+```scala mdoc
+implicit def tuple2hwtuple[A <: Data, B <: Data](tup: (A, B)): HWTuple2[A, B] =
+  tup.viewAs[HWTuple2[A, B]]
+```
+
+Now, the original code just works!
+
+```scala mdoc
+class TupleExample extends RawModule {
+  val a, b, c, d = IO(Input(UInt(8.W)))
+  val cond = IO(Input(Bool()))
+  val x, y = IO(Output(UInt(8.W)))
+  (x, y) := Mux(cond, (a, b), (c, d))
+}
+```
+
+```scala mdoc:invisible
+// Always emit Verilog to make sure it actually works
+emitVerilog(new TupleExample)
+```
+
+Note that this example ignored `DataProduct` which is another required piece (see [the documentation
+about it below](#dataproduct)).
+
+All of this is slated to be included the Chisel standard library.
+
+## Totality and PartialDataView
+
+A `DataView` is _total_ if all fields of the _Target_ type and all fields of the _View_ type are 
+included in the mapping.
+Chisel will error if a field is accidentally left out from a `DataView`.
+For example:
+
+```scala mdoc
+class BundleA extends Bundle {
+  val foo = UInt(8.W)
+  val bar = UInt(8.W)
+}
+class BundleB extends Bundle {
+  val fizz = UInt(8.W)
+}
+```
+
+```scala mdoc:crash
+{ // Using an extra scope here to avoid a bug in mdoc (documentation generation)
+// We forgot BundleA.foo in the mapping!
+implicit val myView = DataView[BundleA, BundleB](_ => new BundleB, _.bar -> _.fizz)
+class BadMapping extends Module {
+   val in = IO(Input(new BundleA))
+   val out = IO(Output(new BundleB))
+   out := in.viewAs[BundleB]
+}
+// We must run Chisel to see the error
+emitVerilog(new BadMapping)
+}
+```
+
+As that error suggests, if we *want* the view to be non-total, we can use a `PartialDataView`:
+
+```scala mdoc
+// A PartialDataView does not have to be total for the Target
+implicit val myView = PartialDataView[BundleA, BundleB](_ => new BundleB, _.bar -> _.fizz)
+class PartialDataViewModule extends Module {
+   val in = IO(Input(new BundleA))
+   val out = IO(Output(new BundleB))
+   out := in.viewAs[BundleB]
+}
+```
+
+```scala mdoc:verilog
+emitVerilog(new PartialDataViewModule)
+```
+
+While `PartialDataViews` need not be total for the _Target_, both `PartialDataViews` and `DataViews`
+must always be total for the _View_.
+This has the consequence that `PartialDataViews` are **not** invertible in the same way as `DataViews`.
+
+For example:
+
+```scala mdoc:crash
+{ // Using an extra scope here to avoid a bug in mdoc (documentation generation)
+implicit val myView2 = myView.invert(_ => new BundleA)
+class PartialDataViewModule2 extends Module {
+   val in = IO(Input(new BundleA))
+   val out = IO(Output(new BundleB))
+   // Using the inverted version of the mapping
+   out.viewAs[BundleA] := in
+}
+// We must run Chisel to see the error
+emitVerilog(new PartialDataViewModule2)
+}
+```
+
+As noted, the mapping must **always** be total for the `View`.
+
+## Advanced Details
+
+`DataView` takes advantage of features of Scala that may be new to many users of Chisel—in particular
+[Type Classes](#type-classes).
+
+### Type Classes
+
+[Type classes](https://en.wikipedia.org/wiki/Type_class) are powerful language feature for writing
+polymorphic code.
+They are a common feature in "modern programming languages" like
+Scala,
+Swift (see [protocols](https://docs.swift.org/swift-book/LanguageGuide/Protocols.html)),
+and Rust (see [traits](https://doc.rust-lang.org/book/ch10-02-traits.html)). 
+Type classes may appear similar to inheritance in object-oriented programming but there are some
+important  differences:
+
+1. You can provide a type class for a type you don't own (eg. one defined in a 3rd party library,
+  the Scala standard library, or Chisel itself)
+2. You can write a single type class for many types that do not have a sub-typing relationship
+3. You can provide multiple different type classes for the same type
+
+For `DataView`, (1) is crucial because we want to be able to implement `DataViews` of built-in Scala
+types like tuples and `Seqs`. Furthermore, `DataView` has two type parameters (the _Target_ and the
+_View_ types) so inheritance does not really make sense—which type would `extend` `DataView`?
+
+In Scala 2, type classes are not a built-in language feature, but rather are implemented using implicits.
+There are great resources out there for interested readers:
+* [Basic Tutorial](https://scalac.io/blog/typeclasses-in-scala/)
+* [Fantastic Explanation on StackOverflow](https://stackoverflow.com/a/5598107/2483329)
+
+Note that Scala 3 has added built-in syntax for type classes that does not apply to Chisel 3 which
+currently only supports Scala 2.
+
+### Implicit Resolution
+
+Given that `DataView` is implemented using implicits, it is important to understand implicit
+resolution.
+Whenever the compiler sees an implicit argument is required, it first looks in _current scope_
+before looking in the _implicit scope_.
+
+1. Current scope
+    * Values defined in the current scope
+    * Explicit imports
+    * Wildcard imports
+2. Implicit scope
+    * Companion object of a type
+    * Implicit scope of an argument's type
+    * Implicit scope of type parameters
+    
+If at either stage, multiple implicits are found, then the static overloading rule is used to resolve
+it.
+Put simply, if one implicit applies to a more-specific type than the other, the more-specific one
+will be selected.
+If multiple implicits apply within a given stage, then the compiler throws an ambiguous implicit
+resolution error.
+
+
+This section draws heavily from [[1]](https://stackoverflow.com/a/5598107/2483329) and
+[[2]](https://stackoverflow.com/a/5598107/2483329).
+In particular, see [1] for examples.
+
+#### Implicit Resolution Example
+
+To help clarify a bit, let us consider how implicit resolution works for `DataView`.
+Consider the definition of `viewAs`:
+
+```scala
+def viewAs[V <: Data](implicit dataView: DataView[T, V]): V
+```
+
+Armed with the knowledge from the previous section, we know that whenever we call `.viewAs`, the
+Scala compiler will first look for a `DataView[T, V]` in the current scope (defined in, or imported),
+then it will look in the companion objects of `DataView`, `T`, and `V`.
+This enables a fairly powerful pattern, namely that default or typical implementations of a `DataView`
+should be defined in the companion object for one of the two types.
+We can think about `DataViews` defined in this way as "low priority defaults".
+They can then be overruled by a specific import if a given user ever wants different behavior.
+For example:
+
+Given the following types:
+
+```scala mdoc
+class Foo extends Bundle {
+  val a = UInt(8.W)
+  val b = UInt(8.W)
+}
+class Bar extends Bundle {
+  val c = UInt(8.W)
+  val d = UInt(8.W)
+}
+object Foo {
+  implicit val f2b = DataView[Foo, Bar](_ => new Bar, _.a -> _.c, _.b -> _.d)
+  implicit val b2f = f2b.invert(_ => new Foo)
+}
+```
+
+This provides an implementation of `DataView` in the _implicit scope_ as a "default" mapping between
+`Foo` and `Bar` (and it doesn't even require an import!):
+
+```scala mdoc
+class FooToBar extends Module {
+  val foo = IO(Input(new Foo))
+  val bar = IO(Output(new Bar))
+  bar := foo.viewAs[Bar]
+}
+```
+
+```scala mdoc:verilog
+emitVerilog(new FooToBar)
+```
+
+However, it's possible that some user of `Foo` and `Bar` wants different behavior,
+perhaps they would prefer more of "swizzling" behavior rather than a direct mapping:
+
+```scala mdoc
+object Swizzle {
+  implicit val swizzle = DataView[Foo, Bar](_ => new Bar, _.a -> _.d, _.b -> _.c)
+}
+// Current scope always wins over implicit scope
+import Swizzle._
+class FooToBarSwizzled extends Module {
+  val foo = IO(Input(new Foo))
+  val bar = IO(Output(new Bar))
+  bar := foo.viewAs[Bar]
+}
+```
+
+```scala mdoc:verilog
+emitVerilog(new FooToBarSwizzled)
+```
+
+### DataProduct
+
+`DataProduct` is a type class used by `DataView` to validate the correctness of a user-provided mapping.
+In order for a type to be "viewable" (ie. the `Target` type of a `DataView`), it must have an
+implementation of `DataProduct`.
+
+For example, say we have some non-Bundle type:
+```scala mdoc
+// Loosely based on chisel3.util.Counter
+class MyCounter(val width: Int) {
+  /** Indicates if the Counter is incrementing this cycle */
+  val active = WireDefault(false.B)
+  val value = RegInit(0.U(width.W))
+  def inc(): Unit = {
+    active := true.B
+    value := value + 1.U
+  }
+  def reset(): Unit = {
+    value := 0.U
+  }
+}
+```
+
+Say we want to view `MyCounter` as a `Valid[UInt]`:
+
+```scala mdoc:fail
+import chisel3.util.Valid
+implicit val counterView = DataView[MyCounter, Valid[UInt]](c => Valid(UInt(c.width.W)), _.value -> _.bits, _.active -> _.valid)
+```
+
+As you can see, this fails Scala compliation.
+We need to provide an implementation of `DataProduct[MyCounter]` which provides Chisel a way to access
+the objects of type `Data` within `MyCounter`:
+
+```scala mdoc:silent
+import chisel3.util.Valid
+implicit val counterProduct = new DataProduct[MyCounter] {
+  // The String part of the tuple is a String path to the object to help in debugging
+  def dataIterator(a: MyCounter, path: String): Iterator[(Data, String)] =
+    List(a.value -> s"$path.value", a.active -> s"$path.active").iterator
+}
+// Now this works
+implicit val counterView = DataView[MyCounter, Valid[UInt]](c => Valid(UInt(c.width.W)), _.value -> _.bits, _.active -> _.valid)
+```
+
+Why is this useful?
+This is how Chisel is able to check for totality as [described above](#totality-and-partialdataview).
+In addition to checking if a user has left a field out of the mapping, it also allows Chisel to check
+if the user has included a `Data` in the mapping that isn't actually a part of the _target_ nor the
+_view_.
+
diff --git a/docs/src/explanations/explanations.md b/docs/src/explanations/explanations.md
new file mode 100644
index 00000000..01894ad7
--- /dev/null
+++ b/docs/src/explanations/explanations.md
@@ -0,0 +1,39 @@
+---
+layout: docs
+title:  "Explanations"
+section: "chisel3"
+---
+
+# Explanations
+
+Explanation documentation gives background and context.
+They can also explain why things are so - design decisions,
+historical reasons, technical constraints.
+
+If you are just getting started with Chisel, we suggest you
+read these documents in the following order:
+
+* [Motivation](motivation)
+* [Supported Hardware](supported-hardware)
+* [Data Types](data-types)
+* [Bundles and Vecs](bundles-and-vecs)
+* [Combinational Circuits](combinational-circuits)
+* [Operators](operators)
+* [Width Inference](width-inference)
+* [Functional Abstraction](functional-abstraction)
+* [Ports](ports)
+* [Modules](modules)
+* [Sequential Circuits](sequential-circuits)
+* [Memories](memories)
+* [Interfaces and Connections](interfaces-and-connections)
+* [Black Boxes](blackboxes)
+* [Enumerations](enumerations)
+* [Functional Module Creation](functional-module-creation)
+* [Muxes and Input Selection](muxes-and-input-selection)
+* [Multiple Clock Domains](multi-clock)
+* [Reset](reset)
+* [Polymorphism and Paramterization](polymorphism-and-parameterization)
+* [Printing in Chisel](printing)
+* [Naming](naming)
+* [Unconnected Wires](unconnected-wires)
+* [Annotations](annotations)
diff --git a/docs/src/wiki-deprecated/functional-abstraction.md b/docs/src/explanations/functional-abstraction.md
index 04dde7d1..4e3900b6 100644
--- a/docs/src/wiki-deprecated/functional-abstraction.md
+++ b/docs/src/explanations/functional-abstraction.md
@@ -3,11 +3,19 @@ layout: docs
 title:  "Functional Abstraction"
 section: "chisel3"
 ---
+
+# Functional Abstraction
+
 We can define functions to factor out a repeated piece of logic that
 we later reuse multiple times in a design.  For example, we can wrap
 up our earlier example of a simple combinational logic block as
 follows:
-```scala
+
+```scala mdoc:invisible
+import chisel3._
+```
+
+```scala mdoc:silent
 def clb(a: UInt, b: UInt, c: UInt, d: UInt): UInt =
   (a & b) | (~c & d)
 ```
@@ -21,9 +29,6 @@ argument list.  The equals (```=})```sign separates the function argument list f
 definition.
 
 We can then use the block in another circuit as follows:
-```scala
+```scala mdoc:silent
 val out = clb(a,b,c,d)
 ```
-
-We will later describe many powerful ways to use functions to
-construct hardware using Scala's functional programming support.
diff --git a/docs/src/wiki-deprecated/functional-module-creation.md b/docs/src/explanations/functional-module-creation.md
index 3e2e95bc..407edb1d 100644
--- a/docs/src/wiki-deprecated/functional-module-creation.md
+++ b/docs/src/explanations/functional-module-creation.md
@@ -3,6 +3,9 @@ layout: docs
 title:  "Functional Module Creation"
 section: "chisel3"
 ---
+
+# Functional Module Creation
+
 Objects in Scala have a pre-existing creation function (method) called `apply`.
 When an object is used as value in an expression (which basically means that the constructor was called), this method determines the returned value.
 When dealing with hardware modules, one would expect the module output to be representative of the hardware module's functionality.
@@ -12,7 +15,19 @@ This can be referred to as creating a functional interface for module constructi
 If we apply this on the standard mux2 example, we would to return the mux2 output ports when we used mux2 in an expression.
 Implementing this requires building a constructor that takes multiplexer inputs as parameters and returns the multiplexer output:
 
-```scala
+```scala mdoc:silent
+import chisel3._
+
+class Mux2 extends Module {
+  val io = IO(new Bundle {
+    val sel = Input(Bool())
+    val in0 = Input(UInt())
+    val in1 = Input(UInt())
+    val out = Output(UInt())
+  })
+  io.out := Mux(io.sel, io.in0, io.in1)
+}
+
 object Mux2 {
   def apply(sel: UInt, in0: UInt, in1: UInt) = {
     val m = Module(new Mux2)
@@ -28,7 +43,7 @@ As we can see in the code example, we defined the `apply` method to take the Mux
 By defining modules in this way, it is easier to later implement larger and more complex version of this regular module.
 For example, we previously implemented Mux4 like this:
 
-```scala
+```scala mdoc:silent
 class Mux4 extends Module {
   val io = IO(new Bundle {
     val in0 = Input(UInt(1.W))
@@ -60,7 +75,33 @@ class Mux4 extends Module {
 However, by using the creation function we redefined for Mux2, we can now use the Mux2 outputs as values of the modules themselves
 when writing the Mux4 output expression:
 
-```scala
+```scala mdoc:invisible:reset
+// We need to re-do this to allow us to `reset`
+// and then re-define Mux4
+import chisel3._
+
+class Mux2 extends Module {
+  val io = IO(new Bundle {
+    val sel = Input(Bool())
+    val in0 = Input(UInt())
+    val in1 = Input(UInt())
+    val out = Output(UInt())
+  })
+  io.out := Mux(io.sel, io.in0, io.in1)
+}
+
+object Mux2 {
+  def apply(sel: UInt, in0: UInt, in1: UInt) = {
+    val m = Module(new Mux2)
+    m.io.in0 := in0
+    m.io.in1 := in1
+    m.io.sel := sel
+    m.io.out
+  }
+}
+```
+
+```scala mdoc:silent
 class Mux4 extends Module {
   val io = IO(new Bundle {
     val in0 = Input(UInt(1.W))
@@ -76,4 +117,4 @@ class Mux4 extends Module {
 }
 ```
 
-This allows to write more intuitively readable hardware connection descriptions, which are similar to software expression evaluation.
+This allows us to write more intuitively readable hardware connection descriptions, which are similar to software expression evaluation.
diff --git a/docs/src/wiki-deprecated/interfaces-and-connections.md b/docs/src/explanations/interfaces-and-connections.md
index 5902f5cd..9f48b642 100644
--- a/docs/src/wiki-deprecated/interfaces-and-connections.md
+++ b/docs/src/explanations/interfaces-and-connections.md
@@ -3,6 +3,7 @@ layout: docs
 title:  "Interfaces and Connections"
 section: "chisel3"
 ---
+
 # Interfaces & Bulk Connections
 
 For more sophisticated modules it is often useful to define and instantiate interface classes while defining the IO for a module. First and foremost, interface classes promote reuse allowing users to capture once and for all common interfaces in a useful form.
@@ -15,7 +16,11 @@ Note that Chisel has some built-in standard interface which should be used whene
 
 As we saw earlier, users can define their own interfaces by defining a class that subclasses Bundle. For example, a user could define a simple link for hand-shaking data as follows:
 
-```scala
+```scala mdoc:invisible
+import chisel3._
+```
+
+```scala mdoc:silent
 class SimpleLink extends Bundle {
   val data = Output(UInt(16.W))
   val valid = Output(Bool())
@@ -23,7 +28,7 @@ class SimpleLink extends Bundle {
 ```
 
 We can then extend SimpleLink by adding parity bits using bundle inheritance:
-```scala
+```scala mdoc:silent
 class PLink extends SimpleLink {
   val parity = Output(UInt(5.W))
 }
@@ -31,7 +36,7 @@ class PLink extends SimpleLink {
 In general, users can organize their interfaces into hierarchies using inheritance.
 
 From there we can define a filter interface by nesting two PLinks into a new FilterIO bundle:
-```scala
+```scala mdoc:silent
 class FilterIO extends Bundle {
   val x = Flipped(new PLink)
   val y = new PLink
@@ -40,10 +45,10 @@ class FilterIO extends Bundle {
 where flip recursively changes the direction of a bundle, changing input to output and output to input.
 
 We can now define a filter by defining a filter class extending module:
-```scala
+```scala mdoc:silent
 class Filter extends Module {
   val io = IO(new FilterIO)
-  ...
+  // ...
 }
 ```
 where the io field contains FilterIO.
@@ -51,7 +56,7 @@ where the io field contains FilterIO.
 ## Bundle Vectors
 
 Beyond single elements, vectors of elements form richer hierarchical interfaces. For example, in order to create a crossbar with a vector of inputs, producing a vector of outputs, and selected by a UInt input, we utilize the Vec constructor:
-```scala
+```scala mdoc:silent
 import chisel3.util.log2Ceil
 class CrossbarIo(n: Int) extends Bundle {
   val in = Vec(n, Flipped(new PLink))
@@ -64,7 +69,7 @@ where Vec takes a size as the first argument and a block returning a port as the
 ## Bulk Connections
 
 We can now compose two filters into a filter block as follows:
-```scala
+```scala mdoc:silent
 class Block extends Module {
   val io = IO(new FilterIO)
   val f1 = Module(new Filter)
@@ -96,7 +101,7 @@ Usually, we use the utility function [`Decoupled()`](https://chisel.eecs.berkele
 
 Take a look at the following example Chisel code to better understand exactly what is generated:
 
-```scala
+```scala mdoc:silent:reset
 import chisel3._
 import chisel3.util.Decoupled
 
diff --git a/docs/src/wiki-deprecated/memories.md b/docs/src/explanations/memories.md
index e4b9a80b..10759f25 100644
--- a/docs/src/wiki-deprecated/memories.md
+++ b/docs/src/explanations/memories.md
@@ -3,41 +3,45 @@ layout: docs
 title:  "Memories"
 section: "chisel3"
 ---
+
+# Memories
+
 Chisel provides facilities for creating both read only and read/write memories.
 
 ## ROM
 
-Users can define read only memories with a `Vec`:
+Users can define read-only memories by constructing a `Vec` with `VecInit`.
+`VecInit` can accept either a variable-argument number of `Data` literals or a `Seq[Data]` literals that initialize the ROM.
 
-``` scala
-    VecInit(inits: Seq[T])
-    VecInit(elt0: T, elts: T*)
+For example, users can create a small ROM initialized to 1, 2, 4, 8 and loop through all values using a counter as an address generator as follows:
+
+```scala mdoc:compile-only
+import chisel3._
+import chisel3.util.Counter
+val m = VecInit(1.U, 2.U, 4.U, 8.U)
+val c = Counter(m.length)
+c.inc()
+val r = m(c.value)
 ```
 
-where `inits` is a sequence of initial `Data` literals that initialize the ROM. For example,  users cancreate a small ROM initialized to 1, 2, 4, 8 and loop through all values using a counter as an address generator as follows:
+We can create an *n* value sine lookup table generator using a ROM initialized as follows:
 
-``` scala
-    val m = VecInit(Array(1.U, 2.U, 4.U, 8.U))
-    val r = m(counter(m.length.U))
-```
+```scala mdoc:compile-only
+import chisel3._
 
-We can create an *n* value sine lookup table using a ROM initialized as follows:
-
-``` scala
-    def sinTable(amp: Double, n: Int) = {
-      val times =
-        (0 until n).map(i => (i*2*Pi)/(n.toDouble-1) - Pi)
-      val inits =
-        times.map(t => round(amp * sin(t)).asSInt(32.W))
-      VecInit(inits)
-    }
-    def sinWave(amp: Double, n: Int) =
-      sinTable(amp, n)(counter(n.U))
+val Pi = math.Pi
+def sinTable(amp: Double, n: Int) = {
+  val times =
+    (0 until n).map(i => (i*2*Pi)/(n.toDouble-1) - Pi)
+  val inits =
+    times.map(t => Math.round(amp * math.sin(t)).asSInt(32.W))
+  VecInit(inits)
+}
 ```
 
 where `amp` is used to scale the fixpoint values stored in the ROM.
 
-## Memories
+## Read-Write Memories
 
 Memories are given special treatment in Chisel since hardware implementations of memory vary greatly. For example, FPGA memories are instantiated quite differently from ASIC memories. Chisel defines a memory abstraction that can map to either simple Verilog behavioural descriptions or to instances of memory modules that are available from external memory generators provided by foundry or IP vendors.
 
@@ -51,6 +55,7 @@ If the same memory address is both written and sequentially read on the same clo
 Values on the read data port are not guaranteed to be held until the next read cycle. If that is the desired behavior, external logic to hold the last read value must be added.
 
 #### Read port/write port
+
 Ports into `SyncReadMem`s are created by applying a `UInt` index.  A 1024-entry SRAM with one write port and one read port might be expressed as follows:
 
 ```scala mdoc:silent
@@ -74,9 +79,11 @@ class ReadWriteSmem extends Module {
 
 Below is an example waveform of the one write port/one read port `SyncReadMem` with [masks](#masks). Note that the signal names will differ from the exact wire names generated for the `SyncReadMem`. With masking, it is also possible that multiple RTL arrays will be generated with the behavior below.
 
-![read/write ports example waveform](https://svg.wavedrom.com/github/freechipsproject/www.chisel-lang.org/master/docs/src/main/tut/chisel3/memories_waveforms/smem_read_write.json)    
+![read/write ports example waveform](https://svg.wavedrom.com/github/freechipsproject/www.chisel-lang.org/master/docs/src/main/resources/json/smem_read_write.json)    
+
 
 #### Single-ported
+
 Single-ported SRAMs can be inferred when the read and write conditions are mutually exclusive in the same `when` chain:
 
 ```scala mdoc:silent
@@ -105,7 +112,7 @@ class RWSmem extends Module {
 
 Here is an example single read/write port waveform, with [masks](#masks) (again, generated signal names and number of arrays may differ):
 
-![read/write ports example waveform](https://svg.wavedrom.com/github/freechipsproject/www.chisel-lang.org/master/docs/src/main/tut/chisel3/memories_waveforms/smem_rw.json)
+![read/write ports example waveform](https://svg.wavedrom.com/github/freechipsproject/www.chisel-lang.org/master/docs/src/main/resources/json/smem_rw.json)
 
 ### `Mem`: combinational/asynchronous-read, sequential/synchronous-write
 
@@ -168,3 +175,10 @@ class MaskedRWSmem extends Module {
   }
 }
 ```
+
+### Memory Initialization
+
+Chisel memories can be initialized from an external `binary` or `hex` file emitting proper Verilog for synthesis or simulation. There are multiple modes of initialization.
+
+For more information, check the experimental docs on [Loading Memories](../appendix/experimental-features#loading-memories) feature.
+
diff --git a/docs/src/wiki-deprecated/modules.md b/docs/src/explanations/modules.md
index 23006c9c..f82a14d6 100644
--- a/docs/src/wiki-deprecated/modules.md
+++ b/docs/src/explanations/modules.md
@@ -3,6 +3,9 @@ layout: docs
 title:  "Modules"
 section: "chisel3"
 ---
+
+# Modules
+
 Chisel *modules* are very similar to Verilog *modules* in
 defining a hierarchical structure in the generated circuit.
 
@@ -116,8 +119,8 @@ class Foo extends Module {
 class FooWrapper extends RawModule {
   val a_i  = IO(Input(Bool()))
   val b_o  = IO(Output(Bool()))
-  val clk  = Input(Clock())
-  val rstn = Input(Bool())
+  val clk  = IO(Input(Clock()))
+  val rstn = IO(Input(Bool()))
 
   val foo = withClockAndReset(clk, !rstn){ Module(new Foo) }
 
diff --git a/docs/src/wiki-deprecated/introduction.md b/docs/src/explanations/motivation.md
index 43fc9887..afe02a7b 100644
--- a/docs/src/wiki-deprecated/introduction.md
+++ b/docs/src/explanations/motivation.md
@@ -1,32 +1,12 @@
 ---
 layout: docs
-title:  "Introduction"
+title:  "Motivation"
 section: "chisel3"
 ---
-This document is a tutorial introduction to _Chisel_ (Constructing
-Hardware In a Scala Embedded Language).  Chisel is a hardware
-construction language embedded in the high-level programming language
-Scala.  At some point we will provide a proper reference manual, in
-addition to more tutorial examples.  In the meantime, this document
-along with a lot of trial and error should set you on your way to
-using Chisel. _Chisel is really only a set of special class
-definitions, predefined objects, and usage conventions within Scala,
-so when you write Chisel you are actually writing a Scala
-program that constructs a hardware graph._  However, for the tutorial we don't presume that you
-understand how to program in Scala.  We will point out necessary Scala
-features through the Chisel examples we give, and significant hardware
-designs can be completed using only the material contained herein.
-But as you gain experience and want to make your code simpler or more
-reusable, you will find it important to leverage the underlying power
-of the Scala language. We recommend you consult one of the excellent
-Scala books to become more expert in Scala programming.
 
->Through the tutorial, we format commentary on our design choices as in
-this paragraph.  You should be able to skip the commentary sections
-and still fully understand how to use Chisel, but we hope you'll find
-them interesting.
+# Motivation -- "Why Chisel?"
 
->We were motivated to develop a new hardware language by years of
+We were motivated to develop a new hardware language by years of
 struggle with existing hardware description languages in our research
 projects and hardware design courses.  _Verilog_ and _VHDL_ were developed
 as hardware _simulation_ languages, and only later did they become
@@ -39,7 +19,7 @@ While it is possible to use a subset of these languages and still get
 acceptable results, they nonetheless present a cluttered and confusing
 specification model, particularly in an instructional setting.
 
->However, our strongest motivation for developing a new hardware
+However, our strongest motivation for developing a new hardware
 language is our desire to change the way that electronic system design
 takes place.  We believe that it is important to not only teach
 students how to design circuits, but also to teach them how to design
@@ -56,7 +36,7 @@ circuit generation, they lack the powerful facilities present in
 modern programming languages, such as object-oriented programming,
 type inference, support for functional programming, and reflection.
 
->Instead of building a new hardware design language from scratch, we
+Instead of building a new hardware design language from scratch, we
 chose to embed hardware construction primitives within an existing
 language.  We picked Scala not only because it includes the
 programming features we feel are important for building circuit
diff --git a/docs/src/wiki-deprecated/muxes-and-input-selection.md b/docs/src/explanations/muxes-and-input-selection.md
index fd7b7e7f..ae087e83 100644
--- a/docs/src/wiki-deprecated/muxes-and-input-selection.md
+++ b/docs/src/explanations/muxes-and-input-selection.md
@@ -3,19 +3,24 @@ layout: docs
 title:  "Muxes and Input Selection"
 section: "chisel3"
 ---
+
+# Muxes and Input Selection
+
 Selecting inputs is very useful in hardware description, and therefore Chisel provides several built-in generic input-selection implementations.
+
 ### Mux
 The first one is `Mux`. This is a 2-input selector. Unlike the `Mux2` example which was presented previously, the built-in `Mux` allows
 the inputs (`in0` and `in1`) to be any datatype as long as they are the same subclass of `Data`.
 
-by using the functional module creation feature presented in the previous section, we can create multi-input selector in a simple way:
+By using the functional module creation feature presented in the previous section, we can create multi-input selector in a simple way:
 
 ```scala
 Mux(c1, a, Mux(c2, b, Mux(..., default)))
 ```
 
 ### MuxCase
-However, this is not necessary since Chisel also provides the built-in `MuxCase`, which implements that exact feature.
+
+The nested `Mux` is not necessary since Chisel also provides the built-in `MuxCase`, which implements that exact feature.
 `MuxCase` is an n-way `Mux`, which can be used as follows:
 
 ```scala
@@ -44,13 +49,14 @@ MuxCase(default,
 Note that the conditions/cases/selectors (eg. c1, c2) must be in parentheses.
 
 ### Mux1H
-Another ```Mux``` utility is ```Mux1H``` that takes a sequence of selectors and values and returns the value associated with the one selector that is set. If zero or multiple selectors are set the behavior is undefined.  For example:
+Another ```Mux``` utility is the one-hot mux, ```Mux1H```. It takes a sequence of selectors and values and returns the value associated with the one selector that is set. If zero or multiple selectors are set the behavior is undefined.  For example:
+
 ```scala
-  val hotValue = chisel3.util.oneHotMux(Seq(
+  val hotValue = chisel3.util.Mux1H(Seq(
     io.selector(0) -> 2.U,
     io.selector(1) -> 4.U,
     io.selector(2) -> 8.U,
     io.selector(4) -> 11.U,
   ))
 ```
-```oneHotMux``` whenever possible generates *Firrtl* that is readily optimizable as low depth and/or tree.  This optimization is not possible when the values are of type ```FixedPoint``` or an aggregate type that contains ```FixedPoint```s and results instead as a simple ```Mux``` tree.  This behavior could be sub-optimal.  As ```FixedPoint``` is still *experimental* this behavior may change in the future.
+```Mux1H``` whenever possible generates *Firrtl* that is readily optimizable as low depth and/or tree.  This optimization is not possible when the values are of type ```FixedPoint``` or an aggregate type that contains ```FixedPoint```s and results instead as a simple ```Mux``` tree.  This behavior could be sub-optimal.  As ```FixedPoint``` is still *experimental* this behavior may change in the future.
diff --git a/docs/src/wiki-deprecated/operators.md b/docs/src/explanations/operators.md
index c23e2009..231a53fa 100644
--- a/docs/src/wiki-deprecated/operators.md
+++ b/docs/src/explanations/operators.md
@@ -3,7 +3,9 @@ layout: docs
 title:  "Operators"
 section: "chisel3"
 ---
-### List of operators
+
+# Chisel Operators
+
 Chisel defines a set of hardware operators:
 
 | Operation        | Explanation |
diff --git a/docs/src/wiki-deprecated/polymorphism-and-parameterization.md b/docs/src/explanations/polymorphism-and-parameterization.md
index c652baca..b388ee5b 100644
--- a/docs/src/wiki-deprecated/polymorphism-and-parameterization.md
+++ b/docs/src/explanations/polymorphism-and-parameterization.md
@@ -3,12 +3,15 @@ layout: docs
 title:  "Polymorphism and Parameterization"
 section: "chisel3"
 ---
+
+# Polymorphism and Parameterization
+
 _This section is advanced and can be skipped at first reading._
 
 Scala is a strongly typed language and uses parameterized types to specify generic functions and classes.
 In this section, we show how Chisel users can define their own reusable functions and classes using parameterized classes.
 
-# Parameterized Functions
+## Parameterized Functions
 
 Earlier we defined `Mux2` on `Bool`, but now we show how we can define a generic multiplexer function.
 We define this function as taking a boolean condition and con and alt arguments (corresponding to then and else expressions) of type `T`:
@@ -59,13 +62,15 @@ In this case, `reduce` creates a summation circuit.
 Finally, the `FIR` function is constrained to work on inputs of type `Num` where Chisel multiplication and addition are defined.
 --->
 
-# Parameterized Classes
+## Parameterized Classes
 
 Like parameterized functions, we can also parameterize classes to make them more reusable.
 For instance, we can generalize the Filter class to use any kind of link.
 We do so by parameterizing the `FilterIO` class and defining the constructor to take a single argument `gen` of type `T` as below.
-
-```scala
+```scala mdoc:invisible
+import chisel3._
+```
+```scala mdoc:silent
 class FilterIO[T <: Data](gen: T) extends Bundle {
   val x = Input(gen)
   val y = Output(gen)
@@ -74,22 +79,32 @@ class FilterIO[T <: Data](gen: T) extends Bundle {
 
 We can now define `Filter` by defining a module class that also takes a link type constructor argument and passes it through to the `FilterIO` interface constructor:
 
-```scala
+```scala mdoc:silent
 class Filter[T <: Data](gen: T) extends Module {
   val io = IO(new FilterIO(gen))
-  ...
+  // ...
 }
 ```
 
 We can now define a `PLink`-based `Filter` as follows:
-
-```scala
+```scala mdoc:invisible
+class SimpleLink extends Bundle {
+  val data = Output(UInt(16.W))
+  val valid = Output(Bool())
+}
+class PLink extends SimpleLink {
+  val parity = Output(UInt(5.W))
+}
+```
+```scala mdoc:compile-only
 val f = Module(new Filter(new PLink))
 ```
 
 A generic FIFO could be defined as follows:
 
-```scala
+```scala mdoc:silent
+import chisel3.util.log2Up
+
 class DataBundle extends Bundle {
   val a = UInt(32.W)
   val b = UInt(32.W)
@@ -104,8 +119,8 @@ class Fifo[T <: Data](gen: T, n: Int) extends Module {
     val enqDat = Input(gen)
     val deqDat = Output(gen)
   })
-  val enqPtr     = RegInit(0.asUInt(sizeof(n).W))
-  val deqPtr     = RegInit(0.asUInt(sizeof(n).W))
+  val enqPtr     = RegInit(0.U((log2Up(n)).W))
+  val deqPtr     = RegInit(0.U((log2Up(n)).W))
   val isFull     = RegInit(false.B)
   val doEnq      = io.enqRdy && io.enqVal
   val doDeq      = io.deqRdy && io.deqVal
@@ -118,7 +133,7 @@ class Fifo[T <: Data](gen: T, n: Int) extends Module {
   enqPtr := Mux(doEnq, enqPtrInc, enqPtr)
   deqPtr := Mux(doDeq, deqPtrInc, deqPtr)
   isFull := isFullNext
-  val ram = Mem(n)
+  val ram = Mem(n, gen)
   when (doEnq) {
     ram(enqPtr) := io.enqDat
   }
@@ -130,13 +145,20 @@ class Fifo[T <: Data](gen: T, n: Int) extends Module {
 
 An Fifo with 8 elements of type DataBundle could then be instantiated as:
 
-```scala
+```scala mdoc:compile-only
 val fifo = Module(new Fifo(new DataBundle, 8))
 ```
 
 It is also possible to define a generic decoupled (ready/valid) interface:
+```scala mdoc:invisible:reset
+import chisel3._
+class DataBundle extends Bundle {
+  val a = UInt(32.W)
+  val b = UInt(32.W)
+}
+```
 
-```scala
+```scala mdoc:silent
 class DecoupledIO[T <: Data](data: T) extends Bundle {
   val ready = Input(Bool())
   val valid = Output(Bool())
@@ -147,28 +169,30 @@ class DecoupledIO[T <: Data](data: T) extends Bundle {
 This template can then be used to add a handshaking protocol to any
 set of signals:
 
-```scala
+```scala mdoc:silent
 class DecoupledDemo extends DecoupledIO(new DataBundle)
 ```
 
 The FIFO interface can be now be simplified as follows:
 
-```scala
+```scala mdoc:silent
 class Fifo[T <: Data](data: T, n: Int) extends Module {
   val io = IO(new Bundle {
     val enq = Flipped(new DecoupledIO(data))
     val deq = new DecoupledIO(data)
   })
-  ...
+  // ...
 }
 ```
 
-# Parametrization based on Modules
+## Parametrization based on Modules
 
 You can also parametrize modules based on other modules rather than just types. The following is an example of a module parametrized by other modules as opposed to e.g. types.
 
-```scala
-import chisel3.experimental.{BaseModule, RawModule}
+```scala mdoc:silent
+import chisel3.RawModule
+import chisel3.experimental.BaseModule
+import chisel3.stage.ChiselStage
 
 // Provides a more specific interface since generic Module
 // provides no compile-time information on generic module's IOs.
@@ -204,6 +228,13 @@ class X[T <: BaseModule with MyAdder](genT: => T) extends Module {
     subMod.in2 := io.in2
 }
 
-println(chisel3.Driver.emitVerilog(new X(new Mod1)))
-println(chisel3.Driver.emitVerilog(new X(new Mod2)))
+println(ChiselStage.emitVerilog(new X(new Mod1)))
+println(ChiselStage.emitVerilog(new X(new Mod2)))
+```
+
+Output:
+
+```scala mdoc:verilog
+ChiselStage.emitVerilog(new X(new Mod1))
+ChiselStage.emitVerilog(new X(new Mod2))
 ```
diff --git a/docs/src/wiki-deprecated/ports.md b/docs/src/explanations/ports.md
index 251ce243..ce38cf22 100644
--- a/docs/src/wiki-deprecated/ports.md
+++ b/docs/src/explanations/ports.md
@@ -3,6 +3,9 @@ layout: docs
 title:  "Ports"
 section: "chisel3"
 ---
+
+# Ports
+
 Ports are used as interfaces to hardware components.  A port is simply
 any `Data` object that has directions assigned to its members.
 
@@ -11,7 +14,10 @@ Chisel provides port constructors to allow a direction to be added
 constructors wrap the type of the port in `Input` or `Output`.
 
 An example port declaration is as follows:
-```scala
+```scala mdoc:invisible
+import chisel3._
+```
+```scala mdoc
 class Decoupled extends Bundle {
   val ready = Output(Bool())
   val data  = Input(UInt(32.W))
@@ -33,8 +39,9 @@ provide powerful wiring constructs described later.
 Chisel 3.2 introduced `DataMirror.modulePorts` which can be used to inspect the IOs of any Chisel module (this includes modules in both `import chisel3._` and `import Chisel._`, as well as BlackBoxes from each package).
 Here is an example of how to use this API:
 
-```scala
+```scala mdoc
 import chisel3.experimental.DataMirror
+import chisel3.stage.{ChiselGeneratorAnnotation, ChiselStage}
 
 class Adder extends Module {
   val a = IO(Input(UInt(8.W)))
@@ -50,18 +57,11 @@ class Test extends Module {
   adder.b := DontCare
 
   // Inspect ports of adder
-  // Prints something like this
-  /**
-    * Found port clock: Clock(IO clock in Adder)
-    * Found port reset: Bool(IO reset in Adder)
-    * Found port a: UInt<8>(IO a in Adder)
-    * Found port b: UInt<8>(IO b in Adder)
-    * Found port c: UInt<8>(IO c in Adder)
-    */
-  DataMirror.modulePorts(adder).foreach { case (name, port) => {
+  // See the result below.
+   DataMirror.modulePorts(adder).foreach { case (name, port) => {
     println(s"Found port $name: $port")
   }}
 }
 
-chisel3.Driver.execute(Array[String](), () => new Test)
-```
+(new ChiselStage).execute(Array.empty, Seq(ChiselGeneratorAnnotation(() => new Test)))
+```
\ No newline at end of file
diff --git a/docs/src/wiki-deprecated/printing.md b/docs/src/explanations/printing.md
index 36dcfaae..abd1a427 100644
--- a/docs/src/wiki-deprecated/printing.md
+++ b/docs/src/explanations/printing.md
@@ -3,6 +3,9 @@ layout: docs
 title:  "Printing"
 section: "chisel3"
 ---
+
+# Printing in Chisel
+
 Chisel provides the `printf` function for debugging purposes. It comes in two flavors:
 
 * [Scala-style](#scala-style)
@@ -12,14 +15,17 @@ Chisel provides the `printf` function for debugging purposes. It comes in two fl
 
 Chisel also supports printf in a style similar to [Scala's String Interpolation](http://docs.scala-lang.org/overviews/core/string-interpolation.html). Chisel provides a custom string interpolator `p` which can be used as follows:
 
-```scala
+```scala mdoc:invisible
+import chisel3._
+```
+```scala mdoc:compile-only
 val myUInt = 33.U
 printf(p"myUInt = $myUInt") // myUInt = 33
 ```
 
 Note that when concatenating `p"..."` strings, you need to start with a `p"..."` string:
 
-```scala
+```scala mdoc:compile-only
 // Does not interpolate the second string
 val myUInt = 33.U
 printf("my normal string" + p"myUInt = $myUInt")
@@ -29,7 +35,8 @@ printf("my normal string" + p"myUInt = $myUInt")
 
 Other formats are available as follows:
 
-```scala
+```scala mdoc:compile-only
+val myUInt = 33.U
 // Hexadecimal
 printf(p"myUInt = 0x${Hexadecimal(myUInt)}") // myUInt = 0x21
 // Binary
@@ -44,8 +51,8 @@ We recognize that the format specifiers are verbose, so we are working on a more
 
 Chisel provides default custom "pretty-printing" for Vecs and Bundles. The default printing of a Vec is similar to printing a Seq or List in Scala while printing a Bundle is similar to printing a Scala Map.
 
-```scala
-val myVec = Vec(5.U, 10.U, 13.U)
+```scala mdoc:compile-only
+val myVec = VecInit(5.U, 10.U, 13.U)
 printf(p"myVec = $myVec") // myVec = Vec(5, 10, 13)
 
 val myBundle = Wire(new Bundle {
@@ -61,7 +68,7 @@ printf(p"myBundle = $myBundle") // myBundle = Bundle(a -> 3, b -> 11)
 
 Chisel also provides the ability to specify _custom_ printing for user-defined Bundles.
 
-```scala
+```scala mdoc:compile-only
 class Message extends Bundle {
   val valid = Bool()
   val addr = UInt(32.W)
@@ -124,7 +131,7 @@ Note that single quotes do not require escaping, but are legal to escape.
 
 Thus printf can be used in a way very similar to how it is used in C:
 
-```scala
+```scala mdoc:compile-only
 val myUInt = 32.U
 printf("myUInt = %d", myUInt) // myUInt = 32
 ```
diff --git a/docs/src/wiki-deprecated/reset.md b/docs/src/explanations/reset.md
index f5e4a24a..a99a39e3 100644
--- a/docs/src/wiki-deprecated/reset.md
+++ b/docs/src/explanations/reset.md
@@ -4,6 +4,8 @@ title:  "Reset"
 section: "chisel3"
 ---
 
+# Reset
+
 ```scala mdoc:invisible
 import chisel3._
 
diff --git a/docs/src/wiki-deprecated/sequential-circuits.md b/docs/src/explanations/sequential-circuits.md
index 10294403..36bbb1aa 100644
--- a/docs/src/wiki-deprecated/sequential-circuits.md
+++ b/docs/src/explanations/sequential-circuits.md
@@ -3,8 +3,15 @@ layout: docs
 title:  "Sequential Circuits"
 section: "chisel3"
 ---
+
+# Sequential Circuits
+
+```scala mdoc:invisible
+import chisel3._
+val in = Bool()
+```
 The simplest form of state element supported by Chisel is a positive edge-triggered register, which can be instantiated as:
-```scala
+```scala mdoc:compile-only
 val reg = RegNext(in)
 ```
 This circuit has an output that is a copy of the input signal `in` delayed by one clock cycle. Note that we do not have to specify the type of Reg as it will be automatically inferred from its input when instantiated in this way. In the current version of Chisel, clock and reset are global signals that are implicitly included where needed.
@@ -12,25 +19,26 @@ This circuit has an output that is a copy of the input signal `in` delayed by on
 Note that registers which do not specify an initial value will not change value upon toggling the reset signal.
 
 Using registers, we can quickly define a number of useful circuit constructs. For example, a rising-edge detector that takes a boolean signal in and outputs true when the current value is true and the previous value is false is given by:
-```scala
+
+```scala mdoc:silent
 def risingedge(x: Bool) = x && !RegNext(x)
 ```
 Counters are an important sequential circuit. To construct an up-counter that counts up to a maximum value, max, then wraps around back to zero (i.e., modulo max+1), we write:
-```scala
+```scala mdoc:silent
 def counter(max: UInt) = {
-  val x = RegInit(0.asUInt(max.getWidth))
+  val x = RegInit(0.asUInt(max.getWidth.W))
   x := Mux(x === max, 0.U, x + 1.U)
   x
 }
 ```
 The counter register is created in the counter function with a reset value of 0 (with width large enough to hold max), to which the register will be initialized when the global reset for the circuit is asserted. The := assignment to x in counter wires an update combinational circuit which increments the counter value unless it hits the max at which point it wraps back to zero. Note that when x appears on the right-hand side of an assignment, its output is referenced, whereas when on the left-hand side, its input is referenced.
 Counters can be used to build a number of useful sequential circuits. For example, we can build a pulse generator by outputting true when a counter reaches zero:
-```scala
+```scala mdoc:silent
 // Produce pulse every n cycles.
 def pulse(n: UInt) = counter(n - 1.U) === 0.U
 ```
 A square-wave generator can then be toggled by the pulse train, toggling between true and false on each pulse:
-```scala
+```scala mdoc:silent
 // Flip internal state when input true.
 def toggle(p: Bool) = {
   val x = RegInit(false.B)
@@ -38,5 +46,5 @@ def toggle(p: Bool) = {
   x
 }
 // Square wave of a given period.
-def squareWave(period: UInt) = toggle(pulse(period/2))
+def squareWave(period: UInt) = toggle(pulse(period >> 1))
 ```
diff --git a/docs/src/wiki-deprecated/supported-hardware.md b/docs/src/explanations/supported-hardware.md
index 97f82698..fe3909e7 100644
--- a/docs/src/wiki-deprecated/supported-hardware.md
+++ b/docs/src/explanations/supported-hardware.md
@@ -3,6 +3,9 @@ layout: docs
 title:  "Supported Hardware"
 section: "chisel3"
 ---
+
+# Supported Hardware
+
 While Chisel focuses on binary logic, Chisel can support analog and tri-state wires with the `Analog` type - see [Datatypes in Chisel](data-types).
 
 We focus on binary logic designs as they constitute the vast majority of designs in practice. Tri-state logic are poorly supported standard industry flows and require special/controlled hard macros in order to be done.
diff --git a/docs/src/wiki-deprecated/unconnected-wires.md b/docs/src/explanations/unconnected-wires.md
index 1fa12e59..48012d12 100644
--- a/docs/src/wiki-deprecated/unconnected-wires.md
+++ b/docs/src/explanations/unconnected-wires.md
@@ -3,10 +3,13 @@ layout: docs
 title:  "Unconnected Wires"
 section: "chisel3"
 ---
-The Invalidate API [(#645)](https://github.com/freechipsproject/chisel3/pull/645) adds support to chisel
+
+# Unconnected Wires
+
+The Invalidate API [(#645)](https://github.com/freechipsproject/chisel3/pull/645) adds support to Chisel
 for reporting unconnected wires as errors.
 
-Prior to this pull request, chisel automatically generated a firrtl `is invalid` for `Module IO()`, and each `Wire()` definition.
+Prior to this pull request, Chisel automatically generated a firrtl `is invalid` for `Module IO()`, and each `Wire()` definition.
 This made it difficult to detect cases where output signals were never driven.
 Chisel now supports a `DontCare` element, which may be connected to an output signal, indicating that that signal is intentionally not driven.
 Unless a signal is driven by hardware or connected to a `DontCare`, Firrtl will complain with a "not fully initialized" error.
@@ -14,23 +17,41 @@ Unless a signal is driven by hardware or connected to a `DontCare`, Firrtl will
 ### API
 
 Output signals may be connected to DontCare, generating a `is invalid` when the corresponding firrtl is emitted.
-```scala
+
+```scala mdoc:invisible
+import chisel3._
+```
+```scala mdoc:silent
+
+class Out extends Bundle { 
+  val debug = Bool()
+  val debugOption = Bool()
+}
+val io = new Bundle { val out = new Out }
+```
+
+```scala mdoc:compile-only
 io.out.debug := true.B
 io.out.debugOption := DontCare
 ```
+
 This indicates that the signal `io.out.debugOption` is intentionally not driven and firrtl should not issue a "not fully initialized"
 error for this signal.
 
 This can be applied to aggregates as well as individual signals:
-```scala
-{
-  ...
+```scala mdoc:invisible
+import chisel3._
+```
+```scala mdoc:silent
+import chisel3._
+class ModWithVec extends Module {
+  // ...
   val nElements = 5
   val io = IO(new Bundle {
     val outs = Output(Vec(nElements, Bool()))
   })
   io.outs <> DontCare
-  ...
+  // ...
 }
 
 class TrivialInterface extends Bundle {
@@ -38,11 +59,11 @@ class TrivialInterface extends Bundle {
   val out = Output(Bool())
 }
 
-{
-  ...
+class ModWithTrivalInterface extends Module {
+  // ...
   val io = IO(new TrivialInterface)
   io <> DontCare
-  ...
+  // ...
 }
 ```
 
@@ -51,26 +72,31 @@ and `true` in `Strict` mode.
 
 You can selectively enable this for Chisel2 compatibility mode by providing your own explicit `compileOptions`,
 either for a group of Modules (via inheritance):
-```scala
-abstract class ExplicitInvalidateModule extends Module()(chisel3.core.ExplicitCompileOptions.NotStrict.copy(explicitInvalidate = true))
+```scala mdoc:silent
+abstract class ExplicitInvalidateModule extends Module()(chisel3.ExplicitCompileOptions.NotStrict.copy(explicitInvalidate = true))
 ```
 or on a per-Module basis:
-```scala
+```scala mdoc:silent
 class MyModule extends Module {
-  override val compileOptions = chisel3.core.ExplicitCompileOptions.NotStrict.copy(explicitInvalidate = true)
-  ...
+  override val compileOptions = chisel3.ExplicitCompileOptions.NotStrict.copy(explicitInvalidate = true)
+  val io = IO(new Bundle { /* ... */ } )
+  // ...
 }
 ```
 
 Or conversely, disable this stricter checking (which is now the default in pure chisel3):
-```scala
-abstract class ImplicitInvalidateModule extends Module()(chisel3.core.ExplicitCompileOptions.Strict.copy(explicitInvalidate = false))
+```scala mdoc:silent
+abstract class ImplicitInvalidateModule extends Module()(chisel3.ExplicitCompileOptions.Strict.copy(explicitInvalidate = false))
 ```
 or on a per-Module basis:
-```scala
+```scala mdoc:invisible:reset
+import chisel3._
+```
+```scala mdoc:silent
 class MyModule extends Module {
-  override val compileOptions = chisel3.core.ExplicitCompileOptions.Strict.copy(explicitInvalidate = false)
-  ...
+  override val compileOptions = chisel3.ExplicitCompileOptions.Strict.copy(explicitInvalidate = false)
+  val io = IO(new Bundle { /* ... */ } )
+  // ...
 }
 ```
 
diff --git a/docs/src/wiki-deprecated/width-inference.md b/docs/src/explanations/width-inference.md
index 60f9d519..66d9736d 100644
--- a/docs/src/wiki-deprecated/width-inference.md
+++ b/docs/src/explanations/width-inference.md
@@ -3,6 +3,9 @@ layout: docs
 title:  "Width Inference"
 section: "chisel3"
 ---
+
+# Width Inference
+
 Chisel provides bit width inference to reduce design effort. Users are encouraged to manually specify widths of ports and registers to prevent any surprises, but otherwise unspecified widths will be inferred by the Firrtl compiler.
 
 For all circuit components declared with unspecified widths, the FIRRTL compiler will infer the minimum possible width that maintains the legality of all its incoming connections. Implicit here is that inference is done in a right to left fashion in the sense of an assignment statement in chisel, i.e. from the left hand side from the right hand side. If a component has no incoming connections, and the width is unspecified, then an error is thrown to indicate that the width could not be inferred.
diff --git a/docs/src/images/type_hierarchy.dot b/docs/src/images/type_hierarchy.dot
index d3bf6eb4..b98cc269 100644
--- a/docs/src/images/type_hierarchy.dot
+++ b/docs/src/images/type_hierarchy.dot
@@ -10,7 +10,10 @@ digraph TypeHierarchy {
       "Chisel Internal"
     }
     { node [fillcolor="#e5f5e0"]
-      Bool UInt SInt FixedPoint
+      Bool UInt SInt
+      FixedPoint Interval
+      Analog
+      Clock
       Reset
       AsyncReset
       Record
@@ -27,8 +30,9 @@ digraph TypeHierarchy {
       color=transparent
       Element
       Bits Num
-      Reset
-      Bool UInt SInt FixedPoint
+      Reset Clock Analog
+      UInt SInt FixedPoint Interval
+      Bool
       color=transparent
       Aggregate
       VecLike
@@ -37,10 +41,12 @@ digraph TypeHierarchy {
       Vec
 
       {Aggregate Element} -> Data
-      {Bits Reset} -> Element
-      {FixedPoint SInt UInt} -> {Bits Num}
+      {Bits Reset Clock Analog} -> Element
+      {UInt SInt FixedPoint Interval} -> {Bits Num}
       Bool -> {UInt Reset}
-      Ellipsis -> Bundle -> Record -> Aggregate
+      Ellipsis -> Bundle
+      Ellipsis -> Record -> Aggregate
+      Bundle -> Record
       Vec -> {Aggregate VecLike}
       AsyncReset -> {Element Reset}
     }
diff --git a/docs/src/images/type_hierarchy.png b/docs/src/images/type_hierarchy.png
index f3947975..9c4f74f1 100644
--- a/docs/src/images/type_hierarchy.png
+++ b/docs/src/images/type_hierarchy.png
diff --git a/docs/src/images/type_hierarchy.svg b/docs/src/images/type_hierarchy.svg
index c120daba..faf23a1e 100644
--- a/docs/src/images/type_hierarchy.svg
+++ b/docs/src/images/type_hierarchy.svg
@@ -1,261 +1,309 @@
 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
  "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<!-- Generated by graphviz version 2.41.20190111.1241 (20190111.1241)
+<!-- Generated by graphviz version 2.44.1 (20200629.0846)
  -->
 <!-- Title: TypeHierarchy Pages: 1 -->
-<svg width="574pt" height="387pt"
- viewBox="0.00 0.00 574.00 387.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+<svg width="674pt" height="387pt"
+ viewBox="0.00 0.00 674.00 387.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
 <g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 383)">
 <title>TypeHierarchy</title>
 <g id="clust5" class="cluster">
 <title>cluster_data_hierarchy</title>
-<polygon fill="transparent" stroke="transparent" points="8,-31 8,-371 438,-371 438,-31 8,-31"/>
+<polygon fill="transparent" stroke="transparent" points="8,-31 8,-371 536,-371 536,-31 8,-31"/>
 </g>
 <g id="clust13" class="cluster">
 <title>cluster_legend</title>
-<polygon fill="transparent" stroke="black" points="446,-8 446,-227 558,-227 558,-8 446,-8"/>
-<text text-anchor="middle" x="502" y="-15.8" font-family="Times,serif" font-size="14.00">Legend</text>
+<polygon fill="transparent" stroke="black" points="544,-8 544,-227 658,-227 658,-8 544,-8"/>
+<text text-anchor="middle" x="601" y="-15.8" font-family="Times,serif" font-size="14.00">Legend</text>
 </g>
 <!-- Data -->
 <g id="node1" class="node">
 <title>Data</title>
-<polygon fill="#f7fbff" stroke="black" points="172,-363 118,-363 118,-327 172,-327 172,-363"/>
-<text text-anchor="middle" x="145" y="-341.3" font-family="Times,serif" font-size="14.00">Data</text>
+<polygon fill="#f7fbff" stroke="black" points="370,-363 316,-363 316,-327 370,-327 370,-363"/>
+<text text-anchor="middle" x="343" y="-341.3" font-family="Times,serif" font-size="14.00">Data</text>
 </g>
 <!-- Element -->
 <g id="node2" class="node">
 <title>Element</title>
-<polygon fill="#f7fbff" stroke="black" points="262,-291 200,-291 200,-255 262,-255 262,-291"/>
-<text text-anchor="middle" x="231" y="-269.3" font-family="Times,serif" font-size="14.00">Element</text>
+<polygon fill="#f7fbff" stroke="black" points="256,-291 194,-291 194,-255 256,-255 256,-291"/>
+<text text-anchor="middle" x="225" y="-269.3" font-family="Times,serif" font-size="14.00">Element</text>
 </g>
 <!-- Element&#45;&gt;Data -->
 <g id="edge1" class="edge">
 <title>Element&#45;&gt;Data</title>
-<path fill="none" stroke="black" d="M209.74,-291.3C198.91,-300.12 185.58,-310.97 173.84,-320.53"/>
-<polygon fill="black" stroke="black" points="171.56,-317.87 166.01,-326.9 175.98,-323.3 171.56,-317.87"/>
+<path fill="none" stroke="black" d="M253.87,-291.12C269.76,-300.55 289.63,-312.34 306.58,-322.39"/>
+<polygon fill="black" stroke="black" points="305.26,-325.68 315.65,-327.77 308.83,-319.66 305.26,-325.68"/>
 </g>
 <!-- Bits -->
 <g id="node3" class="node">
 <title>Bits</title>
-<polygon fill="#f7fbff" stroke="black" points="380,-219 326,-219 326,-183 380,-183 380,-219"/>
-<text text-anchor="middle" x="353" y="-197.3" font-family="Times,serif" font-size="14.00">Bits</text>
+<polygon fill="#f7fbff" stroke="black" points="72,-219 18,-219 18,-183 72,-183 72,-219"/>
+<text text-anchor="middle" x="45" y="-197.3" font-family="Times,serif" font-size="14.00">Bits</text>
 </g>
 <!-- Bits&#45;&gt;Element -->
 <g id="edge3" class="edge">
 <title>Bits&#45;&gt;Element</title>
-<path fill="none" stroke="black" d="M329.26,-219.1C325.23,-221.83 321.04,-224.56 317,-227 302.46,-235.81 286.02,-244.66 271.44,-252.16"/>
-<polygon fill="black" stroke="black" points="269.49,-249.22 262.16,-256.88 272.66,-255.46 269.49,-249.22"/>
+<path fill="none" stroke="black" d="M67.6,-219.23C71.91,-222.06 76.49,-224.79 81,-227 114.15,-243.21 154.43,-255.21 183.94,-262.72"/>
+<polygon fill="black" stroke="black" points="183.36,-266.18 193.91,-265.19 185.04,-259.39 183.36,-266.18"/>
 </g>
 <!-- Num -->
 <g id="node4" class="node">
 <title>Num</title>
-<polygon fill="#f7fbff" stroke="black" points="308,-219 254,-219 254,-183 308,-183 308,-219"/>
-<text text-anchor="middle" x="281" y="-197.3" font-family="Times,serif" font-size="14.00">Num</text>
+<polygon fill="#f7fbff" stroke="black" points="290,-219 236,-219 236,-183 290,-183 290,-219"/>
+<text text-anchor="middle" x="263" y="-197.3" font-family="Times,serif" font-size="14.00">Num</text>
 </g>
 <!-- Aggregate -->
 <g id="node5" class="node">
 <title>Aggregate</title>
-<polygon fill="#f7fbff" stroke="black" points="96.5,-291 23.5,-291 23.5,-255 96.5,-255 96.5,-291"/>
-<text text-anchor="middle" x="60" y="-269.3" font-family="Times,serif" font-size="14.00">Aggregate</text>
+<polygon fill="#f7fbff" stroke="black" points="495.5,-291 422.5,-291 422.5,-255 495.5,-255 495.5,-291"/>
+<text text-anchor="middle" x="459" y="-269.3" font-family="Times,serif" font-size="14.00">Aggregate</text>
 </g>
 <!-- Aggregate&#45;&gt;Data -->
 <g id="edge2" class="edge">
 <title>Aggregate&#45;&gt;Data</title>
-<path fill="none" stroke="black" d="M81.01,-291.3C91.72,-300.12 104.89,-310.97 116.5,-320.53"/>
-<polygon fill="black" stroke="black" points="114.29,-323.24 124.23,-326.9 118.74,-317.84 114.29,-323.24"/>
+<path fill="none" stroke="black" d="M430.62,-291.12C415.12,-300.48 395.75,-312.17 379.17,-322.17"/>
+<polygon fill="black" stroke="black" points="377.04,-319.37 370.29,-327.53 380.66,-325.36 377.04,-319.37"/>
 </g>
 <!-- VecLike -->
 <g id="node6" class="node">
 <title>VecLike</title>
-<polygon fill="#f7fbff" stroke="black" points="177.5,-291 114.5,-291 114.5,-255 177.5,-255 177.5,-291"/>
-<text text-anchor="middle" x="146" y="-269.3" font-family="Times,serif" font-size="14.00">VecLike</text>
+<polygon fill="#f7fbff" stroke="black" points="404,-291 342,-291 342,-255 404,-255 404,-291"/>
+<text text-anchor="middle" x="373" y="-269.3" font-family="Times,serif" font-size="14.00">VecLike</text>
 </g>
 <!-- Chisel Internal -->
 <g id="node7" class="node">
 <title>Chisel Internal</title>
-<polygon fill="#f7fbff" stroke="black" points="550.5,-219 453.5,-219 453.5,-183 550.5,-183 550.5,-219"/>
-<text text-anchor="middle" x="502" y="-197.3" font-family="Times,serif" font-size="14.00">Chisel Internal</text>
+<polygon fill="#f7fbff" stroke="black" points="649.5,-219 552.5,-219 552.5,-183 649.5,-183 649.5,-219"/>
+<text text-anchor="middle" x="601" y="-197.3" font-family="Times,serif" font-size="14.00">Chisel Internal</text>
 </g>
 <!-- Bool -->
 <g id="node8" class="node">
 <title>Bool</title>
-<polygon fill="#e5f5e0" stroke="black" points="286,-75 232,-75 232,-39 286,-39 286,-75"/>
-<text text-anchor="middle" x="259" y="-53.3" font-family="Times,serif" font-size="14.00">Bool</text>
+<polygon fill="#e5f5e0" stroke="black" points="262,-75 208,-75 208,-39 262,-39 262,-75"/>
+<text text-anchor="middle" x="235" y="-53.3" font-family="Times,serif" font-size="14.00">Bool</text>
 </g>
 <!-- UInt -->
 <g id="node9" class="node">
 <title>UInt</title>
-<polygon fill="#e5f5e0" stroke="black" points="430,-147 376,-147 376,-111 430,-111 430,-147"/>
-<text text-anchor="middle" x="403" y="-125.3" font-family="Times,serif" font-size="14.00">UInt</text>
+<polygon fill="#e5f5e0" stroke="black" points="164,-147 110,-147 110,-111 164,-111 164,-147"/>
+<text text-anchor="middle" x="137" y="-125.3" font-family="Times,serif" font-size="14.00">UInt</text>
 </g>
 <!-- Bool&#45;&gt;UInt -->
-<g id="edge11" class="edge">
+<g id="edge15" class="edge">
 <title>Bool&#45;&gt;UInt</title>
-<path fill="none" stroke="black" d="M286.09,-71.17C308.77,-82.19 341.36,-98.03 366.37,-110.19"/>
-<polygon fill="black" stroke="black" points="365.02,-113.43 375.55,-114.65 368.08,-107.13 365.02,-113.43"/>
+<path fill="none" stroke="black" d="M211.03,-75.12C198.45,-84.11 182.87,-95.24 169.25,-104.97"/>
+<polygon fill="black" stroke="black" points="167.17,-102.15 161.07,-110.81 171.24,-107.85 167.17,-102.15"/>
 </g>
 <!-- Reset -->
-<g id="node12" class="node">
+<g id="node15" class="node">
 <title>Reset</title>
-<polygon fill="#e5f5e0" stroke="black" points="216,-219 162,-219 162,-183 216,-183 216,-219"/>
-<text text-anchor="middle" x="189" y="-197.3" font-family="Times,serif" font-size="14.00">Reset</text>
+<polygon fill="#e5f5e0" stroke="black" points="362,-219 308,-219 308,-183 362,-183 362,-219"/>
+<text text-anchor="middle" x="335" y="-197.3" font-family="Times,serif" font-size="14.00">Reset</text>
 </g>
 <!-- Bool&#45;&gt;Reset -->
-<g id="edge12" class="edge">
+<g id="edge16" class="edge">
 <title>Bool&#45;&gt;Reset</title>
-<path fill="none" stroke="black" d="M231.86,-58.21C195.38,-60.13 131.69,-69.64 102,-111 92.67,-124 94.16,-133.05 102,-147 107.81,-157.34 131.42,-171.4 152.58,-182.44"/>
-<polygon fill="black" stroke="black" points="151.25,-185.69 161.75,-187.12 154.43,-179.45 151.25,-185.69"/>
+<path fill="none" stroke="black" d="M262.28,-67.06C282.45,-75.26 308.8,-89.39 323,-111 334.94,-129.17 337.43,-153.94 337.23,-172.74"/>
+<polygon fill="black" stroke="black" points="333.73,-172.63 336.86,-182.75 340.72,-172.89 333.73,-172.63"/>
 </g>
 <!-- UInt&#45;&gt;Bits -->
-<g id="edge5" class="edge">
+<g id="edge7" class="edge">
 <title>UInt&#45;&gt;Bits</title>
-<path fill="none" stroke="black" d="M390.64,-147.3C384.77,-155.53 377.63,-165.52 371.16,-174.58"/>
-<polygon fill="black" stroke="black" points="368.18,-172.72 365.22,-182.9 373.88,-176.79 368.18,-172.72"/>
+<path fill="none" stroke="black" d="M114.26,-147.3C102.56,-156.2 88.14,-167.18 75.49,-176.8"/>
+<polygon fill="black" stroke="black" points="73.32,-174.06 67.48,-182.9 77.56,-179.63 73.32,-174.06"/>
 </g>
 <!-- UInt&#45;&gt;Num -->
-<g id="edge6" class="edge">
+<g id="edge8" class="edge">
 <title>UInt&#45;&gt;Num</title>
-<path fill="none" stroke="black" d="M375.92,-145.54C358.55,-155.5 335.79,-168.56 316.91,-179.39"/>
-<polygon fill="black" stroke="black" points="314.93,-176.5 308,-184.51 318.42,-182.57 314.93,-176.5"/>
+<path fill="none" stroke="black" d="M164.03,-145.02C182.34,-155.19 206.75,-168.75 226.74,-179.86"/>
+<polygon fill="black" stroke="black" points="225.14,-182.97 235.58,-184.77 228.54,-176.85 225.14,-182.97"/>
 </g>
 <!-- SInt -->
 <g id="node10" class="node">
 <title>SInt</title>
-<polygon fill="#e5f5e0" stroke="black" points="358,-147 304,-147 304,-111 358,-111 358,-147"/>
-<text text-anchor="middle" x="331" y="-125.3" font-family="Times,serif" font-size="14.00">SInt</text>
+<polygon fill="#e5f5e0" stroke="black" points="236,-147 182,-147 182,-111 236,-111 236,-147"/>
+<text text-anchor="middle" x="209" y="-125.3" font-family="Times,serif" font-size="14.00">SInt</text>
 </g>
 <!-- SInt&#45;&gt;Bits -->
-<g id="edge7" class="edge">
+<g id="edge9" class="edge">
 <title>SInt&#45;&gt;Bits</title>
-<path fill="none" stroke="black" d="M336.44,-147.3C338.89,-155.1 341.84,-164.49 344.57,-173.17"/>
-<polygon fill="black" stroke="black" points="341.29,-174.41 347.62,-182.9 347.96,-172.31 341.29,-174.41"/>
+<path fill="none" stroke="black" d="M181.96,-143.01C178.95,-144.39 175.92,-145.74 173,-147 135.36,-163.23 122.96,-165.38 81.37,-182.99"/>
+<polygon fill="black" stroke="black" points="79.85,-179.83 72.04,-186.99 82.61,-186.27 79.85,-179.83"/>
 </g>
 <!-- SInt&#45;&gt;Num -->
-<g id="edge8" class="edge">
+<g id="edge10" class="edge">
 <title>SInt&#45;&gt;Num</title>
-<path fill="none" stroke="black" d="M318.64,-147.3C312.77,-155.53 305.63,-165.52 299.16,-174.58"/>
-<polygon fill="black" stroke="black" points="296.18,-172.72 293.22,-182.9 301.88,-176.79 296.18,-172.72"/>
+<path fill="none" stroke="black" d="M222.35,-147.3C228.76,-155.61 236.56,-165.72 243.61,-174.86"/>
+<polygon fill="black" stroke="black" points="240.93,-177.12 249.81,-182.9 246.47,-172.84 240.93,-177.12"/>
 </g>
 <!-- FixedPoint -->
 <g id="node11" class="node">
 <title>FixedPoint</title>
-<polygon fill="#e5f5e0" stroke="black" points="286,-147 210,-147 210,-111 286,-111 286,-147"/>
-<text text-anchor="middle" x="248" y="-125.3" font-family="Times,serif" font-size="14.00">FixedPoint</text>
+<polygon fill="#e5f5e0" stroke="black" points="92,-147 16,-147 16,-111 92,-111 92,-147"/>
+<text text-anchor="middle" x="54" y="-125.3" font-family="Times,serif" font-size="14.00">FixedPoint</text>
 </g>
 <!-- FixedPoint&#45;&gt;Bits -->
-<g id="edge9" class="edge">
+<g id="edge11" class="edge">
 <title>FixedPoint&#45;&gt;Bits</title>
-<path fill="none" stroke="black" d="M273.69,-147.12C287.29,-156.19 304.17,-167.45 318.86,-177.24"/>
-<polygon fill="black" stroke="black" points="316.95,-180.18 327.22,-182.81 320.84,-174.35 316.95,-180.18"/>
+<path fill="none" stroke="black" d="M51.78,-147.3C50.78,-155.02 49.59,-164.29 48.49,-172.89"/>
+<polygon fill="black" stroke="black" points="45,-172.53 47.2,-182.9 51.95,-173.42 45,-172.53"/>
 </g>
 <!-- FixedPoint&#45;&gt;Num -->
-<g id="edge10" class="edge">
+<g id="edge12" class="edge">
 <title>FixedPoint&#45;&gt;Num</title>
-<path fill="none" stroke="black" d="M256.16,-147.3C259.91,-155.27 264.45,-164.9 268.62,-173.74"/>
-<polygon fill="black" stroke="black" points="265.51,-175.34 272.94,-182.9 271.84,-172.36 265.51,-175.34"/>
+<path fill="none" stroke="black" d="M92.14,-144.04C95.13,-145.07 98.11,-146.07 101,-147 153.49,-163.97 170.68,-162.7 226.06,-182.95"/>
+<polygon fill="black" stroke="black" points="225.09,-186.32 235.68,-186.54 227.54,-179.76 225.09,-186.32"/>
 </g>
-<!-- Reset&#45;&gt;Element -->
+<!-- Interval -->
+<g id="node12" class="node">
+<title>Interval</title>
+<polygon fill="#e5f5e0" stroke="black" points="313.5,-147 254.5,-147 254.5,-111 313.5,-111 313.5,-147"/>
+<text text-anchor="middle" x="284" y="-125.3" font-family="Times,serif" font-size="14.00">Interval</text>
+</g>
+<!-- Interval&#45;&gt;Bits -->
+<g id="edge13" class="edge">
+<title>Interval&#45;&gt;Bits</title>
+<path fill="none" stroke="black" d="M254.42,-143.6C251.27,-144.84 248.09,-146 245,-147 176.93,-169.07 153.55,-159.77 81.74,-183.17"/>
+<polygon fill="black" stroke="black" points="80.62,-179.85 72.25,-186.35 82.85,-186.49 80.62,-179.85"/>
+</g>
+<!-- Interval&#45;&gt;Num -->
+<g id="edge14" class="edge">
+<title>Interval&#45;&gt;Num</title>
+<path fill="none" stroke="black" d="M278.81,-147.3C276.47,-155.1 273.65,-164.49 271.05,-173.17"/>
+<polygon fill="black" stroke="black" points="267.65,-172.31 268.13,-182.9 274.36,-174.32 267.65,-172.31"/>
+</g>
+<!-- Analog -->
+<g id="node13" class="node">
+<title>Analog</title>
+<polygon fill="#e5f5e0" stroke="black" points="218,-219 162,-219 162,-183 218,-183 218,-219"/>
+<text text-anchor="middle" x="190" y="-197.3" font-family="Times,serif" font-size="14.00">Analog</text>
+</g>
+<!-- Analog&#45;&gt;Element -->
 <g id="edge4" class="edge">
+<title>Analog&#45;&gt;Element</title>
+<path fill="none" stroke="black" d="M198.65,-219.3C202.64,-227.27 207.45,-236.9 211.87,-245.74"/>
+<polygon fill="black" stroke="black" points="208.85,-247.52 216.45,-254.9 215.11,-244.39 208.85,-247.52"/>
+</g>
+<!-- Clock -->
+<g id="node14" class="node">
+<title>Clock</title>
+<polygon fill="#e5f5e0" stroke="black" points="144,-219 90,-219 90,-183 144,-183 144,-219"/>
+<text text-anchor="middle" x="117" y="-197.3" font-family="Times,serif" font-size="14.00">Clock</text>
+</g>
+<!-- Clock&#45;&gt;Element -->
+<g id="edge5" class="edge">
+<title>Clock&#45;&gt;Element</title>
+<path fill="none" stroke="black" d="M141.29,-219.11C145.19,-221.78 149.19,-224.49 153,-227 164.27,-234.43 176.68,-242.29 187.98,-249.34"/>
+<polygon fill="black" stroke="black" points="186.42,-252.49 196.76,-254.79 190.11,-246.54 186.42,-252.49"/>
+</g>
+<!-- Reset&#45;&gt;Element -->
+<g id="edge6" class="edge">
 <title>Reset&#45;&gt;Element</title>
-<path fill="none" stroke="black" d="M199.38,-219.3C204.26,-227.44 210.19,-237.31 215.58,-246.3"/>
-<polygon fill="black" stroke="black" points="212.59,-248.12 220.74,-254.9 218.59,-244.52 212.59,-248.12"/>
+<path fill="none" stroke="black" d="M310.74,-219.15C306.84,-221.81 302.83,-224.51 299,-227 287.35,-234.58 274.46,-242.55 262.75,-249.65"/>
+<polygon fill="black" stroke="black" points="260.83,-246.72 254.07,-254.88 264.44,-252.71 260.83,-246.72"/>
 </g>
 <!-- AsyncReset -->
-<g id="node13" class="node">
+<g id="node16" class="node">
 <title>AsyncReset</title>
-<polygon fill="#e5f5e0" stroke="black" points="191.5,-147 110.5,-147 110.5,-111 191.5,-111 191.5,-147"/>
-<text text-anchor="middle" x="151" y="-125.3" font-family="Times,serif" font-size="14.00">AsyncReset</text>
+<polygon fill="#e5f5e0" stroke="black" points="433.5,-147 352.5,-147 352.5,-111 433.5,-111 433.5,-147"/>
+<text text-anchor="middle" x="393" y="-125.3" font-family="Times,serif" font-size="14.00">AsyncReset</text>
 </g>
 <!-- AsyncReset&#45;&gt;Element -->
-<g id="edge18" class="edge">
+<g id="edge23" class="edge">
 <title>AsyncReset&#45;&gt;Element</title>
-<path fill="none" stroke="black" d="M187.11,-147C201.42,-155.68 216.46,-167.68 225,-183 235.4,-201.66 236.33,-226.05 234.98,-244.58"/>
-<polygon fill="black" stroke="black" points="231.48,-244.42 233.98,-254.72 238.45,-245.11 231.48,-244.42"/>
+<path fill="none" stroke="black" d="M393.97,-147.07C394.21,-168.49 391.31,-205.09 371,-227 344.24,-255.88 299.43,-266.4 266.49,-270.14"/>
+<polygon fill="black" stroke="black" points="265.87,-266.68 256.25,-271.13 266.55,-273.65 265.87,-266.68"/>
 </g>
 <!-- AsyncReset&#45;&gt;Reset -->
-<g id="edge19" class="edge">
+<g id="edge24" class="edge">
 <title>AsyncReset&#45;&gt;Reset</title>
-<path fill="none" stroke="black" d="M160.39,-147.3C164.76,-155.36 170.06,-165.11 174.9,-174.02"/>
-<polygon fill="black" stroke="black" points="171.87,-175.78 179.71,-182.9 178.02,-172.44 171.87,-175.78"/>
+<path fill="none" stroke="black" d="M378.66,-147.3C371.71,-155.7 363.23,-165.93 355.6,-175.14"/>
+<polygon fill="black" stroke="black" points="352.86,-172.96 349.17,-182.9 358.25,-177.43 352.86,-172.96"/>
 </g>
 <!-- Record -->
-<g id="node14" class="node">
+<g id="node17" class="node">
 <title>Record</title>
-<polygon fill="#e5f5e0" stroke="black" points="72,-219 16,-219 16,-183 72,-183 72,-219"/>
-<text text-anchor="middle" x="44" y="-197.3" font-family="Times,serif" font-size="14.00">Record</text>
+<polygon fill="#e5f5e0" stroke="black" points="528,-219 472,-219 472,-183 528,-183 528,-219"/>
+<text text-anchor="middle" x="500" y="-197.3" font-family="Times,serif" font-size="14.00">Record</text>
 </g>
 <!-- Record&#45;&gt;Aggregate -->
-<g id="edge15" class="edge">
+<g id="edge19" class="edge">
 <title>Record&#45;&gt;Aggregate</title>
-<path fill="none" stroke="black" d="M47.96,-219.3C49.72,-227.02 51.84,-236.29 53.8,-244.89"/>
-<polygon fill="black" stroke="black" points="50.45,-245.93 56.09,-254.9 57.27,-244.37 50.45,-245.93"/>
+<path fill="none" stroke="black" d="M489.87,-219.3C485.15,-227.36 479.44,-237.11 474.22,-246.02"/>
+<polygon fill="black" stroke="black" points="471.05,-244.5 469.02,-254.9 477.09,-248.04 471.05,-244.5"/>
 </g>
 <!-- Bundle -->
-<g id="node15" class="node">
+<g id="node18" class="node">
 <title>Bundle</title>
-<polygon fill="#e5f5e0" stroke="black" points="72,-147 16,-147 16,-111 72,-111 72,-147"/>
-<text text-anchor="middle" x="44" y="-125.3" font-family="Times,serif" font-size="14.00">Bundle</text>
+<polygon fill="#e5f5e0" stroke="black" points="528,-147 472,-147 472,-111 528,-111 528,-147"/>
+<text text-anchor="middle" x="500" y="-125.3" font-family="Times,serif" font-size="14.00">Bundle</text>
 </g>
 <!-- Bundle&#45;&gt;Record -->
-<g id="edge14" class="edge">
+<g id="edge20" class="edge">
 <title>Bundle&#45;&gt;Record</title>
-<path fill="none" stroke="black" d="M44,-147.3C44,-155.02 44,-164.29 44,-172.89"/>
-<polygon fill="black" stroke="black" points="40.5,-172.9 44,-182.9 47.5,-172.9 40.5,-172.9"/>
+<path fill="none" stroke="black" d="M500,-147.3C500,-155.02 500,-164.29 500,-172.89"/>
+<polygon fill="black" stroke="black" points="496.5,-172.9 500,-182.9 503.5,-172.9 496.5,-172.9"/>
 </g>
 <!-- Vec -->
-<g id="node16" class="node">
+<g id="node19" class="node">
 <title>Vec</title>
-<polygon fill="#e5f5e0" stroke="black" points="144,-219 90,-219 90,-183 144,-183 144,-219"/>
-<text text-anchor="middle" x="117" y="-197.3" font-family="Times,serif" font-size="14.00">Vec</text>
+<polygon fill="#e5f5e0" stroke="black" points="454,-219 400,-219 400,-183 454,-183 454,-219"/>
+<text text-anchor="middle" x="427" y="-197.3" font-family="Times,serif" font-size="14.00">Vec</text>
 </g>
 <!-- Vec&#45;&gt;Aggregate -->
-<g id="edge16" class="edge">
+<g id="edge21" class="edge">
 <title>Vec&#45;&gt;Aggregate</title>
-<path fill="none" stroke="black" d="M102.91,-219.3C96.08,-227.7 87.74,-237.93 80.24,-247.14"/>
-<polygon fill="black" stroke="black" points="77.53,-244.93 73.93,-254.9 82.96,-249.35 77.53,-244.93"/>
+<path fill="none" stroke="black" d="M434.91,-219.3C438.55,-227.27 442.95,-236.9 446.99,-245.74"/>
+<polygon fill="black" stroke="black" points="443.84,-247.26 451.18,-254.9 450.21,-244.35 443.84,-247.26"/>
 </g>
 <!-- Vec&#45;&gt;VecLike -->
-<g id="edge17" class="edge">
+<g id="edge22" class="edge">
 <title>Vec&#45;&gt;VecLike</title>
-<path fill="none" stroke="black" d="M124.17,-219.3C127.43,-227.19 131.37,-236.7 135,-245.45"/>
-<polygon fill="black" stroke="black" points="131.85,-247 138.91,-254.9 138.32,-244.32 131.85,-247"/>
+<path fill="none" stroke="black" d="M413.65,-219.3C407.24,-227.61 399.44,-237.72 392.39,-246.86"/>
+<polygon fill="black" stroke="black" points="389.53,-244.84 386.19,-254.9 395.07,-249.12 389.53,-244.84"/>
 </g>
 <!-- Chisel Types -->
-<g id="node17" class="node">
+<g id="node20" class="node">
 <title>Chisel Types</title>
-<polygon fill="#e5f5e0" stroke="black" points="546,-147 458,-147 458,-111 546,-111 546,-147"/>
-<text text-anchor="middle" x="502" y="-125.3" font-family="Times,serif" font-size="14.00">Chisel Types</text>
+<polygon fill="#e5f5e0" stroke="black" points="645,-147 557,-147 557,-111 645,-111 645,-147"/>
+<text text-anchor="middle" x="601" y="-125.3" font-family="Times,serif" font-size="14.00">Chisel Types</text>
 </g>
 <!-- Chisel Types&#45;&gt;Chisel Internal -->
-<g id="edge21" class="edge">
+<g id="edge26" class="edge">
 <title>Chisel Types&#45;&gt;Chisel Internal</title>
-<path fill="none" stroke="black" d="M502,-147.3C502,-155.02 502,-164.29 502,-172.89"/>
-<polygon fill="black" stroke="black" points="498.5,-172.9 502,-182.9 505.5,-172.9 498.5,-172.9"/>
+<path fill="none" stroke="black" d="M601,-147.3C601,-155.02 601,-164.29 601,-172.89"/>
+<polygon fill="black" stroke="black" points="597.5,-172.9 601,-182.9 604.5,-172.9 597.5,-172.9"/>
 </g>
 <!-- User Types -->
-<g id="node18" class="node">
+<g id="node21" class="node">
 <title>User Types</title>
-<polygon fill="#fcbba1" stroke="black" points="541.5,-75 462.5,-75 462.5,-39 541.5,-39 541.5,-75"/>
-<text text-anchor="middle" x="502" y="-53.3" font-family="Times,serif" font-size="14.00">User Types</text>
+<polygon fill="#fcbba1" stroke="black" points="640.5,-75 561.5,-75 561.5,-39 640.5,-39 640.5,-75"/>
+<text text-anchor="middle" x="601" y="-53.3" font-family="Times,serif" font-size="14.00">User Types</text>
 </g>
 <!-- User Types&#45;&gt;Chisel Types -->
-<g id="edge20" class="edge">
+<g id="edge25" class="edge">
 <title>User Types&#45;&gt;Chisel Types</title>
-<path fill="none" stroke="black" d="M502,-75.3C502,-83.02 502,-92.29 502,-100.89"/>
-<polygon fill="black" stroke="black" points="498.5,-100.9 502,-110.9 505.5,-100.9 498.5,-100.9"/>
+<path fill="none" stroke="black" d="M601,-75.3C601,-83.02 601,-92.29 601,-100.89"/>
+<polygon fill="black" stroke="black" points="597.5,-100.9 601,-110.9 604.5,-100.9 597.5,-100.9"/>
 </g>
 <!-- Ellipsis -->
-<g id="node19" class="node">
+<g id="node22" class="node">
 <title>Ellipsis</title>
-<polygon fill="#fcbba1" stroke="black" points="71,-75 17,-75 17,-39 71,-39 71,-75"/>
-<text text-anchor="middle" x="44" y="-53.3" font-family="Times,serif" font-size="14.00">...</text>
+<polygon fill="#fcbba1" stroke="black" points="503,-75 449,-75 449,-39 503,-39 503,-75"/>
+<text text-anchor="middle" x="476" y="-53.3" font-family="Times,serif" font-size="14.00">...</text>
+</g>
+<!-- Ellipsis&#45;&gt;Record -->
+<g id="edge18" class="edge">
+<title>Ellipsis&#45;&gt;Record</title>
+<path fill="none" stroke="black" d="M469.08,-75.09C462.72,-93.28 455.36,-122.72 463,-147 466.1,-156.85 471.75,-166.47 477.72,-174.75"/>
+<polygon fill="black" stroke="black" points="475.09,-177.06 483.96,-182.85 480.63,-172.79 475.09,-177.06"/>
 </g>
 <!-- Ellipsis&#45;&gt;Bundle -->
-<g id="edge13" class="edge">
+<g id="edge17" class="edge">
 <title>Ellipsis&#45;&gt;Bundle</title>
-<path fill="none" stroke="black" d="M44,-75.3C44,-83.02 44,-92.29 44,-100.89"/>
-<polygon fill="black" stroke="black" points="40.5,-100.9 44,-110.9 47.5,-100.9 40.5,-100.9"/>
+<path fill="none" stroke="black" d="M481.93,-75.3C484.61,-83.1 487.83,-92.49 490.8,-101.17"/>
+<polygon fill="black" stroke="black" points="487.58,-102.57 494.14,-110.9 494.2,-100.3 487.58,-102.57"/>
 </g>
 </g>
 </svg>
diff --git a/docs/src/introduction.md b/docs/src/introduction.md
new file mode 100644
index 00000000..3b68aae2
--- /dev/null
+++ b/docs/src/introduction.md
@@ -0,0 +1,41 @@
+---
+layout: docs
+title:  "Introduction"
+section: "chisel3"
+---
+
+# An Introduction to Chisel
+
+_Chisel_ (Constructing
+Hardware In a Scala Embedded Language) is a hardware
+construction language embedded in the high-level programming language
+Scala.
+ Chisel is a library of special class
+definitions, predefined objects, and usage conventions within [Scala](https://www.scala-lang.org/),
+so when you write Chisel you are actually writing a Scala
+program that constructs a hardware graph.
+As you gain experience and want to make your code simpler or more
+reusable, you will find it important to leverage the underlying power
+of the Scala language. We recommend you consult one of the excellent
+Scala books to become more expert in Scala programming.
+
+For a tutorial covering both Chisel and Scala, see the 
+[**online Chisel Bootcamp**](https://mybinder.org/v2/gh/freechipsproject/chisel-bootcamp/master).
+
+For quick reference "How-To" guides see the [Cookbooks](cookbooks/cookbooks).
+
+For a deeper introduction to key concepts in  Chisel see the [Explanations](explanations/explanations).
+
+The [API Documentation](https://www.chisel-lang.org/api/) gives the detailed reference for the Chisel source code.
+Note that previous versions can be found via the sidebar menu at [https://www.chisel-lang.org/chisel3].
+
+The [Resources](resources/resources) provides links to other useful resources for learning and working with Chisel.
+
+The [Appendix](appendix/appendix) covers some more advanced topics.
+
+The [Developers](developers/developers) section provides information for those working on the Chisel library itself.
+
+>Throughout these pages, we format commentary on our design choices as in
+this paragraph.  You should be able to skip the commentary sections
+and still fully understand how to use Chisel, but we hope you'll find
+them interesting.
diff --git a/docs/src/wiki-deprecated/faqs.md b/docs/src/resources/faqs.md
index 45694cdc..feefa4d0 100644
--- a/docs/src/wiki-deprecated/faqs.md
+++ b/docs/src/resources/faqs.md
@@ -4,10 +4,12 @@ title:  "Frequently Asked Questions"
 section: "chisel3"
 ---
 
+# Frequently Asked Questions
+
 * [Where should I start if I want to learn Chisel?](#where-should-i-start-if-i-want-to-learn-chisel)
 * [How do I ... in Chisel?](#how-do-i-do--eg-like-that-in-verilog-in-chisel)
+* [What versions of the various projects work together?](#what-versions)
 * [How can I contribute to Chisel?](#how-can-i-contribute-to-chisel)
-* [What is the difference between release and master branches?](#what-is-the-difference-between-release-and-master-branches)
 * [Why DecoupledIO instead of ReadyValidIO?](#why-decoupledio-instead-of-readyvalidio)
 * [Why do I have to wrap module instantiations in `Module(...)`?](#why-do-i-have-to-wrap-module-instantiations-in-module)
 * [Why Chisel?](#why-chisel)
@@ -24,44 +26,15 @@ We recommend the [Chisel Bootcamp](https://github.com/freechipsproject/chisel-bo
 
 ### How do I do ... (e.g. like that in Verilog) in Chisel?
 
-See the [cookbook](cookbook).
-
-### How can I contribute to Chisel?
-
-A good to place to start is to fill out the [How Can I Contribute Form](https://docs.google.com/forms/d/e/1FAIpQLSfwTTY8GkfSZ2sU2T2mNpfNMpIM70GlXOrjqiHoC9ZBvwn_CA/viewform).
-
-### What is the difference between release and master branches?
-
-We have two main branches for each main Chisel project:
-
-- `master`
-- `release`
-
-`master` is the main development branch and it is updated frequently (often several times a day).
-Although we endeavour to keep the `master` branches in sync, they may drift out of sync for a day or two.
-We do not publish the `master` branches.
-If you wish to use them, you need to clone the GitHub repositories and use `sbt publishLocal` to make them available on your local machine.
+See the [cookbooks](../cookbooks/cookbook).
 
-The `release` branches are updated less often (currently bi-weekly) and we try to guarantee they are in sync.
-We publish these to Sonatype/Maven on a bi-weekly basis.
+### What versions of the various projects work together? <a name="what-versions"></a>
 
-In general, you can not mix `release` and `master` branches and assume they will work.
+See [Chisel Project Versioning](../appendix/versioning).
 
-The default branches for the user-facing repositories (chisel-template and chisel-tutorial) are the `release` branches - these should always *just work* for new users as they use the `release` branches of chisel projects.
-
-If you want to use something more current than the `release` branch, you should `git checkout master` for all the chisel repos you intend to use, then `sbt publishLocal` them in this order:
-
-- firrtl
-- firrtl-interpreter
-- chisel3
-- chisel-testers
-
-Then, if you're working with the user-facing repositories:
-
-- chisel-tutorial
-- chisel-template
+### How can I contribute to Chisel?
 
-Since this is a substantial amount of work (with no guarantee of success), unless you are actively involved in Chisel development, we encourage you to stick with the `release` branches and their respective dependencies.
+Check out the [Contributor Documentation](https://github.com/chipsalliance/chisel3#contributor-documentation) in the chisel3 repository.
 
 ### Why DecoupledIO instead of ReadyValidIO?
 
@@ -78,82 +51,58 @@ Chisel Modules are written by defining a [Scala class](http://docs.scala-lang.or
 
 ### Why Chisel?
 
-Borrowed from [Chisel Introduction](introduction)
-
->We were motivated to develop a new hardware language by years of
-struggle with existing hardware description languages in our research
-projects and hardware design courses.  _Verilog_ and _VHDL_ were developed
-as hardware _simulation_ languages, and only later did they become
-a basis for hardware _synthesis_.  Much of the semantics of these
-languages are not appropriate for hardware synthesis and, in fact,
-many constructs are simply not synthesizable.  Other constructs are
-non-intuitive in how they map to hardware implementations, or their
-use can accidently lead to highly inefficient hardware structures.
-While it is possible to use a subset of these languages and still get
-acceptable results, they nonetheless present a cluttered and confusing
-specification model, particularly in an instructional setting.
-
->However, our strongest motivation for developing a new hardware
-language is our desire to change the way that electronic system design
-takes place.  We believe that it is important to not only teach
-students how to design circuits, but also to teach them how to design
-*circuit generators* ---programs that automatically generate
-designs from a high-level set of design parameters and constraints.
-Through circuit generators, we hope to leverage the hard work of
-design experts and raise the level of design abstraction for everyone.
-To express flexible and scalable circuit construction, circuit
-generators must employ sophisticated programming techniques to make
-decisions concerning how to best customize their output circuits
-according to high-level parameter values and constraints.  While
-Verilog and VHDL include some primitive constructs for programmatic
-circuit generation, they lack the powerful facilities present in
-modern programming languages, such as object-oriented programming,
-type inference, support for functional programming, and reflection.
-
->Instead of building a new hardware design language from scratch, we
-chose to embed hardware construction primitives within an existing
-language.  We picked Scala not only because it includes the
-programming features we feel are important for building circuit
-generators, but because it was specifically developed as a base for
-domain-specific languages.
+Please see [Chisel Motivation](../explanations/motivation)
 
 ### Does Chisel support X and Z logic values
 
-Chisel does not directly support Verilog logic values ```x``` *unknown* and ```z``` *high-impedance*.  There are a number of reasons to want to avoid these values.  See:[The Dangers of Living With An X](http://infocenter.arm.com/help/topic/com.arm.doc.arp0009a/Verilog_X_Bugs.pdf) and [Malicious LUT: A stealthy FPGA Trojan injected and triggered by the design flow](http://ieeexplore.ieee.org/document/7827620/).  Chisel has it's own eco-system of unit and functional testers that limit the need for ```x``` and ```z``` and their omission simplify language implementation, design, and testing.  The circuits created by chisel do not preclude developers from using ```x``` and ```z``` in downstream toolchains as they see fit.
+Chisel does not directly support Verilog logic values ```x``` *unknown* and ```z``` *high-impedance*.  There are a number of reasons to want to avoid these values.  See:[The Dangers of Living With An X](http://infocenter.arm.com/help/topic/com.arm.doc.arp0009a/Verilog_X_Bugs.pdf) and [Malicious LUT: A stealthy FPGA Trojan injected and triggered by the design flow](http://ieeexplore.ieee.org/document/7827620/).  Chisel has its own eco-system of unit and functional testers that limit the need for ```x``` and ```z``` and their omission simplify language implementation, design, and testing.  The circuits created by chisel do not preclude developers from using ```x``` and ```z``` in downstream toolchains as they see fit.
 
 ### Get me Verilog
 I wrote a module and I want to see the Verilog; what do I do?
 
 Here's a simple hello world module in a file HelloWorld.scala.
 
+
 ```scala
 package intro
+```
+```scala mdoc:silent
 import chisel3._
 class HelloWorld extends Module {
   val io = IO(new Bundle{})
   printf("hello world\n")
 }
 ```
+
 Add the following
-```scala
-object HelloWorld extends App {
-  chisel3.Driver.execute(args, () => new HelloWorld)
+```scala mdoc:silent
+import chisel3.stage.ChiselStage
+object VerilogMain extends App {
+  (new ChiselStage).emitVerilog(new HelloWorld)
 }
 ```
 Now you can get some Verilog. Start sbt:
 ```
 bash> sbt
-> run-main intro.HelloWorld
-[info] Running examples.HelloWorld
+> run-main intro.VerilogMain
+[info] Running intro.VerilogMain
 [info] [0.004] Elaborating design...
 [info] [0.100] Done elaborating.
 [success] Total time: 1 s, completed Jan 12, 2017 6:24:03 PM
 ```
 or as a one-liner:
 ```
-bash> sbt 'runMain intro.HelloWorld'
+bash> sbt 'runMain intro.VerilogMain'
+```
+After either of the above there will be a HelloWorld.v file in the current directory:
+```scala mdoc:invisible
+val verilog = ChiselStage.emitVerilog(new HelloWorld)
+```
+```scala mdoc:passthrough
+println("```verilog")
+println(verilog)
+println("```")
 ```
-After either of the above there will be a HelloWorld.v file in the current directory.
 
 You can see additional options with
 ```
@@ -172,61 +121,84 @@ Alternatively, you can also use the sbt console to invoke the Verilog driver:
 $ sbt
 > console
 [info] Starting scala interpreter...
-[info]
-Welcome to Scala 2.11.8 (OpenJDK 64-Bit Server VM, Java 1.8.0_121).
+Welcome to Scala 2.12.13 (OpenJDK 64-Bit Server VM, Java 1.8.0_275).
 Type in expressions for evaluation. Or try :help.
-scala> chisel3.Driver.execute(Array[String](), () => new HelloWorld)
+
+scala> (new chisel3.stage.ChiselStage).emitVerilog(new HelloWorld())
 chisel3.Driver.execute(Array[String](), () => new HelloWorld)
-[info] [0.014] Elaborating design...
-[info] [0.306] Done elaborating.
-Total FIRRTL Compile Time: 838.8 ms
-res3: chisel3.ChiselExecutionResult = [...]
+Elaborating design...
+Done elaborating.
+res1: String =
+"module HelloWorld(
+  input   clock,
+  input   reset
+);
+...
 ```
 
 As before, there should be a HelloWorld.v file in the current directory.
 
+Note: Using the following, without the `new`,
+will ONLY return the string representation, and will not emit a `.v` file:
+
+```scala mdoc:silent
+ChiselStage.emitVerilog(new HelloWorld())
+```
+
 ### Get me FIRRTL
 
-If for some reason you don't want the Verilog (e.g. maybe you want to run some custom transformations before exporting to Verilog), then use something along these lines (replace Multiplier with your module):
+If for some reason you don't want the Verilog (e.g. maybe you want to run some custom transformations before exporting to Verilog), then use something along these lines:
 
 ```scala
 package intro
+```
+```scala mdoc:silent:reset
 
 import chisel3._
-import java.io.File
+import chisel3.stage.ChiselStage
+
+class MyFirrtlModule extends Module {
+  val io = IO(new Bundle{})
+}
 
-object Main extends App {
-  val f = new File("Multiplier.fir")
-  chisel3.Driver.dumpFirrtl(chisel3.Driver.elaborate(() => new Multiplier), Option(f))
+object FirrtlMain extends App {
+  (new ChiselStage).emitFirrtl(new MyFirrtlModule)
 }
 ```
 
 Run it with:
 
 ```
-sbt 'runMain intro.Main'
+sbt 'runMain intro.FirrtlMain'
+```
+```scala mdoc:invisible
+val theFirrtl = ChiselStage.emitFirrtl(new MyFirrtlModule)
+```
+```scala mdoc:passthrough
+println("```")
+println(theFirrtl)
+println("```")
 ```
 
-Alternatively, you can also use the sbt console to invoke the FIRRTL driver directly (replace HelloWorld with your module name):
+Alternatively, you can also use the sbt console to invoke the FIRRTL driver directly (replace MyFirrtlModule with your module name):
 
 ```
 $ sbt
 > console
 [info] Starting scala interpreter...
-[info]
-Welcome to Scala 2.11.11 (OpenJDK 64-Bit Server VM, Java 1.8.0_151).
+Welcome to Scala 2.12.13 (OpenJDK 64-Bit Server VM, Java 1.8.0_275).
 Type in expressions for evaluation. Or try :help.
-scala> chisel3.Driver.dumpFirrtl(chisel3.Driver.elaborate(() => new HelloWorld), Option(new java.io.File("output.fir")))
-chisel3.Driver.dumpFirrtl(chisel3.Driver.elaborate(() => new HelloWorld), Option(new java.io.File("output.fir")))
-[info] [0.000] Elaborating design...
-[info] [0.001] Done elaborating.
-res3: java.io.File = output.fir
+
+scala> (new chisel3.stage.ChiselStage).emitFirrtl(new MyFirrtlModule)
+Elaborating design...
+Done elaborating.
+res3: String = ...
 ```
 
 ### Why doesn't Chisel tell me which wires aren't connected?
 
-As of commit [c313e13](https://github.com/freechipsproject/chisel3/commit/c313e137d4e562ef20195312501840ceab8cbc6a) it can!
-Please visit the wiki page [Unconnected Wires](unconnected-wires) for details.
+As long as your code uses `import chisel3._` (and not `import Chisel._`), it does!
+See [Unconnected Wires](../explanations/unconnected-wires) for details.
 
 ### What does `Reference ... is not fully initialized.` mean?
 
@@ -235,7 +207,7 @@ It means that you have unconnected wires in your design which could be an indica
 In Chisel2 compatibility mode (`NotStrict` compile options), chisel generates firrtl code that disables firrtl's initialized wire checks.
 In pure chisel3 (`Strict` compile options), the generated firrtl code does not contain these disablers (`is invalid`).
 Output wires that are not driven (not connected) are reported by firrtl as `not fully initialized`.
-Please visit the wiki page [Unconnected Wires](unconnected-wires) for details on solving the problem.
+Read more at [Unconnected Wires](../explanations/unconnected-wires) for details on solving the problem.
 
 ### Can I specify behavior before and after generated initial blocks?
 Users may define the following macros if they wish to specify behavior before or after emitted initial blocks.
diff --git a/docs/src/wiki-deprecated/resources.md b/docs/src/resources/resources.md
index 8b75be49..fadd26a1 100644
--- a/docs/src/wiki-deprecated/resources.md
+++ b/docs/src/resources/resources.md
@@ -4,6 +4,8 @@ title:  "Resources and References"
 section: "chisel3"
 ---
 
+# Chisel Resources
+
 The *best resource* to learn about Chisel is the [**online Chisel Bootcamp**](https://mybinder.org/v2/gh/freechipsproject/chisel-bootcamp/master). This runs in your browser and assumes no prior Scala knowledge. (You may also run this locally via the [backing chisel-bootcamp GitHub repository](https://github.com/freechipsproject/chisel-bootcamp).)
 
 When you're ready to build your own circuits in Chisel, **we recommend starting from the [Chisel Template](https://github.com/freechipsproject/chisel-template) repository**, which provides a pre-configured project, example design, and testbench. Follow the [chisel-template readme](https://github.com/freechipsproject/chisel-template) to get started.
@@ -12,3 +14,4 @@ The following additional resources and references may be useful:
 
 - [Chisel Cheatsheet](https://github.com/freechipsproject/chisel-cheatsheet/releases/latest/download/chisel_cheatsheet.pdf)
 - [Digital Design With Chisel](https://github.com/schoeberl/chisel-book)
+- [Frequently Asked Questions](faqs)
diff --git a/docs/src/wiki-deprecated/experimental-features.md b/docs/src/wiki-deprecated/experimental-features.md
deleted file mode 100644
index d36b2946..00000000
--- a/docs/src/wiki-deprecated/experimental-features.md
+++ /dev/null
@@ -1,119 +0,0 @@
----
-layout: docs
-title:  "Experimental Features"
-section: "chisel3"
----
-
-Chisel has a number of new features that are worth checking out.  This page is an informal list of these features and projects.
-
-### FixedPoint
-FixedPoint numbers are basic *Data* type along side of UInt, SInt, etc.  Most common math and logic operations
-are supported. Chisel allows both the width and binary point to be inferred by the Firrtl compiler which can simplify
-circuit descriptions. See [FixedPointSpec](https://github.com/freechipsproject/chisel3/tree/master/src/test/scala/chiselTests/FixedPointSpec.scala)
-
-### Module Variants
-The standard Chisel *Module* requires a ```val io = IO(...)```, the experimental package introduces several
-new ways of defining Modules
-- BaseModule: no contents, instantiable
-- BlackBox extends BaseModule
-- UserDefinedModule extends BaseModule: this module can contain Chisel RTL. No default clock or reset lines. No default IO. - User should be able to specify non-io ports, ideally multiple of them.
-- ImplicitModule extends UserModule: has clock, reset, and io, essentially current Chisel Module.
-- RawModule: will be the user-facing version of UserDefinedModule
-- Module: type-aliases to ImplicitModule, the user-facing version of ImplicitModule.
-
-### Bundle Literals
-
-Chisel 3.2 introduces an experimental mechanism for Bundle literals in #820, but this feature is largely incomplete and not ready for user code yet. The following is provided as documentation for library writers who want to take a stab at using this mechanism for their library's bundles.
-
-```mdoc scala
-class MyBundle extends Bundle {
-  val a = UInt(8.W)
-  val b = Bool()
-
-  // Bundle literal constructor code, which will be auto-generated using macro annotations in
-  // the future.
-  import chisel3.core.BundleLitBinding
-  import chisel3.internal.firrtl.{ULit, Width}
-
-  // Full bundle literal constructor
-  def Lit(aVal: UInt, bVal: Bool): MyBundle = {
-    val clone = cloneType
-    clone.selfBind(BundleLitBinding(Map(
-      clone.a -> litArgOfBits(aVal),
-      clone.b -> litArgOfBits(bVal)
-    )))
-    clone
-  }
-
-  // Partial bundle literal constructor
-  def Lit(aVal: UInt): MyBundle = {
-    val clone = cloneType
-    clone.selfBind(BundleLitBinding(Map(
-      clone.a -> litArgOfBits(aVal)
-    )))
-    clone
-  }
-}
-```
-
-Example usage:
-
-```scala
-val outsideBundleLit = (new MyBundle).Lit(42.U, true.B)
-```
-
-### Interval Type
-
-**Intervals** are a new experimental numeric type that comprises UInt, SInt and FixedPoint numbers.
-It augments these types with range information, i.e. upper and lower numeric bounds.
-This information can be used to exercise tighter programmatic control over the ultimate widths of
-signals in the final circuit.  The **Firrtl** compiler can infer this range information based on
-operations and earlier values in the circuit. Intervals support all the ordinary bit and arithmetic operations
-associated with UInt, SInt, and FixedPoint and adds the following methods for manipulating the range of
-a **source** Interval with the IntervalRange of **target** Interval
-
-#### Clip -- Fit the value **source** into the IntervalRange of **target**, saturate if out of bounds
-The clip method applied to an interval creates a new interval based on the argument to clip,
-and constructs the necessary hardware so that the source Interval's value will be mapped into the new Interval.
-Values that are outside the result range will be pegged to either maximum or minimum of result range as appropriate.
-
-> Generates necessary hardware to clip values, values greater than range are set to range.high, values lower than range are set to range min.
-
-#### Wrap -- Fit the value **source** into the IntervalRange of **target**, wrapping around if out of bounds
-The wrap method applied to an interval creates a new interval based on the argument to wrap,
-and constructs the necessary
-hardware so that the source Interval's value will be mapped into the new Interval.
-Values that are outside the result range will be wrapped until they fall within the result range.
-
-> Generates necessary hardware to wrap values, values greater than range are set to range.high, values lower than range are set to range min.
-
-> Does not handle out of range values that are less than half the minimum or greater than twice maximum
-
-#### Squeeze -- Fit the value **source** into the smallest IntervalRange based on source and target.
-The squeeze method applied to an interval creates a new interval based on the argument to clip, the two ranges must overlap
-behavior of squeeze with inputs outside of the produced range is undefined.
-
-> Generates no hardware, strictly a sizing operation
-
-##### Range combinations
-
-| Condition | A.clip(B) | A.wrap(B) | A.squeeze(B) |
-| --------- | --------------- | --------------- | --------------- |
-| A === B   | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  |
-| A contains B   | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  |
-| B contains A   | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  |
-| A min < B min, A max in B  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  |
-| A min in B, A max > B max  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  |
-| A strictly less than B   | error               | error               | error               |
-| A strictly greater than B   | error               | error               | error               |
-
-
-#### Applying binary point operators to an Interval
-
-Consider a Interval with a binary point of 3: aaa.bbb
-
-| operation | after operation | binary point | lower | upper | meaning |
-| --------- | --------------- | ------------ | ----- | ----- | ------- |
-| setBinaryPoint(2) | aaa.bb |  2 | X | X  | set the precision |
-| shiftLeftBinaryPoint(2) | a.aabbb |  5 | X | X  | increase the precision |
-| shiftRighBinaryPoint(2) | aaaa.b |  1 | X | X  | reduce the precision |
diff --git a/docs/src/wiki-deprecated/interval-type.md b/docs/src/wiki-deprecated/interval-type.md
deleted file mode 100644
index 7f33461e..00000000
--- a/docs/src/wiki-deprecated/interval-type.md
+++ /dev/null
@@ -1,55 +0,0 @@
-# Intervals
-**Intervals** are a new experimental numeric type that comprises UInt, SInt and FixedPoint numbers.
-It augments these types with range information, i.e. upper and lower numeric bounds.
-This information can be used to exercise tighter programmatic control over the ultimate widths of
-signals in the final circuit.  The **Firrtl** compiler can infer this range information based on 
-operations and earlier values in the circuit. Intervals support all the ordinary bit and arithmetic operations
-associated with UInt, SInt, and FixedPoint and adds the following methods for manipulating the range of
-a **source** Interval with the IntervalRange of **target** Interval 
-
-### Clip -- Fit the value **source** into the IntervalRange of **target**, saturate if out of bounds
-The clip method applied to an interval creates a new interval based on the argument to clip,
-and constructs the necessary hardware so that the source Interval's value will be mapped into the new Interval.
-Values that are outside the result range will be pegged to either maximum or minimum of result range as appropriate.
-
-> Generates necessary hardware to clip values, values greater than range are set to range.high, values lower than range are set to range min.
-
-### Wrap -- Fit the value **source** into the IntervalRange of **target**, wrapping around if out of bounds
-The wrap method applied to an interval creates a new interval based on the argument to wrap,
-and constructs the necessary
-hardware so that the source Interval's value will be mapped into the new Interval.
-Values that are outside the result range will be wrapped until they fall within the result range.
-
-> Generates necessary hardware to wrap values, values greater than range are set to range.high, values lower than range are set to range min.
-
-> Does not handle out of range values that are less than half the minimum or greater than twice maximum
-
-### Squeeze -- Fit the value **source** into the smallest IntervalRange based on source and target.
-The squeeze method applied to an interval creates a new interval based on the argument to clip, the two ranges must overlap
-behavior of squeeze with inputs outside of the produced range is undefined.
-
-> Generates no hardware, strictly a sizing operation
-
-#### Range combinations
-
-| Condition | A.clip(B) | A.wrap(B) | A.squeeze(B) |
-| --------- | --------------- | --------------- | --------------- |
-| A === B   | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  |
-| A contains B   | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  |
-| B contains A   | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  |
-| A min < B min, A max in B  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  |
-| A min in B, A max > B max  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  | max(Alo, Blo), min(Ahi, Bhi)  |
-| A strictly less than B   | error               | error               | error               |
-| A strictly greater than B   | error               | error               | error               |
-
-
-### Applying binary point operators to an Interval
-
-Consider a Interval with a binary point of 3: aaa.bbb 
-
-| operation | after operation | binary point | lower | upper | meaning | 
-| --------- | --------------- | ------------ | ----- | ----- | ------- |
-| setBinaryPoint(2) | aaa.bb |  2 | X | X  | set the precision |
-| shiftLeftBinaryPoint(2) | a.aabbb |  5 | X | X  | increase the precision |
-| shiftRighBinaryPoint(2) | aaaa.b |  1 | X | X  | reduce the precision |
-