docs label disambiguation

docs/Generators/IceNet.rst

@@ -8,11 +8,11 @@ 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
-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
+There are four basic parts of the NIC: the :ref:`Generators/IceNet:Controller`, which takes requests
+from and sends responses to the CPU; the :ref:`Generators/IceNet:Send Path`, which reads data from
+memory and sends it out to the network; the :ref:`Generators/IceNet:Receive Path`, which receives
 data from the network and writes it to memory; and, optionally,
-the :ref:`Pause Handler`, which generates Ethernet pause frames for the purpose
+the :ref:`Generators/IceNet:Pause Handler`, which generates Ethernet pause frames for the purpose
 of flow control.
 
 Controller
@@ -78,7 +78,7 @@ Configuration
 To add IceNIC to your design, add ``HasPeripheryIceNIC`` to your lazy module
 and ``HasPeripheryIceNICModuleImp`` to the module implementation. If you
 are confused about the distinction between lazy module and module
-implementation, refer to :ref:`Cake Pattern / Mixin`.
+implementation, refer to :ref:`Chipyard-Basics/Configs-Parameters-Mixins:Cake Pattern / Mixin`.
 
 Then add the ``WithIceNIC`` config fragment to your configuration. This will
 define ``NICKey``, which IceNIC uses to determine its parameters. The config fragment

docs/Generators/Rocket-Chip.rst

@@ -30,7 +30,7 @@ The tiles connect to the ``SystemBus``, which connect it to the L2 cache banks.
 The L2 cache banks then connect to the ``MemoryBus``, which connects to the
 DRAM controller through a TileLink to AXI converter.
 
-To learn more about the memory hierarchy, see :ref:`Memory Hierarchy`.
+To learn more about the memory hierarchy, see :ref:`Customization/Memory-Hierarchy:Memory Hierarchy`.
 
 MMIO
 ----

docs/Generators/TestChipIP.rst

@@ -2,9 +2,9 @@ Test Chip IP
 ============
 
 Chipyard includes a Test Chip IP library which provides various hardware
-widgets that may be useful when designing SoCs. This includes a :ref:`Serial Adapter`,
-:ref:`Block Device Controller`, :ref:`TileLink SERDES`, :ref:`TileLink Switcher`,
-:ref:`TileLink Ring Network`, and :ref:`UART Adapter`.
+widgets that may be useful when designing SoCs. This includes a :ref:`Generators/TestChipIP:Serial Adapter`,
+:ref:`Generators/TestChipIP:Block Device Controller`, :ref:`Generators/TestChipIP:TileLink SERDES`, :ref:`Generators/TestChipIP:TileLink Switcher`,
+:ref:`Generators/TestChipIP:TileLink Ring Network`, and :ref:`Generators/TestChipIP:UART Adapter`.
 
 Serial Adapter
 --------------
@@ -14,7 +14,7 @@ processor. An instance of RISC-V frontend server running on the host CPU
 can send commands to the serial adapter to read and write data from the memory
 system. The frontend server uses this functionality to load the test program
 into memory and to poll for completion of the program. More information on
-this can be found in :ref:`Chipyard Boot Process`.
+this can be found in :ref:`Customization/Boot-Process:Chipyard Boot Process`.
 
 Block Device Controller
 -----------------------
@@ -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:`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

@@ -4,7 +4,7 @@ Included RTL Generators
 ============================
 
 A Generator can be thought of as a generalized RTL design, written using a mix of meta-programming and standard RTL.
-This type of meta-programming is enabled by the Chisel hardware description language (see :ref:`Chisel`).
+This type of meta-programming is enabled by the Chisel hardware description language (see :ref:`Tools/Chisel:Chisel`).
 A standard RTL design is essentially just a single instance of a design coming from a generator.
 However, by using meta-programming and parameter systems, generators can allow for integration of complex hardware designs in automated ways.
 The following pages introduce the generators integrated with the Chipyard framework.