Corrected spelling mistakes found by lintian

5 files changed, 13 insertions, 13 deletions

diff --git a/manual/CHAPTER_Prog/stubnets.cc b/manual/CHAPTER_Prog/stubnets.cc
index 4d1452c97..ef4b1245d 100644
--- a/manual/CHAPTER_Prog/stubnets.cc
+++ b/manual/CHAPTER_Prog/stubnets.cc
@@ -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):
diff --git a/manual/CHAPTER_Techmap.tex b/manual/CHAPTER_Techmap.tex
index 26632d0b5..e5c7456c4 100644
--- a/manual/CHAPTER_Techmap.tex
+++ b/manual/CHAPTER_Techmap.tex
@@ -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
diff --git a/manual/CHAPTER_Verilog.tex b/manual/CHAPTER_Verilog.tex
index 960747747..485b4f357 100644
--- a/manual/CHAPTER_Verilog.tex
+++ b/manual/CHAPTER_Verilog.tex
@@ -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
diff --git a/manual/command-reference-manual.tex b/manual/command-reference-manual.tex
index 9d9665c1e..35249ed88 100644
--- a/manual/command-reference-manual.tex
+++ b/manual/command-reference-manual.tex
@@ -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.
 
diff --git a/manual/manual.tex b/manual/manual.tex
index c305ecb05..19d3b7b2f 100644
--- a/manual/manual.tex
+++ b/manual/manual.tex
@@ -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.