summaryrefslogtreecommitdiff
path: root/manual/CHAPTER_Approach.tex
diff options
context:
space:
mode:
Diffstat (limited to 'manual/CHAPTER_Approach.tex')
-rw-r--r--manual/CHAPTER_Approach.tex14
1 files changed, 7 insertions, 7 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.