mirrors/yosys
3
0
Fork 0
mirror of https://github.com/YosysHQ/yosys synced 2025-08-25 12:36:02 +00:00
Code Activity

Typos and grammar fixes through chapter 4.

Browse source
This commit is contained in:
Anthony J. Bentley 2014-05-02 03:08:40 -06:00
parent 7188542155
commit 154c9f8b51
2 changed files with 32 additions and 32 deletions
Download patch file Download diff file Expand all files Collapse all files

14
manual/CHAPTER_Approach.tex
View file

@ -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.