Add pre-commit support

.pre-commit-config.yaml

@@ -0,0 +1,11 @@
+# See https://pre-commit.com for more information
+# See https://pre-commit.com/hooks.html for more hooks
+repos:
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v3.2.0
+    hooks:
+      - id: trailing-whitespace
+      - id: end-of-file-fixer
+      - id: check-yaml
+      - id: check-json
+      - id: check-added-large-files

LICENSE

@@ -27,4 +27,3 @@ SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
 CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
 OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-

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
 ^^^^^^^^^^