1 files changed, 0 insertions, 102 deletions
diff --git a/manual/CHAPTER_Techmap.tex b/manual/CHAPTER_Techmap.tex
deleted file mode 100644
index 13aa8e5a3..000000000
--- a/manual/CHAPTER_Techmap.tex
+++ /dev/null
@@ -1,102 +0,0 @@
-
-\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 equivalent netlist utilizing 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/common/techmap.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 useful 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.
-