mirror of
https://github.com/YosysHQ/yosys
synced 2025-06-06 14:13:23 +00:00
Removing typical phases doc
Moved remaining content into relevant places. Added `load_design.rst` to more scripting. Split fsm handling and abc out of optimization passes. Also moved things around to match the general flow previously described. Changed generic `synth` for `prep` instead.
This commit is contained in:
Krystine Sherwin
parent
f9ce3d1c26
commit
1e3b90ae56
11 changed files with 568 additions and 666 deletions
|
|
@ -1,17 +1,35 @@
|
|||
Synthesis starter
|
||||
-----------------
|
||||
|
||||
..
|
||||
Typical phases of a synthesis flow are as follows:
|
||||
|
||||
- Reading and elaborating the design
|
||||
- Higher-level synthesis and optimization
|
||||
|
||||
- Converting ``always``-blocks to logic and registers
|
||||
- Perform coarse-grain optimizations (resource sharing, const folding, ...)
|
||||
- Handling of memories and other coarse-grain blocks
|
||||
- Extracting and optimizing finite state machines
|
||||
|
||||
- Convert remaining logic to bit-level logic functions
|
||||
- Perform optimizations on bit-level logic functions
|
||||
- Map bit-level logic gates and registers to cell library
|
||||
- Write results to output file
|
||||
|
||||
A simple counter
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
.. role:: yoscrypt(code)
|
||||
:language: yoscrypt
|
||||
|
||||
This section covers an example project available in
|
||||
``docs/source/code_examples/intro/*``. The project contains a simple ASIC
|
||||
This section covers an `example project`_ available in
|
||||
``docs/source/code_examples/intro/``. The project contains a simple ASIC
|
||||
synthesis script (``counter.ys``), a digital design written in Verilog
|
||||
(``counter.v``), and a simple CMOS cell library (``mycells.lib``).
|
||||
|
||||
.. _example project: https://github.com/YosysHQ/yosys/tree/krys/docs/docs/source/code_examples/intro
|
||||
|
||||
First, let's quickly look at the design:
|
||||
|
||||
.. literalinclude:: /code_examples/intro/counter.v
|
||||
|
|
@ -159,20 +177,27 @@ Some of the commands we might use here are:
|
|||
- :doc:`/cmd/memory`,
|
||||
- :doc:`/cmd/wreduce`,
|
||||
- :doc:`/cmd/peepopt`,
|
||||
- :doc:`/cmd/pmuxtree`,
|
||||
- :doc:`/cmd/alumacc`, and
|
||||
- :doc:`/cmd/share`.
|
||||
|
||||
Techmap
|
||||
~~~~~~~
|
||||
We could have also
|
||||
|
||||
Logic gate mapping
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
:yoscrypt:`techmap` - Map coarse-grain RTL cells (adders, etc.) to fine-grain
|
||||
logic gates (AND, OR, NOT, etc.).
|
||||
|
||||
.. literalinclude:: /code_examples/intro/counter.ys
|
||||
:language: yoscrypt
|
||||
:lines: 8-9
|
||||
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.
|
||||
|
||||
Result:
|
||||
The built-in logic gate types are: ``$_NOT_``, ``$_AND_``, ``$_OR_``,
|
||||
``$_XOR_``, and ``$_MUX_``.
|
||||
|
||||
See :doc:`/yosys_internals/formats/cell_library` for more about the internal
|
||||
cells used.
|
||||
|
||||
.. figure:: /_images/code_examples/intro/counter_02.*
|
||||
:class: width-helper
|
||||
|
|
@ -193,6 +218,22 @@ Mapping to hardware
|
|||
|
||||
``counter`` after hardware cell mapping
|
||||
|
||||
:cmd:ref:`dfflibmap`
|
||||
This command maps the internal register cell types to the register types
|
||||
described in a liberty file.
|
||||
|
||||
: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.
|
||||
|
||||
:cmd:ref:`iopadmap`
|
||||
Top-level input/outputs must usually be implemented using special I/O-pad
|
||||
cells. This command inserts such cells to the design.
|
||||
|
||||
:cmd:ref:`dfflegalize`
|
||||
Specify a set of supported FF cells/cell groups and convert all FFs to them.
|
||||
|
||||
.. _cmos_lib:
|
||||
|
||||
The CMOS cell library
|
||||
|
|
@ -215,3 +256,4 @@ The script file
|
|||
:language: yoscrypt
|
||||
:caption: ``docs/source/code_examples/intro/counter.ys``
|
||||
|
||||
See also :doc:`/using_yosys/synthesis/synth`.
|
||||
|
|
|
|||
|
|
@ -1,457 +0,0 @@
|
|||
Typical phases of a synthesis flow
|
||||
----------------------------------
|
||||
|
||||
.. role:: yoscrypt(code)
|
||||
:language: yoscrypt
|
||||
|
||||
.. todo:: should e.g. :yoscrypt:`proc` and :yoscrypt:`memory` examples be
|
||||
included here (typical phases) or examples
|
||||
|
||||
.. todo:: expand bullet points
|
||||
|
||||
- Reading and elaborating the design
|
||||
- Higher-level synthesis and optimization
|
||||
|
||||
- Converting ``always``-blocks to logic and registers
|
||||
- Perform coarse-grain optimizations (resource sharing, const folding, ...)
|
||||
- Handling of memories and other coarse-grain blocks
|
||||
- Extracting and optimizing finite state machines
|
||||
|
||||
- Convert remaining logic to bit-level logic functions
|
||||
- Perform optimizations on bit-level logic functions
|
||||
- Map bit-level logic gates and registers to cell library
|
||||
- Write results to output file
|
||||
|
||||
Reading the design
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. todo:: include ``read_verilog <<EOF`` when discussing how to read designs?
|
||||
|
||||
.. code-block:: yoscrypt
|
||||
|
||||
read_verilog file1.v
|
||||
read_verilog -I include_dir -D enable_foo -D WIDTH=12 file2.v
|
||||
read_verilog -lib cell_library.v
|
||||
|
||||
verilog_defaults -add -I include_dir
|
||||
read_verilog file3.v
|
||||
read_verilog file4.v
|
||||
verilog_defaults -clear
|
||||
|
||||
verilog_defaults -push
|
||||
verilog_defaults -add -I include_dir
|
||||
read_verilog file5.v
|
||||
read_verilog file6.v
|
||||
verilog_defaults -pop
|
||||
|
||||
|
||||
Design elaboration
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
During design elaboration Yosys figures out how the modules are hierarchically
|
||||
connected. It also re-runs the AST parts of the Verilog frontend to create all
|
||||
needed variations of parametric modules.
|
||||
|
||||
.. todo:: hierarchy without ``-top`` is bad
|
||||
- resolve non-module-specific references (sub modules, interfaces et al)
|
||||
- check sub modules exist, discarding unused
|
||||
- set top attribute
|
||||
- also mention failure modes
|
||||
- also prep?
|
||||
|
||||
.. code-block:: yoscrypt
|
||||
|
||||
# simplest form. at least this version should be used after reading all input files
|
||||
#
|
||||
hierarchy
|
||||
|
||||
# recommended form. fails if parts of the design hierarchy are missing, removes
|
||||
# everything that is unreachable from the top module, and marks the top module.
|
||||
#
|
||||
hierarchy -check -top top_module
|
||||
|
||||
|
||||
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
|
||||
multiplexer and register cells. It also is a macro command that calls the other
|
||||
``proc_*`` commands in a sensible order:
|
||||
|
||||
#. :cmd:ref:`proc_clean` removes empty branches and processes.
|
||||
#. :cmd:ref:`proc_rmdead` removes unreachable branches.
|
||||
#. :cmd:ref:`proc_prune`
|
||||
#. :cmd:ref:`proc_init` special handling of "initial" blocks.
|
||||
#. :cmd:ref:`proc_arst` identifies modeling of async resets.
|
||||
#. :cmd:ref:`proc_rom`
|
||||
#. :cmd:ref:`proc_mux` converts decision trees to multiplexer networks.
|
||||
#. :cmd:ref:`proc_dlatch`
|
||||
#. :cmd:ref:`proc_dff` extracts registers from processes.
|
||||
#. :cmd:ref:`proc_memwr`
|
||||
#. :cmd:ref:`proc_clean` this should remove all the processes, provided all went
|
||||
fine.
|
||||
|
||||
After all the ``proc_*`` commands, :yoscrypt:`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`.
|
||||
|
||||
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
|
||||
after design elaboration.
|
||||
|
||||
Example
|
||||
^^^^^^^
|
||||
|
||||
.. todo:: describe ``proc`` images
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/proc_01.v
|
||||
:language: verilog
|
||||
:caption: ``docs/source/code_examples/synth_flow/proc_01.v``
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/proc_01.ys
|
||||
:language: yoscrypt
|
||||
:caption: ``docs/source/code_examples/synth_flow/proc_01.ys``
|
||||
|
||||
.. figure:: /_images/code_examples/synth_flow/proc_01.*
|
||||
:class: width-helper
|
||||
|
||||
.. figure:: /_images/code_examples/synth_flow/proc_02.*
|
||||
:class: width-helper
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/proc_02.v
|
||||
:language: verilog
|
||||
:caption: ``docs/source/code_examples/synth_flow/proc_02.v``
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/proc_02.ys
|
||||
:language: yoscrypt
|
||||
:caption: ``docs/source/code_examples/synth_flow/proc_02.ys``
|
||||
|
||||
.. figure:: /_images/code_examples/synth_flow/proc_03.*
|
||||
:class: width-helper
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/proc_03.ys
|
||||
:language: yoscrypt
|
||||
:caption: ``docs/source/code_examples/synth_flow/proc_03.ys``
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/proc_03.v
|
||||
:language: verilog
|
||||
:caption: ``docs/source/code_examples/synth_flow/proc_03.v``
|
||||
|
||||
|
||||
Optimizations
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
The :cmd:ref:`opt` command implements a series of simple optimizations. It also
|
||||
is a macro command that calls other commands:
|
||||
|
||||
.. code-block:: yoscrypt
|
||||
|
||||
opt_expr # const folding and simple expression rewriting
|
||||
opt_merge -nomux # merging identical cells
|
||||
|
||||
do
|
||||
opt_muxtree # remove never-active branches from multiplexer tree
|
||||
opt_reduce # consolidate trees of boolean ops to reduce functions
|
||||
opt_merge # merging identical cells
|
||||
opt_rmdff # remove/simplify registers with constant inputs
|
||||
opt_clean # remove unused objects (cells, wires) from design
|
||||
opt_expr # const folding and simple expression rewriting
|
||||
while [changed design]
|
||||
|
||||
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
|
||||
|
||||
hierarchy; proc; opt; memory; opt_expr;; fsm;;
|
||||
|
||||
Example
|
||||
^^^^^^^
|
||||
|
||||
.. todo:: describe ``opt`` images
|
||||
|
||||
.. figure:: /_images/code_examples/synth_flow/opt_01.*
|
||||
:class: width-helper
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/opt_01.ys
|
||||
:language: yoscrypt
|
||||
:caption: ``docs/source/code_examples/synth_flow/opt_01.ys``
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/opt_01.v
|
||||
:language: verilog
|
||||
:caption: ``docs/source/code_examples/synth_flow/opt_01.v``
|
||||
|
||||
.. figure:: /_images/code_examples/synth_flow/opt_02.*
|
||||
:class: width-helper
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/opt_02.ys
|
||||
:language: yoscrypt
|
||||
:caption: ``docs/source/code_examples/synth_flow/opt_02.ys``
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/opt_02.v
|
||||
:language: verilog
|
||||
:caption: ``docs/source/code_examples/synth_flow/opt_02.v``
|
||||
|
||||
.. figure:: /_images/code_examples/synth_flow/opt_03.*
|
||||
:class: width-helper
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/opt_03.ys
|
||||
:language: yoscrypt
|
||||
:caption: ``docs/source/code_examples/synth_flow/opt_03.ys``
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/opt_03.v
|
||||
:language: verilog
|
||||
:caption: ``docs/source/code_examples/synth_flow/opt_03.v``
|
||||
|
||||
.. figure:: /_images/code_examples/synth_flow/opt_04.*
|
||||
:class: width-helper
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/opt_04.v
|
||||
:language: verilog
|
||||
:caption: ``docs/source/code_examples/synth_flow/opt_04.v``
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/opt_04.ys
|
||||
:language: yoscrypt
|
||||
:caption: ``docs/source/code_examples/synth_flow/opt_04.ys``
|
||||
|
||||
When to use :cmd:ref:`opt` or :cmd:ref:`clean`
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
much higher in these cases as the possible loss.
|
||||
|
||||
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.
|
||||
|
||||
Other common optimization commands
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. todo:: fill out descriptions for other optimization commands
|
||||
|
||||
:cmd:ref:`wreduce`
|
||||
Reduces the word size of operations.
|
||||
|
||||
:cmd:ref:`peepopt`
|
||||
Applies a collection of peephole optimizers to the current design.
|
||||
|
||||
:cmd:ref:`share`
|
||||
Merges shareable resources into a single resource using a SAT solver to
|
||||
determine if two resources are shareable.
|
||||
|
||||
Memory handling
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
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`
|
||||
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
|
||||
``memory_*`` commands in a sensible order:
|
||||
|
||||
.. todo:: fill out missing :cmd:ref:`memory` subcommands descriptions
|
||||
|
||||
#. :cmd:ref:`memory_bmux2rom`
|
||||
#. :cmd:ref:`memory_dff` merges registers into the memory read- and write cells.
|
||||
#. :cmd:ref:`memory_share`
|
||||
#. :cmd:ref:`memory_memx`
|
||||
#. :cmd:ref:`memory_collect` collects all read and write cells for a memory and
|
||||
transforms them into one multi-port memory cell.
|
||||
#. :cmd:ref:`memory_bram`
|
||||
#. :cmd:ref:`memory_map` takes the multi-port memory cell and transforms it to
|
||||
address decoder logic and registers.
|
||||
|
||||
.. todo:: is :yoscrypt:`memory -nomap; techmap -map my_memory_map.v; memory_map`
|
||||
superceded by :yoscrypt:`memory_libmap`?
|
||||
|
||||
Usually it is preferred to use architecture-specific RAM resources for memory.
|
||||
For example:
|
||||
|
||||
.. code-block:: yoscrypt
|
||||
|
||||
memory -nomap; techmap -map my_memory_map.v; memory_map
|
||||
|
||||
For more information about :cmd:ref:`memory`, such as disabling certain sub
|
||||
commands, see :doc:`/cmd/memory`.
|
||||
|
||||
Example
|
||||
^^^^^^^
|
||||
|
||||
.. todo:: describe ``memory`` images
|
||||
|
||||
.. figure:: /_images/code_examples/synth_flow/memory_01.*
|
||||
:class: width-helper
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/memory_01.ys
|
||||
:language: yoscrypt
|
||||
:caption: ``docs/source/code_examples/synth_flow/memory_01.ys``
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/memory_01.v
|
||||
:language: verilog
|
||||
:caption: ``docs/source/code_examples/synth_flow/memory_01.v``
|
||||
|
||||
.. figure:: /_images/code_examples/synth_flow/memory_02.*
|
||||
:class: width-helper
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/memory_02.v
|
||||
:language: verilog
|
||||
:caption: ``docs/source/code_examples/synth_flow/memory_02.v``
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/memory_02.ys
|
||||
:language: yoscrypt
|
||||
:caption: ``docs/source/code_examples/synth_flow/memory_02.ys``
|
||||
|
||||
The :cmd:ref:`memory_libmap` command
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. todo:: :cmd:ref:`memory_libmap` description
|
||||
|
||||
FSM handling
|
||||
~~~~~~~~~~~~
|
||||
|
||||
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:
|
||||
|
||||
#. :cmd:ref:`fsm_detect` 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.
|
||||
#. :cmd:ref:`fsm_extract` replaces the entire FSM (logic and state registers)
|
||||
with a ``$fsm`` cell.
|
||||
#. :cmd:ref:`fsm_opt` optimizes the FSM. Called multiple times.
|
||||
#. :cmd:ref:`fsm_expand` optionally merges additional auxilliary gates into the
|
||||
``$fsm`` cell.
|
||||
#. :cmd:ref:`fsm_recode` also optimizes the FSM.
|
||||
#. :cmd:ref:`fsm_info` logs internal FSM information.
|
||||
#. :cmd:ref:`fsm_export` optionally exports each FSM to KISS2 files.
|
||||
#. :cmd:ref:`fsm_map` converts the (optimized) ``$fsm`` cell back to logic and
|
||||
registers.
|
||||
|
||||
See also :doc:`/cmd/fsm`.
|
||||
|
||||
DSP handling
|
||||
~~~~~~~~~~~~
|
||||
|
||||
.. todo:: add info about dsp handling
|
||||
|
||||
Technology mapping
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The :cmd:ref:`techmap` command replaces cells with implementations given as
|
||||
verilog source. For example implementing a 32 bit adder using 16 bit adders:
|
||||
|
||||
.. figure:: /_images/code_examples/synth_flow/techmap_01.*
|
||||
:class: width-helper
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/techmap_01_map.v
|
||||
:language: verilog
|
||||
:caption: ``docs/source/code_examples/synth_flow/techmap_01_map.v``
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/techmap_01.v
|
||||
:language: verilog
|
||||
:caption: ``docs/source/code_examples/synth_flow/techmap_01.v``
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/techmap_01.ys
|
||||
:language: yoscrypt
|
||||
:caption: ``docs/source/code_examples/synth_flow/techmap_01.ys``
|
||||
|
||||
See :doc:`/yosys_internals/techmap` for more.
|
||||
|
||||
stdcell mapping
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
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_``.
|
||||
|
||||
The register types are: ``$_SR_NN_``, ``$_SR_NP_``, ``$_SR_PN_``, ``$_SR_PP_``,
|
||||
``$_DFF_N_``, ``$_DFF_P_ $_DFF_NN0_``, ``$_DFF_NN1_``, ``$_DFF_NP0_``,
|
||||
``$_DFF_NP1_``, ``$_DFF_PN0_``, ``$_DFF_PN1_``, ``$_DFF_PP0_ $_DFF_PP1_``,
|
||||
``$_DFFSR_NNN_``, ``$_DFFSR_NNP_``, ``$_DFFSR_NPN_``, ``$_DFFSR_NPP_``,
|
||||
``$_DFFSR_PNN_ $_DFFSR_PNP_``, ``$_DFFSR_PPN_``, ``$_DFFSR_PPP_``,
|
||||
``$_DLATCH_N_``, and ``$_DLATCH_P_``.
|
||||
|
||||
See :doc:`/yosys_internals/formats/cell_library` for more about the internal
|
||||
cells used.
|
||||
|
||||
The :cmd:ref:`abc` command
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
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 :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 :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
|
||||
:cmd:ref:`write_blif` and load the output file into ABC outside of Yosys.
|
||||
|
||||
Example
|
||||
^^^^^^^
|
||||
|
||||
.. todo:: describe ``abc`` images
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/abc_01.v
|
||||
:language: verilog
|
||||
:caption: ``docs/source/code_examples/synth_flow/abc_01.v``
|
||||
|
||||
.. literalinclude:: /code_examples/synth_flow/abc_01.ys
|
||||
:language: yoscrypt
|
||||
:caption: ``docs/source/code_examples/synth_flow/abc_01.ys``
|
||||
|
||||
.. figure:: /_images/code_examples/synth_flow/abc_01.*
|
||||
:class: width-helper
|
||||
|
||||
Other special-purpose mapping commands
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The commands below may be used depending on the targeted architecture for
|
||||
compatibility with, or to take advantage of, resources available.
|
||||
|
||||
:cmd:ref:`dfflibmap`
|
||||
This command maps the internal register cell types to the register types
|
||||
described in a liberty file.
|
||||
|
||||
: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.
|
||||
|
||||
:cmd:ref:`iopadmap`
|
||||
Top-level input/outputs must usually be implemented using special I/O-pad
|
||||
cells. This command inserts such cells to the design.
|
||||
|
||||
:cmd:ref:`alumacc`
|
||||
Translate arithmetic operations like $add, $mul, $lt, etc. to $alu and $macc
|
||||
cells.
|
||||
|
||||
:cmd:ref:`dfflegalize`
|
||||
Specify a set of supported FF cells/cell groups and convert all FFs to them.
|
||||
|
||||
:cmd:ref:`deminout`
|
||||
Convert inout ports to input or output ports, if possible.
|
||||
|
||||
:cmd:ref:`pmuxtree`
|
||||
Transforms parallel mux cells, ``$pmux``, to trees of ``$mux`` cells.
|
||||
Loading…
Add table
Add a link
Reference in a new issue