From 7ed02a7d385921a22e88fa1e77dc411d16a732c8 Mon Sep 17 00:00:00 2001 From: Jerry Zhao Date: Mon, 7 Sep 2020 11:36:37 -0700 Subject: [PATCH] Fix Typos --- docs/Customization/IOBinders.rst | 12 ++++++------ generators/chipyard/src/main/scala/TestHarness.scala | 6 +++--- .../src/main/scala/config/TutorialConfigs.scala | 2 +- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/Customization/IOBinders.rst b/docs/Customization/IOBinders.rst index 55920cd3..adfac22b 100644 --- a/docs/Customization/IOBinders.rst +++ b/docs/Customization/IOBinders.rst @@ -10,7 +10,7 @@ The ``IOBinder`` functions are responsible for instantiating IO cells and IOPort ``IOBinders`` are typically defined using the ``OverrideIOBinder`` or ``ComposeIOBinder`` macros. An ``IOBInder`` consists of a function matching ``Systems`` with a given trait that generates IO ports and IOCells, and returns a list of generated ports and cells. -For example, the ``WithUARTIOCells`` IOBinder specifies will, for any ``System`` that might have UART ports (``HasPeripheryUARTModuleIMP``, generate ports within the ``ChipTop`` (``ports``) as well as IOCells with the appropriate type and direction (``cells2d``). This function returns a the list of generated ports, and the list of generate IOCells. The list of generated ports is passed to the ``HarnessBinders`` such that they can be connected to ``TestHarness`` devices. +For example, the ``WithUARTIOCells`` IOBinder will, for any ``System`` that might have UART ports (``HasPeripheryUARTModuleImp``, generate ports within the ``ChipTop`` (``ports``) as well as IOCells with the appropriate type and direction (``cells2d``). This function returns a the list of generated ports, and the list of generated IOCells. The list of generated ports is passed to the ``HarnessBinders`` such that they can be connected to ``TestHarness`` devices. .. literalinclude:: ../../generators/chipyard/src/main/scala/IOBinders.scala @@ -21,15 +21,15 @@ For example, the ``WithUARTIOCells`` IOBinder specifies will, for any ``System`` HarnessBinders ============== -The ``HarnessBinder`` functions determine what modules to bind to the IOs of a ``ChipTop`` in the ``TestHarness``. The ``HarnessBinder`` interface is designed to be reused across various simulation modes, enabling decoupling of the target design from simulation and testing concerns. +The ``HarnessBinder`` functions determine what modules to bind to the IOs of a ``ChipTop`` in the ``TestHarness``. The ``HarnessBinder`` interface is designed to be reused across various simulation/implementation modes, enabling decoupling of the target design from simulation and testing concerns. * For SW RTL simulations, the default set of ``HarnessBinders`` instantiate software-simulated models of various devices, for example external memory or UART, and connect those models to the IOs of the ``ChipTop``. * For FireSim simulations, FireSim-specific ``HarnessBinders`` instantiate ``Bridges``, which faciliate cycle-accurate simulation across the simulated chip's IOs. See the FireSim documentation for more details. * In the future, a Chipyard FPGA prototyping flow may use ``HarnessBinders`` to connect ``ChipTop`` IOs to other devices or IOs in the FPGA harness. -For FireSim simulations, the ``HarnessBinder`` attach ``Bridge`` modules (See the FireSim documentation for more details). +For FireSim simulations, the ``HarnessBinder`` attaches ``Bridge`` modules (See the FireSim documentation for more details). -Like ``IOBinders``, ``HarnessBinders`` are defined using macros (``OverrideHarnessBinder, ComposeHarnessBinder``), and matches ``Systems`` with a given trait. However, ``HarnessBinders`` are also passed a reference to the ``TestHarness`` (``th: HasHarnessSignalReferences``) and the list of ports generated by the corresponding ``IOBinder`` (``ports: Seq[Data]``). +Like ``IOBinders``, ``HarnessBinders`` are defined using macros (``OverrideHarnessBinder, ComposeHarnessBinder``), and match ``Systems`` with a given trait. However, ``HarnessBinders`` are also passed a reference to the ``TestHarness`` (``th: HasHarnessSignalReferences``) and the list of ports generated by the corresponding ``IOBinder`` (``ports: Seq[Data]``). For exmaple, the ``WithUARTAdapter`` will connect the UART SW display adapter to the ports generated by the ``WithUARTIOCells`` described earlier, if those ports are present. @@ -38,8 +38,8 @@ For exmaple, the ``WithUARTAdapter`` will connect the UART SW display adapter to :start-after: DOC include start: WithUARTAdapter :end-before: DOC include end: WithUARTAdapter -The ``IOBinder`` and ``HarnesBinder`` system is designed to enable decoupling of concerns between target design and simulation ssystem. +The ``IOBinder`` and ``HarnessBinder`` system is designed to enable decoupling of concerns between the target design and the simulation system. -For a given set of chip IOs, there may be not only multiple simulation platforms ("harnesses", so-to-speak), but also multiple simulation strategies. For example, the choice of whether to connect the backing AXI4 memory port to a accurate DRAM model (``SimDRAM``) or a simple simulated memory model (``SimAXIMem``) is isolated in ``HarnessBinders``, and does not affect target RTL generation. +For a given set of chip IOs, there may be not only multiple simulation platforms ("harnesses", so-to-speak), but also multiple simulation strategies. For example, the choice of whether to connect the backing AXI4 memory port to an accurate DRAM model (``SimDRAM``) or a simple simulated memory model (``SimAXIMem``) is isolated in ``HarnessBinders``, and does not affect target RTL generation. Similarly, for a given simulation platform and strategy, there may be multiple strategies for generating the chip IOs. This target-design configuration is isolated in the ``IOBinders``. diff --git a/generators/chipyard/src/main/scala/TestHarness.scala b/generators/chipyard/src/main/scala/TestHarness.scala index 67cf03bf..2faff565 100644 --- a/generators/chipyard/src/main/scala/TestHarness.scala +++ b/generators/chipyard/src/main/scala/TestHarness.scala @@ -31,8 +31,8 @@ class TestHarness(implicit val p: Parameters) extends Module with HasHarnessSign val success = Output(Bool()) }) - val ldut = LazyModule(p(BuildTop)(p)).suggestName("chiptop") - val dut = Module(ldut.module) + val lazyDut = LazyModule(p(BuildTop)(p)).suggestName("chiptop") + val dut = Module(lazyDut.module) io.success := false.B val harnessClock = clock @@ -42,7 +42,7 @@ class TestHarness(implicit val p: Parameters) extends Module with HasHarnessSign // dutReset assignment can be overridden via a harnessFunction, but by default it is just reset val dutReset = WireDefault(if (p(GlobalResetSchemeKey).pinIsAsync) reset.asAsyncReset else reset) - ldut match { case d: HasTestHarnessFunctions => + lazyDut match { case d: HasTestHarnessFunctions => d.harnessFunctions.foreach(_(this)) ApplyHarnessBinders(this, d.lazySystem, p(HarnessBinders), d.portMap.toMap) } diff --git a/generators/chipyard/src/main/scala/config/TutorialConfigs.scala b/generators/chipyard/src/main/scala/config/TutorialConfigs.scala index e7adbdc1..3c64958f 100644 --- a/generators/chipyard/src/main/scala/config/TutorialConfigs.scala +++ b/generators/chipyard/src/main/scala/config/TutorialConfigs.scala @@ -48,7 +48,7 @@ class TutorialMMIOConfig extends Config( new chipyard.config.AbstractConfig ) -// // Tutorial Phase 3: Integrate a SHA3 RoCC accelerator +// Tutorial Phase 3: Integrate a SHA3 RoCC accelerator class TutorialSha3Config extends Config( // Uncomment this line once you added SHA3 to the build.sbt, and cloned the SHA3 repo // new sha3.WithSha3Accel ++