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/Advanced-Concepts/CDEs.rst

@@ -28,11 +28,11 @@ Consider the following example using CDEs.
     }
 
 
-When forming a query based on a ``Parameters`` object, like ``p(SomeKeyX)``, the configuration system traverses the "chain" of mixins until it finds a partial function which is defined at the key, and then returns that value.
+When forming a query based on a ``Parameters`` object, like ``p(SomeKeyX)``, the configuration system traverses the "chain" of config fragments until it finds a partial function which is defined at the key, and then returns that value.
 
 .. code:: scala
 
-    val params = Config(new WithX(true) ++ new WithY(true)) // "chain" together mixins
+    val params = Config(new WithX(true) ++ new WithY(true)) // "chain" together config fragments
     params(SomeKeyX) // evaluates to true
     params(SomeKeyY) // evaluates to true
     params(SomeKeyZ) // evaluates to false
@@ -68,7 +68,7 @@ In this example, the partial function in ``WithXEqualsYSite`` will look up the v
 Here
 ~~~~
 
-``here`` provides a ``View`` of the locally defined Config, which typically just contains some partial function.
+``here`` provides a ``View`` of the locally defined config, which typically just contains some partial function.
 
 .. code:: scala
 
@@ -103,7 +103,7 @@ Up
     params_1(SomeKeyX) // evaluates to true
     params_2(SomeKeyX) // evaluates to false
 
-In this example, note how ``up(SomeKeyY, site)`` in ``WithXEqualsYUp`` will refer to *either* the the partial function defining ``SomeKeyY`` in ``WithY(true)`` *or* the default value for ``SomeKeyY`` provided in the original ``case object SomeKeyY`` definition, *depending on the order in which the mixins were used*. Since the order of mixins affects the the order of the ``View`` traversal, ``up`` provides a different ``View`` of the parameterization in ``params_1`` and ``params_2``.
+In this example, note how ``up(SomeKeyY, site)`` in ``WithXEqualsYUp`` will refer to *either* the the partial function defining ``SomeKeyY`` in ``WithY(true)`` *or* the default value for ``SomeKeyY`` provided in the original ``case object SomeKeyY`` definition, *depending on the order in which the config fragments were used*. Since the order of config fragments affects the the order of the ``View`` traversal, ``up`` provides a different ``View`` of the parameterization in ``params_1`` and ``params_2``.
 
 
 Also note that again, ``site`` must be recursively passed through the call to ``up``.

docs/Advanced-Concepts/Chip-Communication.rst

@@ -81,7 +81,7 @@ Similar to TSI, the DMI protocol is an implementation of HTIF.
 In order to communicate with the DUT with the DMI protocol, the DUT needs to contain a Debug Transfer Module (DTM).
 The DTM is given in the `RISC-V Debug Specification <https://riscv.org/specifications/debug-specification/>`__
 and is responsible for managing communication between the DUT and whatever lives on the other side of the DMI (in this case FESVR).
-This is implemented in the Rocket Chip ``Subsystem`` by having the ``HasPeripheryDebug`` and ``HasPeripheryDebugModuleImp`` mixins.
+This is implemented in the Rocket Chip ``Subsystem`` by having the ``HasPeripheryDebug`` and ``HasPeripheryDebugModuleImp`` traits.
 During simulation, the host sends DMI commands to a
 simulation stub called ``SimDTM`` (C++ class) that resides in a ``SimDTM`` Verilog module
 (both are located in the ``generators/rocket-chip`` project). This ``SimDTM`` Verilog module then
@@ -138,7 +138,7 @@ Creating a DTM+JTAG Config
 First, a DTM config must be created for the system that you want to create.
 This step is similar to the DMI simulation section within the :ref:`Starting the TSI or DMI Simulation` section.
 The configuration is very similar to a DMI-based configuration. The main difference
-is the addition of the ``WithJtagDTM`` mixin that configures the instantiated DTM to use the JTAG protocol as the
+is the addition of the ``WithJtagDTM`` config fragment that configures the instantiated DTM to use the JTAG protocol as the
 bringup method.
 
 .. literalinclude:: ../../generators/chipyard/src/main/scala/RocketConfigs.scala

docs/Advanced-Concepts/Top-Testharness.rst

@@ -52,7 +52,7 @@ Please refer to :ref:`Communicating with the DUT` for more information on these
 TestHarness
 -------------------------
 
-The wiring between the ``TestHarness`` and the Top are performed in methods defined in mixins added to the Top.
+The wiring between the ``TestHarness`` and the Top are performed in methods defined in traits added to the Top.
 When these methods are called from the ``TestHarness``, they may instantiate modules within the scope of the harness,
 and then connect them to the DUT. For example, the ``connectSimAXIMem`` method defined in the
 ``CanHaveMasterAXI4MemPortModuleImp`` trait, when called from the ``TestHarness``, will instantiate ``SimAXIMems``

docs/Advanced-Concepts/index.rst

@@ -2,7 +2,7 @@ Advanced Concepts
 ================================
 
 The following sections are advanced topics about how to Chipyard works, how to use Chipyard, and special features of the framework.
-They expect you to know about Chisel, Parameters, Configs, etc.
+They expect you to know about Chisel, Parameters, configs, etc.
 
 .. toctree::
    :maxdepth: 2