1 files changed, 5 insertions, 5 deletions
diff --git a/doc/using/QuickStartGuide.rst b/doc/using/QuickStartGuide.rst
index 9dbe84bdf..974d550ac 100644
--- a/doc/using/QuickStartGuide.rst
+++ b/doc/using/QuickStartGuide.rst
@@ -47,7 +47,7 @@ To illustrate the general purpose of `VHDL`, here is a commented `'Hello world'`
 .. HINT::
    If a GCC/LLVM variant of `GHDL` is used:
 
-   * `Analysis` generates a file, :file:`hello.o`, which is the object file corresponding to your `VHDL` program.  This is not created with mcode.
+   * `Analysis` generates a file, :file:`hello.o`, which is the object file corresponding to your `VHDL` program. This is not created with mcode.
    * The elaboration step is mandatory after running the analysis and prior to launching the simulation. This wil generate an executable binary named :file:`hello_world`.
    * As a result, :option:`-r` is just a passthrough to the binary generated in the `elaboration`. Therefore, the executable can be run directly, ``./hello_world``. See :option:`-r` for more informartion.
 
@@ -96,7 +96,7 @@ VHDL is generally used for hardware design. This example starts with a `full add
     co <= (i0 and i1) or (i0 and ci) or (i1 and ci);
   end rtl;
 
-You can analyze this design file, ``ghdl -a adder.vhdl``, and try to execute the `adder` design. But this is useless, since nothing externally visible will happen. In order to check this full adder, a :dfn:`testbench` has to be run. This testbench is very simple, since the adder is also simple: it checks exhaustively all inputs.  Note that only the behaviour is tested, timing constraints are not checked. A file named :file:`adder_tb.vhdl` contains the testbench for the adder:
+You can analyze this design file, ``ghdl -a adder.vhdl``, and try to execute the `adder` design. But this is useless, since nothing externally visible will happen. In order to check this full adder, a :dfn:`testbench` has to be run. This testbench is very simple, since the adder is also simple: it checks exhaustively all inputs. Note that only the behaviour is tested, timing constraints are not checked. A file named :file:`adder_tb.vhdl` contains the testbench for the adder:
 
 .. code-block:: VHDL
 
@@ -181,14 +181,14 @@ Unless you are only studying VHDL, you will work with larger designs than the on
 
 - First, untar the sources: ``tar zxvf dlx.tar.gz``.
 
-.. HINT:: In order not to pollute the sources with the library, it is a good idea to create a :file:`work/` subdirectory for the `WORK` library.  To any GHDL commands, we will add the :option:`--workdir=work` option, so that all files generated by the compiler (except the executable) will be placed in this directory.
+.. HINT:: In order not to pollute the sources with the library, it is a good idea to create a :file:`work/` subdirectory for the `WORK` library. To any GHDL commands, we will add the :option:`--workdir=work` option, so that all files generated by the compiler (except the executable) will be placed in this directory.
 
   .. code-block:: shell
 
      $ cd dlx
      $ mkdir work
 
-* Then, we will run the ``dlx_test_behaviour`` design.  We need to analyze all the design units for the design hierarchy, in the correct order. GHDL provides an easy way to do this, by importing the sources, ``ghdl -i --workdir=work *.vhdl``.
+* Then, we will run the ``dlx_test_behaviour`` design. We need to analyze all the design units for the design hierarchy, in the correct order. GHDL provides an easy way to do this, by importing the sources, ``ghdl -i --workdir=work *.vhdl``.
 
 * GHDL knows all the design units of the DLX, but none of them has been analyzed. Run the make option, ``ghdl -m --workdir=work dlx_test_behaviour``, which analyzes and elaborates a design. This creates many files in the :file:`work/` directory, and (GCC/LLVM only) the :file:`dlx_test_behaviour` executable in the current directory.
 
@@ -201,7 +201,7 @@ Unless you are only studying VHDL, you will work with larger designs than the on
      dlx-behaviour.vhdl:395:11:(assertion note): TRAP instruction
       encountered, execution halted
 
-* Lastly, since the clock is still running, you have to manually stop the program with the :kbd:`C-c` key sequence.  This behavior prevents you from running the test bench in batch mode. However, you may force the simulator to stop when an assertion above or equal a certain severity level occurs. To do so, call run with this option instead: ``ghdl -r --workdir=work dlx_test_behaviour --assert-level=note```. With this option, the program stops just after the previous message:
+* Lastly, since the clock is still running, you have to manually stop the program with the :kbd:`C-c` key sequence. This behavior prevents you from running the test bench in batch mode. However, you may force the simulator to stop when an assertion above or equal a certain severity level occurs. To do so, call run with this option instead: ``ghdl -r --workdir=work dlx_test_behaviour --assert-level=note```. With this option, the program stops just after the previous message:
 
   .. code-block:: shell