manual/CHAPTER_Techmap.tex

   1
   2 \chapter{Technology Mapping}
   3 \label{chapter:techmap}
   4
   5 Previous chapters outlined how HDL code is transformed into an RTL netlist. The
   6 RTL netlist is still based on abstract coarse-grain cell types like arbitrary
   7 width adders and even multipliers. This chapter covers how an RTL netlist is
   8 transformed into a functionally equivalent netlist utilizing the cell types
   9 available in the target architecture.
  10
  11 Technology mapping is often performed in two phases. In the first phase RTL cells
  12 are mapped to an internal library of single-bit cells (see Sec.~\ref{sec:celllib_gates}).
  13 In the second phase this netlist of internal gate types is transformed to a netlist
  14 of gates from the target technology library.
  15
  16 When the target architecture provides coarse-grain cells (such as block ram
  17 or ALUs), these must be mapped to directly form the RTL netlist, as information
  18 on the coarse-grain structure of the design is lost when it is mapped to
  19 bit-width gate types.
  20
  21 \section{Cell Substitution}
  22
  23 The simplest form of technology mapping is cell substitution, as performed by
  24 the {\tt techmap} pass. This pass, when provided with a Verilog file that
  25 implements the RTL cell types using simpler cells, simply replaces the RTL
  26 cells with the provided implementation.
  27
  28 When no map file is provided, {\tt techmap} uses a built-in map file that
  29 maps the Yosys RTL cell types to the internal gate library used by Yosys.
  30 The curious reader may find this map file as {\tt techlibs/common/techmap.v} in
  31 the Yosys source tree.
  32
  33 Additional features have been added to {\tt techmap} to allow for conditional
  34 mapping of cells (see {\tt help techmap} or Sec.~\ref{cmd:techmap}). This can
  35 for example be useful if the target architecture supports hardware multipliers for
  36 certain bit-widths but not for others.
  37
  38 A usual synthesis flow would first use the {\tt techmap} pass to directly map
  39 some RTL cells to coarse-grain cells provided by the target architecture (if
  40 any) and then use techmap with the built-in default file to map the remaining
  41 RTL cells to gate logic.
  42
  43 \section{Subcircuit Substitution}
  44
  45 Sometimes the target architecture provides cells that are more powerful than
  46 the RTL cells used by Yosys. For example a cell in the target architecture that can
  47 calculate the absolute-difference of two numbers does not match any single
  48 RTL cell type but only combinations of cells.
  49
  50 For these cases Yosys provides the {\tt extract} pass that can match a given set
  51 of modules against a design and identify the portions of the design that are
  52 identical (i.e.~isomorphic subcircuits) to any of the given modules. These
  53 matched subcircuits are then replaced by instances of the given modules.
  54
  55 The {\tt extract} pass also finds basic variations of the given modules,
  56 such as swapped inputs on commutative cell types.
  57
  58 In addition to this the {\tt extract} pass also has limited support for
  59 frequent subcircuit mining, i.e.~the process of finding recurring subcircuits
  60 in the design. This has a few applications, including the design of new
  61 coarse-grain architectures \cite{intersynthFdlBookChapter}.
  62
  63 The hard algorithmic work done by the {\tt extract} pass (solving the
  64 isomorphic subcircuit problem and frequent subcircuit mining) is performed
  65 using the SubCircuit library that can also be used stand-alone without Yosys
  66 (see Sec.~\ref{sec:SubCircuit}).
  67
  68 \section{Gate-Level Technology Mapping}
  69 \label{sec:techmap_extern}
  70
  71 On the gate-level the target architecture is usually described by a ``Liberty
  72 file''. The Liberty file format is an industry standard format that can be
  73 used to describe the behaviour and other properties of standard library cells
  74 \citeweblink{LibertyFormat}.
  75
  76 Mapping a design utilizing the Yosys internal gate library (e.g.~as a result
  77 of mapping it to this representation using the {\tt techmap} pass) is
  78 performed in two phases.
  79
  80 First the register cells must be mapped to the registers that are available
  81 on the target architectures. The target architecture might not provide all
  82 variations of d-type flip-flops with positive and negative clock edge,
  83 high-active and low-active asynchronous set and/or reset, etc. Therefore the
  84 process of mapping the registers might add additional inverters to the design
  85 and thus it is important to map the register cells first.
  86
  87 Mapping of the register cells may be performed by using the {\tt dfflibmap}
  88 pass. This pass expects a Liberty file as argument (using the {\tt -liberty}
  89 option) and only uses the register cells from the Liberty file.
  90
  91 Secondly the combinational logic must be mapped to the target architecture.
  92 This is done using the external program ABC \citeweblink{ABC} via the
  93 {\tt abc} pass by using the {\tt -liberty} option to the pass. Note that
  94 in this case only the combinatorial cells are used from the cell library.
  95
  96 Occasionally Liberty files contain trade secrets (such as sensitive timing
  97 information) that cannot be shared freely. This complicates processes such as
  98 reporting bugs in the tools involved. When the information in the Liberty file
  99 used by Yosys and ABC are not part of the sensitive information, the additional
 100 tool {\tt yosys-filterlib} (see Sec.~\ref{sec:filterlib}) can be used to strip
 101 the sensitive information from the Liberty file.
 102