Converting a number of inline commands to refs

Also reflowing text for line width.
Maybe look into supporting commands with options?

docs/source/yosys_internals/formats/cell_library.rst

@@ -255,8 +255,8 @@ additional two parameters:
 ``\ARST_VALUE``
    	The state of ``\Q`` will be set to this value when the reset is active.
 
-Usually these cells are generated by the ``proc`` pass using the information in
-the designs RTLIL::Process objects.
+Usually these cells are generated by the :cmd:ref:`proc` pass using the
+information in the designs RTLIL::Process objects.
 
 D-type flip-flops with synchronous reset are represented by ``$sdff`` cells. As
 the ``$dff`` cells they have ``\CLK``, ``\D`` and ``\Q`` ports. In addition they
@@ -270,8 +270,8 @@ additional two parameters:
 ``\SRST_VALUE``
 	The state of ``\Q`` will be set to this value when the reset is active.
 
-Note that the ``$adff`` and ``$sdff`` cells can only be used when the reset value is
-constant.
+Note that the ``$adff`` and ``$sdff`` cells can only be used when the reset
+value is constant.
 
 D-type flip-flops with asynchronous load are represented by ``$aldff`` cells. As
 the ``$dff`` cells they have ``\CLK``, ``\D`` and ``\Q`` ports. In addition they
@@ -433,16 +433,17 @@ The ``$memwr_v2`` cells have a clock input ``\CLK``, an enable input ``\EN``
 	``1'b1`` and on the negative edge if this parameter is ``1'b0``.
 
 ``\PORTID``
-	An identifier for this write port, used to index write port bit mask parameters.
+	An identifier for this write port, used to index write port bit mask
+	parameters.
 
 ``\PRIORITY_MASK``
-	This parameter is a bitmask of write ports that this write port has
-	priority over in case of writing to the same address.  The bits of this
-	parameter are indexed by the other write port's ``\PORTID`` parameter.
-	Write ports can only have priority over write ports with lower port ID.
-	When two ports write to the same address and neither has priority over
-	the other, the result is undefined.  Priority can only be set between
-	two synchronous ports sharing the same clock domain.
+	This parameter is a bitmask of write ports that this write port has priority
+	over in case of writing to the same address.  The bits of this parameter are
+	indexed by the other write port's ``\PORTID`` parameter. Write ports can
+	only have priority over write ports with lower port ID. When two ports write
+	to the same address and neither has priority over the other, the result is
+	undefined.  Priority can only be set between two synchronous ports sharing
+	the same clock domain.
 
 The ``$meminit_v2`` cells have an address input ``\ADDR``, a data input
 ``\DATA``, with the width of the ``\DATA`` port equal to ``\WIDTH`` parameter
@@ -468,13 +469,13 @@ synthesis to succeed.
 	initialization conflict.
 
 The HDL frontend models a memory using RTLIL::Memory objects and asynchronous
-``$memrd_v2`` and ``$memwr_v2`` cells. The ``memory`` pass (i.e.~its various
-sub-passes) migrates ``$dff`` cells into the ``$memrd_v2`` and ``$memwr_v2``
-cells making them synchronous, then converts them to a single ``$mem_v2`` cell
-and (optionally) maps this cell type to ``$dff`` cells for the individual words
-and multiplexer-based address decoders for the read and write interfaces. When
-the last step is disabled or not possible, a ``$mem_v2`` cell is left in the
-design.
+``$memrd_v2`` and ``$memwr_v2`` cells. The :cmd:ref:`memory` pass (i.e.~its
+various sub-passes) migrates ``$dff`` cells into the ``$memrd_v2`` and
+``$memwr_v2`` cells making them synchronous, then converts them to a single
+``$mem_v2`` cell and (optionally) maps this cell type to ``$dff`` cells for the
+individual words and multiplexer-based address decoders for the read and write
+interfaces. When the last step is disabled or not possible, a ``$mem_v2`` cell
+is left in the design.
 
 The ``$mem_v2`` cell provides the following parameters:
 
@@ -600,15 +601,15 @@ The ``$mem_v2`` cell has the following ports:
 	This input is ``\WR_PORTS*\WIDTH`` bits wide, containing all data
 	signals for the write ports.
 
-The ``memory_collect`` pass can be used to convert discrete ``$memrd_v2``,
-``$memwr_v2``, and ``$meminit_v2`` cells belonging to the same memory to a
-single ``$mem_v2`` cell, whereas the ``memory_unpack`` pass performs the inverse
-operation. The ``memory_dff`` pass can combine asynchronous memory ports that
-are fed by or feeding registers into synchronous memory ports. The
-``memory_bram`` pass can be used to recognize ``$mem_v2`` cells that can be
-implemented with a block RAM resource on an FPGA. The ``memory_map`` pass can be
-used to implement ``$mem_v2`` cells as basic logic: word-wide DFFs and address
-decoders.
+The :cmd:ref:`memory_collect` pass can be used to convert discrete
+``$memrd_v2``, ``$memwr_v2``, and ``$meminit_v2`` cells belonging to the same
+memory to a single ``$mem_v2`` cell, whereas the :cmd:ref:`memory_unpack` pass
+performs the inverse operation. The :cmd:ref:`memory_dff` pass can combine
+asynchronous memory ports that are fed by or feeding registers into synchronous
+memory ports. The :cmd:ref:`memory_bram` pass can be used to recognize
+``$mem_v2`` cells that can be implemented with a block RAM resource on an FPGA.
+The :cmd:ref:`memory_map` pass can be used to implement ``$mem_v2`` cells as
+basic logic: word-wide DFFs and address decoders.
 
 Finite state machines
 ~~~~~~~~~~~~~~~~~~~~~

docs/source/yosys_internals/formats/rtlil_rep.rst

@@ -6,22 +6,22 @@ representation. The only exception are the high-level frontends that use the AST
 representation as an intermediate step before generating RTLIL data.
 
 In order to avoid reinventing names for the RTLIL classes, they are simply
-referred to by their full C++ name, i.e. including the ``RTLIL::`` namespace prefix,
-in this document.
+referred to by their full C++ name, i.e. including the ``RTLIL::`` namespace
+prefix, in this document.
 
 :numref:`Figure %s <fig:Overview_RTLIL>` shows a simplified Entity-Relationship
 Diagram (ER Diagram) of RTLIL. In :math:`1:N` relationships the arrow points
-from the :math:`N` side to the :math:`1`. For example one ``RTLIL::Design`` contains
-:math:`N` (zero to many) instances of ``RTLIL::Module`` . A two-pointed arrow
-indicates a :math:`1:1` relationship.
+from the :math:`N` side to the :math:`1`. For example one ``RTLIL::Design``
+contains :math:`N` (zero to many) instances of ``RTLIL::Module`` . A two-pointed
+arrow indicates a :math:`1:1` relationship.
 
 The ``RTLIL::Design`` is the root object of the RTLIL data structure. There is
 always one "current design" in memory which passes operate on, frontends add
 data to and backends convert to exportable formats. But in some cases passes
-internally generate additional ``RTLIL::Design`` objects. For example when a pass is
-reading an auxiliary Verilog file such as a cell library, it might create an
-additional ``RTLIL::Design`` object and call the Verilog frontend with this other
-object to parse the cell library.
+internally generate additional ``RTLIL::Design`` objects. For example when a
+pass is reading an auxiliary Verilog file such as a cell library, it might
+create an additional ``RTLIL::Design`` object and call the Verilog frontend with
+this other object to parse the cell library.
 
 .. figure:: ../../../images/overview_rtlil.*
 	:class: width-helper
@@ -31,9 +31,9 @@ object to parse the cell library.
 
 There is only one active ``RTLIL::Design`` object that is used by all frontends,
 passes and backends called by the user, e.g. using a synthesis script. The
-``RTLIL::Design`` then contains zero to many ``RTLIL::Module`` objects. This corresponds
-to modules in Verilog or entities in VHDL. Each module in turn contains objects
-from three different categories:
+``RTLIL::Design`` then contains zero to many ``RTLIL::Module`` objects. This
+corresponds to modules in Verilog or entities in VHDL. Each module in turn
+contains objects from three different categories:
 
 -  ``RTLIL::Cell`` and ``RTLIL::Wire`` objects represent classical netlist data.
 
@@ -44,8 +44,8 @@ from three different categories:
 -  ``RTLIL::Memory`` objects represent addressable memories (arrays).
 
 Usually the output of the synthesis procedure is a netlist, i.e. all
-``RTLIL::Process`` and ``RTLIL::Memory`` objects must be replaced by ``RTLIL::Cell`` and
-``RTLIL::Wire`` objects by synthesis passes.
+``RTLIL::Process`` and ``RTLIL::Memory`` objects must be replaced by
+``RTLIL::Cell`` and ``RTLIL::Wire`` objects by synthesis passes.
 
 All features of the HDL that cannot be mapped directly to these RTLIL classes
 must be transformed to an RTLIL-compatible representation by the HDL frontend.
@@ -78,9 +78,9 @@ This has three advantages:
 
 -  Second, the information about which identifiers were originally provided by
    the user is always available which can help guide some optimizations. For
-   example the ``opt_rmunused`` tries to preserve signals with a user-provided
-   name but doesn't hesitate to delete signals that have auto-generated names
-   when they just duplicate other signals.
+   example the :cmd:ref:`opt_rmunused` tries to preserve signals with a
+   user-provided name but doesn't hesitate to delete signals that have
+   auto-generated names when they just duplicate other signals.
 
 -  Third, the delicate job of finding suitable auto-generated public visible
    names is deferred to one central location. Internally auto-generated names
@@ -184,8 +184,8 @@ An ``RTLIL::Cell`` object has the following properties:
 -  A list of parameters (for parametric cells)
 -  Cell ports and the connections of ports to wires and constants
 
-The connections of ports to wires are coded by assigning an ``RTLIL::SigSpec`` to
-each cell port. The ``RTLIL::SigSpec`` data type is described in the next
+The connections of ports to wires are coded by assigning an ``RTLIL::SigSpec``
+to each cell port. The ``RTLIL::SigSpec`` data type is described in the next
 section.
 
 .. _sec:rtlil_sigspec:
@@ -320,8 +320,8 @@ trees before further processing them.
 
 One of the first actions performed on a design in RTLIL representation in most
 synthesis scripts is identifying asynchronous resets. This is usually done using
-the ``proc_arst`` pass. This pass transforms the above example to the following
-``RTLIL::Process``:
+the :cmd:ref:`proc_arst` pass. This pass transforms the above example to the
+following ``RTLIL::Process``:
 
 .. code:: RTLIL
    :number-lines:
@@ -381,8 +381,8 @@ synthesis tasks.
 RTLIL::Memory
 -------------
 
-For every array (memory) in the HDL code an ``RTLIL::Memory`` object is created. A
-memory object has the following properties:
+For every array (memory) in the HDL code an ``RTLIL::Memory`` object is created.
+A memory object has the following properties:
 
 -  The memory name
 -  A list of attributes