techmap - generic technology mapper
techmap [-map filename] [selection]
This pass implements a very simple technology mapper that replaces cells in
the design with implementations given in form of a Verilog or ilang source
the library of cell implementations to be used.
without this parameter a builtin library is used that
transforms the internal RTL cells to the internal gate
like -map above, but with an in-memory design instead of a file.
load the cell implementations as separate modules into the design
instead of inlining them.
only run the specified number of iterations.
instead of the iterative breadth-first algorithm use a recursive
depth-first algorithm. both methods should yield equivalent results,
but may differ in performance.
Automatically call "proc" on implementations that contain processes.
this option will cause techmap to exit with an error if it can't map
a selected cell. only cell types that end on an underscore are accepted
as final cell types by this mode.
-D <define>, -I <incdir>
this options are passed as-is to the Verilog frontend for loading the
map file. Note that the Verilog frontend is also called with the
'-ignore_redef' option set.
When a module in the map file has the 'techmap_celltype' attribute set, it will
match cells with a type that match the text value of this attribute. Otherwise
the module name will be used to match the cell.
When a module in the map file has the 'techmap_simplemap' attribute set, techmap
will use 'simplemap' (see 'help simplemap') to map cells matching the module.
When a module in the map file has the 'techmap_maccmap' attribute set, techmap
will use 'maccmap' (see 'help maccmap') to map cells matching the module.
When a module in the map file has the 'techmap_wrap' attribute set, techmap
will create a wrapper for the cell and then run the command string that the
attribute is set to on the wrapper module.
All wires in the modules from the map file matching the pattern _TECHMAP_*
or *._TECHMAP_* are special wires that are used to pass instructions from
the mapping module to the techmap command. At the moment the following special
wires are supported:
When this wire is set to a non-zero constant value, techmap will not
use this module and instead try the next module with a matching
When such a wire exists but does not have a constant value after all
_TECHMAP_DO_* commands have been executed, an error is generated.
This wires are evaluated in alphabetical order. The constant text value
of this wire is a yosys command (or sequence of commands) that is run
by techmap on the module. A common use case is to run 'proc' on modules
that are written using always-statements.
When such a wire has a non-constant value at the time it is to be
evaluated, an error is produced. That means it is possible for such a
wire to start out as non-constant and evaluate to a constant value
during processing of other _TECHMAP_DO_* commands.
A _TECHMAP_DO_* command may start with the special token 'CONSTMAP; '.
in this case techmap will create a copy for each distinct configuration
of constant inputs and shorted inputs at this point and import the
constant and connected bits into the map module. All further commands
are executed in this copy. This is a very convenient way of creating
optimized specializations of techmap modules without using the special
parameters described below.
A _TECHMAP_DO_* command may start with the special token 'RECURSION; '.
then techmap will recursively replace the cells in the module with their
implementation. This is not affected by the -max_iter option.
It is possible to combine both prefixes to 'RECURSION; CONSTMAP; '.
In addition to this special wires, techmap also supports special parameters in
modules in the map file:
When a parameter with this name exists, it will be set to the type name
of the cell that matches the module.
When this pair of parameters is available in a module for a port, then
former has a 1-bit for each constant input bit and the latter has the
value for this bit. The unused bits of the latter are set to undef (x).
For an N-bit port, the _TECHMAP_CONNMAP_<port-name>_ parameter, if it
exists, will be set to an N*_TECHMAP_BITS_CONNMAP_ bit vector containing
N words (of _TECHMAP_BITS_CONNMAP_ bits each) that assign each single
bit driver a unique id. The values 0-3 are reserved for 0, 1, x, and z.
This can be used to detect shorted inputs.
When a module in the map file has a parameter where the according cell in the
design has a port, the module from the map file is only used if the port in
the design is connected to a constant value. The parameter is then set to the
A cell with the name _TECHMAP_REPLACE_ in the map file will inherit the name
of the cell that is being replaced.
See 'help extract' for a pass that does the opposite thing.
See 'help flatten' for a pass that does flatten the design (which is
essentially techmap but using the design itself as map library).