Update harnessClk/Rst naming to buildtop | Small docs cleanup

docs/Advanced-Concepts/Chip-Communication.rst

@@ -46,7 +46,7 @@ Using the Tethered Serial Interface (TSI)
 
 By default, Chipyard uses the Tethered Serial Interface (TSI) to communicate with the DUT.
 TSI protocol is an implementation of HTIF that is used to send commands to the RISC-V DUT.
-These TSI commands are simple R/W commands that are able to probe the DUT's memory space.
+These TSI commands are simple R/W commands that are able to access the DUT's memory space.
 During simulation, the host sends TSI commands to a simulation stub in the test harness called ``SimSerial``
 (C++ class) that resides in a ``SimSerial`` Verilog module (both are located in the ``generators/testchipip``
 project).
@@ -59,7 +59,7 @@ Once the serialized transaction is received on the chip, it is deserialized and
 which handles the request.
 In simulation, FESVR resets the DUT, writes into memory the test program, and indicates to the DUT to start the program
 through an interrupt (see :ref:`customization/Boot-Process:Chipyard Boot Process`).
-Using TSI is currently the fastest mechanism to communicate with the DUT in simulation and is also used by FireSim.
+Using TSI is currently the fastest mechanism to communicate with the DUT in simulation (compared to DMI/JTAG) and is also used by FireSim.
 
 Using the Debug Module Interface (DMI)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -173,7 +173,7 @@ The following image shows the DUT with these set of default signals:
 
 In this setup, the serial-link is connected to the TSI/FESVR peripherals while the AXI port is connected
 to a simulated AXI memory.
-However, AXI ports tend to have many signals associated with them so instead of creating an AXI port off the DUT,
+However, AXI ports tend to have many signals, and thus wires, associated with them so instead of creating an AXI port off the DUT,
 one can send the memory transactions over the bi-directional serial-link (``TLSerdesser``) so that the main
 interface to the DUT is the serial-link (which has comparatively less signals than an AXI port).
 This new setup (shown below) is a typical Chipyard test chip setup:
@@ -216,7 +216,7 @@ This is done by the RISC-V soft-core running FESVR, sending TSI commands to a ``
 Once the commands are converted to serialized TileLink, then they can be sent over some medium to the DUT
 (like an FMC cable or a set of wires connecting FPGA outputs to the DUT board).
 Similar to simulation, if the chip requests offchip memory, it can then send the transaction back over the serial-link.
-Then the request can be serviced by the channel of FPGA DRAM.
+Then the request can be serviced by the FPGA DRAM.
 The following image shows this flow:
 
 .. image:: ../_static/images/chip-bringup.png

docs/Advanced-Concepts/Harness-Clocks.rst

@@ -8,8 +8,8 @@ have independent clock domains through diplomacy.
 This implies that some reference clock enters the ``ChipTop`` and then is divided down into
 separate clock domains.
 From the perspective of the ``TestHarness`` module, the ``ChipTop`` clock and reset is
-provided from the harness clock and reset (called ``harnessClock`` and ``harnessReset``).
-In the default case, this ``harnessClock`` and ``harnessReset`` is directly wired to the
+provided from a clock and reset called ``buildtopClock`` and ``buildtopReset``.
+In the default case, this ``buildtopClock`` and ``buildtopReset`` is directly wired to the
 clock and reset IO's of the ``TestHarness`` module.
 However, the ``TestHarness`` has the ability to generate a standalone clock and reset signal
 that is separate from the reference clock/reset of ``ChipTop``.
@@ -32,7 +32,7 @@ Here you can see the ``p(HarnessClockInstantiatorKey)`` is used to request a clo
 
 .. note::
     In the case that the reference clock entering ``ChipTop`` is not the overall reference clock of the simulation
-    (i.e. not the clock/reset coming into the ``TestHarness`` module), the ``harnessClock`` and ``harnessReset`` can
+    (i.e. the clock/reset coming into the ``TestHarness`` module), the ``buildtopClock`` and ``buildtopReset`` can
     differ from the implicit ``TestHarness`` clock and reset. For example, if the ``ChipTop`` reference is 500MHz but an
-    extra harness clock is requested at 1GHz, the ``TestHarness`` implicit clock/reset will be at 1GHz while the ``harnessClock``
-    and ``harnessReset`` will be at 500MHz.
+    extra harness clock is requested at 1GHz, the ``TestHarness`` implicit clock/reset will be at 1GHz while the ``buildtopClock``
+    and ``buildtopReset`` will be at 500MHz.