Docs: Reflow line length

docs/source/yosys_internals/formats/rtlil_rep.rst

@@ -76,11 +76,10 @@ 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, `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
-   names.
+   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 names.
 
 -  Third, the delicate job of finding suitable auto-generated public visible
    names is deferred to one central location. Internally auto-generated names
@@ -204,8 +203,8 @@ A "signal" is everything that can be applied to a cell port. I.e.
 -  | Concatenations of the above
    | 1em For example: ``{16'd1337, mywire[15:8]}``
 
-The ``RTLIL::SigSpec`` data type is used to represent signals. The ``RTLIL::Cell``
-object contains one ``RTLIL::SigSpec`` for each cell port.
+The ``RTLIL::SigSpec`` data type is used to represent signals. The
+``RTLIL::Cell`` object contains one ``RTLIL::SigSpec`` for each cell port.
 
 In addition, connections between wires are represented using a pair of
 ``RTLIL::SigSpec`` objects. Such pairs are needed in different locations.
@@ -234,9 +233,9 @@ control logic of the behavioural code. Let's consider a simple example:
            q <= d;
    endmodule
 
-In this example there is no data path and therefore the ``RTLIL::Module`` generated
-by the frontend only contains a few ``RTLIL::Wire`` objects and an ``RTLIL::Process`` .
-The ``RTLIL::Process`` in RTLIL syntax:
+In this example there is no data path and therefore the ``RTLIL::Module``
+generated by the frontend only contains a few ``RTLIL::Wire`` objects and an
+``RTLIL::Process``. The ``RTLIL::Process`` in RTLIL syntax:
 
 .. code:: RTLIL
    :number-lines:
@@ -320,8 +319,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 `proc_arst` pass. This pass transforms the above example to the following
+``RTLIL::Process``:
 
 .. code:: RTLIL
    :number-lines:
@@ -340,9 +339,9 @@ following ``RTLIL::Process``:
    end
 
 This pass has transformed the outer ``RTLIL::SwitchRule`` into a modified
-``RTLIL::SyncRule`` object for the ``\reset`` signal. Further processing converts the
-``RTLIL::Process`` into e.g. a d-type flip-flop with asynchronous reset and a
-multiplexer for the enable signal:
+``RTLIL::SyncRule`` object for the ``\reset`` signal. Further processing
+converts the ``RTLIL::Process`` into e.g. a d-type flip-flop with asynchronous
+reset and a multiplexer for the enable signal:
 
 .. code:: RTLIL
    :number-lines:
@@ -365,11 +364,11 @@ multiplexer for the enable signal:
        connect \Y $0\q[0:0]
    end
 
-Different combinations of passes may yield different results. Note that
-`$adff` and `$mux` are internal cell types that still need to be mapped to
-cell types from the target cell library.
+Different combinations of passes may yield different results. Note that `$adff`
+and `$mux` are internal cell types that still need to be mapped to cell types
+from the target cell library.
 
-Some passes refuse to operate on modules that still contain ``RTLIL::Process`` 
+Some passes refuse to operate on modules that still contain ``RTLIL::Process``
 objects as the presence of these objects in a module increases the complexity.
 Therefore the passes to translate processes to a netlist of cells are usually
 called early in a synthesis script. The proc pass calls a series of other passes
@@ -389,9 +388,9 @@ A memory object has the following properties:
 -  The width of an addressable word
 -  The size of the memory in number of words
 
-All read accesses to the memory are transformed to `$memrd` cells and all
-write accesses to `$memwr` cells by the language frontend. These cells consist
-of independent read- and write-ports to the memory. Memory initialization is
+All read accesses to the memory are transformed to `$memrd` cells and all write
+accesses to `$memwr` cells by the language frontend. These cells consist of
+independent read- and write-ports to the memory. Memory initialization is
 transformed to `$meminit` cells by the language frontend. The ``\MEMID``
 parameter on these cells is used to link them together and to the
 ``RTLIL::Memory`` object they belong to.
@@ -402,8 +401,8 @@ the separate `$memrd` and `$memwr` cells can be consolidated using resource
 sharing. As resource sharing is a non-trivial optimization problem where
 different synthesis tasks can have different requirements it lends itself to do
 the optimisation in separate passes and merge the ``RTLIL::Memory`` objects and
-`$memrd` and `$memwr` cells to multiport memory blocks after resource
-sharing is completed.
+`$memrd` and `$memwr` cells to multiport memory blocks after resource sharing is
+completed.
 
 The memory pass performs this conversion and can (depending on the options
 passed to it) transform the memories directly to d-type flip-flops and address