From: Anthony J. Bentley Date: Fri, 11 Apr 2014 08:42:59 +0000 (-0600) Subject: Typos and grammar fixes through chapter 2. X-Git-Tag: yosys-0.3.0~29^2 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=9c1e578afe6af40be4600c20c883fa016fc7fa26;p=yosys.git Typos and grammar fixes through chapter 2. --- diff --git a/manual/CHAPTER_Basics.tex b/manual/CHAPTER_Basics.tex index 9cc4720e2..c0eda0e84 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 675d24026..f735d46b2 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 d6ffd95a6..c305ecb05 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