diff options
Diffstat (limited to 'manual')
| -rw-r--r-- | manual/CHAPTER_Approach.tex | 14 | ||||
| -rw-r--r-- | manual/CHAPTER_Overview.tex | 50 |
2 files changed, 32 insertions, 32 deletions
diff --git a/manual/CHAPTER_Approach.tex b/manual/CHAPTER_Approach.tex index a2c40bea..69122580 100644 --- a/manual/CHAPTER_Approach.tex +++ b/manual/CHAPTER_Approach.tex @@ -8,7 +8,7 @@ approach followed in the effort to implement this tool. \section{Data- and Control-Flow} -The data- and control-flow of a typical synthesis-tool is very similar to the data- and control-flow of a typical +The data- and control-flow of a typical synthesis tool is very similar to the data- and control-flow of a typical compiler: different subsystems are called in a predetermined order, each consuming the data generated by the last subsystem and generating the data for the next subsystem (see Fig.~\ref{fig:approach_flow}). @@ -44,10 +44,10 @@ last subsystem and generating the data for the next subsystem (see Fig.~\ref{fig \end{figure} The first subsystem to be called is usually called a {\it frontend}. It does not process the data generated by -another subsystem but instead reads the user input; in the case of a HDL synthesis tool the behavioural +another subsystem but instead reads the user input---in the case of a HDL synthesis tool, the behavioural HDL code. -The subsystems that consume data from previous subsystems and produces data for the next subsystems (usually in the +The subsystems that consume data from previous subsystems and produce data for the next subsystems (usually in the same or a similar format) are called {\it passes}. The last subsystem that is executed transforms the data generated by the last pass into a suitable output @@ -61,7 +61,7 @@ script. Yosys uses two different internal formats. The first is used to store an abstract syntax tree (AST) of a verilog input file. This format is simply called {\it AST} and is generated by the Verilog Frontend. This data structure -is then consumed by a subsystem called {\it AST Frontend}\footnote{In Yosys the term {\it pass} is only used to +is consumed by a subsystem called {\it AST Frontend}\footnote{In Yosys the term {\it pass} is only used to refer to commands that operate on the RTLIL data structure.}. This AST Frontend then generates a design in Yosys' main internal format, the Register-Transfer-Level-Intermediate-Language (RTLIL) representation. It does that by first performing a number of simplifications within the AST representation and then generating RTLIL from @@ -71,10 +71,10 @@ The RTLIL representation is used by all passes as input and outputs. This has th using different representational formats between different passes: \begin{itemize} -\item The passes can be re-arranged in a different order and passes can be removed or inserted. +\item The passes can be rearranged in a different order and passes can be removed or inserted. \item Passes can simply pass-thru the parts of the design they don't change without the need to convert between formats. In fact Yosys passes output the same data structure they received - as input and perform all changes in place. + as input and performs all changes in place. \item All passes use the same interface, thus reducing the effort required to understand a pass when reading the Yosys source code, e.g.~when adding additional features. \end{itemize} @@ -95,7 +95,7 @@ The use of RTLIL also has the disadvantage of having a very powerful format between all passes, even when doing gate-level synthesis where the more advanced features are not needed. In order to reduce complexity for passes that operate on a low-level representation, these passes check the features used in -the input RTLIL and fail to run when non-supported high-level constructs are +the input RTLIL and fail to run when unsupported high-level constructs are used. In such cases a pass that transforms the higher-level constructs to lower-level constructs must be called from the synthesis script first. diff --git a/manual/CHAPTER_Overview.tex b/manual/CHAPTER_Overview.tex index b9df57d1..ec402231 100644 --- a/manual/CHAPTER_Overview.tex +++ b/manual/CHAPTER_Overview.tex @@ -3,8 +3,8 @@ \label{chapter:overview} Yosys is an extensible open source hardware synthesis tool. It is aimed at -designers who are looking for an easy accessible, universal, and vendor -independent synthesis tool, and scientists who do research in +designers who are looking for an easily accessible, universal, and +vendor-independent synthesis tool, as well as scientists who do research in electronic design automation (EDA) and are looking for an open synthesis framework that can be used to test algorithms on complex real-world designs. @@ -49,7 +49,7 @@ of the backends, namely the Verilog Backend for generating Verilog netlists and the ILANG Backend for writing the RTLIL data in the same format that is understood by the ILANG Frontend. -With the exception of the AST Frontend, that is called by the high-level HDL +With the exception of the AST Frontend, which is called by the high-level HDL frontends and can't be called directly by the user, all program modules are called by the user (usually using a synthesis script that contains text commands for Yosys). @@ -57,7 +57,7 @@ commands for Yosys). By combining passes in different ways and/or adding additional passes to Yosys it is possible to adapt Yosys to a wide range of applications. For this to be possible it is key that (1) all passes operate on the same data structure -(RTLIL) and (2) that this data structure is powerful enough represent the design +(RTLIL) and (2) that this data structure is powerful enough to represent the design in different stages of the synthesis. \begin{figure}[t] @@ -97,7 +97,7 @@ refers to the fact, that RTLIL also has a text representation, usually referred The only exception are the high-level frontends that use the AST representation as an intermediate step before generating RTLIL data. -In order to avoid re-inventing names for the RTLIL classes, they are simply referred to by their full C++ name, i.e.~including +In order to avoid reinventing names for the RTLIL classes, they are simply referred to by their full C++ name, i.e.~including the {\tt RTLIL::} namespace prefix, in this document. Figure~\ref{fig:Overview_RTLIL} shows a simplified Entity-Relationship Diagram (ER Diagram) of RTLIL. In $1:N$ relationships the arrow @@ -105,7 +105,7 @@ points from the $N$ side to the $1$. For example one RTLIL::Design contains $N$ A two-pointed arrow indicates a $1:1$ relationship. The RTLIL::Design is the root object of the RTLIL data structure. There is always one ``current design'' in memory -on which passes operate, frontends add data to it and backends convert to exportable formats. But in some cases passes +which passes operate on, frontends add data to and backends convert to exportable formats. But in some cases passes internally generate additional RTLIL::Design objects. For example when a pass is reading an auxiliary Verilog file such as a cell library, it might create an additional RTLIL::Design object and call the Verilog frontend with this other object to parse the cell library. @@ -154,12 +154,12 @@ transformed to an RTLIL-compatible representation by the HDL frontend. This incl Verilog-features such as generate-blocks, loops and parameters. The following sections contain a more detailed description of the different -parts of RTLIL and rationales behind some of the design decisions. +parts of RTLIL and rationale behind some of the design decisions. \subsection{RTLIL Identifiers} All identifiers in RTLIL (such as module names, port names, signal names, cell -types, etc.) follow the following naming convention: They must either start with +types, etc.) follow the following naming convention: they must either start with a backslash (\textbackslash) or a dollar sign (\$). Identifiers starting with a backslash are public visible identifiers. Usually @@ -172,13 +172,13 @@ identifiers that start with a backslash. This has three advantages: \begin{itemize} -\item Firstly it is impossible that an auto-generated identifier collides with +\item First, it is impossible that an auto-generated identifier collides with an identifier that was provided by the user. -\item Secondly the information about which identifiers were originally +\item Second, the information about which identifiers were originally provided by the user is always available which can help guide some optimizations. For example the ``opt\_rmunused'' -is trying to preserve signals with a user-provided name but doesn't hesitate to delete signals that have +tries to preserve signals with a user-provided name but doesn't hesitate to delete signals that have auto-generated names when they just duplicate other signals. -\item Thirdly the delicate job of finding suitable auto-generated public visible +\item Third, the delicate job of finding suitable auto-generated public visible names is deferred to one central location. Internally auto-generated names that may hold important information for Yosys developers can be used without disturbing external tools. For example the Verilog backend assigns names in the form {\tt \_{\it integer}\_}. @@ -216,7 +216,7 @@ Verilog and VHDL both support parametric modules (known as ``generic entities'' format does not support parametric modules itself. Instead each module contains a callback function into the AST frontend to generate a parametrized variation of the RTLIL::Module as needed. This callback then returns the auto-generated name of the parametrized variation of the module. (A hash -over the parameters and the module name is used to prohibit the same parametrized variation to be +over the parameters and the module name is used to prohibit the same parametrized variation from being generated twice. For modules with only a few parameters, a name directly containing all parameters is generated instead of a hash string.) @@ -233,7 +233,7 @@ An RTLIL::Wire object has the following properties: \begin{itemize} \item The wire name \item A list of attributes -\item A width (busses are just wires with a width > 1) +\item A width (buses are just wires with a width > 1) \item If the wire is a port: port number and direction (input/output/inout) \end{itemize} @@ -256,7 +256,7 @@ An RTLIL::Cell object has the following properties: \end{itemize} The connections of ports to wires are coded by assigning an RTLIL::SigSpec -to each cell ports. The RTLIL::SigSpec data type is described in the next section. +to each cell port. The RTLIL::SigSpec data type is described in the next section. \subsection{RTLIL::SigSpec} @@ -382,7 +382,7 @@ end This pass has transformed the outer RTLIL::SwitchRule into a modified RTLIL::SyncRule object for the {\tt \textbackslash{}reset} signal. Further processing converts the RTLIL::Process -e.g.~into a d-type flip-flop with asynchronous reset and a multiplexer for the enable signal: +into e.g.~a d-type flip-flop with asynchronous reset and a multiplexer for the enable signal: \begin{lstlisting}[numbers=left,frame=single,language=rtlil] cell $adff $procdff$6 @@ -442,31 +442,31 @@ The {\tt memory} pass performs this conversion and can (depending on the options to it) transform the memories directly to d-type flip-flops and address logic or yield multiport memory blocks (represented using {\tt \$mem} cells). -See Sec.~\ref{sec:memcells} for details on the memory cell types. +See Sec.~\ref{sec:memcells} for details about the memory cell types. \section{Command Interface and Synthesis Scripts} Yosys reads and processes commands from synthesis scripts, command line arguments and an interactive command prompt. Yosys commands consist of a command name and an optional -whitespace sparated list of arguments. Commands are terminated using the newline character +whitespace separated list of arguments. Commands are terminated using the newline character or a semicolon ({\tt ;}). Empty lines and lines starting with the hash sign ({\tt \#}) are ignored. See Sec.~\ref{sec:typusecase} for an example synthesis script. The command {\tt help} can be used to access the command reference manual. -Most commands can operate not only on the entire design but also only on {\it selected} +Most commands can operate not only on the entire design but also specifically on {\it selected} parts of the design. For example the command {\tt dump} will print all selected objects in the current design while {\tt dump foobar} will only print the module {\tt foobar} and {\tt dump *} will print the entire design regardless of the current selection. The selection mechanism is very powerful. For example the command {\tt dump */t:\$add \%x:+[A] */w:* \%i} will print all wires that are connected to the \B{A} port of -a {\tt \$add} cell. A detailed documentation of the select framework can be +a {\tt \$add} cell. Detailed documentation of the select framework can be found in the command reference for the {\tt select} command. \section{Source Tree and Build System} -The Yosys source tree is organized in the following top-level directories: +The Yosys source tree is organized into the following top-level directories: \begin{itemize} @@ -512,15 +512,15 @@ and a {\tt Makefile.inc}. The Yosys kernel automatically detects all commands li Yosys. So it is not needed to add additional commands to a central list of commands. \end{sloppypar} -A good starting point for reading example source code for learning how to write passes +Good starting points for reading example source code to learn how to write passes are {\tt passes/opt/opt\_rmdff.cc} and {\tt passes/opt/opt\_share.cc}. See the top-level README file for a quick {\it Getting Started} guide and build -instructions. Yosys is a pure Makefile based project. +instructions. The Yosys build is based solely on Makefiles. Users of the Qt Creator IDE can generate a QT Creator project file using {\tt make qtcreator}. Users of the Eclipse IDE can use the ``Makefile Project with Existing Code'' project type in the Eclipse ``New Project'' dialog (only -available after the CDT plugin has been installed) to create an Eclipse Project -for programming extensions to Yosys or just browsing the Yosys code base. +available after the CDT plugin has been installed) to create an Eclipse project +in order to programming extensions to Yosys or just browse the Yosys code base. |