docs: Fixing the :term:`PIP` References.

Signed-off-by: Tim 'mithro' Ansell <me@mith.ro>

docs/architecture/glossary.rst

@@ -147,6 +147,11 @@ Glossary
     One of the configurable input/output blocks that connect the :term:`FPGA`
     to external devices.
 
+  Interconnect tile
+  INT
+    An interconnect tile (`INT_L`, `INT_R`) is used to connect other tiles to
+    the fabric. It is also frequently called a switch box.
+
   LUT
     A lookup table (LUT) is a logic element on the :term:`FPGA`. LUTs function
     as a ROM, apply combinatorial logic, and generate the output value for a

docs/architecture/interconnect.rst

@@ -1,30 +1,30 @@
-Interconnect :term:`PIP`s
-=========================
+Interconnect :term:`PIPs <pip>`
+===============================
 
-Fake :term:`PIP`s
------------------
+Fake :term:`PIPs <pip>`
+-----------------------
 
-Some :term:`PIP`s are not "real", in the sense that no bit pattern in the bit-stream correspond to the PIP being used. This is the case for all the :term:`PIP`s in the switchbox in a CLB tile (ex: CLBLM_L_INTER): They either correspond to buffers that are always on (i.e. 1:1 connections such as `CLBLL_L.CLBLL_L_AQ->CLBLL_LOGIC_OUTS0`), or they correspond to permutations of LUT input signals, which is handled by changing the LUT init value accordingly, or they are used to "connect" two signals that are driven by the same signal from within the CLB.
+Some :term:`PIPs <pip>` are not "real", in the sense that no bit pattern in the bit-stream correspond to the PIP being used. This is the case for all the :term:`PIPs <pip>` in the switchbox in a CLB tile (ex: CLBLM_L_INTER): They either correspond to buffers that are always on (i.e. 1:1 connections such as `CLBLL_L.CLBLL_L_AQ->CLBLL_LOGIC_OUTS0`), or they correspond to permutations of LUT input signals, which is handled by changing the LUT init value accordingly, or they are used to "connect" two signals that are driven by the same signal from within the CLB.
 
 FIXME: Check the above is true.
 
 The bit switchbox in an :term:`INT`s tile also contains a few 1:1 connections that are in fact always present and have no corresponding configuration bits.
 
-Regular :term:`PIP`s
---------------------
+Regular :term:`PIPs <pip>`
+--------------------------
 
-Regular :term:`PIP`s correspond to a bit pattern that is present in the bit stream when the PIP is used in the current design. There is a block of up to 10-ish bits for each destination signal. For each configuration (i.e. source net that can drive the destination) there is a pair of bits that is set.
+Regular :term:`PIPs <pip>` correspond to a bit pattern that is present in the bit stream when the PIP is used in the current design. There is a block of up to 10-ish bits for each destination signal. For each configuration (i.e. source net that can drive the destination) there is a pair of bits that is set.
 
 FIXME: Check if the above is true for PIPs outside of the INT switch box.
 
-For example, when the bits 05_57 and 11_56 are set then SR1END3->SE2BEG3 is enabled, but when 08_56 and 11_56 are set then ER1END3->SE2BEG3 is enabled (in an :term:`INT_L`s tile paired with a CLBLL_L tile). A configuration in which all three bits are set is invalid. See `segbits_int_[lr].db` for a complete list of bit pattern for configuring :term:`PIP`s.
+For example, when the bits 05_57 and 11_56 are set then SR1END3->SE2BEG3 is enabled, but when 08_56 and 11_56 are set then ER1END3->SE2BEG3 is enabled (in an :term:`INT_L`s tile paired with a CLBLL_L tile). A configuration in which all three bits are set is invalid. See `segbits_int_[lr].db` for a complete list of bit pattern for configuring :term:`PIPs <pip>`.
 
 VCC Drivers
 -----------
 
-The default state for a net is to be driven high. The :term:`PIP`s that drive a net from `VCC_WIRE` correspond to the "empty configuration" with no bits set.
+The default state for a net is to be driven high. The :term:`PIPs <pip>` that drive a net from `VCC_WIRE` correspond to the "empty configuration" with no bits set.
 
-Bidirectional :term:`PIP`s
---------------------------
+Bidirectional :term:`PIPs <pip>`
+--------------------------------
 
-Bidirectional :term:`PIP`s are used to stitch together long traces (LV*, LVB*). In case of bidirectional :term:`PIP`s there are two different configuration patterns, one for each direction.
+Bidirectional :term:`PIPs <pip>` are used to stitch together long traces (LV*, LVB*). In case of bidirectional :term:`PIPs <pip>` there are two different configuration patterns, one for each direction.

docs/format/db.rst

@@ -73,12 +73,12 @@ Related tools:
    * Ex: CLB is solved by first solving LUT bits, and then solving FF bits
 
 
-Interconnect :term:`PIP` Tags
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Interconnect :term:`PIP <pip>` Tags
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Tags for interconnect :term:`PIP`s are stored in the `segbits_int_l.db` and `segbits_int_r.db` database files.
+Tags for interconnect :term:`PIPs <pip>` are stored in the `segbits_int_l.db` and `segbits_int_r.db` database files.
 
-Tags that enable interconnect :term:`PIP`s have the following syntax: `<tile_type>.<destination_wire>.<source_wire>`.
+Tags that enable interconnect :term:`PIPs <pip>` have the following syntax: `<tile_type>.<destination_wire>.<source_wire>`.
 
 The `<tile_type>` may be `INT_L` or `INT_R`. The destination and source wires are wire names in that tile type. For example, consider the following entry in `segbits_int_l.db`: `INT_L.NL1BEG1.NN6END2 07_32 12_33`
 
@@ -96,7 +96,7 @@ Tags for CLB tiles use a dot-separated hierarchy for their tag names. For exampl
 ppips_*.db
 ----------
 
-Pseudo :term:`PIP`s are :term:`PIP`s in the Vivado tool, but do not have actual bit pattern. The `ppips_*.db` files contain information on pseudo-:term:`PIP`s. Those files contain one entry per pseudo-PIP, each with one of the following three tags: `always`, `default` or `hint`. The tag `always` is used for pseudo-:term:`PIP`s that are actually always-on, i.e. that are permanent connections between two wires. The tag `default` is used for pseudo-:term:`PIP`s that represent the default behavior if no other driver has been configured for the destination net (all `default` pseudo-:term:`PIP`s connect to the `VCC_WIRE` net). And the tag `hint` is used for :term:`PIP`s that are used by Vivado to tell the router that two logic slice outputs drive the same value, i.e. behave like they are connected as far as the routing process is concerned.
+Pseudo :term:`PIPs <pip>` are :term:`PIPs <pip>` in the Vivado tool, but do not have actual bit pattern. The `ppips_*.db` files contain information on pseudo-:term:`PIPs <pip>`. Those files contain one entry per pseudo-PIP, each with one of the following three tags: `always`, `default` or `hint`. The tag `always` is used for pseudo-:term:`PIPs <pip>` that are actually always-on, i.e. that are permanent connections between two wires. The tag `default` is used for pseudo-:term:`PIPs <pip>` that represent the default behavior if no other driver has been configured for the destination net (all `default` pseudo-:term:`PIPs <pip>` connect to the `VCC_WIRE` net). And the tag `hint` is used for :term:`PIPs <pip>` that are used by Vivado to tell the router that two logic slice outputs drive the same value, i.e. behave like they are connected as far as the routing process is concerned.
 
 mask_*.db
 ---------