Rename Config Mixins to Fragments (#451)

* [docs] rename config mixins -> fragments [ci skip]

* [docs] cleanup naming | link similar sections [ci skip]

* [boom] bump for mixin rename [ci skip]

* [docs] cleanup capitalization [ci skip]

* [docs] consistent config fragment naming [ci skip]

* [boom] bump boom for documentation changes [ci skip]

* [docs] update source comments [ci skip]

* [docs] fix last config fragment name [ci skip]

Co-Authored-By: alonamid <alonamid@eecs.berkeley.edu>

Co-authored-by: alonamid <alonamid@eecs.berkeley.edu>

docs/Generators/Gemmini.rst

@@ -3,9 +3,9 @@ Gemmini
 
 The Gemmini project is developing a systolic-array based matrix multiplication unit generator for the investigation of software/hardware implications of such integrated SoC accelerators. It is inspired by recent trends in machine learning accelerators for edge and mobile SoCs.
 
-Gemmini is implemented as a RoCC accelerator with non-standard RISC-V custom instructions. The Gemmini unit uses the RoCC port of a Rocket or BOOM `tile`, and by default connects to the memory system through the System Bus (i.e., directly to the L2 cache). 
+Gemmini is implemented as a RoCC accelerator with non-standard RISC-V custom instructions. The Gemmini unit uses the RoCC port of a Rocket or BOOM `tile`, and by default connects to the memory system through the System Bus (i.e., directly to the L2 cache).
 
-To add a Gemmini unit to an SoC, you should add the ``gemmini.DefaultGemminiConfig`` config mixin to the SoC configurations. To change the configuration of the Gemmini accelerator unit, you can write a custom configuration to replace the ``DefaultGemminiConfig``, which you can view under `generators/gemmini/src/main/scala/configs.scala <https://github.com/ucb-bar/gemmini/blob/master/src/main/scala/gemmini/configs.scala>`__ to see the possible configuration parameters.
+To add a Gemmini unit to an SoC, you should add the ``gemmini.DefaultGemminiConfig`` config fragment to the SoC configurations. To change the configuration of the Gemmini accelerator unit, you can write a custom configuration to replace the ``DefaultGemminiConfig``, which you can view under `generators/gemmini/src/main/scala/configs.scala <https://github.com/ucb-bar/gemmini/blob/master/src/main/scala/gemmini/configs.scala>`__ to see the possible configuration parameters.
 
 The example Chipyard config includes the following example SoC configuration which includes Gemmini:
 
@@ -46,12 +46,12 @@ Gemmini Software
 ------------------
 
 The Gemmini non-standard ISA extension is specified in the `Gemmini repository <https://github.com/ucb-bar/gemmini/blob/master/README.md>`__.
-The ISA includes configuration instructions, data movement instructions (from main memory to the Gemmini scratchpad, and from the Gemmini accumulators to main memory), and matrix multiplication execution instructions. 
+The ISA includes configuration instructions, data movement instructions (from main memory to the Gemmini scratchpad, and from the Gemmini accumulators to main memory), and matrix multiplication execution instructions.
 
 Since Gemmini instructions are not exposed through the GNU binutils assembler, several C macros are provided in order to construct the instruction encodings to call these instructions.
 
 The Gemmini generator includes a C matrix multiplication library which wraps the calls to the custom Gemmini instructions.
-The ``software`` directory of the generator includes the aforementioned library and macros, as well as bare-metal tests, and some FireMarshal workloads to run the tests in a Linux environment. In particular, the matrix multiplication C library can be found in the ``software/gemmini-rocc-tests/include/gemmini.h`` file. 
+The ``software`` directory of the generator includes the aforementioned library and macros, as well as bare-metal tests, and some FireMarshal workloads to run the tests in a Linux environment. In particular, the matrix multiplication C library can be found in the ``software/gemmini-rocc-tests/include/gemmini.h`` file.
 
 The Gemmini generator generates a C header file based on the generator parameters. This header files gets compiled together with the matrix multiplication library to tune library performance. The generated header file can be found under ``software/gemmini-rocc-tests/include/gemmini_params.h``
 
@@ -64,7 +64,7 @@ To build Gemmini tests:
 
     cd generators/gemmini/software/gemmini-rocc-tests/
     ./build.sh
-    
+
 Afterwards, the test binaries will be found in ``generators/gemmini/software/gemmini-rocc-tests/build``. Binaries whose names end in ``-baremetal`` are meant to be run in a bare-metal environment, while binaries whose names end in ``-linux`` are meant to run in a Linux environment. You can run the tests either on a cycle-accurate RTL simulator, or on a (much faster) functional ISA simulator called Spike.
 
 The Gemmini generator implements a custom non-standard version of Spike. This implementation is found within the ``esp-tools`` Spike implementation, together with the Hwacha vector accelerator non-standard ISA-extension. In order to use this version of Spike, please make sure to build the ``esp-tools`` software toolchain, as described in :ref:`build-toolchains`.
@@ -80,7 +80,7 @@ Spike is built by default without a commit log. However, if you would like to ad
 Alternative SoC Configs
 --------------------------
 
-The Gemmini generator includes additional alternative SoC configs (configs that are not in the Chipyard example project). 
+The Gemmini generator includes additional alternative SoC configs (configs that are not in the Chipyard example project).
 If you would like to build one of these alternative SoC configurations which are defined in within the Gemmini project repository, you can run the following commands. These commands are similar to the one required when building a simulation from the example project, but they specify that the location of the configs are in the Gemmini subproject, as opposed to the Chipyard example project:
 
 .. code-block:: shell

docs/Generators/Hwacha.rst

@@ -7,9 +7,9 @@ The Hwacha project includes the Hwacha microarchitecture generator, as well as t
 
 For more information on the Hwacha project, please visit the `Hwacha website <http://hwacha.org/>`__.
 
-To add the Hwacha vector unit to an SoC, you should add the ``hwacha.DefaultHwachaConfig`` config mixin to the SoC configurations. The Hwacha vector unit uses the RoCC port of a Rocket or BOOM `tile`, and by default connects to the memory system through the `System Bus` (i.e., directly to the L2 cache). 
+To add the Hwacha vector unit to an SoC, you should add the ``hwacha.DefaultHwachaConfig`` config fragment to the SoC configurations. The Hwacha vector unit uses the RoCC port of a Rocket or BOOM `tile`, and by default connects to the memory system through the `System Bus` (i.e., directly to the L2 cache).
 
 To change the configuration of the Hwacha vector unit, you can write a custom configuration to replace the ``DefaultHwachaConfig``. You can view the ``DefaultHwachaConfig`` under `generators/hwacha/src/main/scala/configs.scala <https://github.com/ucb-bar/hwacha/blob/master/src/main/scala/configs.scala>`__ to see the possible configuration parameters.
- 
+
 Since Hwacha implements a non-standard RISC-V extension, it requires a unique software toolchain to be able to compile and assemble its vector instructions.
 To install the Hwacha toolchain, run the ``./scripts/build-toolchains.sh esp-tools`` command within the root Chipyard directory. This may take a while, and it will install the ``esp-tools-install`` directory within your Chipyard root directory. ``esp-tools`` is a fork of ``riscv-tools`` (formerly a collection of relevant software RISC-V tools) that was enhanced with additional non-standard vector instructions. However, due to the upstreaming of the equivalent RISC-V toolchains, ``esp-tools`` may not be up-to-date with the latest mainline version of the tools included in it.

docs/Generators/IceNet.rst

@@ -8,7 +8,7 @@ A diagram of IceNet's microarchitecture is shown below.
 
 .. image:: ../_static/images/nic-design.png
 
-There are four basic parts of the NIC: the :ref:`Controller`, which takes requests 
+There are four basic parts of the NIC: the :ref:`Controller`, which takes requests
 from and sends responses to the CPU; the :ref:`Send Path`, which reads data from
 memory and sends it out to the network; the :ref:`Receive Path`, which receives
 data from the network and writes it to memory; and, optionally,
@@ -80,8 +80,8 @@ and ``HasPeripheryIceNICModuleImp`` to the module implementation. If you
 are confused about the distinction between lazy module and module
 implementation, refer to :ref:`Cake Pattern`.
 
-Then add the ``WithIceNIC`` config mixin to your configuration. This will
-define ``NICKey``, which IceNIC uses to determine its parameters. The mixin
+Then add the ``WithIceNIC`` config fragment to your configuration. This will
+define ``NICKey``, which IceNIC uses to determine its parameters. The config fragment
 takes two arguments. The ``inBufFlits`` argument is the number of 64-bit flits
 that the input packet buffer can hold and the ``usePauser`` argument determines
 whether or not the NIC will have a pause handler.

docs/Generators/SHA3.rst

@@ -68,9 +68,9 @@ Using a SHA3 Accelerator
 ------------------------
 Since the SHA3 accelerator is designed as a RoCC accelerator,
 it can be mixed into a Rocket or BOOM core by overriding the
-``BuildRoCC`` key. The configuration mixin is defined in the SHA3
+``BuildRoCC`` key. The config fragment is defined in the SHA3
 generator. An example configuration highlighting the use of
-this mixin is shown here:
+this config fragment is shown here:
 
 .. literalinclude:: ../../generators/chipyard/src/main/scala/RocketConfigs.scala
    :language: scala

docs/Generators/SiFive-Generators.rst

@@ -1,13 +1,13 @@
 SiFive Generators
 ==================
 
-Chipyard includes several open-source generators developed and maintained by `SiFive <https://www.sifive.com/>`__. 
+Chipyard includes several open-source generators developed and maintained by `SiFive <https://www.sifive.com/>`__.
 These are currently organized within two submodules named ``sifive-blocks`` and ``sifive-cache``.
 
 Last-Level Cache Generator
 -----------------------------
 
-``sifive-cache`` includes last-level cache geneator. The Chipyard framework uses this last-level cache as an L2 cache. To use this L2 cache, you should add the ``freechips.rocketchip.subsystem.WithInclusiveCache`` mixin to your SoC configuration.
+``sifive-cache`` includes last-level cache geneator. The Chipyard framework uses this last-level cache as an L2 cache. To use this L2 cache, you should add the ``freechips.rocketchip.subsystem.WithInclusiveCache`` config fragment to your SoC configuration.
 To learn more about configuring this L2 cache, please refer to the :ref:`memory-hierarchy` section.
 
 
@@ -16,24 +16,24 @@ Peripheral Devices
 ``sifive-blocks`` includes multiple peripheral device generators, such as UART, SPI, PWM, JTAG, GPIO and more.
 
 These peripheral devices usually affect the memory map of the SoC, and its top-level IO as well.
-To integrate one of these devices in your SoC, you will need to define a custom mixin with the approriate address for the device using the Rocket Chip parameter system. As an example, for a GPIO device you could add the following mixin to set the GPIO address to ``0x10012000``. This address is the start address for the GPIO configuration registers. 
+To integrate one of these devices in your SoC, you will need to define a custom config fragment with the approriate address for the device using the Rocket Chip parameter system. As an example, for a GPIO device you could add the following config fragment to set the GPIO address to ``0x10012000``. This address is the start address for the GPIO configuration registers.
 
-.. literalinclude:: ../../generators/chipyard/src/main/scala/ConfigMixins.scala
+.. literalinclude:: ../../generators/chipyard/src/main/scala/ConfigFragments.scala
     :language: scala
     :start-after: DOC include start: gpio mixin
     :end-before: DOC include end: gpio mixin
 
-Additionally, if the device requires top-level IOs, you will need to define a mixin to change the top-level configuration of your SoC.
+Additionally, if the device requires top-level IOs, you will need to define a config fragment to change the top-level configuration of your SoC.
 When adding a top-level IO, you should also be aware of whether it interacts with the test-harness.
 
 This example instantiates a top-level module with include GPIO ports, and then ties-off the GPIO port inputs to 0 (``false.B``).
 
 
-Finally, you add the relevant config mixin to the SoC config. For example:
+Finally, you add the relevant config fragment to the SoC config. For example:
 
 .. literalinclude:: ../../generators/chipyard/src/main/scala/RocketConfigs.scala
     :language: scala
     :start-after: DOC include start: GPIORocketConfig
     :end-before: DOC include end: GPIORocketConfig
 
-Some of the devices in ``sifive-blocks`` (such as GPIO) may already have pre-defined mixins within the Chipyard example project. You may be able to use these config mixins directly, but you should be aware of their addresses within the SoC address map. 
+Some of the devices in ``sifive-blocks`` (such as GPIO) may already have pre-defined config fragments within the Chipyard example project. You may be able to use these config fragments directly, but you should be aware of their addresses within the SoC address map.

docs/Generators/TestChipIP.rst

@@ -22,7 +22,7 @@ The block device controller provides a generic interface for secondary storage.
 This device is primarily used in FireSim to interface with a block device
 software simulation model. The default Linux configuration in `firesim-software <https://github.com/firesim/firesim-software>`_
 
-To add a block device to your design, add the ``WithBlockDevice`` config mixin to your configuration.
+To add a block device to your design, add the ``WithBlockDevice`` config fragment to your configuration.
 
 
 TileLink SERDES