Regardless of the way a lower level representation of a circuit is
obtained (synthesis or manual design), the lower level representation is usually
verified by comparing simulation results of the lower level and the higher level
-representation \footnote{In the last years formal equivalence
+representation \footnote{In recent years formal equivalence
checking also became an important verification method for validating RTL and
lower abstraction representation of the design.}.
Therefore even if no synthesis is used, there must still be a simulatable
\subsection{System Level}
The System Level abstraction of a system only looks at its biggest building
-blocks like CPUs and computing cores. On this level the circuit is usually described
+blocks like CPUs and computing cores. At this level the circuit is usually described
using traditional programming languages like C/C++ or Matlab. Sometimes special
software libraries are used that are aimed at simulation circuits on the system
level, such as SystemC.
\subsection{Logical Gate Level}
-On the logical gate level the design is represented by a netlist that uses only
+At the logical gate level the design is represented by a netlist that uses only
cells from a small number of single-bit cells, such as basic logic gates (AND,
-OR, NOT, XOR, etc.) and Registers (usually D-Type Flip-flops).
+OR, NOT, XOR, etc.) and registers (usually D-Type Flip-flops).
A number of netlist formats exists that can be used on this level, e.g.~the Electronic Design
Interchange Format (EDIF), but for ease of simulation often a HDL netlist is used. The latter
gate netlist to an equivalent netlist of physically available gate types.
The simplest approach to logic synthesis is {\it two-level logic synthesis}, where a logic function
-is converted into a sum-of-products representation, e.g.~using a karnaugh map.
-This is a simple approach, but has exponential worst-case effort and can not make efficient use of
+is converted into a sum-of-products representation, e.g.~using a Karnaugh map.
+This is a simple approach, but has exponential worst-case effort and cannot make efficient use of
physical gates other than AND/NAND-, OR/NOR- and NOT-Gates.
Therefore modern logic synthesis tools utilize much more complicated {\it multi-level logic
\subsection{Behavioural Modelling}
Code that utilizes the Verilog {\tt always} statement is using {\it Behavioural
-Modelling}. In behavioural, modelling a circuit is described by means of imperative
+Modelling}. In behavioural modelling, a circuit is described by means of imperative
program code that is executed on certain events, namely any change, a rising
edge, or a falling edge of a signal. This is a very flexible construct during
simulation but is only synthesizable when one of the following is modelled:
correct synthesis of basic behavioural models). But it is also crucial for the
areas that concern minor details of the standard, such as the exact rules
for handling signed expressions, even when the HDL code does not target
-different synthesis tools. This is because (different to software source code that
+different synthesis tools. This is because (unlike software source code that
is only processed by compilers), in most design flows HDL code is not only
processed by the synthesis tool but also by one or more simulators and sometimes
even a formal verification tool. It is key for this verification process
Generally it is hard to give a one-dimensional description of how well a synthesis tool
optimizes the design. First of all because not all optimizations are applicable to all
-designs and all synthesis tasks. Some optimizations work (best) on a coarse grain level
-(with complex cells such as adders or multipliers) and others work (best) on a fine
-grain level (single bit gates). Some optimizations target area and others target speed.
+designs and all synthesis tasks. Some optimizations work (best) on a coarse-grained level
+(with complex cells such as adders or multipliers) and others work (best) on a fine-grained
+level (single bit gates). Some optimizations target area and others target speed.
Some work well on large designs while others don't scale well and can only be applied
to small designs.
description file that is using regular expressions to specify the text pattern that should match
the individual tokens.
-The lexer is also responsible for skipping ignored characters (such as white spaces outside string
+The lexer is also responsible for skipping ignored characters (such as whitespace outside string
constants and comments in the case of Verilog) and converting the original text snippet to a token
value.
Traditionally a parser and lexer are connected using the pipelined approach: The lexer provides a function that
is called by the parser. This function reads data from the input until a complete lexical token has been read. Then
this token is returned to the parser. So the lexer does not first generate a complete list of lexical tokens
-and then passes it to the parser. Instead they are running concurrently and the parser can consume tokens as
+and then pass it to the parser. Instead they run concurrently and the parser can consume tokens as
the lexer produces them.
-The single-pass pipelining approach has the advantage of lower memory footprint (at no time the complete design
-must be kept in memory) but has the disadvantage of tighter coupling between the interacting components.
+The single-pass pipelining approach has the advantage of lower memory footprint (at no time must the complete design
+be kept in memory) but has the disadvantage of tighter coupling between the interacting components.
Therefore single-pass pipelining should only be used when the lower memory footprint is required or the
components are also conceptually tightly coupled. The latter certainly is the case for a parser and its lexer.
available for a long time, and it is therefore likely that a FOSS HDL synthesis tool
with a feature-complete Verilog or VHDL front end must exist which can be used as a basis for a custom RTL synthesis tool.
-Due to the authors preference for Verilog over VHDL it has been decided early
+Due to the author's preference for Verilog over VHDL it was decided early
on to go for Verilog instead of VHDL\footnote{A quick investigation into FOSS
VHDL tools yielded similar grim results for FOSS VHDL synthesis tools.}.
So the existing FOSS Verilog synthesis tools were evaluated (see
\section{Structure of this Document}
-The structure of this document is a follows:
+The structure of this document is as follows:
Chapter~\ref{chapter:intro} is this introduction.
Chapter~\ref{chapter:basics} covers a short introduction to the world of HDL
-synthesis. Basic principles and the terminology is outlined in this chapter.
+synthesis. Basic principles and the terminology are outlined in this chapter.
Chapter~\ref{chapter:approach} gives the quickest possible outline to how the
problem of implementing a HDL synthesis tool is approached in the case of
for Yosys.
Chapters~\ref{chapter:verilog}, \ref{chapter:opt}, and \ref{chapter:techmap}
-cover three improtant pieces of the synthesis pileline: The Verilog frontend,
+cover three important pieces of the synthesis pipeline: The Verilog frontend,
the optimization passes and the technology mapping to the target architecture,
respectively.
projects / yosys.git / commitdiff