Rename SerialAdapter+SimSerial to TSIToTileLink/SimTSI/TSIHarness

docs/Advanced-Concepts/Chip-Communication.rst

@@ -47,12 +47,12 @@ 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 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``
+During simulation, the host sends TSI commands to a simulation stub in the test harness called ``SimTSI``
+(C++ class) that resides in a ``SimTSI`` Verilog module (both are located in the ``generators/testchipip``
 project).
-This ``SimSerial`` Verilog module then sends the TSI command recieved by the simulation stub
+This ``SimTSI`` Verilog module then sends the TSI command recieved by the simulation stub
 to an adapter that converts the TSI command into a TileLink request.
-This conversion is done by the ``SerialAdapter`` module (located in the ``generators/testchipip`` project).
+This conversion is done by the ``TSIToTileLink`` module (located in the ``generators/testchipip`` project).
 After the transaction is converted to TileLink, the ``TLSerdesser`` (located in ``generators/testchipip``) serializes the
 transaction and sends it to the chip (this ``TLSerdesser`` is sometimes also referred to as a digital serial-link or SerDes).
 Once the serialized transaction is received on the chip, it is deserialized and masters a TileLink bus on the chip
@@ -76,7 +76,7 @@ simulation stub called ``SimDTM`` (C++ class) that resides in a ``SimDTM`` Veril
 sends the DMI command recieved by the simulation stub into the DUT which then converts the DMI
 command into a TileLink request. This conversion is done by the DTM named ``DebugModule`` in the ``generators/rocket-chip`` project.
 When the DTM receives the program to load, it starts to write the binary byte-wise into memory.
-This is considerably slower than the TSI protocol communication pipeline (i.e. ``SimSerial``/``SerialAdapter``/TileLink)
+This is considerably slower than the TSI protocol communication pipeline (i.e. ``SimTSI``/``TSIToTileLink``/TileLink)
 which directly writes the program binary to memory.
 
 Starting the TSI or DMI Simulation
@@ -216,7 +216,7 @@ Softcore-driven Bringup Setup of the Example Test Chip after Tapeout
 Assuming this example test chip is taped out and now ready to be tested, we can communicate with the chip using this serial-link.
 For example, a common test setup used at Berkeley to evaluate Chipyard-based test-chips includes an FPGA running a RISC-V soft-core that is able to speak to the DUT (over an FMC).
 This RISC-V soft-core would serve as the host of the test that will run on the DUT.
-This is done by the RISC-V soft-core running FESVR, sending TSI commands to a ``SerialAdapter`` / ``TLSerdesser`` programmed on the FPGA.
+This is done by the RISC-V soft-core running FESVR, sending TSI commands to a ``TSIToTileLink`` / ``TLSerdesser`` programmed on the FPGA.
 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.

docs/Advanced-Concepts/Resources.rst

@@ -2,24 +2,24 @@ Accessing Scala Resources
 ===============================
 
 A simple way to copy over a source file to the build directory to be used for a simulation compile or VLSI flow is to use the ``addResource`` function given by FIRRTL.
-An example of its use can be seen in `generators/testchipip/src/main/scala/SerialAdapter.scala <https://github.com/ucb-bar/testchipip/blob/master/src/main/scala/SerialAdapter.scala>`_.
+An example of its use can be seen in `generators/testchipip/src/main/scala/SimTSI.scala <https://github.com/ucb-bar/testchipip/blob/master/src/main/scala/SimTSI.scala>`_.
 Here is the example inlined:
 
 .. code-block:: scala
 
-    class SimSerial(w: Int) extends BlackBox with HasBlackBoxResource {
+    class SimTSI extends BlackBox with HasBlackBoxResource {
       val io = IO(new Bundle {
         val clock = Input(Clock())
         val reset = Input(Bool())
-        val serial = Flipped(new SerialIO(w))
+        val tsi = Flipped(new TSIIO)
         val exit = Output(Bool())
       })
 
-      addResource("/testchipip/vsrc/SimSerial.v")
-      addResource("/testchipip/csrc/SimSerial.cc")
+      addResource("/testchipip/vsrc/SimTSI.v")
+      addResource("/testchipip/csrc/SimTSI.cc")
     }
 
-In this example, the ``SimSerial`` files will be copied from a specific folder (in this case the ``path/to/testchipip/src/main/resources/testchipip/...``) to the build folder.
+In this example, the ``SimTSI`` files will be copied from a specific folder (in this case the ``path/to/testchipip/src/main/resources/testchipip/...``) to the build folder.
 The ``addResource`` path retrieves resources from the ``src/main/resources`` directory.
 So to get an item at ``src/main/resources/fileA.v`` you can use ``addResource("/fileA.v")``.
 However, one caveat of this approach is that to retrieve the file during the FIRRTL compile, you must have that project in the FIRRTL compiler's classpath.

docs/Chipyard-Basics/Configs-Parameters-Mixins.rst

@@ -83,8 +83,8 @@ This example shows the Chipyard default top that composes multiple traits togeth
     :end-before: DOC include end: DigitalTop
 
 
-There are two "cakes" or mixins here. One for the lazy module (ex. ``CanHavePeripherySerial``) and one for the lazy module
-implementation (ex. ``CanHavePeripherySerialModuleImp`` where ``Imp`` refers to implementation). The lazy module defines
+There are two "cakes" or mixins here. One for the lazy module (ex. ``CanHavePeripheryTLSerial``) and one for the lazy module
+implementation (ex. ``CanHavePeripheryTLSerialModuleImp`` where ``Imp`` refers to implementation). The lazy module defines
 all the logical connections between generators and exchanges configuration information among them, while the
 lazy module implementation performs the actual Chisel RTL elaboration.
 
@@ -93,19 +93,17 @@ In the ``DigitalTop`` example class, the "outer" ``DigitalTop`` instantiates the
 of the module until all logical connections are determined and all configuration information is exchanged.
 The ``System`` outer base class, as well as the
 ``CanHavePeriphery<X>`` outer traits contain code to perform high-level logical
-connections. For example, the ``CanHavePeripherySerial`` outer trait contains code
-to optionally lazily instantiate the ``SerialAdapter``, and connect the ``SerialAdapter``'s
+connections. For example, the ``CanHavePeripheryTLSerial`` outer trait contains code
+to optionally lazily instantiate the ``TLSerdesser``, and connect the ``TLSerdesser`` 's
 TileLink node to the Front bus.
 
 The ``ModuleImp`` classes and traits perform elaboration of real RTL.
-For example, the ``CanHavePeripherySerialModuleImp`` trait optionally physically connects
-the ``SerialAdapter`` module, and instantiates queues.
 
 In the test harness, the SoC is elaborated with
 ``val dut = p(BuildTop)(p)``.
 
 After elaboration, the system submodule of ``ChipTop`` will be a ``DigitalTop`` module, which contains a
-``SerialAdapter`` module (among others), if the config specified for that block to be instantiated.
+``TLSerdesser`` module (among others), if the config specified for that block to be instantiated.
 
 From a high level, classes which extend ``LazyModule`` *must* reference
 their module implementation through ``lazy val module``, and they
@@ -116,7 +114,7 @@ other normal modules OR lazy modules (for nested Diplomacy
 graphs, for example).
 
 The naming convention for an additive mixin or trait is ``CanHave<YourMixin>``.
-This is shown in the ``Top`` class where things such as ``CanHavePeripherySerial`` connect a RTL component to a bus and expose signals to the top-level.
+This is shown in the ``Top`` class where things such as ``CanHavePeripheryTLSerial`` connect a RTL component to a bus and expose signals to the top-level.
 
 Additional References
 ---------------------------

docs/Generators/TestChipIP.rst

@@ -2,16 +2,16 @@ Test Chip IP
 ============
 
 Chipyard includes a Test Chip IP library which provides various hardware
-widgets that may be useful when designing SoCs. This includes a :ref:`Generators/TestChipIP:Serial Adapter`,
+widgets that may be useful when designing SoCs. This includes a :ref:`Generators/TestChipIP:SimTSI`,
 :ref:`Generators/TestChipIP:Block Device Controller`, :ref:`Generators/TestChipIP:TileLink SERDES`, :ref:`Generators/TestChipIP:TileLink Switcher`,
 :ref:`Generators/TestChipIP:TileLink Ring Network`, and :ref:`Generators/TestChipIP:UART Adapter`.
 
-Serial Adapter
+SimTSI
 --------------
 
-The serial adapter is used by tethered test chips to communicate with the host
+The SimTSI and TSIToTileLink are used by tethered test chips to communicate with the host
 processor. An instance of RISC-V frontend server running on the host CPU
-can send commands to the serial adapter to read and write data from the memory
+can send commands to the TSIToTileLink to read and write data from the memory
 system. The frontend server uses this functionality to load the test program
 into memory and to poll for completion of the program. More information on
 this can be found in :ref:`Customization/Boot-Process:Chipyard Boot Process`.