mirror of
				https://github.com/YosysHQ/yosys
				synced 2025-10-31 11:42:30 +00:00 
			
		
		
		
	Typos and grammar fixes through chapter 2.
This commit is contained in:
		
							parent
							
								
									6ef2224331
								
							
						
					
					
						commit
						9c1e578afe
					
				
					 3 changed files with 21 additions and 21 deletions
				
			
		|  | @ -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,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. | 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 can not 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. | ||||||
| 
 | 
 | ||||||
| Therefore modern logic synthesis tools utilize much more complicated {\it multi-level logic | 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} | \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…
	
	Add table
		Add a link
		
	
		Reference in a new issue