Run pre-commit on all files

docs/Advanced-Concepts/CDEs.rst

@@ -107,5 +107,3 @@ In this example, note how ``up(SomeKeyY, site)`` in ``WithXEqualsYUp`` will refe
 
 
 Also note that again, ``site`` must be recursively passed through the call to ``up``.
-
-

docs/Advanced-Concepts/Debugging-RTL.rst

@@ -96,11 +96,10 @@ To run overnight tests (repeated random tests), run
 
   make CONFIG=CustomConfig TORTURE_ONIGHT_OPTIONS=<overnight options> torture-overnight
 
-You can find the overnight options in `overnight/src/main/scala/main.scala` in the torture repo.  
+You can find the overnight options in `overnight/src/main/scala/main.scala` in the torture repo.
 
 Firesim Debugging
 ---------------------------
 Chisel printfs, asserts, Dromajo co-simulation, and waveform generation are also available in FireSim
 FPGA-accelerated simulation. See the FireSim
 `documentation <https://docs.fires.im/en/latest/>`__ for more detail.
-

docs/Advanced-Concepts/index.rst

@@ -16,4 +16,3 @@ They expect you to know about Chisel, Parameters, configs, etc.
    CDEs
    Harness-Clocks
    Managing-Published-Scala-Dependencies
-

docs/Chipyard-Basics/index.rst

@@ -19,5 +19,3 @@ Hit next to get started!
    Development-Ecosystem
    Configs-Parameters-Mixins
    Initial-Repo-Setup
-
-

docs/Customization/DMA-Devices.rst

@@ -35,5 +35,3 @@ Once we've created our top-level module including the DMA widget, we can create
     :language: scala
     :start-after: DOC include start: InitZeroRocketConfig
     :end-before: DOC include end: InitZeroRocketConfig
-
-

docs/Customization/Keys-Traits-Configs.rst

@@ -75,5 +75,3 @@ We can use this config fragment when composing our configs.
 
 .. note::
    Readers who want more information on the configuration system may be interested in reading :ref:`cdes`.
-
-

docs/Customization/MMIO-Peripherals.rst

@@ -138,5 +138,3 @@ Now with all of that done, we can go ahead and run our simulation.
 
     cd sims/verilator
     make CONFIG=GCDTLRocketConfig BINARY=../../tests/gcd.riscv run-binary
-
-

docs/Customization/RoCC-Accelerators.rst

@@ -67,4 +67,3 @@ For instance, if we wanted to add the previously defined accelerator and route c
       new RocketConfig)
 
 To add RoCC instructions in your program, use the RoCC C macros provided in ``tests/rocc.h``. You can find examples in the files ``tests/accum.c`` and ``charcount.c``.
-

docs/Generators/Gemmini.rst

@@ -7,4 +7,3 @@ Gemmini enables architects to make useful insights into how different components
 Check out `Gemmini's documentation <https://github.com/ucb-bar/gemmini/blob/master/README.md>`__ to learn how to generate, simulate, and profile DNN accelerators with Gemmini and Chipyard.
 
 .. image:: ../_static/images/gemmini-system.png
-

docs/Generators/Ibex.rst

@@ -11,4 +11,4 @@ The core exposes a custom memory interface, interrupt ports, and other misc. por
 
 While the core itself is not a generator, we expose the same parameterization that the Ibex core provides so that all supported Ibex configurations are available.
 
-For more information, see the `GitHub repository for Ibex <https://github.com/lowRISC/ibex>`__.
+For more information, see the `GitHub repository for Ibex <https://github.com/lowRISC/ibex>`__.

docs/Generators/SHA3.rst

@@ -79,5 +79,3 @@ this config fragment is shown here:
 
 The SHA3 example baremetal and Linux tests are located in the SHA3 repository.
 Please refer to its `README.md <https://github.com/ucb-bar/sha3/blob/master/README.md>`_ for more information on how to run/build the tests.
-
-

docs/Generators/Sodor.rst

@@ -4,7 +4,7 @@ Sodor Core
 `Sodor <https://github.com/ucb-bar/riscv-sodor>`__ is a collection of 5 simple RV32MI cores designed for educational purpose.
 The `Sodor core` is wrapped in an tile during generation so it can be used as a component within the `Rocket Chip SoC generator`.
 The cores contain a small scratchpad memory to which the program are loaded through a TileLink slave port, and the cores **DO NOT**
-support external memory. 
+support external memory.
 
 The five available cores and their corresponding generator configuration are:
 

docs/Generators/TestChipIP.rst

@@ -69,7 +69,7 @@ to the TLXbar provided by RocketChip, but uses ring networks internally rather
 than crossbars. This can be useful for chips with very wide TileLink networks
 (many cores and L2 banks) that can sacrifice cross-section bandwidth to relieve
 wire routing congestion. Documentation on how to use the ring network can be
-found in :ref:`Customization/Memory-Hierarchy:The System Bus`. The implementation itself can be found 
+found in :ref:`Customization/Memory-Hierarchy:The System Bus`. The implementation itself can be found
 `here <https://github.com/ucb-bar/testchipip/blob/master/src/main/scala/Ring.scala>`_,
 and may serve as an example of how to implement your own TileLink network with
 a different topology.

docs/Generators/index.rst

@@ -34,4 +34,3 @@ so changes to the generators themselves will automatically be used when building
    NVDLA
    Sodor
    Mempress
-

docs/Prototyping/VCU118.rst

@@ -122,7 +122,7 @@ Additionally, these instructions assume you are using Linux with ``sudo`` privil
 
 3. The VCU118 bootrom assumes that the Linux binary to load into memory will be located on sector 34 of the SDCard.
    Change the default partition alignment to `1` so you can write to sector `34`.
-   Do this with the `l` command from the expert menu (opened with 'x', closed with 'm'). 
+   Do this with the `l` command from the expert menu (opened with 'x', closed with 'm').
 
 4. Create a 512MiB partition to store the Linux binary (this can be smaller but it must be larger than the size of the Linux binary).
    Use `n`, partion number 1 and select sector 34, with size `+1048576` (corresponding to 512MiB).
@@ -162,4 +162,4 @@ To interact with Linux via the UART console, you can connect to the serial port
 
    screen -S FPGA_UART_CONSOLE /dev/ttyUSB1 115200
 
-Once connected, you should see the binary being loaded as well as Linux output (in some cases you might need to reset the DUT). Sign in as 'root' with password 'fpga'. 
+Once connected, you should see the binary being loaded as well as Linux output (in some cases you might need to reset the DUT). Sign in as 'root' with password 'fpga'.

docs/TileLink-Diplomacy-Reference/Diplomacy-Connectors.rst

@@ -9,7 +9,7 @@ library provides four operators that can be used to form edges between nodes.
 
 This is the basic connection operator. It is the same syntax as the Chisel
 uni-directional connector, but it is not equivalent. This operator connects
-Diplomacy nodes, not Chisel bundles. 
+Diplomacy nodes, not Chisel bundles.
 
 The basic connection operator always creates a single edge between the two
 nodes.

docs/TileLink-Diplomacy-Reference/Register-Router.rst

@@ -2,15 +2,15 @@ Register Router
 ===============
 
 Memory-mapped devices generally follow a common pattern. They expose a set
-of registers to the CPUs. By writing to a register, the CPU can change the 
+of registers to the CPUs. By writing to a register, the CPU can change the
 device's settings or send a command. By reading from a register, the CPU can
 query the device's state or retrieve results.
 
-While designers can manually instantiate a manager node and write the logic 
+While designers can manually instantiate a manager node and write the logic
 for exposing registers themselves, it's much easier to use RocketChip's
 ``regmap`` interface, which can generate most of the glue logic.
 
-For TileLink devices, you can use the ``regmap`` interface by extending 
+For TileLink devices, you can use the ``regmap`` interface by extending
 the ``TLRegisterRouter`` class, as shown in :ref:`mmio-accelerators`,
 or you can create a regular LazyModule and instantiate a ``TLRegisterNode``.
 This section will focus on the second method.

docs/TileLink-Diplomacy-Reference/Widgets.rst

@@ -465,6 +465,3 @@ if you want multi-beat reads/writes.
 AXI4RAM only supports AXI4-Lite operations, so multi-beat reads/writes and
 reads/writes smaller than full-width are not supported. Use an ``AXI4Fragmenter``
 if you want to use the full AXI4 protocol.
-
-
-

docs/VLSI/ASAP7-Tutorial.rst

@@ -54,8 +54,8 @@ Prerequisites
 * Genus, Innovus, Voltus, VCS, and Calibre licenses
 * For ASAP7 specifically (`README <https://github.com/ucb-bar/hammer/tree/master/src/hammer-vlsi/technology/asap7>`__ for more details):
 
-  * First, download the `ASAP7 v1p7 PDK <https://github.com/The-OpenROAD-Project/asap7>`__ (we recommend shallow-cloning or downloading an archive of the repository). Then, download the `encrypted Calibre decks tarball <http://asap.asu.edu/asap/>`__ tarball to a directory of choice (e.g. the root directory of the PDK) but do not extract it like the instructions say. The tech plugin is configured to extract the tarball into a cache directory for you. 
-  * If you have additional ASAP7 hard macros, their LEF & GDS need to be 4x upscaled @ 4000 DBU precision. 
+  * First, download the `ASAP7 v1p7 PDK <https://github.com/The-OpenROAD-Project/asap7>`__ (we recommend shallow-cloning or downloading an archive of the repository). Then, download the `encrypted Calibre decks tarball <http://asap.asu.edu/asap/>`__ tarball to a directory of choice (e.g. the root directory of the PDK) but do not extract it like the instructions say. The tech plugin is configured to extract the tarball into a cache directory for you.
+  * If you have additional ASAP7 hard macros, their LEF & GDS need to be 4x upscaled @ 4000 DBU precision.
 
 Initial Setup
 -------------
@@ -64,7 +64,7 @@ In the Chipyard root, run:
 .. code-block:: shell
 
     ./scripts/init-vlsi.sh asap7
-    
+
 to pull the Hammer & plugin submodules. Note that for technologies other than ``sky130`` or ``asap7``, the tech submodule must be added in the ``vlsi`` folder first.
 
 Pull the Hammer environment into the shell:
@@ -116,7 +116,7 @@ Place-and-Route
 
 After completion, the final database can be opened in an interactive Innovus session via ``./build/par-rundir/generated-scripts/open_chip``.
 
-Intermediate database are written in ``build/par-rundir`` between each step of the ``par`` action, and can be restored in an interactive Innovus session as desired for debugging purposes. 
+Intermediate database are written in ``build/par-rundir`` between each step of the ``par`` action, and can be restored in an interactive Innovus session as desired for debugging purposes.
 
 Timing reports are found in ``build/par-rundir/timingReports``. They are gzipped text files.
 

docs/VLSI/Building-A-Chip.rst

@@ -50,5 +50,3 @@ Running the VLSI tool flow
 
 For the full documentation on how to use the VLSI tool flow, see the `Hammer Documentation <https://hammer-vlsi.readthedocs.io/>`__.
 For an example of how to use the VLSI in the context of Chipyard, see :ref:`VLSI/ASAP7-Tutorial:ASAP7 Tutorial`.
-
-

docs/VLSI/Hammer.rst

@@ -29,10 +29,10 @@ Hooks are modifications to steps or actions that are programmatically defined in
 VLSI Flow Control
 -----------------
 Sometimes we want more fine-grained control of the VLSI flow than at the action level.
-The Hammer flow supports being able to start/stop before/after any of the steps in a particular action. 
+The Hammer flow supports being able to start/stop before/after any of the steps in a particular action.
 See the `Hammer documentation on Flow Control <https://docs.hammer-eda.org/en/latest/Hammer-Use/Flow-Control.html>`__ for a full list and description of the options.
 The ``Makefile`` in the ``vlsi`` directory passes this extra information via the ``HAMMER_EXTRA_ARGS`` variable.
-This variable can also be used to specify additional YAML configurations that may have 
+This variable can also be used to specify additional YAML configurations that may have
 changed or been omitted from the inital build.
 
 

docs/VLSI/Sky130-Commercial-Tutorial.rst

@@ -57,7 +57,7 @@ In the Chipyard root, run:
 .. code-block:: shell
 
     ./scripts/init-vlsi.sh sky130
-    
+
 to pull the Hammer & plugin submodules. Note that for technologies other than ``sky130`` or ``asap7``, the tech submodule must be added in the ``vlsi`` folder first.
 
 Pull the Hammer environment into the shell:
@@ -76,14 +76,14 @@ To elaborate the ``TinyRocketConfig`` and set up all prerequisites for the build
 
     make buildfile tutorial=sky130-commercial
 
-The command ``make buildfile`` generates a set of Make targets in ``build/hammer.d``. 
-It needs to be re-run if environment variables are changed. 
+The command ``make buildfile`` generates a set of Make targets in ``build/hammer.d``.
+It needs to be re-run if environment variables are changed.
 It is recommended that you edit these variables directly in the Makefile rather than exporting them to your shell environment.
 
 For the purpose of brevity, in this tutorial we will set the Make variable ``tutorial=sky130-commercial``,
 which will cause additional variables to be set in ``tutorial.mk``, a few of which are summarized as follows:
 
-* ``CONFIG=TinyRocketConfig`` selects the target generator config in the same manner as the rest of the Chipyard framework. This elaborates a stripped-down Rocket Chip in the interest of minimizing tool runtime. 
+* ``CONFIG=TinyRocketConfig`` selects the target generator config in the same manner as the rest of the Chipyard framework. This elaborates a stripped-down Rocket Chip in the interest of minimizing tool runtime.
 * ``tech_name=sky130`` sets a few more necessary paths in the ``Makefile``, such as the appropriate Hammer plugin
 * ``TOOLS_CONF`` and ``TECH_CONF`` select the approproate YAML configuration files, ``example-tools.yml`` and ``example-sky130.yml``, which are described below
 * ``DESIGN_CONF`` and ``EXTRA_CONFS`` allow for additonal design-specific overrides of the Hammer IR in ``example-sky130.yml``
@@ -102,13 +102,13 @@ example-sky130.yml
 ^^^^^^^^^^^^^^^^^^
 This contains the Hammer configuration for this example project. Example clock constraints, power straps definitions, placement constraints, and pin constraints are given. Additional configuration for the extra libraries and tools are at the bottom.
 
-First, set ``technology.sky130.sky130A/sky130_nda/openram_lib`` to the absolute path of the respective directories containing the Sky130 PDK and SRAM files. See the 
+First, set ``technology.sky130.sky130A/sky130_nda/openram_lib`` to the absolute path of the respective directories containing the Sky130 PDK and SRAM files. See the
 `Sky130 Hammer plugin README <https://github.com/ucb-bar/hammer/blob/master/src/hammer-vlsi/technology/sky130/README.md>`__
 for details about the PDK setup.
 
 example-tools.yml
 ^^^^^^^^^^^^^^^^^
-This contains the Hammer configuration for a commercial tool flow. 
+This contains the Hammer configuration for a commercial tool flow.
 It selects tools for synthesis (Cadence Genus), place and route (Cadence Innovus), DRC and LVS (Mentor Calibre).
 
 Synthesis
@@ -127,7 +127,7 @@ Place-and-Route
 
 After completion, the final database can be opened in an interactive Innovus session via ``./build/par-rundir/generated-scripts/open_chip``.
 
-Intermediate database are written in ``build/par-rundir`` between each step of the ``par`` action, and can be restored in an interactive Innovus session as desired for debugging purposes. 
+Intermediate database are written in ``build/par-rundir`` between each step of the ``par`` action, and can be restored in an interactive Innovus session as desired for debugging purposes.
 
 Timing reports are found in ``build/par-rundir/timingReports``. They are gzipped text files.
 
@@ -142,9 +142,9 @@ To run DRC & LVS, and view the results in Calibre:
     make lvs tutorial=sky130-commercial
     ./build/chipyard.TestHarness.TinyRocketConfig-ChipTop/lvs-rundir/generated-scripts/view_lvs
 
-Some DRC errors are expected from this PDK, especially with regards to the SRAMs, as explained in the 
+Some DRC errors are expected from this PDK, especially with regards to the SRAMs, as explained in the
 `Sky130 Hammer plugin README  <https://github.com/ucb-bar/hammer/blob/master/src/hammer-vlsi/technology/sky130/README.md>`__.
-For this reason, the ``example-vlsi-sky130`` script black-boxes the SRAMs for DRC/LVS analysis. 
+For this reason, the ``example-vlsi-sky130`` script black-boxes the SRAMs for DRC/LVS analysis.
 
 Simulation
 ^^^^^^^^^^

docs/VLSI/Sky130-OpenROAD-Tutorial.rst

@@ -48,7 +48,7 @@ Prerequisites
   * Yosys (synthesis), install `from source <https://yosyshq.net/yosys/download.html>`__ or `using conda <https://anaconda.org/TimVideos/yosys>`__
   * OpenROAD (place-and-route), install `from source <https://openroad.readthedocs.io/en/latest/main/README.html#install-dependencies>`__
   * Magic (DRC), install `from source <http://www.opencircuitdesign.com/magic/install.html>`__
-  * NetGen (LVS), install `from source <http://www.opencircuitdesign.com/netgen/install.html>`__ or `using conda <https://anaconda.org/conda-forge/netgen>`__ 
+  * NetGen (LVS), install `from source <http://www.opencircuitdesign.com/netgen/install.html>`__ or `using conda <https://anaconda.org/conda-forge/netgen>`__
 
 * Sky130 PDK, install using `these directions  <https://github.com/ucb-bar/hammer/blob/master/src/hammer-vlsi/technology/sky130/README.md>`__
 
@@ -59,8 +59,8 @@ In the Chipyard root, run:
 .. code-block:: shell
 
     ./scripts/init-vlsi.sh sky130 openroad
-    
-to pull the Hammer submodule. Note that for technologies other than ``sky130`` or ``asap7``, the tech plugin submodule is cloned into the ``vlsi`` folder, 
+
+to pull the Hammer submodule. Note that for technologies other than ``sky130`` or ``asap7``, the tech plugin submodule is cloned into the ``vlsi`` folder,
 and for the commercial tool flow (set up by omitting the ``openroad`` argument), the tool plugin submodules are cloned into the ``vlsi`` folder.
 
 Pull the Hammer environment into the shell:
@@ -79,14 +79,14 @@ To elaborate the ``TinyRocketConfig`` and set up all prerequisites for the build
 
     make buildfile tutorial=sky130-openroad
 
-The command ``make buildfile`` generates a set of Make targets in ``build/hammer.d``. 
-It needs to be re-run if environment variables are changed. 
+The command ``make buildfile`` generates a set of Make targets in ``build/hammer.d``.
+It needs to be re-run if environment variables are changed.
 It is recommended that you edit these variables directly in the Makefile rather than exporting them to your shell environment.
 
 For the purpose of brevity, in this tutorial we will set the Make variable ``tutorial=sky130-openroad``,
 which will cause additional variables to be set in ``tutorial.mk``, a few of which are summarized as follows:
 
-* ``CONFIG=TinyRocketConfig`` selects the target generator config in the same manner as the rest of the Chipyard framework. This elaborates a stripped-down Rocket Chip in the interest of minimizing tool runtime. 
+* ``CONFIG=TinyRocketConfig`` selects the target generator config in the same manner as the rest of the Chipyard framework. This elaborates a stripped-down Rocket Chip in the interest of minimizing tool runtime.
 * ``tech_name=sky130`` sets a few more necessary paths in the ``Makefile``, such as the appropriate Hammer plugin
 * ``TOOLS_CONF`` and ``TECH_CONF`` select the approproate YAML configuration files, ``example-openroad.yml`` and ``example-sky130.yml``, which are described below
 * ``DESIGN_CONF`` and ``EXTRA_CONFS`` allow for additonal design-specific overrides of the Hammer IR in ``example-sky130.yml``
@@ -105,14 +105,14 @@ example-sky130.yml
 ^^^^^^^^^^^^^^^^^^
 This contains the Hammer configuration for this example project. Example clock constraints, power straps definitions, placement constraints, and pin constraints are given. Additional configuration for the extra libraries and tools are at the bottom.
 
-First, set ``technology.sky130.<sky130A, openram_lib>`` to the absolute path of the respective directories containing the Sky130 PDK and SRAM files. See the 
+First, set ``technology.sky130.<sky130A, openram_lib>`` to the absolute path of the respective directories containing the Sky130 PDK and SRAM files. See the
 `Sky130 Hammer plugin README <https://github.com/ucb-bar/hammer/blob/master/src/hammer-vlsi/technology/sky130/README.md>`__
 for details about the PDK setup.
 
 
 example-openroad.yml
 ^^^^^^^^^^^^^^^^^^^^
-This contains the Hammer configuration for the OpenROAD tool flow. 
+This contains the Hammer configuration for the OpenROAD tool flow.
 It selects tools for synthesis (Yosys), place and route (OpenROAD), DRC (Magic), and LVS (NetGen).
 
 Synthesis
@@ -122,7 +122,7 @@ Synthesis
 
     make syn tutorial=sky130-openroad
 
-Post-synthesis logs and collateral are in ``build/syn-rundir``. 
+Post-synthesis logs and collateral are in ``build/syn-rundir``.
 
 .. The raw quality of results data is available at ``build/syn-rundir/reports``, and methods to extract this information for design space exploration are a work in progress.
 
@@ -162,7 +162,7 @@ To run DRC & LVS:
     make drc tutorial=sky130-openroad
     make lvs tutorial=sky130-openroad
 
-Some DRC errors are expected from this PDK, especially with regards to the SRAMs, as explained in the 
+Some DRC errors are expected from this PDK, especially with regards to the SRAMs, as explained in the
 `Sky130 Hammer plugin README  <https://github.com/ucb-bar/hammer/blob/master/src/hammer-vlsi/technology/sky130/README.md>`__.
 
 
@@ -172,7 +172,7 @@ Firt, refer to the :ref:`VLSI/Hammer:VLSI Flow Control` documentation. The below
 
 .. code-block:: shell
 
-      # the following two statements are equivalent because the 
+      # the following two statements are equivalent because the
       #   extraction step immediately precedes the write_design step
       make redo-par HAMMER_EXTRA_ARGS="--start_after_step extraction"
       make redo-par HAMMER_EXTRA_ARGS="--start_before_step write_design"
@@ -187,4 +187,4 @@ Documentation
 For more information about Hammer's underlying implementation, visit the `Hammer documentation website <https://docs.hammer-eda.org/en/latest/index.html>`__.
 
 For details about the plugins used in this tutorial, check out the `OpenROAD tool plugin repo + README <https://github.com/ucb-bar/hammer/tree/master/src/hammer-vlsi/par/openroad>`__
-and `Sky130 tech plugin repo + README <https://github.com/ucb-bar/hammer/tree/master/src/hammer-vlsi/technology/sky130>`__.
+and `Sky130 tech plugin repo + README <https://github.com/ucb-bar/hammer/tree/master/src/hammer-vlsi/technology/sky130>`__.