1 files changed, 29 insertions, 21 deletions
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.