Merge branch 'devel' of ssh://bop-t/users/largo2/git/coriolis into devel

documentation/PythonTutorial/AdvancedTopics.rst

@@ -26,7 +26,7 @@ hierarchical levels, RoutingPads_ can refer to a deeply buried terminal.
 9.3 HyperNets
 ~~~~~~~~~~~~~
 
-This class is part of the *virtual flattening* mechanisms, it allows to
+This class is part of the *virtual flattening* mechanism, it allows to
 go through all the components of a trans-hierarchical net.
 
 

documentation/PythonTutorial/CgtScript.rst

@@ -12,7 +12,7 @@ But, for debugging purpose it may be helpful to run it through the
 interactive layout viewer |cgt|.
 
 For |cgt| to be able to run your script, you must add to your script
-file a function named :cb:`ScriptMain()`, which takes a dictionnary
+file a function named :cb:`ScriptMain()`, which takes a dictionary
 as sole argument (:cb:`**kw`). The ``kw`` dictionary contains, in
 particular, the CellViewer_ object we are running under with the
 keyword ``editor``. You can then load your cell into the viewer
@@ -71,7 +71,7 @@ function. To be able to see exactly what has just been mofied, we must close the
 UpdateSession_ just before calling the breakpoint and reopen it just after.
 The ``Breakpoint.stop()`` function takes two arguments:
 
-#. The ``level`` above witch it will be active.
+#. The ``level`` above which it will be active.
 #. An informative message about the purpose of the breakpoint.
 
 We can create a little function to ease the work:

documentation/PythonTutorial/Collections.rst

@@ -19,7 +19,7 @@ In |Hurricane| all kind of set of objects, whether organized in a real container
 like a ``map<>`` (dictionary / ``dict``) or a ``vector<>`` (table / ``list``) or
 an algorithmic walkthrough of the database can be accessed through a Collection_.
 
-C++ Collections object are exposed in |Python| through the *iterable* protocol,
+C++ Collections objects are exposed in |Python| through the *iterable* protocol,
 allowing to simply write:
 
 .. code-block:: Python
@@ -83,8 +83,8 @@ the ``getCell()`` call wil be:
 
    .. note:: It means that if cells with the same name exist in different
 	     libraries, only the one in the first library will be ever used.
-	     Be also weary of cell files that may remain in the ``WORK_LIB``,
+	     Be also aware that cell files that may remain in the ``WORK_LIB``,
-	     they may unexpectedly shadow cells from the libraries.
+	     may unexpectedly shadow cells from the libraries.
 	     
 
 .. code-block:: Python

documentation/PythonTutorial/Introduction.rst

@@ -39,7 +39,7 @@ don't. Thus we summarize below the more important ones:
 Cell_            The model. A Cell does not have terminals, only nets
                  flagged as *external*
 Instance_        An instance of a model
-Net_             A grouping of electrically connecteds components
+Net_             A grouping of electrically connected components
 Plug_            A terminal of an instance
 RoutingPad_      A physical connexion (*pin*) to an instance
 ===============  =====================================================

documentation/PythonTutorial/Netlist.rst

@@ -39,7 +39,7 @@ parameters:
 6.2 Creating Nets and connecting to Instances
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-An Instance_ as one Plug_ for each external net of the *master cell*.
+An Instance_ has one Plug_ for each external net of the *master cell*.
 The plug allows to create a **logical** connection bewteen a Net_ of
 ``fulladder`` and a net from an Instance_ *master cell*.
 
@@ -89,7 +89,7 @@ Building the :cb:`a` net of ``fulladder``:
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 For supplies, it may  be tedious to connect the Plugs_ of each  cell one by one
-(and  create a  lot of  uneeded objects).  To avoid  that, we  may use  **Named
+(and  create a  lot of  unneeded objects).  To avoid  that, we  may use  **Named
 connections**.  If a  signal in ``fulladder`` is set to  *global*, then it will
 be considered as connected  to any signal with the *same  name* and *global* in
 the master cell of the instances.

documentation/PythonTutorial/index.rst

@@ -9,7 +9,7 @@ Hurricane+Python Tutorial
 
 Printable version of this document `PythonTutorial.pdf <../../../pdf/main/PythonTutorial.pdf>`_.
 
-First, a small disclaimer.  This tutorial  assume that you are already familiar
+First, a small disclaimer.  This tutorial  assumes that you are already familiar
 with the concepts  of |VLSI| designs, such as  *netlist*, *layout*, *instances*
 and hierarchical design.
 

documentation/PythonTutorial/pdfHeader.rst

@@ -43,7 +43,7 @@
 
 
 |noindent|
-**First, a small disclaimer.** This tutorial  assume that you are already familiar
+**First, a small disclaimer.** This tutorial  assumes that you are already familiar
 with the concepts  of |VLSI| designs, such as  *netlist*, *layout*, *instances*
 and hierarchical design.
 

documentation/UsersGuide/Configuration.rst

@@ -21,7 +21,7 @@ General Software Architecture
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 |Coriolis| has been built with respect of the classical paradigm that the
-computational instensive parts have been written in C++, and almost
+computational intensive parts have been written in C++, and almost
 everything else in |Python|. To build the |Python| interface we used
 two methods:
 
@@ -367,4 +367,4 @@ For example: ::
         os.unlink(fileName)
 
 
-See :ref:`Python Interface to Coriolis` for more details those capabilities.
+See :ref:`Python Interface to Coriolis` for more details on those capabilities.

documentation/UsersGuide/Installation.rst

@@ -10,7 +10,7 @@ Installation
    As the sources are being released, the binary packaging is dropped.
    You may still find (very) old versions here: http://asim.lip6.fr/pub/coriolis/2.0 .
 
-In a nutshell, building source consistis in pulling the |git| repository then
+In a nutshell, building source consists in pulling the |git| repository then
 running the |ccb| installer. 
 
 .. note::
@@ -40,7 +40,7 @@ Building documentation prerequisites:
 * latex
 * python-docutils (for reStructuredText)
 
-The following libraries gets directly bundled with |Coriolis|:
+The following libraries get directly bundled with |Coriolis|:
 
 * LEF/DEF (from `SI2 <https://www.si2.org/>`_)
 * FLUTE (from `Chris C. N. Chu <http://home.eng.iastate.edu/~cnchu/flute.html>`_)
@@ -54,7 +54,7 @@ Fixed Directory Tree
 In order to simplify the work of the |ccb| installer, the source, build
 and installation tree is fixed. To successfully compile |Coriolis| you must
 follow it exactly. The tree is relative to the home directory of the user
-building it (noted :fboxtt:`~/` or :fboxtt:`$HOME/`). Only the source
+building it (note :fboxtt:`~/` or :fboxtt:`$HOME/`). Only the source
 directory needs to be manually created by the user, all others will be
 automatically created either by |ccb| or the build system.
 
@@ -95,7 +95,7 @@ automatically created either by |ccb| or the build system.
    with shared libraries. But there are also available ``Static`` instead of ``Shared``
    and ``Debug`` instead of ``Release`` and any combination of them.
 
-   ``Static`` do not work because I don't know yet to mix statically linked binaries
+   ``Static`` does not work because I don't know yet to mix statically linked binaries
    and Python modules (which must be dynamic).
 
 
@@ -122,14 +122,14 @@ The |Coriolis| |git| repository is https://www-soc.lip6.fr/git/coriolis.git
 
 .. note::
    Under |RHEL| 7 or clones, they upgraded their version of |Qt| 4 (from 4.6 to 4.8)
-   so the *diagonal line* bug no longer occur. So we can safely use the default
+   so the *diagonal line* bug no longer occurs. So we can safely use the default
    system |Qt| again.
 
 
 Installing on |RedHat| or compatible distributions
 --------------------------------------------------
 
-1. Install or check that the required prerequisites are installeds : ::
+1. Install or check that the required prerequisites are installed : ::
  
        dummy@lepka:~> yum install -y git cmake bison flex gcc-c++ libstdc++-devel  \
                                      binutils-devel                                \
@@ -138,7 +138,7 @@ Installing on |RedHat| or compatible distributions
                                      python-devel libxml2-devel bzip2-devel        \
 				     qt-devel qwt-devel                            # Qt 4
 
-   Note, that the ``Qwt`` packages are directly availables from the standart distribution
+   Note, that the ``Qwt`` packages are directly available from the standart distribution
    when using |Qt| 4.
 
 2. Install the unpackaged prerequisites. Currently, only RapidJSON_. ::
@@ -157,7 +157,7 @@ Installing on |RedHat| or compatible distributions
 4. Build & install: ::
 
        dummy@lepka:src> cd coriolis
-       dummy@lepka:coriolis> git checkout devel_anabatic
+       dummy@lepka:coriolis> git checkout devel
        dummy@lepka:coriolis> ./bootstrap/ccb.py --project=support  \
                                                 --project=coriolis \
                                                 --make="-j4 install"
@@ -180,7 +180,7 @@ be given as argument: ::
    dummy@lepka:coriolis> ./bootstrap/ccb.py --project=coriolis \
                                             --devtoolset=8 --make="-j4 install"
 
-If you want to uses Qt 5 instead of Qt 4 modify the previous steps as follow:
+If you want to use Qt 5 instead of Qt 4, modify the previous steps as follows:
 
 * At **step 1**, do not install the |QT| 4 related development package (``qt4-devel``),
   but instead: ::
@@ -197,7 +197,7 @@ If you want to uses Qt 5 instead of Qt 4 modify the previous steps as follow:
 
 * At **step 4**, add a ``--qt5`` argument to the ``ccb.py`` command line.
 
-* The |Python| scripts that makes uses of |PyQt| in ``crlcore`` and ``cumulus`` must be
+* The |Python| scripts that make use of |PyQt| in ``crlcore`` and ``cumulus`` must be
   edited to import ``PyQt5`` instead of ``PtQt4`` (should find a way to automatically
   switch between the two of them).
 
@@ -208,10 +208,10 @@ It also may be run in graphical mode (``--gui``).
 Building a Debug Enabled Version
 --------------------------------
 
-The ``Release.Shared`` default version of the |Coriolis| is build stripped of symbols
+The ``Release.Shared`` default version of the |Coriolis| is built stripped of symbols
 and optimized so that it makes analysing a core dump after a crash difficult. In the
 (unlikely) case of a crash, you may want to build, alongside the optimized version,
-a debug one which allow forensic examination by |gdb| (or |valgrind| or whatever).
+a debug one which allows forensic examination by |gdb| (or |valgrind| or whatever).
 
 Run again ``ccb.py``, adding the ``--debug`` argument: ::
 
@@ -250,7 +250,7 @@ As |cgt| is a |Python| script, the right command to run |gdb| is: ::
 Installing on |Debian| 9, |Ubuntu| 18 or compatible distributions
 -----------------------------------------------------------------
 
-First, install or check that the required prerequisites are installeds : ::
+First, install or check that the required prerequisites are installed : ::
 
    dummy@lepka:~> sudo apt install -y build-essential binutils-dev                     \
                                       git cmake bison flex gcc python-dev              \
@@ -270,7 +270,7 @@ Second step is to create the source directory and pull the |git| repository: ::
 Third and final step, build & install: ::
 
    dummy@lepka:src> cd coriolis
-   dummy@lepka:coriolis> git checkout devel_anabatic
+   dummy@lepka:coriolis> git checkout devel
    dummy@lepka:coriolis> ./bootstrap/ccb.py --project=coriolis \
                                             --make="-j4 install"
 
@@ -278,7 +278,7 @@ Third and final step, build & install: ::
 Additionnal Requirement under |MacOS|
 -------------------------------------
 
-|Coriolis| make uses of the :cb:`boost::python` module, but the |macports| |boost|
+|Coriolis| makes use of the :cb:`boost::python` module, but the |macports| |boost|
 seems unable to work with the |Python| bundled with |MacOS|. So you have to install
 both of them from |macports|: ::
 

documentation/UsersGuide/Releases.rst

@@ -63,7 +63,7 @@ Release `2049` is Alpha.
 #. More extensive Python support for all the components of
    |Coriolis|.
 #. Configuration is now completly migrated under Python.
-   |XML| loaders can still be useds for compatibilty.
+   |XML| loaders can still be used for compatibilty.
 #. The |cgt| main has been rewritten in Python. 
 
 
@@ -105,20 +105,20 @@ Release v2.2
 Release v2.3
 ~~~~~~~~~~~~
 
-#. Revert to a more standard organisation of the branchs. **devel_anabatic** is
+#. Reverts to a more standard organisation of the branches. **devel_anabatic** is
    closed and we go on with **master** (stable version) and **devel**.
 
-#. Make |Katana| the default global & detailed router. Put |Knik| & |Kite| in the
+#. Makes |Katana| the default global & detailed router. Put |Knik| & |Kite| in the
-   obsolete menues.
+   obsolete menus.
 
-#. Finally make uses of |PyQt4| widgets. Seems to integrate without problems
+#. Finally makes use of |PyQt4| widgets. Seems to integrate without problems
    with the |Coriolis| own |Qt| widget. The drawback is that to build against |Qt| 5
-   needs to adjustement from the user.
+   needs adjustement from the user.
 
 #. Improved support for whole chip management. The outer part of the chip containing
-   the pad is decoupled from the core. This allow to cleanly separate real pads from
+   the pad is decoupled from the core. This allows to cleanly separate real pads from
    the foundry from a symbolic core. But this does not preclude other combinations
    as fully symbolic or fully real.
 
-   To perform the separation an intermediate hierarchical level ``corona`` between chip
+   To perform the separation, an intermediate hierarchical level ``corona`` between chip
    and core has been introduced.

documentation/UsersGuide/ScriptsPlugins.rst

@@ -20,7 +20,7 @@ Python Interface for |Hurricane| / |Coriolis|
 =============================================
 
 The (almost) complete interface of |Hurricane| is exported as a |Python| module
-and some part of the other components of |Coriolis| (each one in a separate
+and some parts of the other components of |Coriolis| (each one in a separate
 module). The interface has been made to mirror as closely as possible the
 C++ one, so the C++ doxygen documentation could be used to write code with
 either languages.
@@ -31,7 +31,7 @@ A script could be run directly in text mode from the command line or through
 the graphical interface (see :ref:`Python Scripts in Cgt`).
 
 Aside for this requirement, the python script can contain anything valid
-in |Python|, so don't hesitate to use any package or extention.
+in |Python|, so don't hesitate to use any package or extension.
 
 Small example of Python/Stratus script: ::
 
@@ -67,7 +67,7 @@ This typical script can be executed in two ways:
      if __name__ == "__main__" :
 
    part (this is standart |Python|). It is a simple adapter that will
-   calls  :cb:`ScriptMain()`.
+   call  :cb:`ScriptMain()`.
 #. Through |cgt|, either in text or graphical mode. In that case, the
    :cb:`ScriptMain()` is directly called trough a sub-interpreter.
    The arguments of the script are passed through the ``**kw`` dictionnary.
@@ -79,7 +79,7 @@ This typical script can be executed in two ways:
    +======================+===============================================+
    | ``'cell'``           | A Hurricane cell on which to work. Depending  |
    |                      | on the context, it may be ``None``.           |
-   |                      | For example, when run from |cgt|, it the cell |
+   |                      | For example, when run from |cgt|, the cell    |
    |                      | currently loaded in the viewer, if any.       |
    +----------------------+-----------------------------------------------+
    | ``'editor'``         | The viewer from which the script is run, when |
@@ -100,22 +100,22 @@ through this method.
 Chip Placement
 --------------
 
-Automatically perform the placement of a complete chip. This plugin, as well
+Automatically performs the placement of a complete chip. This plugin, as well
 as the other P&R tools expect a specific top-level hierarchy for the design.
-The top-level hierarchy must contains the instances of all the I/O pads and
+The top-level hierarchy must contain the instances of all the I/O pads and
 **exactly one** instance named ``corona`` of an eponym cell ``corona``.
-The ``corona`` cell in turn containing the instance of the chip's core model.
+The ``corona`` cell in turn contains the instance of the chip's core model.
 
 The intermediate ``corona`` hierarchical level has been introduced to handle
-the possible discoupling between real I/O pads supplied by a foundry and a
+the possible decoupling between real I/O pads supplied by a foundry and a
 symbolic core. So the *chip* level contains only real layout and the corona
 and below only symbolic layer.
 
-.. note:: This do not prevent having a design either fully symbolic (pads and core)
+.. note:: This does not prevent having a design either fully symbolic (pads and core)
 	  or fully real.
 
-.. note:: The ``corona`` also avoid the router to actually have to manage directly
+.. note:: The ``corona`` also avoids the router to actually have to manage directly
-	  the pads which simplificate it's configuration and accessorily avoid
+	  the pads which simplify its configuration and besides avoid
 	  to have the pads stuffed with blockages.
 
 |bcenter| |ChipStructure-1| |ecenter|
@@ -159,24 +159,24 @@ The file must contain *one dictionnary* named ``chip``.
 | Parameter Key/Name   | Value/Contents type                                   |
 +======================+=======================================================+
 | ``'pad.ioPadGauge'`` | The routing gauge to use for the pad. Must be given   |
-|                      | as it differs from the one used to route standard     |
+|                      | as it differs from the one used to route              |
 |                      | inside the core                                       |
 +----------------------+-------------------------------------------------------+
-| ``'pad.south'``      | Ordered list (left to right) of pad instances names   |
+| ``'pad.south'``      | Ordered list (left to right) of pad instance  names   |
 |                      | to put on the south side of the chip                  |
 +----------------------+-------------------------------------------------------+
-| ``'pad.east'``       | Ordered list (down to up) of pad instances names      |
+| ``'pad.east'``       | Ordered list (down to up) of pad instance  names      |
 |                      | to put on the east side of the chip                   |
 +----------------------+-------------------------------------------------------+
-| ``'pad.north'``      | Ordered list (left to right) of pad instances names   |
+| ``'pad.north'``      | Ordered list (left to right) of pad instance  names   |
 |                      | to put on the north side of the chip                  |
 +----------------------+-------------------------------------------------------+
-| ``'pad.west'``       | Ordered list (down to up) of pad instances names      |
+| ``'pad.west'``       | Ordered list (down to up) of pad instance  names      |
 |                      | to put on the west side of the chip                   |
 +----------------------+-------------------------------------------------------+
 | ``'core.size'``      | The size of the core (to be used by the placer)       |
 +----------------------+-------------------------------------------------------+
-| ``'chip.size'``      | The size of the whole chip. The sides must be great   |
+| ``'chip.size'``      | The size of the whole chip. The sides must be large   |
 |                      | enough to accomodate all the pads                     |
 +----------------------+-------------------------------------------------------+
 | ``'chip.clockTree'`` | Whether to generate a clock tree or not. This calls   |
@@ -193,17 +193,17 @@ Configuration parameters, defaults are defined in ``etc/coriolis2/<STECHNO>/plug
 |``chip.block.rails.count``         | TypeInt          | :cb:`5`                    |
 |                                   +------------------+----------------------------+
 |                                   | The minimum number of rails around the core   |
-|                                   | block. Must be odd and suppérior to 5.        |
+|                                   | block. Must be odd and above 5.               |
 |                                   | One rail for the clock and at least two pairs |
 |                                   | of power/grounds                              |
 +-----------------------------------+------------------+----------------------------+
 |``chip.block.rails.hWidth``        | TypeInt          | :cb:`12` |lambda|          |
 |                                   +------------------+----------------------------+
-|                                   | The horizontal with of the rails              |
+|                                   | The horizontal width of the rails             |
 +-----------------------------------+------------------+----------------------------+
 |``chip.block.rails.vWidth``        | TypeInt          | :cb:`12` |lambda|          |
 |                                   +------------------+----------------------------+
-|                                   | The vertical with of the rails                |
+|                                   | The vertical width of the rails               |
 +-----------------------------------+------------------+----------------------------+
 |``chip.block.rails.hSpacing``      | TypeInt          | :cb:`6`  |lambda|          |
 |                                   +------------------+----------------------------+
@@ -219,7 +219,7 @@ Configuration parameters, defaults are defined in ``etc/coriolis2/<STECHNO>/plug
 .. note::
    If no clock tree is generated, then the clock rail is *not* created.
    So even if the requested number of rails ``chip.block.rails.count`` is, say 5,
-   only four rails (2* ``power``, 2* ``ground``) will be generateds.
+   only four rails (2* ``power``, 2* ``ground``) will be generated.
 
 
 Clock Tree
@@ -246,7 +246,7 @@ tree.
 
 The clock tree plugin works in four steps:
 
-#. Builds the clock tree: creates the top-block abutment box, compute the
+#. Builds the clock tree: creates the top-block abutment box, computes the
    required levels of H tree and places the clock buffers.
 #. Once the clock buffers are placed, calls the placer (|etesian|) to place
    the ordinary standard cells, whithout disturbing clock H-tree buffers.
@@ -260,7 +260,7 @@ Netlist reorganisation:
   contain all the clock sub-nets. The interface is *not* changed.
 * If the top block contains instances of other models *and* those models
   contain DFFs that get re-connected to the clock sub-nets (from the
-  top level). Changes both the model netlist and interface to propagate
+  top level): Changes both the model netlist and interface to propagate
   the relevant clock sub-nets to the instanciated model. The new model
   with the added clock signal is renamed with a ``_cts`` suffix.
   For example, the sub-block model ``ram.vst`` will become ``ram_cts.vst``.
@@ -306,7 +306,7 @@ example, derived from the |Alliance| :cb:`AM2901` is supplied.
 This example contains only the synthetized netlists and the :cb:`doChip.py` script
 which perform the whole P&R of the design.
 
-You can generate the chip using one of the following method:
+You can generate the chip using one of the following methods:
 
 #. **Command line mode:** directly run the script: ::
 
@@ -316,6 +316,6 @@ You can generate the chip using one of the following method:
    then run the |Python| script :cb:`doChip.py`.
 
 .. note::
-   Between two consecutive run, be sure to erase the netlist/layout generateds: ::
+   Between two consecutive run, be sure to erase the netlist/layout generated: ::
 
        dummy@lepka:AM2901> rm *_cts*.vst *.ap

documentation/UsersGuide/ViewerTools.rst

@@ -83,24 +83,24 @@ The |Coriolis| graphical interface is split up into two windows.
 * The **Viewer**, with the following features:
 
   * Basic load/save capabilities.
-  * Display the current working cell. Could be empty if the design
+  * Displays the current working cell. Could be empty if the design
     is not yet placed.
-  * Execute Stratus Scripts.
+  * Executes Stratus Scripts.
   * Menu to run the tools (placement, routage).
 
 Features are detailed in `Viewer & Tools`_.
 
 |ViewerSnapShot_1|
 
-* The **Controller**, which allows:
+* The **Controller**, which allows to:
 
-  * Tweak what is displayer by the *Viewer*. Through the *Look*,
+  * Tweak what is displayed by the *Viewer*. Through the *Look*,
     *Filter* and *Layers&Gos* tabs.
   * Browse the |netlist| with eponym tab.
   * Show the list of selected objects (if any) with *selection*
   * Walk through the Database, the Cell or the Selection with *Inspector*.
     This is an advanced feature, reserved for experimented users.
-  * The tab *Settings* which give access to all the settings.
+  * The tab *Settings* which gives access to all the settings.
     They are closely related to Configuration & Initialisation.
 
 |bcenter| |ControllerSnapShot_1| |ecenter|
@@ -196,9 +196,9 @@ This |Coriolis| tool is actually an encapsulation of |Coloquinte| which *is* the
 The placement area is defined by the top cell abutment box.
 
 When placing a complete hierarchy, the abutment boxes of the cells (models) other than
-the top cell are sets identical to the one of the top cell and their instances are
+the top cell are set identical to the one of the top cell and their instances are
 all placed at position ``(0,0,ID)``. That is, all the abutments boxes, whatever the
-hierarchical level, defines the same area (they are exactly superposed).
+hierarchical level, define the same area (they are exactly superposed).
 
 We choose this scheme because the placer will see all the instances as virtually
 flattened, so they can be placed anywhere inside the top-cell abutment box.
@@ -313,12 +313,12 @@ following configuration parameters:
    that quantity is substracted from the edge capacities (global routing) to
    give a sense of the cluttering inside the GCells.
 #. ``katana.vTrackReservedLocal``, same as above.
-#. ``etesian.spaceMargin``, increase the free area of the overall design so the
+#. ``etesian.spaceMargin``, increases the free area of the overall design so the
    routing density decrease.
 
 The idea is to increase the horizontal and vertical local track reservation until
-the detailed router succeed. But in doing so we make the task of the global router
+the detailed router succeeds. But in doing so we make the task of the global router
-more and more difficult as the capacity of the edges decrease, and at some point
+more and more difficult as the capacity of the edges decreases, and at some point
 it will fail too. So this is a balance.
 
 Routing a design is done in four ordered steps:
@@ -328,7 +328,7 @@ Routing a design is done in four ordered steps:
 #. Detailed routing   :math:`\textbf{P\&R} \rightarrow \textbf{Step by Step} \rightarrow \textbf{Detailed Route}`
 #. Finalize routing   :math:`\textbf{P\&R} \rightarrow \textbf{Step by Step} \rightarrow \textbf{Finalize Route}`
 
-It is possible to supply to the router a complete wiring for some nets that the user's
+It is possible to supply to the router a complete wiring for some nets that the user
 wants to be routed according to a specific topology. The supplied topology must respect
 the building rules of the |Anabatic| database (contacts must be, *terminals*, *turns*, *h-tee*
 & *v-tee* only). During the first step :fboxtt:`Detailed Pre-Route` the router will solve
@@ -342,7 +342,7 @@ the |Katana| data-structure, and it is not advisable to save the design before
 that step.
 
 You may visualize the density (saturation) of either the edges (global routing)
-or the GCells (detailed routing) until the routing is finalized. Special layers appears
+or the GCells (detailed routing) until the routing is finalized. Special layers appear
 to that effect in the `The Layers&Go Tab`_.
 
 
@@ -408,7 +408,7 @@ All the defaults value given below are from the default |Alliance| technology
 | ``katana.ripupCost``              | TypeInt          | :cb:`3`                    |
 |                                   +------------------+----------------------------+
 |                                   | Differential introduced between two ripup     |
-|                                   | cost to avoid a loop between two ripped up    |
+|                                   | costs to avoid a loop between two ripped up   |
 |                                   | segments                                      |
 +-----------------------------------+------------------+----------------------------+
 | ``katana.strapRipupLimit``        | TypeInt          | :cb:`16`                   |
@@ -443,11 +443,11 @@ Python/Stratus scripts can be executed either in text or graphical mode.
 
 .. note:: **How Cgt Locates Python Scripts:**
    |cgt| uses the Python ``import`` mechanism to load Python scripts.
-   So you must give the name of your script whitout ``.py`` extention and
+   So you must give the name of your script whithout ``.py`` extension and
-   it must be reachable through the ``PYTHONPATH``. You may uses the
+   it must be reachable through the ``PYTHONPATH``. You may use the
    dotted module notation.
 
-A Python/Stratus script must contains a function called ``ScriptMain()``
+A Python/Stratus script must contain a function called ``ScriptMain()``
 with one optional argument, the graphical editor into which it may be
 running (will be set to ``None`` in text mode). The Python interface to
 the editor (type: :cb:`CellViewer`) is limited to basic capabilities
@@ -462,15 +462,15 @@ For more explanation on Python scripts see :ref:`Python Interface to Coriolis`.
 Printing & Snapshots
 --------------------
 
-Printing or saving into a |pdf| is fairly simple, just uses the **File -> Print**
+Printing or saving into a |pdf| is fairly simple, just use the **File -> Print**
 menu or the |CTRL_P| shortcut to open the dialog box.
 
 The print functionality uses exactly the same rendering mechanism as for the
 screen, beeing almost *WYSIWYG*. Thus, to obtain the best results it is advisable
 to select the ``Coriolis.Printer`` look (in the *Controller*), which uses a
-white background and much suited for high resolutions ``32x32`` pixels patterns  
+white background and well suited for high resolutions ``32x32`` pixels patterns  
 
-There is also two mode of printing selectable through the *Controller*
+There is also two modes of printing selectable through the *Controller*
 **Settings -> Misc -> Printer/Snapshot Mode**:
 
 ===============  =================  =====================================================
@@ -500,12 +500,12 @@ The main application binary is |cgt|.
 +---------------+-------------------+-----------------------------------------------------------+
 | Category      | Keys              | Action                                                    |
 +===============+===================+===========================================================+
-| **Moves**     | | |KeyUp|,        | Shift the view in the according direction                 |
+| **Moves**     | | |KeyUp|,        | Shifts the view in the according direction                |
 |               |   |KeyDown|       |                                                           |
 |               | | |KeyLeft|,      |                                                           |
 |               |   |KeyRight|      |                                                           |
 +---------------+-------------------+-----------------------------------------------------------+
-| **Fit**       |   |KeyF|          | Fit to the Cell abutment box                              |
+| **Fit**       |   |KeyF|          | Fits to the Cell abutment box                             |
 +---------------+-------------------+-----------------------------------------------------------+
 | **Refresh**   |   |CTRL_L|        | Triggers a complete display redraw                        |
 +---------------+-------------------+-----------------------------------------------------------+
@@ -557,19 +557,19 @@ The main application binary is |cgt|.
 | **Open/Close**| |CTRL_O|          | Opens a new design. The design name must be               |
 |               |                   | given without path or extention.                          |
 |               +-------------------+-----------------------------------------------------------+
-|               | |CTRL_W|          | Close the current viewer window, but do not quit          |
+|               | |CTRL_W|          | Closes the current viewer window, but does not quit       |
 |               |                   | the application.                                          |
 |               +-------------------+-----------------------------------------------------------+
-|               | |CTRL_Q|          | `CTRL+Q` quit the application                             |
+|               | |CTRL_Q|          | `CTRL+Q` quits the application                            |
 |               |                   | (closing all windows).                                    |
 +---------------+-------------------+-----------------------------------------------------------+
-| **Hierarchy** | |CTRL_Down|       | Go one hierarchy level down. That is, if there            |
+| **Hierarchy** | |CTRL_Down|       | Goes one hierarchy level down. That is, if there          |
-|               |                   | is an *instance* under the cursor position, load          |
+|               |                   | is an *instance* under the cursor position, loads         |
-|               |                   | it's *model* Cell in place of the current one.            |
+|               |                   | its *model* Cell in place of the current one.             |
 |               +-------------------+-----------------------------------------------------------+
-|               | |CTRL_Up|         | Go one hierarchy level up. if we have entered             |
+|               | |CTRL_Up|         | Goes one hierarchy level up. If we have entered           |
 |               |                   | the current model through |CTRL_Down|                     |
-|               |                   | reload the previous model (the one                        |
+|               |                   | reloads the previous model (the one                       |
 |               |                   | in which this model is instanciated).                     |
 +---------------+-------------------+-----------------------------------------------------------+
 
@@ -582,9 +582,9 @@ Appart from the obvious ``--text`` options, all can be used for text and graphic
 +-----------------------------+------------------------------------------------+
 | Arguments                   | Meaning                                        |
 +=============================+================================================+
-| `-t|--text`                 | Instruct |cgt| to run in text mode.            |
+| `-t|--text`                 | Instructs |cgt| to run in text mode.           |
 +-----------------------------+------------------------------------------------+
-| `-L|--log-mode`             | Disable the uses of |ANSI| escape sequence on  |
+| `-L|--log-mode`             | Disables the use of |ANSI| escape sequence on  |
 |                             | the |tty|. Useful when the output is           |
 |                             | redirected to a file.                          |
 +-----------------------------+------------------------------------------------+
@@ -595,15 +595,15 @@ Appart from the obvious ``--text`` options, all can be used for text and graphic
 |                             | (|Etesian|).                                   |
 +-----------------------------+------------------------------------------------+
 | `--events-limit=<count>`    | The maximal number of events after which the   |
-|                             | router will stops. This is mainly a failsafe   |
+|                             | router will stop. This is mainly a failsafe    |
-|                             | against looping. The limit is sets to 4        |
+|                             | against looping. The limit is set to 4         |
 |                             | millions of iteration which should suffice to  |
 |                             | any design of `100K`. gates. For bigger        |
-|                             | designs you may wants to increase this limit.  |
+|                             | designs you may want to increase this limit.   |
 +-----------------------------+------------------------------------------------+
-| `-G|--global-route`         | Run the global router (|Katana|).              |
+| `-G|--global-route`         | Runs the global router (|Katana|).             |
 +-----------------------------+------------------------------------------------+
-| `-R|--detailed-route`       | Run the detailed router (|Katana|).            |
+| `-R|--detailed-route`       | Runs the detailed router (|Katana|).           |
 +-----------------------------+------------------------------------------------+
 | `-s|--save-design=<routed>` | The design into which the routed layout will   |
 |                             | be saved. It is strongly recommanded to choose |
@@ -634,24 +634,24 @@ Miscellaneous Settings
 +---------------------------------------+------------------+----------------------------+
 | ``misc.info``                         | TypeBool         | :cb:`False`                |
 |                                       +------------------+----------------------------+
-|                                       | Enable display of *info* level message        |
+|                                       | Enables display of *info* level message       |
 |                                       | (:cb:`cinfo` stream)                          |
 +---------------------------------------+------------------+----------------------------+
 | ``misc.bug``                          | TypeBool         | :cb:`False`                |
 |                                       +------------------+----------------------------+
-|                                       | Enable display of *bug* level message         |
+|                                       | Enables display of *bug* level message        |
 |                                       | (:cb:`cbug` stream), messages can be a little |
 |                                       | scarry                                        |
 +---------------------------------------+------------------+----------------------------+
 | ``misc.logMode``                      | TypeBool         | :cb:`False`                |
 |                                       +------------------+----------------------------+
-|                                       | If enabled, assume that the output device     |
+|                                       | If enabled, assumes that the output device    |
-|                                       | is not a ``tty`` and suppress any escaped     |
+|                                       | is not a ``tty`` and suppresses any escape    |
 |                                       | sequences                                     |
 +---------------------------------------+------------------+----------------------------+
 | ``misc.verboseLevel1``                | TypeBool         | :cb:`True`                 |
 |                                       +------------------+----------------------------+
-|                                       | First level of verbosity, disable level 2     | 
+|                                       | First level of verbosity, disables level 2    | 
 +---------------------------------------+------------------+----------------------------+
 | ``misc.verboseLevel2``                | TypeBool         | :cb:`False`                |
 |                                       +------------------+----------------------------+
@@ -663,12 +663,12 @@ Miscellaneous Settings
 +---------------------------------------+------------------+----------------------------+
 | ``misc.maxTraceLevel``                | TypeInt          | :cb:`0`                    |
 |                                       +------------------+----------------------------+
-|                                       | Display trace information *between* those two |
+|                                       | Displays trace information *between* those two|
 |                                       | levels (:cb:`cdebug` stream)                  | 
 +---------------------------------------+------------------+----------------------------+
 | ``misc.catchCore``                    | TypeBool         | :cb:`False`                |
 |                                       +------------------+----------------------------+
-|                                       | By default, |cgt| do not dump core.           |
+|                                       | By default, |cgt| does not dump core.         |
 |                                       | To generate one set this flag to :cb:`True`   |
 +---------------------------------------+------------------+----------------------------+
 
@@ -688,10 +688,10 @@ The *Controller* window is composed of seven tabs:
 #. `The Layers&Go Tab`_ to selectively hide/display layers.
 #. `The Netlist Tab`_ to browse through the |netlist|. Works in association
    with the *Selection* tab.
-#. `The Selection Tab`_ allow to view all the currently selected elements.
+#. `The Selection Tab`_ allows to view all the currently selected elements.
-#. `The Inspector Tab`_ browse through either the DataBase, the Cell or
+#. `The Inspector Tab`_ browses through either the DataBase, the Cell or
    the current selection.
-#. `The Settings Tab`_ access all the tool's configuration settings.
+#. `The Settings Tab`_ accesses all the tool's configuration settings.
 
 
 .. _The Look Tab:
@@ -714,12 +714,12 @@ The Filter Tab
 --------------
 
 The filter tab let you select what hierarchical levels of your design will be
-displayed. Hierarchy level are numbered top-down: the level 0 correspond to
+displayed. Hierarchy level are numbered top-down: the level 0 corresponds to
 the top-level cell, the level one to the instances of the top-level Cell and
 so on.
 
 There are also check boxes to enable/disable the processing of Terminal Cell,
-Master Cells and Compnents. The processing of Terminal Cell (hierarchy leaf
+Master Cells and Components. The processing of Terminal Cell (hierarchy leaf
 cells) is disabled by default when you load a hierarchical design and enabled
 when you load a single Cell.
 
@@ -731,8 +731,8 @@ unit used to display coordinates.
    connect two or more parts of net, a *rubber* will be drawn between them
    to signal the gap.
 
-   For example, after the detailed routing no *rubbers* should remains.
+   For example, after the detailed routing no *rubber* should remain.
-   They have been made *very* visibles as big violet lines...
+   They have been made *very* visible as big violet lines...
 
 |bcenter| |ControllerFilter_1| |ecenter|
 
@@ -746,7 +746,7 @@ The Layers&Go Tab
 
 Control the individual display of all *layers* and *Gos*.
 
-* *Layers* correspond to a true physical layer. From a |Hurricane| point of
+* *Layers* correspond to true physical layers. From a |Hurricane| point of
   view they are all the *BasicLayers* (could be matched to GDSII).
 * *Gos* stands from *Graphical Objects*, they are drawings that have no
   physical existence but are added by the various tools to display extra
@@ -771,10 +771,10 @@ The *Netlist* tab shows the list of nets... By default the tab is not
 **Sync Netlist** checkbox. You can narrow the set of displayed nets by
 using the filter pattern (supports regular expressions).
 
-An very useful feature is to enable the **Sync Selection**, which will
+A very useful feature is to enable the **Sync Selection**, which will
 automatically select all the components of the selected net(s). You can
 select multiple nets. In the figure the net ``auxsc35`` is selected and
-is highlited in the *Viewer*.
+is highlighted in the *Viewer*.
 
 |bcenter| |ControllerNetlist_1| |ecenter|
 |bcenter| |ViewerNetlist_1|     |ecenter|
@@ -785,7 +785,7 @@ is highlited in the *Viewer*.
 The Selection Tab
 -----------------
 
-The *Selection* tab list all the components currently selecteds. They
+The *Selection* tab lists all the components currently selected. They
 can be filtered thanks to the filter pattern.
 
 Used in conjunction with the *Netlist* **Sync Selection** you will all see
@@ -806,14 +806,14 @@ The Inspector Tab
 -----------------
 
 This tab is very useful, but mostly for |Coriolis| developpers. It allows
-to browse through the live DataBase. The *Inspector* provide three entry points:
+to browse through the live DataBase. The *Inspector* provides three entry points:
 
 * **DataBase**: Starts from the whole |Hurricane| DataBase.
-* **Cell**: Inspect the currently loaded Cell.
+* **Cell**: Inspects the currently loaded Cell.
-* **Selection**: Inspect the object currently highlited in the *Selection* tab.
+* **Selection**: Inspects the object currently highlighted in the *Selection* tab.
 
 Once an entry point has been activated, you may recursively expore all
-it's fields using the right/left arrows.
+its fields using the right/left arrows.
 
 .. note:: *Do not put your fingers in the socket:* when inspecting 
    anything, do not modify the DataBase. If any object under inspection