mirror of https://github.com/YosysHQ/yosys.git
Merge pull request #33 from bentley/dox
Typos and grammar fixes through chapter 2.
This commit is contained in:
commit
d18c10d991
|
@ -56,7 +56,7 @@ and how they relate to different kinds of synthesis.
|
||||||
Regardless of the way a lower level representation of a circuit is
|
Regardless of the way a lower level representation of a circuit is
|
||||||
obtained (synthesis or manual design), the lower level representation is usually
|
obtained (synthesis or manual design), the lower level representation is usually
|
||||||
verified by comparing simulation results of the lower level and the higher level
|
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
|
checking also became an important verification method for validating RTL and
|
||||||
lower abstraction representation of the design.}.
|
lower abstraction representation of the design.}.
|
||||||
Therefore even if no synthesis is used, there must still be a simulatable
|
Therefore even if no synthesis is used, there must still be a simulatable
|
||||||
|
@ -71,7 +71,7 @@ be considered a ``High-Level Language'' today.
|
||||||
\subsection{System Level}
|
\subsection{System Level}
|
||||||
|
|
||||||
The System Level abstraction of a system only looks at its biggest building
|
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
|
using traditional programming languages like C/C++ or Matlab. Sometimes special
|
||||||
software libraries are used that are aimed at simulation circuits on the system
|
software libraries are used that are aimed at simulation circuits on the system
|
||||||
level, such as SystemC.
|
level, such as SystemC.
|
||||||
|
@ -177,9 +177,9 @@ synthesis operations.
|
||||||
|
|
||||||
\subsection{Logical Gate Level}
|
\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,
|
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
|
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
|
Interchange Format (EDIF), but for ease of simulation often a HDL netlist is used. The latter
|
||||||
|
@ -191,7 +191,7 @@ within the gate level netlist and second the optimal (or at least good) mapping
|
||||||
gate netlist to an equivalent netlist of physically available gate types.
|
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
|
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.
|
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
|
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.
|
physical gates other than AND/NAND-, OR/NOR- and NOT-Gates.
|
||||||
|
|
||||||
|
@ -287,7 +287,7 @@ applications to be used with a richer set of Verilog features.
|
||||||
\subsection{Behavioural Modelling}
|
\subsection{Behavioural Modelling}
|
||||||
|
|
||||||
Code that utilizes the Verilog {\tt always} statement is using {\it Behavioural
|
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
|
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
|
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:
|
simulation but is only synthesizable when one of the following is modelled:
|
||||||
|
@ -457,7 +457,7 @@ Correctness is crucial. In some areas this is obvious (such as
|
||||||
correct synthesis of basic behavioural models). But it is also crucial for the
|
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
|
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
|
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
|
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
|
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
|
even a formal verification tool. It is key for this verification process
|
||||||
|
@ -467,9 +467,9 @@ that all these tools use the same interpretation for the HDL code.
|
||||||
|
|
||||||
Generally it is hard to give a one-dimensional description of how well a synthesis tool
|
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
|
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
|
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
|
(with complex cells such as adders or multipliers) and others work (best) on a fine-grained
|
||||||
grain level (single bit gates). Some optimizations target area and others target speed.
|
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
|
Some work well on large designs while others don't scale well and can only be applied
|
||||||
to small designs.
|
to small designs.
|
||||||
|
|
||||||
|
@ -610,7 +610,7 @@ The lexer is usually generated by a lexer generator (e.g.~{\tt flex} \citeweblin
|
||||||
description file that is using regular expressions to specify the text pattern that should match
|
description file that is using regular expressions to specify the text pattern that should match
|
||||||
the individual tokens.
|
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
|
constants and comments in the case of Verilog) and converting the original text snippet to a token
|
||||||
value.
|
value.
|
||||||
|
|
||||||
|
@ -714,11 +714,11 @@ be connected in two different ways: through {\it Single-Pass Pipelining} and by
|
||||||
Traditionally a parser and lexer are connected using the pipelined approach: The lexer provides a function that
|
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
|
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
|
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 lexer produces them.
|
||||||
|
|
||||||
The single-pass pipelining approach has the advantage of lower memory footprint (at no time the complete design
|
The single-pass pipelining approach has the advantage of lower memory footprint (at no time must the complete design
|
||||||
must be kept in memory) but has the disadvantage of tighter coupling between the interacting components.
|
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
|
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.
|
components are also conceptually tightly coupled. The latter certainly is the case for a parser and its lexer.
|
||||||
|
|
|
@ -45,7 +45,7 @@ researched field. All the information required to write such tools has been open
|
||||||
available for a long time, and it is therefore likely that a FOSS HDL synthesis tool
|
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.
|
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
|
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.}.
|
VHDL tools yielded similar grim results for FOSS VHDL synthesis tools.}.
|
||||||
So the existing FOSS Verilog synthesis tools were evaluated (see
|
So the existing FOSS Verilog synthesis tools were evaluated (see
|
||||||
|
@ -56,12 +56,12 @@ is discussed in this document.
|
||||||
|
|
||||||
\section{Structure of this Document}
|
\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:intro} is this introduction.
|
||||||
|
|
||||||
Chapter~\ref{chapter:basics} covers a short introduction to the world of HDL
|
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
|
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
|
problem of implementing a HDL synthesis tool is approached in the case of
|
||||||
|
@ -82,7 +82,7 @@ Yosys source code. The chapter concludes with an example loadable module
|
||||||
for Yosys.
|
for Yosys.
|
||||||
|
|
||||||
Chapters~\ref{chapter:verilog}, \ref{chapter:opt}, and \ref{chapter:techmap}
|
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,
|
the optimization passes and the technology mapping to the target architecture,
|
||||||
respectively.
|
respectively.
|
||||||
|
|
||||||
|
|
|
@ -140,7 +140,7 @@ bookmarksopen=false%
|
||||||
\eject
|
\eject
|
||||||
|
|
||||||
\chapter*{Abstract}
|
\chapter*{Abstract}
|
||||||
Most of todays digital design is done in HDL code (mostly Verilog or VHDL) and
|
Most of today's digital design is done in HDL code (mostly Verilog or VHDL) and
|
||||||
with the help of HDL synthesis tools.
|
with the help of HDL synthesis tools.
|
||||||
|
|
||||||
In special cases such as synthesis for coarse-grain cell libraries or when
|
In special cases such as synthesis for coarse-grain cell libraries or when
|
||||||
|
@ -158,7 +158,7 @@ by Yosys to perform advanced gate-level optimizations.
|
||||||
An evaluation of Yosys based on real-world designs is included. It is shown
|
An evaluation of Yosys based on real-world designs is included. It is shown
|
||||||
that Yosys can be used as-is to synthesize such designs. The results produced
|
that Yosys can be used as-is to synthesize such designs. The results produced
|
||||||
by Yosys in this tests where successflly verified using formal verification
|
by Yosys in this tests where successflly verified using formal verification
|
||||||
and are compareable in quality to the results produced by a commercial
|
and are comparable in quality to the results produced by a commercial
|
||||||
synthesis tool.
|
synthesis tool.
|
||||||
|
|
||||||
\bigskip
|
\bigskip
|
||||||
|
|
Loading…
Reference in New Issue