Update docs for the removal of val io and MultiIOModule

1 files changed, 11 insertions, 11 deletions

diff --git a/docs/src/explanations/naming.md b/docs/src/explanations/naming.md
index fb1121f9..60c653aa 100644
--- a/docs/src/explanations/naming.md
+++ b/docs/src/explanations/naming.md
@@ -44,7 +44,7 @@ class MyBundle extends Bundle {
   val foo = Input(UInt(3.W))
   // val foo = autoNameRecursively("foo")(Input(UInt(3.W)))
 }
-class Example1 extends MultiIOModule {
+class Example1 extends Module {
   val io = IO(new MyBundle())
   // val io = autoNameRecursively("io")(IO(new MyBundle()))
 }
@@ -57,7 +57,7 @@ Otherwise, it is rewritten to also include the name as a prefix to any signals g
 side of the val declaration:
 
 ```scala mdoc
-class Example2 extends MultiIOModule {
+class Example2 extends Module {
   val in = IO(Input(UInt(2.W)))
   // val in = autoNameRecursively("in")(prefix("in")(IO(Input(UInt(2.W)))))
 
@@ -80,7 +80,7 @@ ChiselStage.emitVerilog(new Example2)
 Note that the naming also works if the hardware type is nested in an `Option` or a subtype of `Iterable`:
 
 ```scala mdoc
-class Example3 extends MultiIOModule {
+class Example3 extends Module {
   val in = IO(Input(UInt(2.W)))
   // val in = autoNameRecursively("in")(prefix("in")(IO(Input(UInt(2.W)))))
 
@@ -102,7 +102,7 @@ ChiselStage.emitVerilog(new Example3)
 
 There is also a slight variant (`autoNameRecursivelyProduct`) for naming hardware with names provided by an unapply:
 ```scala mdoc
-class UnapplyExample extends MultiIOModule {
+class UnapplyExample extends Module {
   def mkIO() = (IO(Input(UInt(2.W))), IO(Output(UInt())))
   val (in, out) = mkIO()
   // val (in, out) = autoNameRecursivelyProduct(List(Some("in"), Some("out")))(mkIO())
@@ -126,7 +126,7 @@ but don't want to influence other names in the module.
 In the following example, we prefix additional logic with "ECO", where `Example4` is pre-ECO and `Example5` is post-ECO:
 
 ```scala mdoc
-class Example4 extends MultiIOModule {
+class Example4 extends Module {
   val in = IO(Input(UInt(2.W)))
   val out = IO(Output(UInt()))
 
@@ -135,7 +135,7 @@ class Example4 extends MultiIOModule {
   out := add + 1.U
 }
 
-class Example5 extends MultiIOModule {
+class Example5 extends Module {
   val in = IO(Input(UInt(2.W)))
   val out = IO(Output(UInt()))
 
@@ -152,7 +152,7 @@ ChiselStage.emitVerilog(new Example5)
 Also note that the prefixes append to each other (including the prefix generated by the compiler plugin):
 
 ```scala mdoc
-class Example6 extends MultiIOModule {
+class Example6 extends Module {
   val in = IO(Input(UInt(2.W)))
   val out = IO(Output(UInt()))
 
@@ -169,7 +169,7 @@ Sometimes you may want to disable the prefixing. This might occur if you are wri
 don't want the prefixing behavior. In this case, you can use the `noPrefix` object:
 
 ```scala mdoc
-class Example7 extends MultiIOModule {
+class Example7 extends Module {
   val in = IO(Input(UInt(2.W)))
   val out = IO(Output(UInt()))
 
@@ -188,7 +188,7 @@ If you want to specify the name of a signal, you can always use the `.suggestNam
 name will still be prefixed (including by the plugin). You can always use the `noPrefix` object to strip this.
 
 ```scala mdoc
-class Example8 extends MultiIOModule {
+class Example8 extends Module {
   val in = IO(Input(UInt(2.W)))
   val out = IO(Output(UInt()))
 
@@ -208,7 +208,7 @@ value. Note that you can parameterize the name by the module's parameters. This
 names more stable and is highly recommended to do.
 
 ```scala mdoc
-class Example9(width: Int) extends MultiIOModule {
+class Example9(width: Int) extends Module {
   override val desiredName = s"EXAMPLE9WITHWIDTH$width"
   val in = IO(Input(UInt(width.W)))
   val out = IO(Output(UInt()))
@@ -236,7 +236,7 @@ For example, the signals in the following module are in a nested scope; the plug
 reflection naming cannot:
 
 ```scala mdoc
-class Example10 extends MultiIOModule {
+class Example10 extends Module {
   {
     val in = IO(Input(UInt(3.W)))
     val out = IO(Output(UInt()))