mirror of
				https://github.com/YosysHQ/yosys
				synced 2025-10-31 03:32:29 +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 | ||||
| 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. | ||||
|  |  | |||
|  | @ -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. | ||||
| 
 | ||||
|  |  | |||
|  | @ -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 | ||||
|  |  | |||
		Loading…
	
	Add table
		Add a link
		
	
		Reference in a new issue