update with tethered v standalone | small flow fixes [ci skip]

docs/Advanced-Usage/Chip-Communication.rst

@@ -3,8 +3,13 @@
 Communicating with the Chip/DUT
 ===============================
 
-What good is a chip/DUT if it can't communicate with the outside world? Chipyard designs
+What good is a chip/DUT if it can't communicate with the outside world? There are two types of designs that can be
-communicate to the outside world in one of two ways:
+made: tethered or standalone designs. A tethered design is where a host must interact with the DUT (a target) to bringup the design.
+A standalone design is a design that can bringup itself (has its own bootrom, loads programs itself, etc). An example of a tethered design
+is a Chipyard simulation where the host computer loads the test program into the designs memory. An example of a standalone design is
+a design where a program can be loaded from an SDCard by default.
+
+Chipyard designs communicate to the outside world in one of two ways that mainly correspond to a tethered design:
 
 * using the Tethered Serial Interface (TSI) or the Debug Module Interface (DMI) with the Front-End Server (FESVR) to communicate with the design
 * using the JTAG interface with OpenOCD and GDB to communicate with the design
@@ -20,7 +25,7 @@ Primer on the Front-End Server (FESVR)
 
 FESVR is a C++ library that manages communication
 between a host machine and a RISC-V target. For debugging, it provides a simple API to reset,
-send messages, and run programs on a DUT but it also provides peripheral device emulation.
+send messages, and load/run programs on a DUT but it also provides peripheral device emulation.
 It can be added used simulators (VCS, Verilator, FireSim) as well as in a bringup sequence
 for a taped out chip.
 
@@ -32,7 +37,7 @@ Using the Tethered Serial Interface (TSI)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 By default, Chipyard uses the Tethered Serial Interface (TSI) to communicate with the target.
-TSI is the implementation of the HTIF interface that is used to send commands to the
+TSI is the implementation of the HTIF that is used to send commands to the
 RISC-V target. These TSI commands are simple R/W commands
 that are able to probe the DUT's memory space. In simulation, these TSI commands connect
 to a ``SimSerial`` (located in the ``generators/testchipip`` project) simulation C++
@@ -51,9 +56,9 @@ sends the converted TileLink commands over a serial link to the chip.
 Using the Debug Module Interface (DMI)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Another option to bringup the target is to use the Debug Module Interface (DMI) provided by Rocket Chip.
+Another option to bringup the target is to use the Debug Module Interface (DMI) provided by a Debug Transfer Module (DTM) existing within the target.
-In this case, a Debug Test Module (DTM) must exist in the target that communicates with the DMI.
+Similar to TSI, DMI is an implementation of HTIF.
-The DTM is given in the RISC-V Debug Specification and is responsible for managing communication between
+The DTM is given in the `RISC-V Debug Specification <https://riscv.org/specifications/debug-specification/>`__ and is responsible for managing communication between
 the target and whatever lives on the other side of the DMI (in this case FESVR). This is added by default
 to the Rocket Chip ``Subsystem`` by having the ``HasPeripheryDebug`` and ``HasPeripheryDebugModuleImp`` mixins.
 Chipyard disables the DTM by default so that it can use the TSI interface.
@@ -74,7 +79,7 @@ configurations. For example:
 
    make CONFIG=LargeBoomConfig run-asm-tests
 
-If you would like to build a DMI system with a Chipyard configuration, the you must create a
+If you would like to build and simulate a DMI system with a Chipyard configuration, the you must create a
 top-level system with the DTM as well as a config to use that top-level system.
 
 .. literalinclude:: ../../generators/example/src/main/scala/RocketConfigs.scala
@@ -91,12 +96,12 @@ The rest of the mixins specify the rest of the system (cores, accelerators, etc)
     # or
     cd sims/vcs
 
-    make CONFIG=dmiRocketConfig TOP=TopWithDTM MODEL=TestHarnessWithDTM
+    make CONFIG=dmiRocketConfig TOP=TopWithDTM MODEL=TestHarnessWithDTM run-asm-tests
 
 Using the JTAG Interface
 ------------------------
 
-The main way to use JTAG with a Rocket Chip based system is to instantiate the Debug Test Module (DTM)
+The main way to use JTAG with a Rocket Chip based system is to instantiate the Debug Transfer Module (DTM)
 and configure it to use a JTAG interface (by default the DTM is setup to use the DMI interface mentioned above).
 However, if you want to use JTAG, you must do the following steps to setup a DTM+JTAG enabled system.
 
@@ -116,7 +121,7 @@ The ``WithJtagDTM`` will configure that instantiated DTM to use JTAG as the brin
 this can be removed if you want a DMI-only bringup).
 The rest of the mixins specify the rest of the system (cores, accelerators, etc).
 
-Starting the DTM+JTAG Simulation
+Building a DTM+JTAG Simulator
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 After creating the config, call the ``make`` command like the following:
@@ -131,7 +136,7 @@ After creating the config, call the ``make`` command like the following:
 
 In this example, this will use the config that you previously specified, as well as set
 the other parameters that are needed to satisfy the build system. After that point, you
-should have a JTAG enabled simulation that you can attach to using OpenOCD and GDB!
+should have a JTAG enabled simulator that you can attach to using OpenOCD and GDB!
 
 Debugging with JTAG
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

docs/Software/Spike.rst

@@ -1,4 +1,19 @@
 The RISC-V ISA Simulator (Spike)
 =================================
 
-.. attention:: This article is a stub. Fill it out!
+Spike is the golden reference functional RISC-V ISA simulator.
+It provides full system emulation or proxied emulation with the HTIF/FESVR.
+It serves as a starting point for running software on a RISC-V target.
+Here is a highlight of some of Spikes main features:
+
+* Multiple ISAs: RV32IMAFDQCV extensions
+* Multiple memory models: Weak Memory Ordering (WMO) and Total Store Ordering (TSO)
+* Priveleged Spec: Machine, Supervisor, User modes (v1.11)
+* Debug Spec
+* Single-step debugging with support for viewing memory/register contents
+* Multiple CPU support
+* JTAG support
+* Highly extensible (add and test new instructions)
+* And much more!
+
+Spike comes pre-packaged in the RISC-V toolchain.