Merge pull request #33 from bentley/dox

Typos and grammar fixes through chapter 2.

3 files changed, 21 insertions, 21 deletions

diff --git a/manual/CHAPTER_Basics.tex b/manual/CHAPTER_Basics.tex
index 9cc4720e..c0eda0e8 100644
--- a/manual/CHAPTER_Basics.tex
+++ b/manual/CHAPTER_Basics.tex
@@ -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
 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
@@ -71,7 +71,7 @@ be considered a ``High-Level Language'' today.
 \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.
@@ -177,9 +177,9 @@ synthesis operations.
 
 \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
@@ -191,8 +191,8 @@ 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.
 
 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
@@ -287,7 +287,7 @@ applications to be used with a richer set of Verilog features.
 \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:
@@ -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
 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
@@ -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
 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.
 
@@ -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
 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.
 
@@ -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
 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.
diff --git a/manual/CHAPTER_Intro.tex b/manual/CHAPTER_Intro.tex
index 675d2402..f735d46b 100644
--- a/manual/CHAPTER_Intro.tex
+++ b/manual/CHAPTER_Intro.tex
@@ -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
 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
@@ -56,12 +56,12 @@ is discussed in 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: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
@@ -82,7 +82,7 @@ Yosys source code. The chapter concludes with an example loadable module
 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.
 
diff --git a/manual/manual.tex b/manual/manual.tex
index d6ffd95a..c305ecb0 100644
--- a/manual/manual.tex
+++ b/manual/manual.tex
@@ -140,7 +140,7 @@ bookmarksopen=false%
 \eject
 
 \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.
 
 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
 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
-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.
 
 \bigskip