From 715ee5631419533e78c4ba22ca480d508cf0cfd6 Mon Sep 17 00:00:00 2001 From: Ruben Undheim Date: Sun, 30 Sep 2018 21:16:21 +0200 Subject: [PATCH] Spelling fixes found by Debian lintian --- doc/source/manual/conversion.rst | 34 +++++++++---------- doc/source/manual/conversion_examples.rst | 4 +-- doc/source/manual/cosimulation.rst | 2 +- doc/source/manual/reference.rst | 4 +-- doc/source/whatsnew/0.4.rst | 2 +- doc/source/whatsnew/0.5.rst | 16 ++++----- doc/source/whatsnew/0.6.rst | 40 +++++++++++------------ doc/source/whatsnew/0.7.rst | 14 ++++---- doc/source/whatsnew/0.8.rst | 2 +- doc/source/whatsnew/0.9.rst | 6 ++-- 10 files changed, 62 insertions(+), 62 deletions(-) diff --git a/doc/source/manual/conversion.rst b/doc/source/manual/conversion.rst index 3d1df941..28f3db04 100644 --- a/doc/source/manual/conversion.rst +++ b/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 diff --git a/doc/source/manual/conversion_examples.rst b/doc/source/manual/conversion_examples.rst index 4ab08af6..33c62a5c 100644 --- a/doc/source/manual/conversion_examples.rst +++ b/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. diff --git a/doc/source/manual/cosimulation.rst b/doc/source/manual/cosimulation.rst index 62d8ef17..14cf9a68 100644 --- a/doc/source/manual/cosimulation.rst +++ b/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. diff --git a/doc/source/manual/reference.rst b/doc/source/manual/reference.rst index 6c664f4b..41c53a8a 100644 --- a/doc/source/manual/reference.rst +++ b/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. diff --git a/doc/source/whatsnew/0.4.rst b/doc/source/whatsnew/0.4.rst index 933fa4ec..f51aaf93 100644 --- a/doc/source/whatsnew/0.4.rst +++ b/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. diff --git a/doc/source/whatsnew/0.5.rst b/doc/source/whatsnew/0.5.rst index a66d5128..3c6a0641 100644 --- a/doc/source/whatsnew/0.5.rst +++ b/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. diff --git a/doc/source/whatsnew/0.6.rst b/doc/source/whatsnew/0.6.rst index cc5b7cad..9eb6bcdb 100644 --- a/doc/source/whatsnew/0.6.rst +++ b/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 convertor automates a number of tasks that are hard to do in +The converter automates a number of hard tasks + 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 -compatible with the convertor to VHDL. Currently, the VHDL solution +no longer supported by the converter to Verilog. This is done to be +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. diff --git a/doc/source/whatsnew/0.7.rst b/doc/source/whatsnew/0.7.rst index 71d8f780..2d0fc295 100644 --- a/doc/source/whatsnew/0.7.rst +++ b/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 diff --git a/doc/source/whatsnew/0.8.rst b/doc/source/whatsnew/0.8.rst index fc8bf964..2555d113 100644 --- a/doc/source/whatsnew/0.8.rst +++ b/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``). diff --git a/doc/source/whatsnew/0.9.rst b/doc/source/whatsnew/0.9.rst index ed7e7a87..d5e619d1 100644 --- a/doc/source/whatsnew/0.9.rst +++ b/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.