1 files changed, 102 insertions, 0 deletions
diff --git a/manual/CHAPTER_Techmap.tex b/manual/CHAPTER_Techmap.tex
new file mode 100644
index 000000000..6a84864e2
--- /dev/null
+++ b/manual/CHAPTER_Techmap.tex
@@ -0,0 +1,102 @@
+
+\chapter{Technology Mapping}
+\label{chapter:techmap}
+
+Previous chapters outlined how HDL code is transformed into an RTL netlist. The
+RTL netlist is still based on abstract coarse-grain cell types like arbitrary
+width adders and even multipliers. This chapter covers how an RTL netlist is
+transformed into a functionally equivialent netlist utililizing the cell types
+available in the target architecture.
+
+Technology mapping is often performed in two phases. In the first phase RTL cells
+are mapped to an internal library of single-bit cells (see Sec.~\ref{sec:celllib_gates}).
+In the second phase this netlist of internal gate types is transformed to a netlist
+of gates from the target technology library.
+
+When the target architecture provides coarse-grain cells (such as block ram
+or ALUs), these must be mapped to directly form the RTL netlist, as information
+on the coarse-grain structure of the design is lost when it is mapped to
+bit-width gate types.
+
+\section{Cell Substitution}
+
+The simplest form of technology mapping is cell substitution, as performed by
+the {\tt techmap} pass. This pass, when provided with a Verilog file that
+implements the RTL cell types using simpler cells, simply replaces the RTL
+cells with the provided implementation.
+
+When no map file is provided, {\tt techmap} uses a built-in map file that
+maps the Yosys RTL cell types to the internal gate library used by Yosys.
+The curious reader may find this map file as {\tt techlibs/stdcells.v} in
+the Yosys source tree.
+
+Additional features have been added to {\tt techmap} to allow for conditional
+mapping of cells (see {\tt help techmap} or Sec.~\ref{cmd:techmap}). This can
+for example be usefull if the target architecture supports hardware multipliers for
+certain bit-widths but not for others.
+
+A usual synthesis flow would first use the {\tt techmap} pass to directly map
+some RTL cells to coarse-grain cells provided by the target architecture (if
+any) and then use techmap with the built-in default file to map the remaining
+RTL cells to gate logic.
+
+\section{Subcircuit Substitution}
+
+Sometimes the target architecture provides cells that are more powerful than
+the RTL cells used by Yosys. For example a cell in the target architecture that can
+calculate the absolute-difference of two numbers does not match any single
+RTL cell type but only combinations of cells.
+
+For these cases Yosys provides the {\tt extract} pass that can match a given set
+of modules against a design and identify the portions of the design that are
+identical (i.e.~isomorphic subcircuits) to any of the given modules. These
+matched subcircuits are then replaced by instances of the given modules.
+
+The {\tt extract} pass also finds basic variations of the given modules,
+such as swapped inputs on commutative cell types.
+
+In addition to this the {\tt extract} pass also has limited support for
+frequent subcircuit mining, i.e.~the process of finding recurring subcircuits
+in the design. This has a few applications, including the design of new
+coarse-grain architectures \cite{intersynthFdlBookChapter}.
+
+The hard algorithmic work done by the {\tt extract} pass (solving the
+isomorphic subcircuit problem and frequent subcircuit mining) is performed
+using the SubCircuit library that can also be used stand-alone without Yosys
+(see Sec.~\ref{sec:SubCircuit}).
+
+\section{Gate-Level Technology Mapping}
+\label{sec:techmap_extern}
+
+On the gate-level the target architecture is usually described by a ``Liberty
+file''. The Liberty file format is an industry standard format that can be
+used to describe the behaviour and other properties of standard library cells
+\citeweblink{LibertyFormat}.
+
+Mapping a design utilizing the Yosys internal gate library (e.g.~as a result
+of mapping it to this representation using the {\tt techmap} pass) is
+performed in two phases.
+
+First the register cells must be mapped to the registers that are available
+on the target architectures. The target architecture might not provide all
+variations of d-type flip-flops with positive and negative clock edge,
+high-active and low-active asynchronous set and/or reset, etc. Therefore the
+process of mapping the registers might add additional inverters to the design
+and thus it is important to map the register cells first.
+
+Mapping of the register cells may be performed by using the {\tt dfflibmap}
+pass. This pass expects a Liberty file as argument (using the {\tt -liberty}
+option) and only uses the register cells from the Liberty file.
+
+Secondly the combinational logic must be mapped to the target architecture.
+This is done using the external program ABC \citeweblink{ABC} via the
+{\tt abc} pass by using the {\tt -liberty} option to the pass. Note that
+in this case only the combinatorial cells are used from the cell library.
+
+Occasionally Liberty files contain trade secrets (such as sensitive timing
+information) that cannot be shared freely. This complicates processes such as
+reporting bugs in the tools involved. When the information in the Liberty file
+used by Yosys and ABC are not part of the sensitive information, the additional
+tool {\tt yosys-filterlib} (see Sec.~\ref{sec:filterlib}) can be used to strip
+the sensitive information from the Liberty file.
+