Spelling fixes found by Debian lintian

doc/source/manual/conversion.rst

@@ -79,7 +79,7 @@ The module ports are inferred from signal usage
 
 Interfaces are convertible 
   An *interface*: an object that has a number of :class:`Signal` objects as its
-  attributes. The convertor supports this by name expansion and mangling.
+  attributes. The converter supports this by name expansion and mangling.
 
 Function calls are mapped to Verilog or VHDL subprograms
   The converter analyzes function calls and function code. Each function is
@@ -130,7 +130,7 @@ Signed arithmetic
   resizings and type casts.
 
   In MyHDL, these issues don't exist because ``intbv`` objects simply
-  work as (constrained) integers. Moreover, the convertor automates
+  work as (constrained) integers. Moreover, the converter automates
   the cumbersome tasks that are required in Verilog and
   VHDL. It uses signed or unsigned types based on the value
   constraints of the intbv objects, and automatically performs the
@@ -216,7 +216,7 @@ follows::
 Such as slice returns a new :class:`intbv` object, with minimum value
 ``0`` , and maximum value ``2**N``.
 
-In addition to the scalar types described above, the convertor also
+In addition to the scalar types described above, the converter also
 supports a number of tuple and list based types. The mapping from
 MyHDL types is summarized in the following table.
 
@@ -267,7 +267,7 @@ Notes:
    Lists are mapped to Verilog memories. 
 
 
-The table as presented applies to MyHDL variables. The convertor also
+The table as presented applies to MyHDL variables. The converter also
 supports MyHDL signals that use ``bool``, ``intbv`` or ``enum``
 objects as their underlying type. For VHDL, these are mapped to VHDL signals
 with an underlying type as specified in the table above. Verilog doesn't have
@@ -275,7 +275,7 @@ the signal concept. For Verilog, a MyHDL signal is mapped to a Verilog
 ``reg`` as in the table above, or to a Verilog ``wire``, depending
 on the signal usage.
 
-The convertor supports MyHDL list of signals provided the underlying
+The converter supports MyHDL list of signals provided the underlying
 signal type is either ``bool`` or ``intbv``. They may be mapped to a
 VHDL signal with a VHDL type as specified in the table, or to a
 Verilog memory.  However, list of signals are not always mapped to a
@@ -381,12 +381,12 @@ converter.
 Docstrings
 ----------
 
-The convertor propagates comments under the form of Python
+The converter propagates comments under the form of Python
 docstrings.
 
 Docstrings are typically used in Python to document certain objects in
 a standard way. Such "official" docstrings are put into the converted
-output at appropriate locations.  The convertor supports official
+output at appropriate locations.  The converter supports official
 docstrings for the top level module and for generators.
 
 Within generators, "nonofficial" docstrings are propagated also. These
@@ -409,7 +409,7 @@ Lists of signals are useful for many purposes. For example, they make
 it easy to create a repetitive structure. Another application is the
 description of memory behavior.
 
-The convertor output is non-hierarchical. That implies that all
+The converter output is non-hierarchical. That implies that all
 signals are declared at the top-level in VHDL or Verilog (as VHDL
 signals, or Verilog regs and wires.)  However, some signals that are a
 list member at some level in the MyHDL design hierarchy may be used as
@@ -439,7 +439,7 @@ modelled by an *interface*: an object that has a number of :class:`Signal`
 objects as its attributes.  Grouping signals into an interface simplifies the
 code, improves efficiency, and reduces errors.
 
-The convertor supports interface using hierarchical name expansion and name
+The converter supports interface using hierarchical name expansion and name
 mangling. 
 
 .. _conv-meth-assign:
@@ -550,7 +550,7 @@ Excluding code from conversion
 For some tasks, such as debugging, it may be useful to insert arbitrary Python
 code that should not be converted.
 
-The convertor supports this by ignoring all code that is embedded in a
+The converter supports this by ignoring all code that is embedded in a
 ``if __debug__`` test. The value of the ``__debug__`` variable is not taken into
 account.
 
@@ -566,14 +566,14 @@ MyHDL provides a way to include user-defined code during the
 conversion process. There are special function attributes that are understood by the
 converter but ignored by the simulator. The attributes are :attr:`verilog_code`
 for Verilog and :attr:`vhdl_code` for VHDL.  They operate like a special
-return value. When defined in a MyHDL function, the convertor will use
+return value. When defined in a MyHDL function, the converter will use
 their value instead of the regular return value. Effectively, it will
 stop converting at that point.
 
 The value of :attr:`verilog_code` or :attr:`vhdl_code` should be a Python
 template string. A template string supports ``$``-based substitutions.
 The ``$name`` notation can be used to refer to the
-variable names in the context of the string. The convertor will
+variable names in the context of the string. The converter will
 substitute the appropriate values in the string and then insert it 
 instead of the regular converted output.
 
@@ -636,7 +636,7 @@ It is converted to VHDL as follows::
     end process DFF_LOGIC;
 
 
-The convertor can handle the more general case. For example, this is
+The converter can handle the more general case. For example, this is
 MyHDL code for a D flip-flop with asynchronous set, asynchronous
 reset, and preference of set over reset::
 
@@ -668,7 +668,7 @@ This is converted to VHDL as follows::
 
 All cases with practical utility can be handled in this way. However,
 there are other cases that cannot be transformed to equivalent
-VHDL. The convertor will detect those cases and give an error.
+VHDL. The converter will detect those cases and give an error.
 
 
 .. _conv-meth-conv:
@@ -681,7 +681,7 @@ Conversion output verification by co-simulation
 To verify the converted Verilog output, co-simulation can be used. To
 make this task easier, the converter also generates a test bench that
 makes it possible to simulate the Verilog design using the Verilog
-co-simulation interface. This permits to verify the Verilog code with
+co-simulation interface. This permits one to verify the Verilog code with
 the same test bench used for the MyHDL code.
 
 
@@ -699,7 +699,7 @@ An alternative is to convert the test bench itself, so that
 both test bench and design can be run in the HDL simulator. Of course,
 this is not a fully general solution, as there are important
 constraints on the kind of code that can be converted.
-Thus, the question is whether the conversion restrictions permit to develop
+Thus, the question is whether the conversion restrictions permit one to develop
 sufficiently complex test benches. In this section, we present some
 insights about this.
 
@@ -781,7 +781,7 @@ instance, and insert an instantiation instead.
 There is a workaround to accomplish this with a small amount of additional
 work. The workaround is to define user-defined code consisting of an
 instantiation of the design under test. As discussed in :ref:`conv-custom`,
-when the convertor sees the hook it will stop converting and insert the
+when the converter sees the hook it will stop converting and insert the
 instantiation instead. Of course, you will want to convert the design
 under test itself also. Therefore, you should use a flag that controls
 whether the hook is defined or not and set it according to the

doc/source/manual/conversion_examples.rst

@@ -40,7 +40,7 @@ The conversion to Verilog generates an equivalent Verilog module in file
 
 .. include-example:: inc.v
 
-The convertor infers a proper Verilog module interface and maps the MyHDL
+The converter infers a proper Verilog module interface and maps the MyHDL
 generator to a Verilog always block.
 
 Similarly, the conversion to VHDL generates a file :file:`inc.vhd` with  the
@@ -57,7 +57,7 @@ functions that make the conversion easier.
 Note also the use of an ``inout`` in the interface.  This is not
 recommended VHDL design practice, but it is required here to have a
 valid VHDL design that matches the behavior of the MyHDL design. As
-this is only an issue for ports and as the convertor output is
+this is only an issue for ports and as the converter output is
 non-hierarchical, the issue is not very common and has an easy
 workaround.
 

doc/source/manual/cosimulation.rst

@@ -295,7 +295,7 @@ blocking assignment events have been processed.
 
 Consequently, I had to look for a workaround. One half of the solution is to use
 the ``cbReadOnlySync`` callback.  This callback runs after all pending events
-have been processed.  However, it does not permit to create new events in the
+have been processed.  However, it does not permit one to create new events in the
 current time step.  The second half of the solution is to map MyHDL delta cycles
 onto real Verilog time steps.  Note that fortunately I had some freedom here
 because of the restriction that only passive HDL code can be co-simulated.

doc/source/manual/reference.rst

@@ -280,7 +280,7 @@ Regular signals
 
     This Signal subclass defines reset signals. *val*, *active*, and *isasync*
     are mandatory arguments.
-    *val* is a boolean value that specifies the intial value,
+    *val* is a boolean value that specifies the initial value,
     *active* is a boolean value that specifies the active level.
     *isasync* is a boolean value that specifies the reset style:
     asynchronous (``True``) or synchronous (``False``).
@@ -544,7 +544,7 @@ The :class:`intbv` class
 
     .. method:: signed()
 
-       Interpretes the msb bit as as sign bit and extends it into the higher-order
+       Interprets the msb bit as as sign bit and extends it into the higher-order
        bits of the underlying object value. The msb bit is the highest-order bit
        within the object's bit width.
 

doc/source/whatsnew/0.4.rst

@@ -247,7 +247,7 @@ Conversion output verification
 It is always prudent to verify the converted Verilog output. To make
 this task easier, the converter also generates a test bench that makes
 it possible to simulate the Verilog design using the Verilog
-co-simulation interface. This permits to verify the Verilog code with
+co-simulation interface. This permits one to verify the Verilog code with
 the same test bench used for the MyHDL code. This is also how the
 Verilog converter development is being verified.
 

doc/source/whatsnew/0.5.rst

@@ -220,14 +220,14 @@ Verilog conversion
 Decorator support
 -----------------
 
-The Verilog convertor was enhanced to support the proposed decorators.
+The Verilog converter was enhanced to support the proposed decorators.
 
 Mapping a list of signals to a RAM memory 
 -----------------------------------------
 
 Certain synthesis tools can map Verilog memories to memory structures. For
 example, this is supported by the Xilinx toolset. To support this interesting
-feature, the Verilog convertor now maps lists of signals in MyHDL to Verilog
+feature, the Verilog converter now maps lists of signals in MyHDL to Verilog
 memories.
 
 The following MyHDL example is a ram model that uses a list of signals to model
@@ -288,7 +288,7 @@ Lists of signals can also be used in MyHDL to elegantly describe iterative
 hierarchical structures. (See the MyHDL manual.) However, there is an important
 difference: such signals will have a name at some level of the hierarchy, while
 in the case described above, the individual signals are anonymous. The
-:func:`toVerilog` convertor detects which case we are in. In the first case,
+:func:`toVerilog` converter detects which case we are in. In the first case,
 the individual signals will still be declared in the Verilog output, using the
 highest-level hierarchical name. It is only in the second case that the list of
 signals is declared as a Verilog memory.
@@ -382,16 +382,16 @@ If required, you can access the 2's complement representation of an
 :class:`intbv` object, but for integer operations such a counting, there is no
 need to worry about this.
 
-Of course, the Verilog convertor has to deal with the representation carefully.
+Of course, the Verilog converter has to deal with the representation carefully.
 MyHDL 0.4 avoided the issue by simply prohibiting :class:`intbv` objects with
 negative values. MyHDL 0.5 adds support for negative values and uses the signed
 Verilog representation to accomplish this.
 
 The problematic cases are those when signed and unsigned representations are
-mixed in Verilog expressions. The convertor avoids this by making sure that
+mixed in Verilog expressions. The converter avoids this by making sure that
 signed arithmetic is used whenever one of the operands is signed. Note that
 this is exactly the opposite of the Verilog default. More specifically, the
-convertor may convert an unsigned operand by adding a sign bit and casting to a
+converter may convert an unsigned operand by adding a sign bit and casting to a
 signed interpretation, using the Verilog ``$signed`` function. Operands that
 are treated like this are positive :class:`intbv` objects, slices and
 subscripts of :class:`intbv` objects, and :class:`bool` objects.
@@ -458,7 +458,7 @@ needs to be escaped (by doubling it) if it is required in the user-defined
 code.
 
 There is one more issue that needs user attention. Normally, the Verilog
-convertor infers inputs, internal signals, and outputs. It also detects
+converter infers inputs, internal signals, and outputs. It also detects
 undriven and multiple driven signals. To do this, it assumes that signals are
 not driven by default. It then processes the code to find out which signals are
 driven from where. However, it cannot do this for user-defined code. Without
@@ -540,7 +540,7 @@ MyHDL supports a number of "trigger objects". These are the objects that can
 occur in ``yield`` statements, for example :class:`delay`, ``posedge``,
 :class:`Signal`, and generator objects. Each of these are handled differently
 and so the simulation loop has to account for the object type. Prior to MyHDL
-0.5, this type check was explicitly done for each occurence of a ``yield``
+0.5, this type check was explicitly done for each occurrence of a ``yield``
 statement during simulation. As many generators will loop endlessly, it is
 clear that the same things will be checked over and over again, resulting in an
 important overhead.

doc/source/whatsnew/0.6.rst

@@ -16,16 +16,16 @@ Rationale
 Since the MyHDL to Verilog conversion has been developed, a path to
 implementation from MyHDL is available. Given the widespread support
 for Verilog, it could thus be argued that there was no real need for a
-convertor to VHDL.
+converter to VHDL.
 
 However, it turns out that VHDL is still very much alive and will
-remain so for the forseeable future. This is especially true for the
+remain so for the foreseeable future. This is especially true for the
 FPGA market, which is especially interesting for MyHDL. It seems much
 more dynamic than the ASIC market. Moreover, because of the nature of
 FPGA's, FPGA designers may be more willing to try out new ideas.
 
 To convince designers to use a new tool, it should integrate with
-their current design flow. That is why the MyHDL to VHDL convertor is
+their current design flow. That is why the MyHDL to VHDL converter is
 needed. It should lower the threshold for VHDL designers to start
 using MyHDL.
 
@@ -38,12 +38,12 @@ MyHDL integration in a VHDL-based design flow
     Designers can start using MyHDL and benefit from its power and
     flexibility, within the context of their proven design flow.
 
-The convertor automates a number of hard tasks 
+The converter automates a number of hard tasks 
-    The convertor automates a number of tasks that are hard to do in
+    The converter automates a number of tasks that are hard to do in
     VHDL directly. For example, when mixing ``unsigned`` and ``signed``
     types it can be difficult to describe the desired behavior
     correctly.  In contrast, a MyHDL designer can use the high-level
-    ``intbv`` type, and let the convertor deal with type
+    ``intbv`` type, and let the converter deal with type
     conversions and resizings.
 
 MyHDL as an IP development platform 
@@ -64,7 +64,7 @@ Approach
 The approach followed to convert MyHDL code to VHDL is identical to
 the one followed for conversion to Verilog in previous MyHDL releases.
 
-In particular, the MyHDL code analyzer in the convertor is identical
+In particular, the MyHDL code analyzer in the converter is identical
 for both target languages. The goal is that all MyHDL code that can be
 converted to Verilog can be converted to VHDL also, and
 vice versa. This has been achieved except for a few minor issues due
@@ -106,7 +106,7 @@ Type mapping
 
 
 In contrast to Verilog, VHDL is a strongly typed language. The
-convertor has to carefully perform type inferencing, and handle type
+converter has to carefully perform type inferencing, and handle type
 conversions and resizings appropriately. To do this right, a
 well-chosen mapping from MyHDL types to VHDL types is crucial.
 
@@ -156,11 +156,11 @@ Notes:
 The table as presented applies to MyHDL variables. They are mapped to
 VHDL variables (except for the case of a ``tuple`` of ``int``).
 
-The convertor also supports MyHDL signals that use ``bool``,
+The converter also supports MyHDL signals that use ``bool``,
 ``intbv`` or ``enum`` objects as their underlying type. These are mapped to
 VHDL signals with a type as specified in the table above.
 
-The convertor supports MyHDL list of signals provided the underlying
+The converter supports MyHDL list of signals provided the underlying
 signal type is either ``bool`` or ``intbv``. They may be mapped to a VHDL
 signal with a VHDL type as specified in the table.
 However, list of signals are not always mapped to a corresponding VHDL
@@ -201,7 +201,7 @@ It is converted to VHDL as follows::
     end process DFF_LOGIC;
 
 
-The convertor can handle the more general case. For example, this is
+The converter can handle the more general case. For example, this is
 MyHDL code for a D flip-flop with asynchronous set, asynchronous
 reset, and preference of set over reset::
 
@@ -233,7 +233,7 @@ This is converted to VHDL as follows::
 
 All cases with practical utility can be handled in this way. However,
 there are other cases that cannot be transformed to equivalent
-VHDL. The convertor will detect those cases and give an error.
+VHDL. The converter will detect those cases and give an error.
 
 
 .. _new06-listofsigs:
@@ -245,7 +245,7 @@ Lists of signals are useful for many purposes. For example, they make
 it easy to create a repetitive structure. Another application is the
 description of memory behavior.
 
-The convertor output is non-hierarchical. That implies that all
+The converter output is non-hierarchical. That implies that all
 signals are declared at the top-level in VHDL or Verilog (as VHDL
 signals, or Verilog regs and wires.)  However, some signals that are a
 list member at some level in the design hierarchy may be used as
@@ -263,7 +263,7 @@ Conversely, when list syntax is used in some generator, then a Verilog
 memory or VHDL array will be declared. The typical example is the
 description of RAM memories.
 
-The convertor in the previous MyHDL release had a severe restriction
+The converter in the previous MyHDL release had a severe restriction
 on the latter case: it didn't allow that, for a certain signal, list
 syntax was used in some generator, and plain signal syntax in another.
 This restriction, together with its rather obscure error message, has
@@ -381,7 +381,7 @@ They can now be converted.
 Methodology notes
 -----------------
 
-The question is whether the conversion restrictions permit to develop
+The question is whether the conversion restrictions permit one to develop
 sufficiently complex test benches. In this section, we present some
 insights about this.
 
@@ -420,13 +420,13 @@ Conversion output verification
 
 .. note:: This functionality is not needed in a typical
           design flow. It is only relevant to debug the
-          MyHDL convertor itself.
+          MyHDL converter itself.
 
 
 Approach
 --------
 
-To verify the convertor output, a methodology has been developed and
+To verify the converter output, a methodology has been developed and
 implemented that doesn't rely on co-simulation and works for both
 Verilog and VHDL.
 
@@ -584,7 +584,7 @@ behavior, or even a bug.
 
 In the present release, lists of signals are considered and
 the corresponding signals are added to the sensitivity list.
-The convertor to Verilog and VHDL is adapted accordingly.
+The converter to Verilog and VHDL is adapted accordingly.
 
 
 Backwards incompatible changes
@@ -629,8 +629,8 @@ Conversion of printing without a newline
 ----------------------------------------
 
 Printing without a newline (a print statement followed by a comma) is
-no longer supported by the convertor to Verilog. This is done to be
+no longer supported by the converter to Verilog. This is done to be
-compatible with the convertor to VHDL. Currently, the VHDL solution
+compatible with the converter to VHDL. Currently, the VHDL solution
 relies on ``std.textio`` and this implies that printing without a
 newline cannot be reliably converted.
 

doc/source/whatsnew/0.7.rst

@@ -61,7 +61,7 @@ parent signal values. For simulation, the transformation is defined by
 a generator which is automatically created and added to the list of
 generators to be simulated. For conversion, the constructor defines
 a piece of dedicated Verilog and VHDL code which is automatically
-added to the convertor output.
+added to the converter output.
 
 Currently, three kinds of shadow signals have been implemented.  The
 original inspiration for shadow signals was to have solution for
@@ -217,7 +217,7 @@ indexing and slicing. This conversion is no longer required;
 the objects can be used directly.
 The corresponding classes now have an :func:`__index__` method
 that takes care of the type conversion automatically.
-This feature is fully supported by the VHDL/Verilog convertor.
+This feature is fully supported by the VHDL/Verilog converter.
 
 
 New configuration attributes for conversion file headers
@@ -263,12 +263,12 @@ The same interpolation variables are available in custom headers.
 Conversion propagates docstrings
 ================================
 
-The convertor now propagates comments under the form of Python
+The converter now propagates comments under the form of Python
 docstrings.
 
 Docstrings are typically used in Python to document certain objects in
 a standard way. Such "official" docstrings are put into the converted
-output at appropriate locations.  The convertor supports official
+output at appropriate locations.  The converter supports official
 docstrings for the top level module and for generators.
 
 Within generators, "nonofficial" docstrings are propagated also. These
@@ -333,7 +333,7 @@ is deprecated and will be unsupported in the future.
 More powerful mapping to case statements
 ========================================
 
-The convertor has become more powerful to map if-then-else structures
+The converter has become more powerful to map if-then-else structures
 to case statements in VHDL and Verilog. Previously, only
 if-then-else structures testing enumerated types were considered.
 Now, integer tests are considered also.
@@ -368,14 +368,14 @@ most likely not an issue.
 Combinatorial always blocks use blocking assignments
 ----------------------------------------------------
 
-The convertor now uses blocking assignments for combinatorial
+The converter now uses blocking assignments for combinatorial
 always blocks in Verilog. This is in line with generally
 accepted Verilog coding conventions.
 
 No synthesis pragmas in Verilog output
 --------------------------------------
 
-The convertor no longer outputs the synthesis pragmas
+The converter no longer outputs the synthesis pragmas
 ``full_case`` and ``parallel_case``. These pragmas do
 more harm than good as they can cause simulation-synthesis
 mismatches. Synthesis tools should be able to infer the

doc/source/whatsnew/0.8.rst

@@ -223,7 +223,7 @@ Interface
 
     This :class:`Signal` subclass defines reset signals. *val*, *active*, and *async*
     are mandatory arguments.
-    *val* is a boolean value that specifies the intial value,
+    *val* is a boolean value that specifies the initial value,
     *active* is a boolean value that specifies the active level.
     *async* is a boolean value that specifies the reset style:
     asynchronous (``True``) or asynchronous (``False``).

doc/source/whatsnew/0.9.rst

@@ -63,9 +63,9 @@ MyHDL module instance. The converter will essentially replace the "." with an
 "_" for each interface element. In essence, interfaces are supported
 using hierarchical name expansion and name mangling. 
 
-Note that the MyHDL convertor supports interfaces, even though
+Note that the MyHDL converter supports interfaces, even though
 the target HDLs do not. This is another great example where the
-convertor supports a high-level feature that is not available
+converter supports a high-level feature that is not available
 in the target HDLs.
 
 See also
@@ -88,7 +88,7 @@ in the concatenation.
 ``std_logic`` type ports 
 ------------------------
 
-:func:`toVHDL` has a new attibute ``std_logic_ports``. When
+:func:`toVHDL` has a new attribute ``std_logic_ports``. When
 set, only ``std_logic`` type ports are used in the interface
 of the top-level VHDL module.