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/flow/command_ordering.rst

@@ -28,13 +28,13 @@ components, such as LUTs, gates, or half- and full-adders.
 The extract pass
 ~~~~~~~~~~~~~~~~
 
-- Like the ``techmap`` pass, the ``extract`` pass is called with a map file. It
-  compares the circuits inside the modules of the map file with the design and
-  looks for sub-circuits in the design that match any of the modules in the map
-  file.
-- If a match is found, the ``extract`` pass will replace the matching subcircuit
-  with an instance of the module from the map file.
-- In a way the ``extract`` pass is the inverse of the techmap pass.
+- Like the :cmd:ref:`techmap` pass, the :cmd:ref:`extract` pass is called with a
+  map file. It compares the circuits inside the modules of the map file with the
+  design and looks for sub-circuits in the design that match any of the modules
+  in the map file.
+- If a match is found, the :cmd:ref:`extract` pass will replace the matching
+  subcircuit with an instance of the module from the map file.
+- In a way the :cmd:ref:`extract` pass is the inverse of the techmap pass.
 
 .. todo:: copypaste
 
@@ -93,19 +93,19 @@ can also be used to implement 16x20-bit multiplication.
 A way of mapping such elements in coarse grain synthesis is the wrap-extract-unwrap method:
 
 wrap
-  Identify candidate-cells in the circuit and wrap them in a cell with a constant
-  wider bit-width using ``techmap``. The wrappers use the same parameters as the original cell, so
-  the information about the original width of the ports is preserved.
-  Then use the ``connwrappers`` command to connect up the bit-extended in- and
-  outputs of the wrapper cells.
+  Identify candidate-cells in the circuit and wrap them in a cell with a
+  constant wider bit-width using :cmd:ref:`techmap`. The wrappers use the same
+  parameters as the original cell, so the information about the original width
+  of the ports is preserved. Then use the ``connwrappers`` command to connect up
+  the bit-extended in- and outputs of the wrapper cells.
 
 extract
   Now all operations are encoded using the same bit-width as the coarse grain
-  element. The ``extract`` command can be used to replace circuits with cells
-  of the target architecture.
+  element. The :cmd:ref:`extract` command can be used to replace circuits with
+  cells of the target architecture.
 
 unwrap
-  The remaining wrapper cell can be unwrapped using ``techmap``.
+  The remaining wrapper cell can be unwrapped using :cmd:ref:`techmap`.
 
 Example: DSP48_MACC
 ~~~~~~~~~~~~~~~~~~~
@@ -144,7 +144,8 @@ Extract: ``macc_xilinx_xmap.v``
    :language: verilog
    :caption: ``docs/resources/PRESENTATION_ExAdv/macc_xilinx_xmap.v``
 
-... simply use the same wrapping commands on this module as on the design to create a template for the ``extract`` command.
+... simply use the same wrapping commands on this module as on the design to
+create a template for the :cmd:ref:`extract` command.
 
 Unwrapping multipliers: ``macc_xilinx_unwrap_map.v``
 

docs/source/yosys_internals/flow/model_checking.rst

@@ -17,7 +17,8 @@ passes in Yosys.
 
 Other applications include checking if a module conforms to interface standards.
 
-The ``sat`` command in Yosys can be used to perform Symbolic Model Checking.
+The :cmd:ref:`sat` command in Yosys can be used to perform Symbolic Model
+Checking.
 
 Checking techmap
 ~~~~~~~~~~~~~~~~

docs/source/yosys_internals/flow/verilog_frontend.rst

@@ -407,9 +407,9 @@ transformed into a set of d-type flip-flops and the
 multiplexers.
 
 In more complex examples (e.g. asynchronous resets) the part of the
-``RTLIL::CaseRule``/``RTLIL::SwitchRule`` tree that describes the
-asynchronous reset must first be transformed to the correct
-``RTLIL::SyncRule`` objects. This is done by the proc_adff pass.
+``RTLIL::CaseRule``/``RTLIL::SwitchRule`` tree that describes the asynchronous
+reset must first be transformed to the correct ``RTLIL::SyncRule`` objects. This
+is done by the :cmd:ref:`proc_adff` pass.
 
 The ProcessGenerator algorithm
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -591,16 +591,16 @@ The proc pass
 
 The ProcessGenerator converts a behavioural model in AST representation to a
 behavioural model in ``RTLIL::Process`` representation. The actual conversion
-from a behavioural model to an RTL representation is performed by the ``proc``
-pass and the passes it launches:
+from a behavioural model to an RTL representation is performed by the
+:cmd:ref:`proc` pass and the passes it launches:
 
--  | proc_clean and proc_rmdead 
+-  | :cmd:ref:`proc_clean` and :cmd:ref:`proc_rmdead` 
    | These two passes just clean up the ``RTLIL::Process`` structure. The
-     ``proc_clean`` pass removes empty parts (eg. empty assignments) from the
-     process and ``proc_rmdead`` detects and removes unreachable branches from
-     the process's decision trees.
+     :cmd:ref:`proc_clean` pass removes empty parts (eg. empty assignments) from
+     the process and :cmd:ref:`proc_rmdead` detects and removes unreachable
+     branches from the process's decision trees.
 
--  | proc_arst 
+-  | :cmd:ref:`proc_arst` 
    | This pass detects processes that describe d-type flip-flops with
      asynchronous resets and rewrites the process to better reflect what they
      are modelling: Before this pass, an asynchronous reset has two
@@ -608,22 +608,22 @@ pass and the passes it launches:
      reset path. After this pass the sync rule for the reset is level-sensitive
      and the top-level ``RTLIL::SwitchRule`` has been removed.
 
--  | proc_mux 
+-  | :cmd:ref:`proc_mux` 
    | This pass converts the ``RTLIL::CaseRule``/ ``RTLIL::SwitchRule``-tree to a
      tree of multiplexers per written signal. After this, the ``RTLIL::Process``
      structure only contains the ``RTLIL::SyncRule`` s that describe the output
      registers.
 
--  | proc_dff
+-  | :cmd:ref:`proc_dff`
    | This pass replaces the ``RTLIL::SyncRule`` s to d-type flip-flops (with
      asynchronous resets if necessary).
 
--  | proc_dff
+-  | :cmd:ref:`proc_dff`
    | This pass replaces the ``RTLIL::MemWriteAction`` s with ``$memwr`` cells.
 
--  | proc_clean
-   | A final call to ``proc_clean`` removes the now empty ``RTLIL::Process``
-     objects.
+-  | :cmd:ref:`proc_clean`
+   | A final call to :cmd:ref:`proc_clean` removes the now empty
+     ``RTLIL::Process`` objects.
 
 Performing these last processing steps in passes instead of in the Verilog
 frontend has two important benefits: