mirror of
https://github.com/YosysHQ/yosys
synced 2025-08-07 19:51:23 +00:00
Corrected spelling mistakes found by lintian
This commit is contained in:
parent
01ef34c147
commit
79cbf9067c
22 changed files with 39 additions and 39 deletions
|
@ -57,7 +57,7 @@ static void find_stub_nets(RTLIL::Design *design, RTLIL::Module *module, bool re
|
|||
// we will record which bits of the (possibly multi-bit) wire are stub signals
|
||||
std::set<int> stub_bits;
|
||||
|
||||
// get a signal description for this wire and split it into seperate bits
|
||||
// get a signal description for this wire and split it into separate bits
|
||||
RTLIL::SigSpec sig = sigmap(wire);
|
||||
|
||||
// for each bit (unless it is a constant):
|
||||
|
|
|
@ -32,7 +32,7 @@ the Yosys source tree.
|
|||
|
||||
Additional features have been added to {\tt techmap} to allow for conditional
|
||||
mapping of cells (see {\tt help techmap} or Sec.~\ref{cmd:techmap}). This can
|
||||
for example be usefull if the target architecture supports hardware multipliers for
|
||||
for example be useful if the target architecture supports hardware multipliers for
|
||||
certain bit-widths but not for others.
|
||||
|
||||
A usual synthesis flow would first use the {\tt techmap} pass to directly map
|
||||
|
|
|
@ -444,7 +444,7 @@ on the AST data structure:
|
|||
\begin{itemize}
|
||||
\item Inline all task and function calls.
|
||||
\item Evaluate all \lstinline[language=Verilog]{generate}-statements and unroll all \lstinline[language=Verilog]{for}-loops.
|
||||
\item Perform const folding where it is neccessary (e.g.~in the value part of {\tt AST\_PARAMETER}, {\tt AST\_LOCALPARAM},
|
||||
\item Perform const folding where it is necessary (e.g.~in the value part of {\tt AST\_PARAMETER}, {\tt AST\_LOCALPARAM},
|
||||
{\tt AST\_PARASET} and {\tt AST\_RANGE} nodes).
|
||||
\item Replace {\tt AST\_PRIMITIVE} nodes with appropriate {\tt AST\_ASSIGN} nodes.
|
||||
\item Replace dynamic bit ranges in the left-hand-side of assignments with {\tt AST\_CASE} nodes with {\tt AST\_COND} children
|
||||
|
@ -819,7 +819,7 @@ the \C{RTLIL::SyncRule}s that describe the output registers.
|
|||
%
|
||||
\item {\tt proc\_dff} \\
|
||||
This pass replaces the \C{RTLIL::SyncRule}s to d-type flip-flops (with
|
||||
asynchronous resets if neccessary).
|
||||
asynchronous resets if necessary).
|
||||
%
|
||||
\item {\tt proc\_clean} \\
|
||||
A final call to {\tt proc\_clean} removes the now empty \C{RTLIL::Process} objects.
|
||||
|
@ -827,7 +827,7 @@ A final call to {\tt proc\_clean} removes the now empty \C{RTLIL::Process} objec
|
|||
|
||||
Performing these last processing steps in passes instead of in the Verilog frontend has two important benefits:
|
||||
|
||||
First it improves the transparency of the process. Everything that happens in a seperate pass is easier to debug,
|
||||
First it improves the transparency of the process. Everything that happens in a separate pass is easier to debug,
|
||||
as the RTLIL data structures can be easily investigated before and after each of the steps.
|
||||
|
||||
Second it improves flexibility. This scheme can easily be extended to support other types of storage-elements, such
|
||||
|
|
|
@ -85,10 +85,10 @@ This is just a shortcut for 'select -clear'.
|
|||
|
||||
This is identical to 'opt_clean', but less verbose.
|
||||
|
||||
When commands are seperated using the ';;' token, this command will be executed
|
||||
When commands are separated using the ';;' token, this command will be executed
|
||||
between the commands.
|
||||
|
||||
When commands are seperated using the ';;;' token, this command will be executed
|
||||
When commands are separated using the ';;;' token, this command will be executed
|
||||
in -purge mode between the commands.
|
||||
\end{lstlisting}
|
||||
|
||||
|
@ -419,7 +419,7 @@ commands.
|
|||
hierarchy [-check] [-top <module>]
|
||||
hierarchy -generate <cell-types> <port-decls>
|
||||
|
||||
In parametric designs, a module might exists in serveral variations with
|
||||
In parametric designs, a module might exists in several variations with
|
||||
different parameter values. This pass looks at all modules in the current
|
||||
design an re-runs the language frontends for the parametric modules as
|
||||
needed.
|
||||
|
@ -881,7 +881,7 @@ The following options can be used to set up a sequential problem:
|
|||
-set-def-at <N> <signal>
|
||||
-set-any-undef-at <N> <signal>
|
||||
-set-all-undef-at <N> <signal>
|
||||
add undef contraints in the given timestep.
|
||||
add undef constraints in the given timestep.
|
||||
|
||||
-set-init <signal> <value>
|
||||
set the initial value for the register driving the signal to the value
|
||||
|
@ -942,7 +942,7 @@ design.
|
|||
|
||||
-all_cell_types
|
||||
Usually this command only considers internal non-memory cells. With
|
||||
this option set, all cells are considered. For unkown cells all ports
|
||||
this option set, all cells are considered. For unknown cells all ports
|
||||
are assumed to be bidirectional 'inout' ports.
|
||||
|
||||
-set_attr <name> <value>
|
||||
|
@ -1089,7 +1089,7 @@ The following actions can be performed on the top sets on the stack:
|
|||
(i.e. select all cells connected to selected wires and select all
|
||||
wires connected to selected cells) The rules specify which cell
|
||||
ports to use for this. the syntax for a rule is a '-' for exclusion
|
||||
and a '+' for inclusion, followed by an optional comma seperated
|
||||
and a '+' for inclusion, followed by an optional comma separated
|
||||
list of cell types followed by an optional comma separated list of
|
||||
cell ports in square brackets. a rule can also be just a cell or wire
|
||||
name that limits the expansion (is included but does not go beyond).
|
||||
|
@ -1452,7 +1452,7 @@ Write the current design to an BLIF file.
|
|||
-false <cell-type> <out-port>
|
||||
use the specified cell types to drive nets that are constant 1 or 0
|
||||
|
||||
The following options can be usefull when the generated file is not going to be
|
||||
The following options can be useful when the generated file is not going to be
|
||||
read by a BLIF parser but a custom tool. It is recommended to not name the output
|
||||
file *.blif when any of this options is used.
|
||||
|
||||
|
|
|
@ -144,7 +144,7 @@ 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
|
||||
testing new synthesis algorithms it might be neccessary to write a custom HDL
|
||||
testing new synthesis algorithms it might be necessary to write a custom HDL
|
||||
synthesis tool or add new features to an existing one. It this cases the
|
||||
availability of a Free and Open Source (FOSS) synthesis tool that can be used
|
||||
as basis for custom tools would be helpful.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue