Converting a number of inline commands to refs

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

docs/source/appendix/APPNOTE_010_Verilog_to_BLIF.rst

@@ -235,8 +235,8 @@ signal is connected throughout the whole design hierarchy.
 
    endmodule
 
-In line 18 the ``proc`` command is called. But in this script the signal name
-globrst is passed to the command as a global reset signal for resetting the
+In line 18 the :cmd:ref:`proc` command is called. But in this script the signal
+name globrst is passed to the command as a global reset signal for resetting the
 registers to their assigned initial values.
 
 Finally in line 19 the techmap command is used to replace all instances of

docs/source/appendix/APPNOTE_012_Verilog_to_BTOR.rst

@@ -180,7 +180,7 @@ to the Yosys documentation, or run ``yosys -h <command_name>``.
 
 The script presented earlier can be easily modified to have a BTOR file that
 does not contain memories. This is done by removing the line number 8 and 10,
-and introduces a new command ``memory`` at line number 8.
+and introduces a new command :cmd:ref:`memory` at line number 8.
 :numref:`btor_script_without_memory` shows the modified Yosys script file:
 
 .. code-block:: sh

docs/source/getting_started/examples.rst

@@ -81,7 +81,8 @@ synthesis script (``counter.ys``), a digital design written in Verilog
 #. :yoscrypt:`dfflibmap -liberty mycells.lib` - Map registers to available
    hardware flip-flops.
 #. :yoscrypt:`abc -liberty mycells.lib` - Map logic to available hardware gates.
-#. :yoscrypt:`clean` - Clean up the design (just the last step of ``opt``).
+#. :yoscrypt:`clean` - Clean up the design (just the last step of
+   :cmd:ref:`opt`).
 #. :yoscrypt:`write_verilog synth.v` - Write final synthesis result to output
    file.
 

docs/source/getting_started/scripting_intro.rst

@@ -10,10 +10,10 @@ terminated using the newline character or a semicolon (;). Empty lines and lines
 starting with the hash sign (#) are ignored. See :ref:`sec:typusecase` for an
 example synthesis script.
 
-The command ``help`` can be used to access the command reference manual, with
-``help <command>`` providing details for a specific command.  ``yosys -H`` or
-``yosys -h <command>`` will do the same outside of an interactive prompt.  The
-entire reference manual is also available here at :doc:`/cmd_ref`.
+The command :cmd:ref:`help` can be used to access the command reference manual,
+with ``help <command>`` providing details for a specific command.  ``yosys -H``
+or ``yosys -h <command>`` will do the same outside of an interactive prompt.
+The entire reference manual is also available here at :doc:`/cmd_ref`.
 
 Example commands
 ~~~~~~~~~~~~~~~~
@@ -99,10 +99,10 @@ Selections intro
 ~~~~~~~~~~~~~~~~
 
 Most commands can operate not only on the entire design but also specifically on
-selected parts of the design. For example the command ``dump`` will print all
-selected objects in the current design while ``dump foobar`` will only print the
-module ``foobar`` and ``dump *`` will print the entire design regardless of the
-current selection.
+selected parts of the design. For example the command :cmd:ref:`dump` will print
+all selected objects in the current design while ``dump foobar`` will only print
+the module ``foobar`` and ``dump *`` will print the entire design regardless of
+the current selection.
 
 .. code:: yoscrypt
 

docs/source/getting_started/typical_phases.rst

@@ -57,17 +57,17 @@ needed variations of parametric modules.
     hierarchy -check -top top_module
 
 
-The ``proc`` command
-~~~~~~~~~~~~~~~~~~~~~~
+The :cmd:ref:`proc` command
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The Verilog frontend converts ``always``-blocks to RTL netlists for the
 expressions and "processess" for the control- and memory elements.
 
-The ``proc`` command transforms this "processess" to netlists of RTL multiplexer
-and register cells.
+The :cmd:ref:`proc` command transforms this "processess" to netlists of RTL
+multiplexer and register cells.
 
-The ``proc`` command is actually a macro-command that calls the following other
-commands:
+The :cmd:ref:`proc` command is actually a macro-command that calls the following
+other commands:
 
 .. code-block:: yoscrypt
 
@@ -80,8 +80,8 @@ commands:
     proc_clean      # if all went fine, this should remove all the processes
 
 Many commands can not operate on modules with "processess" in them. Usually a
-call to ``proc`` is the first command in the actual synthesis procedure after
-design elaboration.
+call to :cmd:ref:`proc` is the first command in the actual synthesis procedure
+after design elaboration.
 
 Example
 ^^^^^^^
@@ -120,11 +120,11 @@ Example
    :caption: ``docs/resources/PRESENTATION_ExSyn/proc_03.v``
 
 
-The ``opt`` command
-~~~~~~~~~~~~~~~~~~~~~
+The :cmd:ref:`opt` command
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The ``opt`` command implements a series of simple optimizations. It also is a
-macro command that calls other commands:
+The :cmd:ref:`opt` command implements a series of simple optimizations. It also
+is a macro command that calls other commands:
 
 .. code-block:: yoscrypt
 
@@ -140,8 +140,8 @@ macro command that calls other commands:
         opt_expr            # const folding and simple expression rewriting
     while [changed design]
 
-The command ``clean`` can be used as alias for ``opt_clean``. And ``;;`` can be
-used as shortcut for ``clean``. For example:
+The command :cmd:ref:`clean` can be used as alias for :cmd:ref:`opt_clean`. And
+``;;`` can be used as shortcut for :cmd:ref:`clean`. For example:
 
 .. code-block:: yoscrypt
 
@@ -195,31 +195,31 @@ Example
    :caption: ``docs/resources/PRESENTATION_ExSyn/opt_04.ys``
 
 
-When to use ``opt`` or ``clean``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+When to use :cmd:ref:`opt` or :cmd:ref:`clean`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Usually it does not hurt to call ``opt`` after each regular command in the
-synthesis script. But it increases the synthesis time, so it is favourable to
-only call ``opt`` when an improvement can be achieved.
+Usually it does not hurt to call :cmd:ref:`opt` after each regular command in
+the synthesis script. But it increases the synthesis time, so it is favourable
+to only call :cmd:ref:`opt` when an improvement can be achieved.
 
 The designs in ``yosys-bigsim`` are a good playground for experimenting with the
-effects of calling ``opt`` in various places of the flow.
+effects of calling :cmd:ref:`opt` in various places of the flow.
 
-It generally is a good idea to call ``opt`` before inherently expensive commands
-such as ``sat`` or ``freduce``, as the possible gain is much higher in this
-cases as the possible loss.
+It generally is a good idea to call :cmd:ref:`opt` before inherently expensive
+commands such as :cmd:ref:`sat` or :cmd:ref:`freduce`, as the possible gain is
+much higher in this cases as the possible loss.
 
-The ``clean`` command on the other hand is very fast and many commands leave a
-mess (dangling signal wires, etc). For example, most commands do not remove any
-wires or cells. They just change the connections and depend on a later call to
-clean to get rid of the now unused objects. So the occasional ``;;`` is a good
-idea in every synthesis script.
+The :cmd:ref:`clean` command on the other hand is very fast and many commands
+leave a mess (dangling signal wires, etc). For example, most commands do not
+remove any wires or cells. They just change the connections and depend on a
+later call to clean to get rid of the now unused objects. So the occasional
+``;;`` is a good idea in every synthesis script.
 
-The ``memory`` command
-~~~~~~~~~~~~~~~~~~~~~~~~
+The :cmd:ref:`memory` command
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In the RTL netlist, memory reads and writes are individual cells. This makes
-consolidating the number of ports for a memory easier. The ``memory``
+consolidating the number of ports for a memory easier. The :cmd:ref:`memory`
 transforms memories to an implementation. Per default that is logic for address
 decoders and registers. It also is a macro command that calls other commands:
 
@@ -269,12 +269,12 @@ Example
    :caption: ``docs/resources/PRESENTATION_ExSyn/memory_02.ys``
 
 
-The ``fsm`` command
-~~~~~~~~~~~~~~~~~~~~~
+The :cmd:ref:`fsm` command
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The ``fsm`` command identifies, extracts, optimizes (re-encodes), and
-re-synthesizes finite state machines. It again is a macro that calls
-a series of other commands:
+The :cmd:ref:`fsm` command identifies, extracts, optimizes (re-encodes), and
+re-synthesizes finite state machines. It again is a macro that calls a series of
+other commands:
 
 .. code-block:: yoscrypt
 
@@ -298,26 +298,27 @@ a series of other commands:
 
 Some details on the most important commands from the ``fsm_*`` group:
 
-The ``fsm_detect`` command identifies FSM state registers and marks them with
-the ``(* fsm_encoding = "auto" *)`` attribute, if they do not have the
+The :cmd:ref:`fsm_detect` command identifies FSM state registers and marks them
+with the ``(* fsm_encoding = "auto" *)`` attribute, if they do not have the
 ``fsm_encoding`` set already. Mark registers with ``(* fsm_encoding = "none"
 *)`` to disable FSM optimization for a register.
 
-The ``fsm_extract`` command replaces the entire FSM (logic and state registers)
-with a ``$fsm`` cell.
+The :cmd:ref:`fsm_extract` command replaces the entire FSM (logic and state
+registers) with a ``$fsm`` cell.
 
-The commands ``fsm_opt`` and ``fsm_recode`` can be used to optimize the FSM.
+The commands :cmd:ref:`fsm_opt` and :cmd:ref:`fsm_recode` can be used to
+optimize the FSM.
 
-Finally the ``fsm_map`` command can be used to convert the (optimized) ``$fsm``
-cell back to logic and registers.
+Finally the :cmd:ref:`fsm_map` command can be used to convert the (optimized)
+``$fsm`` cell back to logic and registers.
 
-The ``techmap`` command
-~~~~~~~~~~~~~~~~~~~~~~~~~
+The :cmd:ref:`techmap` command
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. figure:: ../../images/res/PRESENTATION_ExSyn/techmap_01.*
     :class: width-helper
 
-The ``techmap`` command replaces cells with implementations given as
+The :cmd:ref:`techmap` command replaces cells with implementations given as
 verilog source. For example implementing a 32 bit adder using 16 bit adders:
 
 .. literalinclude:: ../../resources/PRESENTATION_ExSyn/techmap_01_map.v
@@ -335,8 +336,9 @@ verilog source. For example implementing a 32 bit adder using 16 bit adders:
 stdcell mapping
 ^^^^^^^^^^^^^^^
 
-When ``techmap`` is used without a map file, it uses a built-in map file to map
-all RTL cell types to a generic library of built-in logic gates and registers.
+When :cmd:ref:`techmap` is used without a map file, it uses a built-in map file
+to map all RTL cell types to a generic library of built-in logic gates and
+registers.
 
 The built-in logic gate types are: ``$_NOT_``, ``$_AND_``, ``$_OR_``,
 ``$_XOR_``, and ``$_MUX_``.
@@ -351,26 +353,27 @@ The register types are: ``$_SR_NN_``, ``$_SR_NP_``, ``$_SR_PN_``, ``$_SR_PP_``,
 See :doc:`/yosys_internals/formats/cell_library` for more about the internal
 cells used.
 
-The ``abc`` command
-~~~~~~~~~~~~~~~~~~~~~
+The :cmd:ref:`abc` command
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The ``abc`` command provides an interface to ABC_, an open source tool for
-low-level logic synthesis.
+The :cmd:ref:`abc` command provides an interface to ABC_, an open source tool
+for low-level logic synthesis.
 
 .. _ABC: http://www.eecs.berkeley.edu/~alanmi/abc/
 
-The ``abc`` command processes a netlist of internal gate types and can perform:
+The :cmd:ref:`abc` command processes a netlist of internal gate types and can
+perform:
 
 - logic minimization (optimization)
 - mapping of logic to standard cell library (liberty format)
 - mapping of logic to k-LUTs (for FPGA synthesis)
 
-Optionally ``abc`` can process registers from one clock domain and perform
-sequential optimization (such as register balancing).
+Optionally :cmd:ref:`abc` can process registers from one clock domain and
+perform sequential optimization (such as register balancing).
 
 ABC is also controlled using scripts. An ABC script can be specified to use more
 advanced ABC features. It is also possible to write the design with
-``write_blif`` and load the output file into ABC outside of Yosys.
+:cmd:ref:`write_blif` and load the output file into ABC outside of Yosys.
 
 Example
 ^^^^^^^
@@ -389,16 +392,16 @@ Example
 Other special-purpose mapping commands
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-``dfflibmap``
+:cmd:ref:`dfflibmap`
   This command maps the internal register cell types to the register types
   described in a liberty file.
 
-``hilomap``
+:cmd:ref:`hilomap`
   Some architectures require special driver cells for driving a constant hi or
   lo value. This command replaces simple constants with instances of such driver
   cells.
 
-``iopadmap``
+:cmd:ref:`iopadmap`
   Top-level input/outputs must usually be implemented using special I/O-pad
   cells. This command inserts this cells to the design.
 
@@ -436,5 +439,6 @@ Example Synthesis Script
     # write synthesis results
     write_edif synth.edif
 
-The weird ``select`` expressions at the end of this script are discussed later
-in :doc:`using_yosys/more_scripting/selections</using_yosys/more_scripting/selections>`.
+The weird :cmd:ref:`select` expressions at the end of this script are discussed
+later in
+:doc:`using_yosys/more_scripting/selections</using_yosys/more_scripting/selections>`.

docs/source/using_yosys/memory_mapping.rst

@@ -3,12 +3,13 @@
 Memory mapping
 ==============
 
-Documentation for the Yosys ``memory_libmap`` memory mapper.  Note that not all supported patterns
-are included in this document, of particular note is that combinations of multiple patterns should
-generally work.  For example, `Write port with byte enables`_ could be used in conjunction with any
-of the simple dual port (SDP) models.  In general if a hardware memory definition does not support a
-given configuration, additional logic will be instantiated to guarantee behaviour is consistent with
-simulation.
+Documentation for the Yosys :cmd:ref:`memory_libmap` memory mapper.  Note that
+not all supported patterns are included in this document, of particular note is
+that combinations of multiple patterns should generally work.  For example,
+`Write port with byte enables`_ could be used in conjunction with any of the
+simple dual port (SDP) models.  In general if a hardware memory definition does
+not support a given configuration, additional logic will be instantiated to
+guarantee behaviour is consistent with simulation.
 
 See also: `passes/memory/memlib.md <https://github.com/YosysHQ/yosys/blob/master/passes/memory/memlib.md>`_