mirror of
https://github.com/YosysHQ/yosys
synced 2025-06-06 22:23:23 +00:00
Docs: Shorten cmd:ref
This commit is contained in:
Krystine Sherwin
parent
e4ec3717bc
commit
829e02ec5b
22 changed files with 296 additions and 297 deletions
|
|
@ -10,11 +10,11 @@ fine-grained optimisation and LUT mapping.
|
|||
Yosys has two different commands, which both use this logic toolbox, but use it
|
||||
in different ways.
|
||||
|
||||
The :cmd:ref:`abc` pass can be used for both ASIC (e.g. :yoscrypt:`abc
|
||||
The `abc` pass can be used for both ASIC (e.g. :yoscrypt:`abc
|
||||
-liberty`) and FPGA (:yoscrypt:`abc -lut`) mapping, but this page will focus on
|
||||
FPGA mapping.
|
||||
|
||||
The :cmd:ref:`abc9` pass generally provides superior mapping quality due to
|
||||
The `abc9` pass generally provides superior mapping quality due to
|
||||
being aware of combination boxes and DFF and LUT timings, giving it a more
|
||||
global view of the mapping problem.
|
||||
|
||||
|
|
@ -23,7 +23,7 @@ global view of the mapping problem.
|
|||
ABC: the unit delay model, simple and efficient
|
||||
-----------------------------------------------
|
||||
|
||||
The :cmd:ref:`abc` pass uses a highly simplified view of an FPGA:
|
||||
The `abc` pass uses a highly simplified view of an FPGA:
|
||||
|
||||
- An FPGA is made up of a network of inputs that connect through LUTs to a
|
||||
network of outputs. These inputs may actually be I/O pins, D flip-flops,
|
||||
|
|
@ -126,7 +126,7 @@ guide to the syntax:
|
|||
|
||||
By convention, all delays in ``specify`` blocks are in integer picoseconds.
|
||||
Files containing ``specify`` blocks should be read with the ``-specify`` option
|
||||
to :cmd:ref:`read_verilog` so that they aren't skipped.
|
||||
to `read_verilog` so that they aren't skipped.
|
||||
|
||||
LUTs
|
||||
^^^^
|
||||
|
|
@ -145,9 +145,9 @@ DFFs
|
|||
|
||||
DFFs should be annotated with an ``(* abc9_flop *)`` attribute, however ABC9 has
|
||||
some specific requirements for this to be valid: - the DFF must initialise to
|
||||
zero (consider using :cmd:ref:`dfflegalize` to ensure this). - the DFF cannot
|
||||
have any asynchronous resets/sets (see the simplification idiom and the Boxes
|
||||
section for what to do here).
|
||||
zero (consider using `dfflegalize` to ensure this). - the DFF cannot have any
|
||||
asynchronous resets/sets (see the simplification idiom and the Boxes section for
|
||||
what to do here).
|
||||
|
||||
It is worth noting that in pure ``abc9`` mode, only the setup and arrival times
|
||||
are passed to ABC9 (specifically, they are modelled as buffers with the given
|
||||
|
|
@ -158,9 +158,9 @@ Some vendors have universal DFF models which include async sets/resets even when
|
|||
they're unused. Therefore *the simplification idiom* exists to handle this: by
|
||||
using a ``techmap`` file to discover flops which have a constant driver to those
|
||||
asynchronous controls, they can be mapped into an intermediate, simplified flop
|
||||
which qualifies as an ``(* abc9_flop *)``, ran through :cmd:ref:`abc9`, and then
|
||||
mapped back to the original flop. This is used in :cmd:ref:`synth_intel_alm` and
|
||||
:cmd:ref:`synth_quicklogic` for the PolarPro3.
|
||||
which qualifies as an ``(* abc9_flop *)``, ran through `abc9`, and then mapped
|
||||
back to the original flop. This is used in `synth_intel_alm` and
|
||||
`synth_quicklogic` for the PolarPro3.
|
||||
|
||||
DFFs are usually specified to have setup constraints against the clock on the
|
||||
input signals, and an arrival time for the ``Q`` output.
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ Our circuit now looks like this:
|
|||
:class: width-helper invert-helper
|
||||
:name: counter-hierarchy
|
||||
|
||||
``counter`` after :cmd:ref:`hierarchy`
|
||||
``counter`` after `hierarchy`
|
||||
|
||||
Coarse-grain representation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -82,7 +82,7 @@ Logic gate mapping
|
|||
.. figure:: /_images/code_examples/intro/counter_02.*
|
||||
:class: width-helper invert-helper
|
||||
|
||||
``counter`` after :cmd:ref:`techmap`
|
||||
``counter`` after `techmap`
|
||||
|
||||
Mapping to hardware
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -102,7 +102,7 @@ Recall that the Yosys built-in logic gate types are `$_NOT_`, `$_AND_`,
|
|||
`$_OR_`, `$_XOR_`, and `$_MUX_` with an assortment of dff memory types.
|
||||
:ref:`mycells-lib` defines our target cells as ``BUF``, ``NOT``, ``NAND``,
|
||||
``NOR``, and ``DFF``. Mapping between these is performed with the commands
|
||||
:cmd:ref:`dfflibmap` and :cmd:ref:`abc` as follows:
|
||||
`dfflibmap` and `abc` as follows:
|
||||
|
||||
.. literalinclude:: /code_examples/intro/counter.ys
|
||||
:language: yoscrypt
|
||||
|
|
@ -117,7 +117,7 @@ The final version of our ``counter`` module looks like this:
|
|||
|
||||
``counter`` after hardware cell mapping
|
||||
|
||||
Before finally being output as a verilog file with :cmd:ref:`write_verilog`,
|
||||
Before finally being output as a verilog file with `write_verilog`,
|
||||
which can then be loaded into another tool:
|
||||
|
||||
.. literalinclude:: /code_examples/intro/counter.ys
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
The extract pass
|
||||
----------------
|
||||
|
||||
- Like the :cmd:ref:`techmap` pass, the :cmd:ref:`extract` pass is called with a
|
||||
- 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 :cmd:ref:`extract` pass will replace the matching
|
||||
- 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 :cmd:ref:`extract` pass is the inverse of the techmap pass.
|
||||
- In a way the `extract` pass is the inverse of the techmap pass.
|
||||
|
||||
.. todo:: add/expand supporting text, also mention custom pattern matching and
|
||||
pmgen
|
||||
|
|
@ -25,7 +25,7 @@ Example code can be found in |code_examples/macc|_.
|
|||
.. figure:: /_images/code_examples/macc/macc_simple_test_00a.*
|
||||
:class: width-helper invert-helper
|
||||
|
||||
before :cmd:ref:`extract`
|
||||
before `extract`
|
||||
|
||||
.. literalinclude:: /code_examples/macc/macc_simple_test.ys
|
||||
:language: yoscrypt
|
||||
|
|
@ -34,7 +34,7 @@ Example code can be found in |code_examples/macc|_.
|
|||
.. figure:: /_images/code_examples/macc/macc_simple_test_00b.*
|
||||
:class: width-helper invert-helper
|
||||
|
||||
after :cmd:ref:`extract`
|
||||
after `extract`
|
||||
|
||||
.. literalinclude:: /code_examples/macc/macc_simple_test.v
|
||||
:language: verilog
|
||||
|
|
@ -76,18 +76,18 @@ wrap-extract-unwrap method:
|
|||
|
||||
wrap
|
||||
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
|
||||
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 :cmd:ref:`connwrappers` command to
|
||||
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 :cmd:ref:`extract` command can be used to replace circuits with
|
||||
element. The `extract` command can be used to replace circuits with
|
||||
cells of the target architecture.
|
||||
|
||||
unwrap
|
||||
The remaining wrapper cell can be unwrapped using :cmd:ref:`techmap`.
|
||||
The remaining wrapper cell can be unwrapped using `techmap`.
|
||||
|
||||
Example: DSP48_MACC
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -127,7 +127,7 @@ Extract: :file:`macc_xilinx_xmap.v`
|
|||
:caption: :file:`macc_xilinx_xmap.v`
|
||||
|
||||
... simply use the same wrapping commands on this module as on the design to
|
||||
create a template for the :cmd:ref:`extract` command.
|
||||
create a template for the `extract` command.
|
||||
|
||||
Unwrapping multipliers: :file:`macc_xilinx_unwrap_map.v`
|
||||
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
FSM handling
|
||||
============
|
||||
|
||||
The :cmd:ref:`fsm` command identifies, extracts, optimizes (re-encodes), and
|
||||
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:
|
||||
|
||||
.. literalinclude:: /code_examples/macro_commands/fsm.ys
|
||||
:language: yoscrypt
|
||||
:start-after: #end:
|
||||
:caption: Passes called by :cmd:ref:`fsm`
|
||||
:caption: Passes called by `fsm`
|
||||
|
||||
See also :doc:`/cmd/fsm`.
|
||||
|
||||
|
|
@ -18,7 +18,7 @@ general reported technique :cite:p:`fsmextract`.
|
|||
FSM detection
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
The :cmd:ref:`fsm_detect` pass identifies FSM state registers. It sets the
|
||||
The `fsm_detect` pass identifies FSM state registers. It sets the
|
||||
``\fsm_encoding = "auto"`` attribute on any (multi-bit) wire that matches the
|
||||
following description:
|
||||
|
||||
|
|
@ -44,7 +44,7 @@ results.
|
|||
FSM extraction
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
The :cmd:ref:`fsm_extract` pass operates on all state signals marked with the
|
||||
The `fsm_extract` pass operates on all state signals marked with the
|
||||
(``\fsm_encoding != "none"``) attribute. For each state signal the following
|
||||
information is determined:
|
||||
|
||||
|
|
@ -87,7 +87,7 @@ given set of result signals using a set of signal-value assignments. It can also
|
|||
be passed a list of stop-signals that abort the ConstEval algorithm if the value
|
||||
of a stop-signal is needed in order to calculate the result signals.
|
||||
|
||||
The :cmd:ref:`fsm_extract` pass uses the ConstEval class in the following way to
|
||||
The `fsm_extract` pass uses the ConstEval class in the following way to
|
||||
create a transition table. For each state:
|
||||
|
||||
1. Create a ConstEval object for the module containing the FSM
|
||||
|
|
@ -108,12 +108,12 @@ drivers for the control outputs are disconnected.
|
|||
FSM optimization
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
The :cmd:ref:`fsm_opt` pass performs basic optimizations on `$fsm` cells (not
|
||||
The `fsm_opt` pass performs basic optimizations on `$fsm` cells (not
|
||||
including state recoding). The following optimizations are performed (in this
|
||||
order):
|
||||
|
||||
- Unused control outputs are removed from the `$fsm` cell. The attribute
|
||||
``\unused_bits`` (that is usually set by the :cmd:ref:`opt_clean` pass) is
|
||||
``\unused_bits`` (that is usually set by the `opt_clean` pass) is
|
||||
used to determine which control outputs are unused.
|
||||
|
||||
- Control inputs that are connected to the same driver are merged.
|
||||
|
|
@ -134,11 +134,11 @@ order):
|
|||
FSM recoding
|
||||
~~~~~~~~~~~~
|
||||
|
||||
The :cmd:ref:`fsm_recode` pass assigns new bit pattern to the states. Usually
|
||||
The `fsm_recode` pass assigns new bit pattern to the states. Usually
|
||||
this also implies a change in the width of the state signal. At the moment of
|
||||
this writing only one-hot encoding with all-zero for the reset state is
|
||||
supported.
|
||||
|
||||
The :cmd:ref:`fsm_recode` pass can also write a text file with the changes
|
||||
The `fsm_recode` pass can also write a text file with the changes
|
||||
performed by it that can be used when verifying designs synthesized by Yosys
|
||||
using Synopsys Formality.
|
||||
|
|
|
|||
|
|
@ -8,17 +8,17 @@ coarse-grain optimizations before being mapped to hard blocks and fine-grain
|
|||
cells. Most commands in Yosys will target either coarse-grain representation or
|
||||
fine-grain representation, with only a select few compatible with both states.
|
||||
|
||||
Commands such as :cmd:ref:`proc`, :cmd:ref:`fsm`, and :cmd:ref:`memory` rely on
|
||||
Commands such as `proc`, `fsm`, and `memory` rely on
|
||||
the additional information in the coarse-grain representation, along with a
|
||||
number of optimizations such as :cmd:ref:`wreduce`, :cmd:ref:`share`, and
|
||||
:cmd:ref:`alumacc`. :cmd:ref:`opt` provides optimizations which are useful in
|
||||
both states, while :cmd:ref:`techmap` is used to convert coarse-grain cells
|
||||
number of optimizations such as `wreduce`, `share`, and
|
||||
`alumacc`. `opt` provides optimizations which are useful in
|
||||
both states, while `techmap` is used to convert coarse-grain cells
|
||||
to the corresponding fine-grain representation.
|
||||
|
||||
Single-bit cells (logic gates, FFs) as well as LUTs, half-adders, and
|
||||
full-adders make up the bulk of the fine-grain representation and are necessary
|
||||
for commands such as :cmd:ref:`abc`\ /:cmd:ref:`abc9`, :cmd:ref:`simplemap`,
|
||||
:cmd:ref:`dfflegalize`, and :cmd:ref:`memory_map`.
|
||||
for commands such as `abc`\ /`abc9`, `simplemap`,
|
||||
`dfflegalize`, and `memory_map`.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
Memory handling
|
||||
===============
|
||||
|
||||
The :cmd:ref:`memory` command
|
||||
The `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 :cmd:ref:`memory`
|
||||
consolidating the number of ports for a memory easier. The `memory`
|
||||
pass transforms memories to an implementation. Per default that is logic for
|
||||
address decoders and registers. It also is a macro command that calls the other
|
||||
common ``memory_*`` passes in a sensible order:
|
||||
|
|
@ -13,19 +13,19 @@ common ``memory_*`` passes in a sensible order:
|
|||
.. literalinclude:: /code_examples/macro_commands/memory.ys
|
||||
:language: yoscrypt
|
||||
:start-after: #end:
|
||||
:caption: Passes called by :cmd:ref:`memory`
|
||||
:caption: Passes called by `memory`
|
||||
|
||||
.. todo:: Make ``memory_*`` notes less quick
|
||||
|
||||
Some quick notes:
|
||||
|
||||
- :cmd:ref:`memory_dff` merges registers into the memory read- and write cells.
|
||||
- :cmd:ref:`memory_collect` collects all read and write cells for a memory and
|
||||
- `memory_dff` merges registers into the memory read- and write cells.
|
||||
- `memory_collect` collects all read and write cells for a memory and
|
||||
transforms them into one multi-port memory cell.
|
||||
- :cmd:ref:`memory_map` takes the multi-port memory cell and transforms it to
|
||||
- `memory_map` takes the multi-port memory cell and transforms it to
|
||||
address decoder logic and registers.
|
||||
|
||||
For more information about :cmd:ref:`memory`, such as disabling certain sub
|
||||
For more information about `memory`, such as disabling certain sub
|
||||
commands, see :doc:`/cmd/memory`.
|
||||
|
||||
Example
|
||||
|
|
@ -75,22 +75,22 @@ For example:
|
|||
techmap -map my_memory_map.v
|
||||
memory_map
|
||||
|
||||
:cmd:ref:`memory_libmap` attempts to convert memory cells (`$mem_v2` etc) into
|
||||
`memory_libmap` attempts to convert memory cells (`$mem_v2` etc) into
|
||||
hardware supported memory using a provided library (:file:`my_memory_map.txt` in the
|
||||
example above). Where necessary, emulation logic is added to ensure functional
|
||||
equivalence before and after this conversion. :yoscrypt:`techmap -map
|
||||
my_memory_map.v` then uses :cmd:ref:`techmap` to map to hardware primitives. Any
|
||||
my_memory_map.v` then uses `techmap` to map to hardware primitives. Any
|
||||
leftover memory cells unable to be converted are then picked up by
|
||||
:cmd:ref:`memory_map` and mapped to DFFs and address decoders.
|
||||
`memory_map` and mapped to DFFs and address decoders.
|
||||
|
||||
.. note::
|
||||
|
||||
More information about what mapping options are available and associated
|
||||
costs of each can be found by enabling debug outputs. This can be done with
|
||||
the :cmd:ref:`debug` command, or by using the ``-g`` flag when calling Yosys
|
||||
the `debug` command, or by using the ``-g`` flag when calling Yosys
|
||||
to globally enable debug messages.
|
||||
|
||||
For more on the lib format for :cmd:ref:`memory_libmap`, see
|
||||
For more on the lib format for `memory_libmap`, see
|
||||
`passes/memory/memlib.md
|
||||
<https://github.com/YosysHQ/yosys/blob/main/passes/memory/memlib.md>`_
|
||||
|
||||
|
|
|
|||
|
|
@ -6,10 +6,10 @@ This chapter outlines these optimizations.
|
|||
|
||||
.. todo:: "outlines these optimizations" or "outlines *some*.."?
|
||||
|
||||
The :cmd:ref:`opt` macro command
|
||||
The `opt` macro command
|
||||
--------------------------------
|
||||
|
||||
The Yosys pass :cmd:ref:`opt` runs a number of simple optimizations. This
|
||||
The Yosys pass `opt` runs a number of simple optimizations. This
|
||||
includes removing unused signals and cells and const folding. It is recommended
|
||||
to run this pass after each major step in the synthesis script. As listed in
|
||||
:doc:`/cmd/opt`, this macro command calls the following ``opt_*`` commands:
|
||||
|
|
@ -17,11 +17,11 @@ to run this pass after each major step in the synthesis script. As listed in
|
|||
.. literalinclude:: /code_examples/macro_commands/opt.ys
|
||||
:language: yoscrypt
|
||||
:start-after: #end:
|
||||
:caption: Passes called by :cmd:ref:`opt`
|
||||
:caption: Passes called by `opt`
|
||||
|
||||
.. _adv_opt_expr:
|
||||
|
||||
Constant folding and simple expression rewriting - :cmd:ref:`opt_expr`
|
||||
Constant folding and simple expression rewriting - `opt_expr`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. todo:: unsure if this is too much detail and should be in :doc:`/yosys_internals/index`
|
||||
|
|
@ -31,7 +31,7 @@ described in :doc:`/yosys_internals/formats/cell_library`. This means a cell
|
|||
with all constant inputs is replaced with the constant value this cell drives.
|
||||
In some cases this pass can also optimize cells with some constant inputs.
|
||||
|
||||
.. table:: Const folding rules for `$_AND_` cells as used in :cmd:ref:`opt_expr`.
|
||||
.. table:: Const folding rules for `$_AND_` cells as used in `opt_expr`.
|
||||
:name: tab:opt_expr_and
|
||||
:align: center
|
||||
|
||||
|
|
@ -69,7 +69,7 @@ undef.
|
|||
The last two lines simply replace an `$_AND_` gate with one constant-1 input
|
||||
with a buffer.
|
||||
|
||||
Besides this basic const folding the :cmd:ref:`opt_expr` pass can replace 1-bit
|
||||
Besides this basic const folding the `opt_expr` pass can replace 1-bit
|
||||
wide `$eq` and `$ne` cells with buffers or not-gates if one input is
|
||||
constant. Equality checks may also be reduced in size if there are redundant
|
||||
bits in the arguments (i.e. bits which are constant on both inputs). This can,
|
||||
|
|
@ -77,7 +77,7 @@ for example, result in a 32-bit wide constant like ``255`` being reduced to the
|
|||
8-bit value of ``8'11111111`` if the signal being compared is only 8-bit as in
|
||||
:ref:`addr_gen_clean` of :doc:`/getting_started/example_synth`.
|
||||
|
||||
The :cmd:ref:`opt_expr` pass is very conservative regarding optimizing `$mux`
|
||||
The `opt_expr` pass is very conservative regarding optimizing `$mux`
|
||||
cells, as these cells are often used to model decision-trees and breaking these
|
||||
trees can interfere with other optimizations.
|
||||
|
||||
|
|
@ -85,14 +85,14 @@ trees can interfere with other optimizations.
|
|||
:language: Verilog
|
||||
:start-after: read_verilog <<EOT
|
||||
:end-before: EOT
|
||||
:caption: example verilog for demonstrating :cmd:ref:`opt_expr`
|
||||
:caption: example verilog for demonstrating `opt_expr`
|
||||
|
||||
.. figure:: /_images/code_examples/opt/opt_expr.*
|
||||
:class: width-helper invert-helper
|
||||
|
||||
Before and after :cmd:ref:`opt_expr`
|
||||
Before and after `opt_expr`
|
||||
|
||||
Merging identical cells - :cmd:ref:`opt_merge`
|
||||
Merging identical cells - `opt_merge`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This pass performs trivial resource sharing. This means that this pass
|
||||
|
|
@ -101,21 +101,21 @@ of the cell.
|
|||
|
||||
The option ``-nomux`` can be used to disable resource sharing for multiplexer
|
||||
cells (`$mux` and `$pmux`.) This can be useful as it prevents multiplexer
|
||||
trees to be merged, which might prevent :cmd:ref:`opt_muxtree` to identify
|
||||
trees to be merged, which might prevent `opt_muxtree` to identify
|
||||
possible optimizations.
|
||||
|
||||
.. literalinclude:: /code_examples/opt/opt_merge.ys
|
||||
:language: Verilog
|
||||
:start-after: read_verilog <<EOT
|
||||
:end-before: EOT
|
||||
:caption: example verilog for demonstrating :cmd:ref:`opt_merge`
|
||||
:caption: example verilog for demonstrating `opt_merge`
|
||||
|
||||
.. figure:: /_images/code_examples/opt/opt_merge.*
|
||||
:class: width-helper invert-helper
|
||||
|
||||
Before and after :cmd:ref:`opt_merge`
|
||||
Before and after `opt_merge`
|
||||
|
||||
Removing never-active branches from multiplexer tree - :cmd:ref:`opt_muxtree`
|
||||
Removing never-active branches from multiplexer tree - `opt_muxtree`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This pass optimizes trees of multiplexer cells by analyzing the select inputs.
|
||||
|
|
@ -125,19 +125,19 @@ Consider the following simple example:
|
|||
:language: Verilog
|
||||
:start-after: read_verilog <<EOT
|
||||
:end-before: EOT
|
||||
:caption: example verilog for demonstrating :cmd:ref:`opt_muxtree`
|
||||
:caption: example verilog for demonstrating `opt_muxtree`
|
||||
|
||||
The output can never be ``c``, as this would require ``a`` to be 1 for the outer
|
||||
multiplexer and 0 for the inner multiplexer. The :cmd:ref:`opt_muxtree` pass
|
||||
multiplexer and 0 for the inner multiplexer. The `opt_muxtree` pass
|
||||
detects this contradiction and replaces the inner multiplexer with a constant 1,
|
||||
yielding the logic for ``y = a ? b : d``.
|
||||
|
||||
.. figure:: /_images/code_examples/opt/opt_muxtree.*
|
||||
:class: width-helper invert-helper
|
||||
|
||||
Before and after :cmd:ref:`opt_muxtree`
|
||||
Before and after `opt_muxtree`
|
||||
|
||||
Simplifying large MUXes and AND/OR gates - :cmd:ref:`opt_reduce`
|
||||
Simplifying large MUXes and AND/OR gates - `opt_reduce`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This is a simple optimization pass that identifies and consolidates identical
|
||||
|
|
@ -155,7 +155,7 @@ Lastly this pass consolidates trees of `$reduce_and` cells and trees of
|
|||
These three simple optimizations are performed in a loop until a stable result
|
||||
is produced.
|
||||
|
||||
Merging mutually exclusive cells with shared inputs - :cmd:ref:`opt_share`
|
||||
Merging mutually exclusive cells with shared inputs - `opt_share`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This pass identifies mutually exclusive cells of the same type that:
|
||||
|
|
@ -169,17 +169,17 @@ multiplexing its output to multiplexing the non-shared input signals.
|
|||
:language: Verilog
|
||||
:start-after: read_verilog <<EOT
|
||||
:end-before: EOT
|
||||
:caption: example verilog for demonstrating :cmd:ref:`opt_share`
|
||||
:caption: example verilog for demonstrating `opt_share`
|
||||
|
||||
.. figure:: /_images/code_examples/opt/opt_share.*
|
||||
:class: width-helper invert-helper
|
||||
|
||||
Before and after :cmd:ref:`opt_share`
|
||||
Before and after `opt_share`
|
||||
|
||||
When running :cmd:ref:`opt` in full, the original `$mux` (labeled ``$3``) is
|
||||
optimized away by :cmd:ref:`opt_expr`.
|
||||
When running `opt` in full, the original `$mux` (labeled ``$3``) is
|
||||
optimized away by `opt_expr`.
|
||||
|
||||
Performing DFF optimizations - :cmd:ref:`opt_dff`
|
||||
Performing DFF optimizations - `opt_dff`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This pass identifies single-bit d-type flip-flops (`$_DFF_`, `$dff`, and
|
||||
|
|
@ -190,30 +190,30 @@ removing unused control inputs.
|
|||
Called with ``-nodffe`` and ``-nosdff``, this pass is used to prepare a design
|
||||
for :doc:`/using_yosys/synthesis/fsm`.
|
||||
|
||||
Removing unused cells and wires - :cmd:ref:`opt_clean` pass
|
||||
Removing unused cells and wires - `opt_clean` pass
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This pass identifies unused signals and cells and removes them from the design.
|
||||
It also creates an ``\unused_bits`` attribute on wires with unused bits. This
|
||||
attribute can be used for debugging or by other optimization passes.
|
||||
|
||||
When to use :cmd:ref:`opt` or :cmd:ref:`clean`
|
||||
When to use `opt` or `clean`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Usually it does not hurt to call :cmd:ref:`opt` after each regular command in
|
||||
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 :cmd:ref:`opt` when an improvement can be achieved.
|
||||
to only call `opt` when an improvement can be achieved.
|
||||
|
||||
It is generally 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
|
||||
It is generally a good idea to call `opt` before inherently expensive
|
||||
commands such as `sat` or `freduce`, as the possible gain is
|
||||
much higher in these cases as the possible loss.
|
||||
|
||||
The :cmd:ref:`clean` command, which is an alias for :cmd:ref:`opt_clean` with
|
||||
The `clean` command, which is an alias for `opt_clean` with
|
||||
fewer outputs, 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 ``;;``, which itself is
|
||||
an alias for :cmd:ref:`clean`, is a good idea in every synthesis script, e.g:
|
||||
an alias for `clean`, is a good idea in every synthesis script, e.g:
|
||||
|
||||
.. code-block:: yoscrypt
|
||||
|
||||
|
|
@ -227,4 +227,4 @@ Other optimizations
|
|||
- :doc:`/cmd/wreduce`
|
||||
- :doc:`/cmd/peepopt`
|
||||
- :doc:`/cmd/share`
|
||||
- :cmd:ref:`abc` and :cmd:ref:`abc9`, see also: :doc:`abc`.
|
||||
- `abc` and `abc9`, see also: :doc:`abc`.
|
||||
|
|
|
|||
|
|
@ -6,21 +6,21 @@ Converting process blocks
|
|||
|
||||
The Verilog frontend converts ``always``-blocks to RTL netlists for the
|
||||
expressions and "processess" for the control- and memory elements. The
|
||||
:cmd:ref:`proc` command then transforms these "processess" to netlists of RTL
|
||||
`proc` command then transforms these "processess" to netlists of RTL
|
||||
multiplexer and register cells. It also is a macro command that calls the other
|
||||
``proc_*`` commands in a sensible order:
|
||||
|
||||
.. literalinclude:: /code_examples/macro_commands/proc.ys
|
||||
:language: yoscrypt
|
||||
:start-after: #end:
|
||||
:caption: Passes called by :cmd:ref:`proc`
|
||||
:caption: Passes called by `proc`
|
||||
|
||||
After all the ``proc_*`` commands, :cmd:ref:`opt_expr` is called. This can be
|
||||
After all the ``proc_*`` commands, `opt_expr` is called. This can be
|
||||
disabled by calling :yoscrypt:`proc -noopt`. For more information about
|
||||
:cmd:ref:`proc`, such as disabling certain sub commands, see :doc:`/cmd/proc`.
|
||||
`proc`, such as disabling certain sub commands, see :doc:`/cmd/proc`.
|
||||
|
||||
Many commands can not operate on modules with "processess" in them. Usually a
|
||||
call to :cmd:ref:`proc` is the first command in the actual synthesis procedure
|
||||
call to `proc` is the first command in the actual synthesis procedure
|
||||
after design elaboration.
|
||||
|
||||
Example
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ In addition to the above hardware-specific synth commands, there is also
|
|||
getting into any architecture-specific mappings or optimizations. Among other
|
||||
things, this is useful for design verification.
|
||||
|
||||
The following commands are executed by the :cmd:ref:`prep` command:
|
||||
The following commands are executed by the `prep` command:
|
||||
|
||||
.. literalinclude:: /cmd/prep.rst
|
||||
:start-at: begin:
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue