Fix typos in documentation and source code

docs/about.rst

@@ -93,7 +93,7 @@ Getting Started
 
 There are a number of ways to get started.
 
--  :ref:`VUnit User Guide <user_guide>` will guide users on how to use start using the basic features of VUnit but also
+-  :ref:`VUnit User Guide <user_guide>` will guide users on how to start using the basic features of VUnit but also
    provides information about more specific and advanced usage.
 -  :ref:`Run Library User Guide <run_library>` presents the run packages.
 -  :ref:`Check Library User Guide <check_library>` presents the check packages.

docs/blog/2015_09_24_short_introduction_to_vunit.rst

@@ -77,7 +77,7 @@ number of other useful features. For example,
    Message passing can be used for sending transactions without some of
    the limitations of pin-wiggling and procedure-based transactions but
    it is also the basis for several other communication patterns. For
-   more info see the user :vunit_file:`guide <vunit/vhdl/com/user_guide.md>`.
+   more info see the :vunit_file:`com user guide <vunit/vhdl/com/user_guide.md>`.
 
 -  An array package that can handle multidimensional arrays. It's
    typically used for input and output data sets to the DUT. The package
@@ -88,7 +88,7 @@ number of other useful features. For example,
    output, different output levels, filtering on level and design
    hierarchy, output formatting, automatic file and line localization of
    log entries, multiple loggers, and spreadsheet tool integration. For
-   more information see the user :vunit_file:`guide <vunit/vhdl/logging/user_guide.md>`.
+   more information see the :vunit_file:`logging user guide <vunit/vhdl/logging/user_guide.md>`.
 
 VUnit is a truly open project formed by its community. If you want to
 follow the progress you can click on "watch" on the project

docs/blog/2016_11_16_vunit_the_best_value_for_initial_effort_part2.rst

@@ -40,7 +40,7 @@ currently ModelSim/Questa, Riviera-Pro, Active-HDL, GHDL, and Cadence
 Incisive. Support for other simulators is `planned
 <http://github.com/VUnit/vunit/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3A%22simulator%20support%22>`__.
 
-I my next blog I will use the same script to also run all the
+In my next blog I will use the same script to also run all the
 testbenches in my project and present a test report. Until then you
 can have a more detailed look at the script created by downloading the
 `example project <http://github.com/LarsAsplund/udp_ip_stack>`__.

docs/blog/2017_01_12_vunit_getting_started_1_2_3.rst

@@ -5,7 +5,7 @@
 VUnit - Getting Started 1-2-3
 =============================
 
-I recently a started a LinkedIn blog series about getting started with VUnit. The
+I recently started a LinkedIn blog series about getting started with VUnit. The
 first three parts are:
 
 1. `Installing VUnit in 1 minute <https://www.linkedin.com/pulse/vunit-best-value-initial-effort-lars-asplund>`__

docs/blog/2017_10_31_vunit_3_0_color_logging.rst

@@ -43,7 +43,7 @@ how logging is handled in different parts of the system.
 
 The difference is not in how you make these calls but in
 scoreboard_logger itself. Prior to VUnit 3.0 loggers were protected
-types which comes with a number restrictions preventing them to be
+types which comes with a number of restrictions preventing them to be
 used freely. These restrictions are addressed by the upcoming
 VHDL-2017 standard but rather than waiting for that standard to be
 adopted by the simulator vendors, something that usually takes a few

docs/blog/2017_11_07_vunit_3_0_while_waiting_for_vhdl_2017.rst

@@ -51,11 +51,11 @@ different from standard subprograms
   logger.info("Hello world with a protected type variable");
 
 but VUnit hides this behind standard subprogram calls to keep a
-consistent API for all VHDL versions.
+consistent API for all VHDL versions
 
 .. code-block:: vhdl
 
-info(logger, "Hello world for VHDL-93 and later");
+  info(logger, "Hello world for VHDL-93 and later");
 
 A drawback with the protected type variable is that it can't be used
 as freely as other objects. For example
@@ -270,7 +270,7 @@ between such a testbench and one acting on a single interface boils
 down to more advanced communication. That is, how we transfer
 information to/from verification components and how we synchronize
 their actions when they work concurrently. There are many ways to do
-this but what's needed to handle the various use cases is a basically
+this but what's needed to handle the various use cases is basically
 an emailing service in VHDL. Computer science calls it message passing
 but the point is that emailing is something we all know. It only takes
 us a few minutes to figure out a new email client so a message passing

docs/blog/2017_11_23_vunit_matlab_integration.rst

@@ -79,7 +79,7 @@ In this case I have a one-dimensional array (a vector) created by
 
   data_set := new_1d;
 
-The created vecor is empty by default and grows dynamically with every new sample I append.
+The created vector is empty by default and grows dynamically with every new sample I append.
 
 .. code-block:: vhdl
 
@@ -313,4 +313,3 @@ still a number of flaws with this solution. For example
   hardcoded.
 
 It seems that I will have to revisit this post. Until then...
-

docs/check/user_guide.rst

@@ -369,7 +369,7 @@ Common to all point checks is that the condition for failure is
 evaluated at a single point in time, either when the subprogram is
 called as part of sequential code or synchronous to a clock in a clocked
 and usually concurrent procedure call. There are six unclocked versions
-of each point check and they correspond to the two function and four
+of each point check and they correspond to the two functions and four
 procedures previously described for ``check``. The only difference to the
 parameter lists is that the boolean ``expr`` parameter is replaced by
 one or more parameters specific to the point check.
@@ -1042,7 +1042,7 @@ Unconditional Checks
 ~~~~~~~~~~~~~~~~~~~~
 
 The check library has two unconditional checks, ``check_passed`` and
-``check_failed``, that contains no expression parameter to evaluate.
+``check_failed``, that contain no expression parameter to evaluate.
 They are used when the pass/fail status is already given by the program
 flow. For example,
 

docs/ci/intro.rst

@@ -24,5 +24,5 @@ might represent a burden for the adoption of continuous integration in hardware
 category of dev ops.
 
 Nevertheless, thanks to free and public CI/CD services, along with the striking research about portable development
-environment solutions, there are a bunch of alternatives to ease the path. In this section, solutions are grouped in three
+environment solutions, there are a bunch of alternatives to ease the path. In this section, solutions are grouped into three
 categories: :ref:`continuous_integration:script`, :ref:`continuous_integration:container` and :ref:`continuous_integration:manual`.

docs/com/user_guide.rst

@@ -184,7 +184,7 @@ message, pushing data, and sending). That gives an extra level of type safety (a
 
   memory_bfm_pkg.write(net, my_unsigned_address, my_std_logic_vector_data);
 
-If you do not expect the receiver to receive massages of a type it can't handle you can add this else statement
+If you do not expect the receiver to receive messages of a type it can't handle you can add this else statement
 
 .. code-block:: vhdl
 
@@ -553,7 +553,7 @@ the actual testing starts. You can find out by calling the ``num_of_deferred_cre
 Publisher/Subscriber Pattern
 ****************************
 
-A common message pattern is the publisher/subscriber pattern where a publisher actor publishes a messages rather than
+A common message pattern is the publisher/subscriber pattern where a publisher actor publishes a message rather than
 sending it. Actors interested in these messages subscribe to the publisher and the published messages are received just
 like messages sent directly to the subscribers. The purpose of this pattern is to decouple the publisher from the
 subscribers, it doesn't have to know who the subscribers are and there is no need to update the publisher when
@@ -760,7 +760,7 @@ still see a difference when compared to the string presented above.
 
   30000 ps - vunit_lib:com -   TRACE - test sequencer inbox => [3:2 memory BFM -> test sequencer (read reply)]
 
-First is an actor mailbox (``test sequencer inbox``), than an arrow (``=>``) followed by the message string
+First is an actor mailbox (``test sequencer inbox``), then an arrow (``=>``) followed by the message string
 enclosed in square brackets. This means that the message was removed from the mailbox, for example as a result
 of a ``receive_reply`` call. ``com`` also logs when a message is put into a mailbox. In this
 example that event is logged 10 ns earlier and is the result of a ``reply`` call

docs/logging/user_guide.rst

@@ -100,7 +100,7 @@ before ``test_runner_cleanup`` is considered a failure.
 
 Simulation stop is controlled via a stop count mechanism. The stop count mechanism works in the following way:
 
-- Stop count may be ether set or not set for a specific logger and log level.
+- Stop count may be either set or not set for a specific logger and log level.
 - When a log is made to a logger it is checked if there is a stop count set.
 
   - If set it is decremented and reaching zero means simulation stops.
@@ -145,7 +145,7 @@ which will result in the following output.
 
     INFO: Hello world
 
-There default ``verbose`` format which adds more details to the
+The default ``verbose`` format which adds more details to the
 output looks like this:
 
 .. code-block:: console
@@ -267,7 +267,7 @@ state.  The ``unmock`` call also checks that all recorded log messages
 have been checked by a corresponding ``check_log`` or
 ``check_only_log`` procedure.
 
-It is possible to mock several logger or log levels simultaneously.
+It is possible to mock several loggers or log levels simultaneously.
 All mocked log messages are written to the same global mock queue.
 The number of log messages in this queue is returned by the
 ``mock_queue_length`` function.

docs/py/opts.rst

@@ -23,27 +23,27 @@ The following compilation options are known.
    Must be a list of strings.
 
 ``modelsim.vcom_flags``
-   Extra arguments passed to ModelSim ``vcom`` command.
+   Extra arguments passed to ModelSim ``vcom`` command when compiling VHDL files.
    Must be a list of strings.
 
 ``modelsim.vlog_flags``
-   Extra arguments passed to ModelSim ``vlog`` command.
+   Extra arguments passed to ModelSim ``vlog`` command when compiling Verilog files.
    Must be a list of strings.
 
 ``rivierapro.vcom_flags``
-   Extra arguments passed to Riviera PRO ``vcom`` command.
+   Extra arguments passed to Riviera PRO ``vcom`` command when compiling VHDL files.
    Must be a list of strings.
 
 ``rivierapro.vlog_flags``
-   Extra arguments passed to Riviera PRO ``vlog`` command.
+   Extra arguments passed to Riviera PRO ``vlog`` command when compiling Verilog files.
    Must be a list of strings.
 
 ``activehdl.vcom_flags``
-   Extra arguments passed to Active HDL ``vcom`` command.
+   Extra arguments passed to Active HDL ``vcom`` command when compiling VHDL files.
    Must be a list of strings.
 
 ``activehdl.vlog_flags``
-   Extra arguments passed to Active HDL ``vcom`` command.
+   Extra arguments passed to Active HDL ``vcom`` command when compiling Verilog files.
    Must be a list of strings.
 
 ``enable_coverage``
@@ -88,7 +88,7 @@ The following simulation options are known.
   coverage settings.
 
   For GHDL with GCC backend there is less configurability for coverage, and all
-  necessary flags are set by the the ``enable_coverage`` sim and compile options.
+  necessary flags are set by the ``enable_coverage`` sim and compile options.
 
   An example of a ``run.py`` file using coverage can be found
   :vunit_example:`here <vhdl/coverage>`.

docs/py/ui.rst

@@ -29,9 +29,9 @@ common for the entire test bench depending on the situation.  For test
 benches without test such as `tb_example` in the User Guide the
 configuration is common for the entire test bench. For test benches
 containing tests such as `tb_example_many` the configuration is done
-for each test case. If the ``run_all_in_same_sim`` attribute has been used
+for each test case. If the ``run_all_in_same_sim`` attribute has been used,
 configuration is performed at the test bench level even if there are
-individual test within since they must run in the same simulation.
+individual tests within since they must run in the same simulation.
 
 In a VUnit all test benches and test cases are created with an unnamed default
 configuration which is modified by different methods such as ``set_generic`` etc.
@@ -106,20 +106,20 @@ There are two hooks to run user defined Python code.
              the test will fail immediately.
 
              The use case is to automatically create input data files
-             that is read by the test case during simulation. The test
+             that are read by the test case during simulation. The test
              bench can access the test case unique ``output_path`` via
              a :ref:`special generic/parameter <special_generics>`.
 
 :post_check: A ``post_check`` is called after a passing simulation of
              the test case. The function may accept an ``output_path``
              string which is the filesystem path to the directory
              where test outputs are stored. The function may accept an
-             ``output`` string which full standard output from the
+             ``output`` string which is the full standard output from the
              test containing the simulator transcript. The function
              must return ``True`` or the test will fail.
 
              The use case is to automatically check output data files
-             that is written by the test case during simulation. The test
+             that are written by the test case during simulation. The test
              bench can access the test case unique ``output_path`` via
              a :ref:`special generic/parameter <special_generics>`.
 

docs/run/user_guide.rst

@@ -52,7 +52,7 @@ It has the following important properties
   You can put the test code directly between ``test_runner_setup`` and ``test_runner_cleanup`` or you can simply
   use that region to trigger and wait for test activities performed elsewhere (for example in other processes) or
   you can mix those strategies. In this case the test code is in the same process and it uses the ``check_equal``
-  procedure from the :doc:`check library <../check/user_guide>`
+  procedure from the :doc:`check library <../check/user_guide>`.
 
 Running this testbench using PR will result in something like this
 
@@ -617,7 +617,7 @@ simulation on ``error`` when running with PR. When running standalone the defaul
 simulation on the ``failure`` level such that the simulation has the ability to run through all test cases
 despite a failing check like in the example above.
 
-Without PR there is a need print the test result. VUnit provides the ``get_checker_stat`` function to get the
+Without PR there is a need to print the test result. VUnit provides the ``get_checker_stat`` function to get the
 internal error counters and a ``to_string`` function to convert the returned record to a string. The example
 uses that and VUnit logging capabilities to create a simple summary in the test suite cleanup phase.
 

docs/verification_components/user_guide.rst

@@ -95,4 +95,4 @@ activity on several bus interfaces.
 A VC typically has an associated package defining procedures for sending to and receiving messages from the VC.
 Each VC instance is associated with a handle that is created in the test bench and set as a generic on the VC
 instantiation.
-The handle is given as and argument to the procedure calls to direct messages to the specfic VC instance.
+The handle is given as an argument to the procedure calls to direct messages to the specific VC instance.

vunit/ui/__init__.py

@@ -1065,7 +1065,7 @@ def get_compile_order(self, source_files=None):
         compile order dependency but the component instance will not
         elaborate if there is no binding component.
 
-        :param source_files: A list of :class:`.SourceFile` objects or `None` meaing all
+        :param source_files: A list of :class:`.SourceFile` objects or `None` meaning all
         :returns: A list of :class:`.SourceFile` objects in compile order.
         """
         if source_files is None:

vunit/ui/testbench.py

@@ -17,7 +17,7 @@ class TestBench(object):
     """
     User interface of a test bench.
     A test bench consists of one or more :class:`.Test` cases. Setting options for a test
-    bench will apply that option all test cases belonging to that test bench.
+    bench will apply that option to all test cases belonging to that test bench.
     """
 
     def __init__(self, test_bench, library):
@@ -209,9 +209,9 @@ def get_tests(self, pattern="*"):
 
     def scan_tests_from_file(self, file_name):
         """
-        Scan tests from another file than the one containg the test
+        Scan tests from another file than the one containing the test
         bench.  Useful for when the top level test bench does not
-        contain the tests.
+        contain any tests.
 
         Such a structure is not the preferred way of doing things in
         VUnit but this method exists to accommodate legacy needs.

vunit/vhdl/run/src/run.vhd

@@ -41,10 +41,6 @@ package body run_pkg is
 
     if has_active_python_runner(runner_state) then
       core_pkg.setup(output_path(runner_cfg) & "vunit_results");
-    end if;
-
-
-    if has_active_python_runner(runner_state) then
       hide(runner_trace_logger, display_handler, info);
     end if;
 
@@ -78,7 +74,7 @@ package body run_pkg is
 
     set_run_all(runner_state, strip(test_case_candidates(0).all) = "__all__");
     if get_run_all(runner_state) then
-      set_num_of_test_cases(runner_state, unknown_num_of_test_cases_c);
+      set_num_of_test_cases(runner_state, unknown_num_of_test_cases);
     else
       set_num_of_test_cases(runner_state, 0);
       for i in 1 to test_case_candidates'length loop

vunit/vhdl/run/src/runner_pkg.vhd

@@ -52,7 +52,7 @@ package runner_pkg is
 
   procedure set_test_case_name(runner : runner_t; index : positive; new_name : string);
 
-  impure function get_test_case_name(runner : runner_t; index : positive) return string ;
+  impure function get_test_case_name(runner : runner_t; index : positive) return string;
 
   procedure set_num_of_test_cases(runner : runner_t; new_value : integer);
 
@@ -76,7 +76,7 @@ package runner_pkg is
 
   impure function get_run_test_case(runner : runner_t; index : positive) return string;
 
-  procedure set_running_test_case(runner : runner_t; new_name  : string);
+  procedure set_running_test_case(runner : runner_t; new_name : string);
 
   impure function get_running_test_case(runner : runner_t) return string;