yosys/docs/source/getting_started/example_synth.rst

Synthesis starter
-----------------

This page will be a guided walkthrough of the prepackaged iCE40 FPGA synthesis
script - :cmd:ref:`synth_ice40`.  We will take a simple design through each
step, looking at the commands being called and what they do to the design. While
:cmd:ref:`synth_ice40` is specific to the iCE40 platform, most of the operations
we will be discussing are common across the majority of FPGA synthesis scripts.
Thus, this document will provide a good foundational understanding of how
synthesis in Yosys is performed, regardless of the actual architecture being
used.

.. seealso:: Advanced usage docs for
   :doc:`/using_yosys/synthesis/synth`

Demo design
~~~~~~~~~~~

.. role:: yoscrypt(code)
   :language: yoscrypt

First, let's quickly look at the design we'll be synthesizing:

.. todo:: reconsider including the whole (~77 line) design like this

.. literalinclude:: /code_examples/fifo/fifo.v
   :language: Verilog
   :linenos:
   :caption: ``fifo.v``
   :name: fifo-v

.. todo:: fifo.v description

Loading the design
~~~~~~~~~~~~~~~~~~

Let's load the design into Yosys.  From the command line, we can call ``yosys
fifo.v``.  This will open an interactive Yosys shell session and immediately
parse the code from ``fifo.v`` and convert it into an Abstract Syntax Tree
(AST).  If you are interested in how this happens, there is more information in
the document, :doc:`/yosys_internals/flow/verilog_frontend`.  For now, suffice
it to say that we do this to simplify further processing of the design.  You
should see something like the following:

.. literalinclude:: /code_examples/fifo/fifo.out
   :language: console
   :start-at: $ yosys fifo.v
   :end-before: echo on

.. seealso:: Advanced usage docs for
   :doc:`/using_yosys/more_scripting/load_design`

Elaboration
~~~~~~~~~~~

Now that we are in the interactive shell, we can call Yosys commands directly.
Our overall goal is to call :yoscrypt:`synth_ice40 -top fifo`, but for now we
can run each of the commands individually for a better sense of how each part
contributes to the flow.  We will also start with just a single module;
``addr_gen``.

At the bottom of the :cmd:ref:`help` output for
:cmd:ref:`synth_ice40` is the complete list of commands called by this script.
Let's start with the section labeled ``begin``:

.. literalinclude:: /cmd/synth_ice40.rst
   :language: yoscrypt
   :start-after: begin:
   :end-before: flatten:
   :dedent:
   :caption: ``begin`` section
   :name: synth_begin

:yoscrypt:`read_verilog -D ICE40_HX -lib -specify +/ice40/cells_sim.v` loads the
iCE40 cell models which allows us to include platform specific IP blocks in our
design.  PLLs are a common example of this, where we might need to reference
``SB_PLL40_CORE`` directly rather than being able to rely on mapping passes
later.  Since our simple design doesn't use any of these IP blocks, we can safely
skip this command.

The addr_gen module
^^^^^^^^^^^^^^^^^^^

Since we're just getting started, let's instead begin with :yoscrypt:`hierarchy
-top addr_gen`.  This command declares that the top level module is ``addr_gen``,
and everything else can be discarded.

.. literalinclude:: /code_examples/fifo/fifo.v
   :language: Verilog
   :start-at: module addr_gen
   :end-at: endmodule //addr_gen
   :lineno-match:
   :caption: ``addr_gen`` module source
   :name: addr_gen-v

.. note::

   :cmd:ref:`hierarchy` should always be the first command after the design has
   been read.

.. use doscon for a console-like display that supports the `yosys> [command]` format.

.. literalinclude:: /code_examples/fifo/fifo.out
   :language: doscon
   :start-at: yosys> hierarchy -top addr_gen
   :end-before: yosys> select
   :caption: :yoscrypt:`hierarchy -top addr_gen` output

Our ``addr_gen`` circuit now looks like this:

.. figure:: /_images/code_examples/fifo/addr_gen_hier.*
   :class: width-helper
   :name: addr_gen_hier

   ``addr_gen`` module after :cmd:ref:`hierarchy`

.. todo:: how to highlight PROC blocks? 
   They seem to be replaced in ``show``, so the selection never matches

Simple operations like ``addr + 1`` and ``addr == MAX_DATA-1`` can be extracted
from our ``always @`` block in :ref:`addr_gen-v`. This gives us the highlighted
``$add`` and ``$eq`` cells we see. But control logic (like the ``if .. else``)
and memory elements (like the ``addr <= 0``) are not so straightforward.  These
get put into "processes", shown in the schematic as ``PROC``.  Note how the
second line refers to the line numbers of the start/end of the corresponding
``always @`` block.  In the case of an ``initial`` block, we instead see the
``PROC`` referring to line 0.

To handle these, let us now introduce the next command: :doc:`/cmd/proc`.
:cmd:ref:`proc` is a macro command like :cmd:ref:`synth_ice40`.  Rather than
modifying the design directly, it instead calls a series of other commands.  In
the case of :cmd:ref:`proc`, these sub-commands work to convert the behavioral
logic of processes into multiplexers and registers.  Let's see what happens when
we run it.

.. figure:: /_images/code_examples/fifo/addr_gen_proc.*
   :class: width-helper
   :name: addr_gen_proc

   ``addr_gen`` module after :cmd:ref:`proc`

There are now a few new cells from our ``always @``, which have been
highlighted.  The ``if`` statements are now modeled with ``$mux`` cells, while
the register uses an ``$adff`` cell.  If we look at the terminal output we can
also see all of the different ``proc_*`` commands being called.  We will look at
each of these in more detail in :doc:`/using_yosys/synthesis/proc`.

.. TODO:: intro ``opt_expr``
   :doc:`/cmd/opt_expr`

   - by default called at the end of :cmd:ref:`proc`
   - can be disabled with ``-noopt``
   - done here for... reasons?

Notice how in the top left of :ref:`addr_gen_proc` we have a floating wire,
generated from the initial assignment of 0 to the ``addr`` wire.  However, this
initial assignment is not synthesizable, so this will need to be cleaned up
before we can generate the physical hardware.  We can do this now by calling
:cmd:ref:`clean`:

.. figure:: /_images/code_examples/fifo/addr_gen_clean.*
   :class: width-helper
   :name: addr_gen_clean

   ``addr_gen`` module after :cmd:ref:`clean`

.. note::

   :doc:`/cmd/clean` can also be called with two semicolons after any command,
   for example we could have called :yoscrypt:`proc;;` instead of
   :yoscrypt:`proc` and then :yoscrypt:`clean`.  It is generally beneficial to
   run :cmd:ref:`clean` after each command as a quick way of removing
   disconnected parts of the circuit which have been left over.  You may notice
   some scripts will end each line with ``;;``.

.. todo:: consider a brief glossary for terms like adff

The full example
^^^^^^^^^^^^^^^^

Let's now go back and check on our full design by using :yoscrypt:`hierarchy
-check -top fifo`.  By passing the ``-check`` option there we are also
telling the :cmd:ref:`hierarchy` command that if the design includes any
non-blackbox modules without an implementation it should return an error.

Note that if we tried to run this command now then we would get an error.  This
is because we already removed all of the modules other than ``addr_gen``.  We
could restart our shell session, but instead let's use two new commands:

- :doc:`/cmd/design`, and
- :doc:`/cmd/read_verilog`.

.. literalinclude:: /code_examples/fifo/fifo.out
   :language: doscon
   :start-at: design -reset
   :end-before: yosys> proc
   :caption: reloading ``fifo.v`` and running :yoscrypt:`hierarchy -check -top fifo`

Notice how this time we didn't see any of those `$abstract` modules?  That's
because when we ran ``yosys fifo.v``, the first command Yosys called was
:yoscrypt:`read_verilog -defer fifo.v`.  The ``-defer`` option there tells
:cmd:ref:`read_verilog` only read the abstract syntax tree and defer actual
compilation to a later :cmd:ref:`hierarchy` command. This is useful in cases
where the default parameters of modules yield invalid code which is not
synthesizable. This is why Yosys defers compilation automatically and is one of
the reasons why hierarchy should always be the first command after loading the
design.  If we know that our design won't run into this issue, we can skip the
``-defer``.

.. TODO:: more on why :cmd:ref:`hierarchy` is important

.. note::

   The number before a command's output increments with each command run.  Don't
   worry if your numbers don't match ours!  The output you are seeing comes from
   the same script that was used to generate the images in this document,
   included in the source as ``fifo.ys``. There are extra commands being run
   which you don't see, but feel free to try them yourself, or play around with
   different commands.  You can always start over with a clean slate by calling
   ``exit`` or hitting ``ctrl+c`` (i.e. SIGINT) and re-launching the Yosys
   interactive terminal.

We can also run :cmd:ref:`proc` now to finish off the full :ref:`synth_begin`.
Because the design schematic is quite large, we will be showing just the data
path for the ``rdata`` output.  If you would like to see the entire design for
yourself, you can do so with :doc:`/cmd/show`.  Note that the :cmd:ref:`show`
command only works with a single module, so you may need to call it with
:yoscrypt:`show fifo`.

.. figure:: /_images/code_examples/fifo/rdata_proc.*
   :class: width-helper
   :name: rdata_proc

   ``rdata`` output after :cmd:ref:`proc`

The highlighted ``fifo_reader`` block contains an instance of the
:ref:`addr_gen_proc` that we looked at earlier.  Notice how the type is shown as
``$paramod\\addr_gen\\MAX_DATA=s32'...``.  This is a "parametric module": an
instance of the ``addr_gen`` module with the ``MAX_DATA`` parameter set to the
given value.

The other highlighted block is a ``$memrd`` cell.  At this stage of synthesis we
don't yet know what type of memory is going to be implemented, but we *do* know
that ``rdata <= data[raddr];`` could be implemented as a read from memory. Note
that the ``$memrd`` cell here is asynchronous, with both the clock and enable
signal undefined; shown with the ``1'x`` inputs.

.. seealso:: Advanced usage docs for
   :doc:`/using_yosys/synthesis/proc`

Flattening
~~~~~~~~~~

At this stage of a synthesis flow there are a few other commands we could run.
In :cmd:ref:`synth_ice40` we get these:

.. literalinclude:: /cmd/synth_ice40.rst
   :language: yoscrypt
   :start-after: flatten:
   :end-before: coarse:
   :dedent:
   :name: synth_flatten
   :caption: ``flatten`` section

First off is :cmd:ref:`flatten`.  Flattening the design like this can allow for
optimizations between modules which would otherwise be missed.  Let's run
:yoscrypt:`flatten;;` on our design.

.. literalinclude:: /code_examples/fifo/fifo.out
   :language: doscon
   :start-at: yosys> flatten
   :end-before: yosys> select
   :name: flat_clean
   :caption: output of :yoscrypt:`flatten;;`

.. figure:: /_images/code_examples/fifo/rdata_flat.*
   :class: width-helper
   :name: rdata_flat

   ``rdata`` output after :yoscrypt:`flatten;;`

.. role:: yoterm(code)
   :language: doscon

The pieces have moved around a bit, but we can see :ref:`addr_gen_proc` from
earlier has replaced the ``fifo_reader`` block in :ref:`rdata_proc`.  We can
also see that the ``addr`` output has been renamed to ``fifo_reader.addr`` and
merged with the ``raddr`` wire feeding into the ``$memrd`` cell.  This wire
merging happened during the call to :cmd:ref:`clean` which we can see in the
:ref:`flat_clean`.  Note that in an interactive terminal the outputs of
:cmd:ref:`flatten` and :cmd:ref:`clean` will be combined into a single
:yoterm:`yosys> flatten;;` output.

Depending on the target architecture, this stage of synthesis might also see
commands such as :cmd:ref:`tribuf` with the ``-logic`` option and
:cmd:ref:`deminout`.  These remove tristate and inout constructs respectively,
replacing them with logic suitable for mapping to an FPGA.  Since we do not have
any such constructs in our example running these commands does not change our
design.

The coarse-grain representation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

At this stage, the design is in coarse-grain representation.  It still looks
recognizable, and cells are word-level operators with parametrizable width. This
is the stage of synthesis where we do things like const propagation, expression
rewriting, and trimming unused parts of wires.

This is also where we convert our FSMs and hard blocks like DSPs or memories.
Such elements have to be inferred from patterns in the design and there are
special passes for each.  Detection of these patterns can also be affected by
optimizations and other transformations done previously.

.. note::

   While the iCE40 flow had a :ref:`synth_flatten` and put :cmd:ref:`proc` in
   the :ref:`synth_begin`, some synthesis scripts will instead include these in
   this section.

Part 1
^^^^^^

In the iCE40 flow, we start with the following commands:

.. literalinclude:: /cmd/synth_ice40.rst
   :language: yoscrypt
   :start-after: coarse:
   :end-before: wreduce
   :dedent:
   :caption: ``coarse`` section (part 1)
   :name: synth_coarse1

We've already come across :cmd:ref:`opt_expr`, and :cmd:ref:`opt_clean` is the
same as :cmd:ref:`clean` but with more verbose output.  The :cmd:ref:`check`
pass identifies a few obvious problems which will cause errors later.  Calling
it here lets us fail faster rather than wasting time on something we know is
impossible.

Next up is :yoscrypt:`opt -nodffe -nosdff` performing a set of simple
optimizations on the design.  This command also ensures that only a specific
subset of FF types are included, in preparation for the next command:
:doc:`/cmd/fsm`.  Both :cmd:ref:`opt` and :cmd:ref:`fsm` are macro commands
which are explored in more detail in :doc:`/using_yosys/synthesis/opt` and
:doc:`/using_yosys/synthesis/fsm` respectively.

Up until now, the data path for ``rdata`` has remained the same since
:ref:`rdata_flat`.  However the next call to :cmd:ref:`opt` does cause a change.
Specifically, the call to :cmd:ref:`opt_dff` without the ``-nodffe -nosdff``
options is able to fold one of the ``$mux`` cells into the ``$adff`` to form an
``$adffe`` cell; highlighted below:

.. literalinclude:: /code_examples/fifo/fifo.out
   :language: doscon
   :start-at: yosys> opt_dff
   :end-before: yosys> select
   :caption: output of :cmd:ref:`opt_dff`

.. figure:: /_images/code_examples/fifo/rdata_adffe.*
   :class: width-helper
   :name: rdata_adffe

   ``rdata`` output after :cmd:ref:`opt_dff`

.. seealso:: Advanced usage docs for
   
   - :doc:`/using_yosys/synthesis/fsm`
   - :doc:`/using_yosys/synthesis/opt`

Part 2
^^^^^^

The next group of commands performs a series of optimizations:

.. literalinclude:: /cmd/synth_ice40.rst
   :language: yoscrypt
   :start-at: wreduce
   :end-before: t:$mul
   :dedent:
   :caption: ``coarse`` section (part 2)
   :name: synth_coarse2

First up is :doc:`/cmd/wreduce`.  If we run this we get the following:

.. literalinclude:: /code_examples/fifo/fifo.out
   :language: doscon
   :start-at: yosys> wreduce
   :end-before: yosys> select
   :caption: output of :cmd:ref:`wreduce`

Looking at the data path for ``rdata``, the most relevant of these width
reductions are the ones affecting ``fifo.$flatten\fifo_reader.$add$fifo.v``.
That is the ``$add`` cell incrementing the fifo_reader address.  We can look at
the schematic and see the output of that cell has now changed.

.. TODO:: pending bugfix in :cmd:ref:`wreduce` and/or :cmd:ref:`opt_clean`

.. figure:: /_images/code_examples/fifo/rdata_wreduce.*
   :class: width-helper
   :name: rdata_wreduce

   ``rdata`` output after :cmd:ref:`wreduce`

The next two (new) commands are :doc:`/cmd/peepopt` and :doc:`/cmd/share`.
Neither of these affect our design, and they're explored in more detail in
:doc:`/using_yosys/synthesis/opt`, so let's skip over them.  :yoscrypt:`techmap
-map +/cmp2lut.v -D LUT_WIDTH=4` optimizes certain comparison operators by
converting them to LUTs instead.  The usage of :cmd:ref:`techmap` is explored
more in :doc:`/using_yosys/synthesis/techmap_synth`.

Our next command to run is
:doc:`/cmd/memory_dff`.

.. literalinclude:: /code_examples/fifo/fifo.out
   :language: doscon
   :start-at: yosys> memory_dff
   :end-before: yosys> select
   :caption: output of :cmd:ref:`memory_dff`

.. figure:: /_images/code_examples/fifo/rdata_memrdv2.*
   :class: width-helper
   :name: rdata_memrdv2

   ``rdata`` output after :cmd:ref:`memory_dff`

As the title suggests, :cmd:ref:`memory_dff` has merged the output ``$dff`` into
the ``$memrd`` cell and converted it to a ``$memrd_v2`` (highlighted).  This has
also connected the ``CLK`` port to the ``clk`` input as it is now a synchronous
memory read with appropriate enable (``EN=1'1``) and reset (``ARST=1'0`` and
``SRST=1'0``) inputs.

.. seealso:: Advanced usage docs for
   
   - :doc:`/using_yosys/synthesis/opt`
   - :doc:`/using_yosys/synthesis/techmap_synth`
   - :doc:`/using_yosys/synthesis/memory`

Part 3
^^^^^^

The third part of the :cmd:ref:`synth_ice40` flow is a series of commands for
mapping to DSPs.  By default, the iCE40 flow will not map to the hardware DSP
blocks and will only be performed if called with the ``-dsp`` flag:
:yoscrypt:`synth_ice40 -dsp`.  While our example has nothing that could be
mapped to DSPs we can still take a quick look at the commands here and describe
what they do.

.. literalinclude:: /cmd/synth_ice40.rst
   :language: yoscrypt
   :start-at: t:$mul
   :end-before: alumacc
   :dedent:
   :caption: ``coarse`` section (part 3)
   :name: synth_coarse3

:yoscrypt:`wreduce t:$mul` performs width reduction again, this time targetting
only cells of type ``$mul``.  :yoscrypt:`techmap -map +/mul2dsp.v -map
+/ice40/dsp_map.v ... -D DSP_NAME=$__MUL16X16` uses :cmd:ref:`techmap` to map
``$mul`` cells to ``$__MUL16X16`` which are, in turn, mapped to the iCE40
``SB_MAC16``.  Any multipliers which aren't compatible with conversion to
``$__MUL16X16`` are relabelled to ``$__soft_mul`` before :cmd:ref:`chtype`
changes them back to ``$mul``.

During the mul2dsp conversion, some of the intermediate signals are marked with
the attribute ``mul2dsp``.  By calling :yoscrypt:`select a:mul2dsp` we restrict
the following commands to only operate on the cells and wires used for these
signals.  :cmd:ref:`setattr` removes the now unnecessary ``mul2dsp`` attribute.
:cmd:ref:`opt_expr` we've already come across for const folding and simple
expression rewriting, the ``-fine`` option just enables more fine-grain
optimizations.  Then we perform width reduction a final time and clear the
selection.

Finally we have :cmd:ref:`ice40_dsp`: similar to the :cmd:ref:`memory_dff`
command we saw in the previous section, this merges any surrounding registers
into the ``SB_MAC16`` cell.  This includes not just the input/output registers,
but also pipeline registers and even a post-adder where applicable: turning a
multiply + add into a single multiply-accumulate.

.. seealso:: Advanced usage docs for
   :doc:`/using_yosys/synthesis/techmap_synth`

Part 4
^^^^^^

That brings us to the fourth and final part for the iCE40 synthesis flow:

.. literalinclude:: /cmd/synth_ice40.rst
   :language: yoscrypt
   :start-at: alumacc
   :end-before: map_ram:
   :dedent:
   :caption: ``coarse`` section (part 4)
   :name: synth_coarse4

Where before each type of arithmetic operation had its own cell, e.g. ``$add``,
we now want to extract these into ``$alu`` and ``$macc`` cells which can be
mapped to hard blocks.  We do this by running :cmd:ref:`alumacc`, which we can
see produce the following changes in our example design:

.. literalinclude:: /code_examples/fifo/fifo.out
   :language: doscon
   :start-at: yosys> alumacc
   :end-before: yosys> select
   :caption: output of :cmd:ref:`alumacc`

.. figure:: /_images/code_examples/fifo/rdata_alumacc.*
   :class: width-helper
   :name: rdata_alumacc

   ``rdata`` output after :cmd:ref:`alumacc`

The other new command in this part is :doc:`/cmd/memory`.  :cmd:ref:`memory` is
another macro command which we examine in more detail in
:doc:`/using_yosys/synthesis/memory`.  For this document, let us focus just on
the step most relevant to our example: :cmd:ref:`memory_collect`. Up until this
point, our memory reads and our memory writes have been totally disjoint cells;
operating on the same memory only in the abstract. :cmd:ref:`memory_collect`
combines all of the reads and writes for a memory block into a single cell.

.. figure:: /_images/code_examples/fifo/rdata_coarse.*
   :class: width-helper
   :name: rdata_coarse

   ``rdata`` output after :cmd:ref:`memory_collect`

Looking at the schematic after running :cmd:ref:`memory_collect` we see that our
``$memrd_v2`` cell has been replaced with a ``$mem_v2`` cell named ``data``, the
same name that we used in :ref:`fifo-v`. Where before we had a single set of
signals for address and enable, we now have one set for reading (``RD_*``) and
one for writing (``WR_*``), as well as both ``WR_DATA`` input and ``RD_DATA``
output.

.. seealso:: Advanced usage docs for
   :doc:`/using_yosys/synthesis/memory`

Final note
^^^^^^^^^^

Having now reached the end of the the coarse-grain representation, we could also
have gotten here by running :yoscrypt:`synth_ice40 -top fifo -run :map_ram`
after loading the design.  The :yoscrypt:`-run <from_label>:<to_label>` option
with an empty ``<from_label>`` starts from the :ref:`synth_begin`, while the
``<to_label>`` runs up to but including the :ref:`map_ram`.

Hardware mapping
~~~~~~~~~~~~~~~~

The remaining sections each map a different type of hardware and are much more
architecture dependent than the previous sections.  As such we will only be
looking at each section very briefly.

Memory blocks
^^^^^^^^^^^^^

Mapping to hard memory blocks uses a combination of :cmd:ref:`memory_libmap`,
:cmd:ref:`memory_map`, and :cmd:ref:`techmap`.

.. literalinclude:: /cmd/synth_ice40.rst
   :language: yoscrypt
   :start-after: map_ram:
   :end-before: map_ffram:
   :dedent:
   :name: map_ram
   :caption: ``map_ram`` section

.. figure:: /_images/code_examples/fifo/rdata_map_ram.*
   :class: width-helper
   :name: rdata_map_ram

   ``rdata`` output after :ref:`map_ram`

:ref:`map_ram` converts the generic ``$mem_v2`` into the iCE40 ``SB_RAM40_4K``
(highlighted). We can also see the memory address has been remapped, and the
data bits have been reordered (or swizzled).  There is also now a ``$mux`` cell
controlling the value of ``rdata``.  In :ref:`fifo-v` we wrote our memory as
read-before-write, however the ``SB_RAM40_4K`` has undefined behaviour when
reading from and writing to the same address in the same cycle.  As a result,
extra logic is added so that the generated circuit matches the behaviour of the
verilog.  :ref:`no_rw_check` describes how we could change our verilog to match
our hardware instead.

.. literalinclude:: /cmd/synth_ice40.rst
   :language: yoscrypt
   :start-after: map_ffram:
   :end-before: map_gates:
   :dedent:
   :name: map_ffram
   :caption: ``map_ffram`` section

.. figure:: /_images/code_examples/fifo/rdata_map_ffram.*
   :class: width-helper
   :name: rdata_map_ffram

   ``rdata`` output after :ref:`map_ffram`

.. TODO:: what even is this opt output

.. seealso:: Advanced usage docs for
   
   - :doc:`/using_yosys/synthesis/techmap_synth`
   - :doc:`/using_yosys/synthesis/memory`

Arithmetic
^^^^^^^^^^

Uses :cmd:ref:`techmap` to map basic arithmetic logic to hardware.  This sees
somewhat of an explosion in cells as multi-bit ``$mux`` and ``$adffe`` are
replaced with single-bit ``$_MUX_`` and ``$_DFFE_PP0P_`` cells, while the
``$alu`` is replaced with primitive ``$_OR_`` and ``$_NOT_`` gates and a
``$lut`` cell.

.. literalinclude:: /cmd/synth_ice40.rst
   :language: yoscrypt
   :start-after: map_gates:
   :end-before: map_ffs:
   :dedent:
   :name: map_gates
   :caption: ``map_gates`` section

.. figure:: /_images/code_examples/fifo/rdata_map_gates.*
   :class: width-helper
   :name: rdata_map_gates

   ``rdata`` output after :ref:`map_gates`

.. seealso:: Advanced usage docs for
   :doc:`/using_yosys/synthesis/techmap_synth`

Flip-flops
^^^^^^^^^^

Convert FFs to the types supported in hardware with :cmd:ref:`dfflegalize`, and
then use :cmd:ref:`techmap` to map them.  In our example, this converts the
``$_DFFE_PP0P_`` cells to ``SB_DFFER``.

We also run :cmd:ref:`simplemap` here to convert any remaining cells which could
not be mapped to hardware into gate-level primitives.  This includes optimizing
``$_MUX_`` cells where one of the inputs is a constant ``1'0``, replacing it
instead with an ``$_AND_`` cell.

.. literalinclude:: /cmd/synth_ice40.rst
   :language: yoscrypt
   :start-after: map_ffs:
   :end-before: map_luts:
   :dedent:
   :name: map_ffs
   :caption: ``map_ffs`` section

.. figure:: /_images/code_examples/fifo/rdata_map_ffs.*
   :class: width-helper
   :name: rdata_map_ffs

   ``rdata`` output after :ref:`map_ffs`

.. seealso:: Advanced usage docs for
   :doc:`/using_yosys/synthesis/techmap_synth`

LUTs
^^^^

:cmd:ref:`abc` and :cmd:ref:`techmap` are used to map LUTs; converting primitive
cell types to use ``$lut`` and ``SB_CARRY`` cells.  Note that the iCE40 flow
uses :cmd:ref:`abc9` rather than :cmd:ref:`abc`. For more on what these do, and
what the difference between these two commands are, refer to
:doc:`/using_yosys/synthesis/abc`.

.. literalinclude:: /cmd/synth_ice40.rst
   :language: yoscrypt
   :start-after: map_luts:
   :end-before: map_cells:
   :dedent:
   :name: map_luts
   :caption: ``map_luts`` section

.. figure:: /_images/code_examples/fifo/rdata_map_luts.*
   :class: width-helper
   :name: rdata_map_luts

   ``rdata`` output after :ref:`map_luts`

Finally we use :cmd:ref:`techmap` to map the generic ``$lut`` cells to iCE40
``SB_LUT4`` cells.

.. literalinclude:: /cmd/synth_ice40.rst
   :language: yoscrypt
   :start-after: map_cells:
   :end-before: check:
   :dedent:
   :name: map_cells
   :caption: ``map_cells`` section

.. figure:: /_images/code_examples/fifo/rdata_map_cells.*
   :class: width-helper
   :name: rdata_map_cells

   ``rdata`` output after :ref:`map_cells`

.. seealso:: Advanced usage docs for
   
   - :doc:`/using_yosys/synthesis/techmap_synth`
   - :doc:`/using_yosys/synthesis/abc`

Other cells
^^^^^^^^^^^

The following commands may also be used for mapping other cells:

: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.

These commands tend to either be in the :ref:`map_cells` or after the
:ref:`check` depending on the flow.

Final steps
~~~~~~~~~~~~

.. TODO:: example_synth final steps (check section and outputting)

.. literalinclude:: /cmd/synth_ice40.rst
   :language: yoscrypt
   :start-after: check:
   :end-before: blif:
   :dedent:
   :name: check
   :caption: ``check`` section

- :doc:`/cmd/check`
- :doc:`/cmd/autoname`
- :doc:`/cmd/stat`