\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}).
\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
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
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}
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.
\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.
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).
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]
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
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.
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
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}\_}.
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.)
\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}
\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}
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
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}
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.
projects / yosys.git / commitdiff