Docs: Shorten cmd:ref

docs/source/yosys_internals/extending_yosys/extensions.rst

@@ -35,7 +35,7 @@ about the internal data storage format used in Yosys and the classes that it
 provides.
 
 This document will focus on the much simpler version of RTLIL left after the
-commands :cmd:ref:`proc` and :cmd:ref:`memory` (or :yoscrypt:`memory -nomap`):
+commands `proc` and `memory` (or :yoscrypt:`memory -nomap`):
 
 .. figure:: /_images/internals/simplified_rtlil.*
     :class: width-helper invert-helper
@@ -56,7 +56,7 @@ It is possible to only work on this simpler version:
     }
 
 When trying to understand what a command does, creating a small test case to
-look at the output of :cmd:ref:`dump` and :cmd:ref:`show` before and after the
+look at the output of `dump` and `show` before and after the
 command has been executed can be helpful.
 :doc:`/using_yosys/more_scripting/selections` has more information on using
 these commands.
@@ -152,7 +152,7 @@ Most commands modify existing modules, not create new ones.
 When modifying existing modules, stick to the following DOs and DON'Ts:
 
 - Do not remove wires. Simply disconnect them and let a successive
-  :cmd:ref:`clean` command worry about removing it.
+  `clean` command worry about removing it.
 - Use ``module->fixup_ports()`` after changing the ``port_*`` properties of
   wires.
 - You can safely remove cells or change the ``connections`` property of a cell,

docs/source/yosys_internals/flow/verilog_frontend.rst

@@ -600,15 +600,15 @@ 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
-:cmd:ref:`proc` pass and the passes it launches:
+`proc` pass and the passes it launches:
 
--  | :cmd:ref:`proc_clean` and :cmd:ref:`proc_rmdead` 
+-  | `proc_clean` and `proc_rmdead` 
    | These two passes just clean up the ``RTLIL::Process`` structure. The
-     :cmd:ref:`proc_clean` pass removes empty parts (eg. empty assignments) from
-     the process and :cmd:ref:`proc_rmdead` detects and removes unreachable
+     `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_arst` 
+-  | `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
@@ -616,21 +616,21 @@ from a behavioural model to an RTL representation is performed by the
      reset path. After this pass the sync rule for the reset is level-sensitive
      and the top-level ``RTLIL::SwitchRule`` has been removed.
 
--  | :cmd:ref:`proc_mux` 
+-  | `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.
 
--  | :cmd:ref:`proc_dff`
+-  | `proc_dff`
    | This pass replaces the ``RTLIL::SyncRule``\ s to d-type flip-flops (with
      asynchronous resets if necessary).
 
--  | :cmd:ref:`proc_dff`
+-  | `proc_dff`
    | This pass replaces the ``RTLIL::MemWriteAction``\ s with `$memwr` cells.
 
--  | :cmd:ref:`proc_clean`
-   | A final call to :cmd:ref:`proc_clean` removes the now empty
+-  | `proc_clean`
+   | A final call to `proc_clean` removes the now empty
      ``RTLIL::Process`` objects.
 
 Performing these last processing steps in passes instead of in the Verilog

docs/source/yosys_internals/formats/cell_library.rst

@@ -258,7 +258,7 @@ 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 :cmd:ref:`proc` pass using the
+Usually these cells are generated by the `proc` pass using the
 information in the designs RTLIL::Process objects.
 
 D-type flip-flops with synchronous reset are represented by `$sdff` cells. As
@@ -472,7 +472,7 @@ synthesis to succeed.
 	initialization conflict.
 
 The HDL frontend models a memory using ``RTLIL::Memory`` objects and
-asynchronous `$memrd_v2` and `$memwr_v2` cells. The :cmd:ref:`memory` pass
+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
@@ -604,14 +604,14 @@ 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 :cmd:ref:`memory_collect` pass can be used to convert discrete
+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 :cmd:ref:`memory_unpack` pass
-performs the inverse operation. The :cmd:ref:`memory_dff` pass can combine
+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 :cmd:ref:`memory_bram` pass can be used to recognize
+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 :cmd:ref:`memory_map` pass can be used to implement `$mem_v2` cells as
+The `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

@@ -76,7 +76,7 @@ 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, :cmd:ref:`opt_clean` tries to preserve signals with a user-provided
+   example, `opt_clean` 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.  Note that this can be overridden
    with the ``-purge`` option to also delete internal nets with user-provided
@@ -320,7 +320,7 @@ 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 :cmd:ref:`proc_arst` pass. This pass transforms the above example to the
+the `proc_arst` pass. This pass transforms the above example to the
 following ``RTLIL::Process``:
 
 .. code:: RTLIL

docs/source/yosys_internals/techmap.rst

@@ -1,7 +1,7 @@
 Techmap by example
 ------------------
 
-As a quick recap, the :cmd:ref:`techmap` command replaces cells in the design
+As a quick recap, the `techmap` command replaces cells in the design
 with implementations given as Verilog code (called "map files"). It can replace
 Yosys' internal cell types (such as `$or`) as well as user-defined cell types.
 
@@ -87,14 +87,14 @@ Scripting in map modules
 - You can even call techmap recursively!
 - Example use-cases:
 
-    - Using always blocks in map module: call :cmd:ref:`proc`
-    - Perform expensive optimizations (such as :cmd:ref:`freduce`) on cells
+    - Using always blocks in map module: call `proc`
+    - Perform expensive optimizations (such as `freduce`) on cells
       where this is known to work well.
     - Interacting with custom commands.
 
 .. note:: PROTIP:
 
-    Commands such as :cmd:ref:`shell`, ``show -pause``, and :cmd:ref:`dump` can
+    Commands such as `shell`, ``show -pause``, and `dump` can
     be used in the ``_TECHMAP_DO_*`` scripts for debugging map modules.
 
 Example: