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

Conflicts:
	documentation/UsersGuide/Installation.rst

documentation/PythonTutorial/AdvancedTopics.rst

@@ -19,7 +19,7 @@ The trans-hierarchical workhorse.
 9.2 RoutingPads
 ~~~~~~~~~~~~~~~
 
-Unlike the Plugs_ that only make connexions between two **adjacent**
+Unlike the Plugs_ that only make connections between two **adjacent**
 hierarchical levels, RoutingPads_ can refer to a deeply buried terminal.
 
 

documentation/PythonTutorial/CellNetComponent.rst

@@ -7,19 +7,19 @@
 3. Making a Standard Cell -- Layout
 ===================================
 
-In this part, we well show how to create and save a terminal Cell_,
+In this part, we will show how to create and save a terminal Cell_,
 that is, a cell without instances (the end point of a hierarchical
 design). To illustrate the case we will draw the layout of a
 standard cell.
 
 We will introduce the following classes : Cell_, Net_, Component_
-and it's derived classes.
+and its derived classes.
 
 
 3.1 The AllianceFramework (CRL Core)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The |Hurricane| database only manage objects in memory. To load or save
+The |Hurricane| database only manages objects in memory. To load or save
 something from the outside, we need to use a *framework*. As of today, only
 one is available : the Alliance framework. It allows |Coriolis| to handle
 |Alliance| libraries and cells in the exact same way.
@@ -34,7 +34,7 @@ one is available : the Alliance framework. It allows |Coriolis| to handle
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In the |Hurricane| database, all modifications must take place inside
-an UpdateSession_. At the closing of a session, created or modificateds
+an UpdateSession_. At the closing of a session, created or modificated
 objects are fully inserted in the database. This is especially true for
 the visualisation, a created component will be visible *only* only after
 the session close.
@@ -64,7 +64,7 @@ environment is provided by the |CRL| module.
    UpdateSession.close()
 
 
-This is the simplest call to ``createCell()``, and it that case, the newly
+This is the simplest call to ``createCell()``, and in that case, the newly
 created Cell_ will be saved in the *working library* (usually, the current
 directory). You may supply a second argument telling into which library
 you want the Cell_ to be created.
@@ -83,7 +83,7 @@ hundredth of foundry grid (to allow transient non-integer
 computation).
 
 To work with symbolic layout, that is, using lambda based lengths,
-two conversion functions are provideds:
+two conversion functions are provided:
 
 * ``unit = DbU.fromLambda( lbd )`` convert a lambda :cb:`lbd` into a ``DbU``.
 * ``lbd = DbU.toLambda( unit )`` convert a ``DbU`` into a lambda :cb:`lbd`.
@@ -95,7 +95,7 @@ is *integer*.
 3.5 Setting up the Abutment Box
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-To setup the abutment box, we use a Box_ which define a box from
+To setup the abutment box, we use a Box_ which defines a box from
 the coordinates of the lower left corner ``(x1,y1)`` and upper left
 corner ``(x2,y2)``.
 
@@ -157,7 +157,7 @@ Layer_:
 --------------------
 
 As said above, prior to creating any Component_, we must create the Net_ it
-will belongs to. In that example we also make it an *external* net, that is,
+will belong to. In that example we also make it an *external* net, that is,
 a part of the interface. Do not mistake the name of the net given as a string
 argument :cb:`'i'` and the name of the *variable* :cb:`i` holding the Net_ object.
 For the sake of clarity we try to give the variable a close name, but this is
@@ -194,7 +194,7 @@ absolute position. There is a second overload for creating a relatively placed
 segment, see *articulated layout*.
 
 If the net is external, that is, part of the interface of the cell, you may have
-to declare some of it's components as physical connectors usable by the router.
+to declare some of its components as physical connectors usable by the router.
 This is done by calling the NetExternalComponents_ class:
 
 .. code-block:: Python
@@ -205,7 +205,7 @@ This is done by calling the NetExternalComponents_ class:
 3.7 Saving to Disk (CRL Core)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Once you are finished building your cell, you have to save it on disk.
+Once you have finished to build your cell, you have to save it on disk.
 Using the AllianceFramework_ you can save it as a pair of file:
 
 =========================  ===================================  =======================
@@ -229,7 +229,7 @@ will be written in the |Alliance| ``WORK_DIR``.
 The example files can be found in the ``share/doc/coriolis2/examples/scripts/``
 directory (under the the root of the |Coriolis| installation).
 
-The code needed to run it through the |cgt| viewer as been added. For the
+The code needed to run it through the |cgt| viewer has been added. For the
 explanation of that part of the code, refer to `5. Make a script runnable through cgt`_.
 
 

documentation/PythonTutorial/CgtScript.rst

@@ -7,13 +7,13 @@
 5. Make a script runnable through |cgt|
 =======================================
 
-To use your you may run it directly like any other |Python| script.
+To use your script you may run it directly like any other |Python| script.
 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
-as sole argument (:cb:`**kw`). The ``kw`` dictionnary contains, in
+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
 using the menu:
@@ -67,7 +67,7 @@ using the menu:
 ~~~~~~~~~~~~~~~~~~~~~
 
 It is possible to add breakpoints inside a script by calling the ``Breakpoint.stop()``
-function. To be able to see exactly what has just been moficated, we must close the
+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:
 

documentation/PythonTutorial/Collections.rst

@@ -9,7 +9,7 @@
 4. Manipulating Cells, Nets and Components
 ==========================================
 
-In this part, we well show how to navigate through the Nets_ and Components_ of a Cell_.
+In this part, we will show how to navigate through the Nets_ and Components_ of a Cell_.
 
 
 4.1 Hurricane Collections
@@ -48,8 +48,8 @@ In C++ we would have written:
 **Never delete or create an element while you are iterating over a Collection.**
 
 Results can be unpredictable, you may just end up with a core dump, but more
-subtly, some element of the Collection_ may be skippeds or processed twice.
+subtly, some element of the Collection_ may be skipped or processed twice.
-If you want to create or delete en element, do it outside of the collection
+If you want to create or delete an element, do it outside the collection
 loop. For example:
 
 .. code-block:: Python
@@ -78,12 +78,12 @@ the ``getCell()`` call wil be:
              disk since it was first loaded.  Conversely, if the Cell_ has been
              modified in memory, you will get those modifications.
 
-#. Search, in the ordered list of libraries, the first Cell_ that match the
+#. Search, in the ordered list of libraries, the first Cell_ that matches the
    requested name.
 
-   .. note:: It means that if cells with the same name exists in different
+   .. 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 remains in the ``WORK_LIB``,
+	     Be also weary of cell files that may remain in the ``WORK_LIB``,
 	     they may unexpectedly shadow cells from the libraries.
 	     
 

documentation/PythonTutorial/Environment.rst

@@ -8,7 +8,7 @@
 2. Setting up the Environment
 =============================
 
-2.1 Setting up the Pathes
+2.1 Setting up the Paths
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
 To simplify the tedious task of configuring your environment, a helper is provided.
@@ -25,9 +25,9 @@ Use it like this (don't forget the ``eval`` **and** the backquotes):
 
    dummy@lepka:~> eval `<CORIOLIS_INSTALL>/etc/coriolis2/coriolisEnv.py`
 
-.. note:: **Do not call that script in your environement initialisation.**
+.. note:: **Do not call that script in your environment initialisation.**
    When used under |RHEL6| or clones, it needs to be run in the |devtoolset|
-   environement. The script then launch a new shell, which may cause an
+   environment. The script then launches a new shell, which may cause an
    infinite loop if it's called again in, say :cb:`~/.bashrc`.
 
    Instead you may want to create an alias: ::
@@ -39,12 +39,12 @@ Use it like this (don't forget the ``eval`` **and** the backquotes):
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 You may create, in the directory you are lanching |Coriolis| tools, a special
-sub-directory ``.coriolis2/`` that can contains two configuration files:
+sub-directory ``.coriolis2/`` that can contain two configuration files:
 
 * ``techno.py`` tells which technology to use.
-* ``settings.py`` can overrides almost any default configuration setting.
+* ``settings.py`` can override almost any default configuration setting.
 
-Those two files are *optional*, if they do not exists the default settings
+Those two files are *optional*, if they do not exist the default settings
 will be used and the technology is ``symbolic/cmos`` (i.e. purely symbolic).
 
 .. note:: Those two files will by processed by the |Python| interpreter,
@@ -54,7 +54,7 @@ will be used and the technology is ``symbolic/cmos`` (i.e. purely symbolic).
 2.2.1 The :cb:`techno.py` File
 ------------------------------
 
-Must provide one variable named :cb:`technology` which value the path towards
+Must provide one variable named :cb:`technology` which values the path towards
 the technology file. The available technologies are installed under
 ``<CORIOLIS_INSTALL>/etc/coriolis2``. For example, to use the 45nm FreeDPK
 which is in: ::

documentation/PythonTutorial/Introduction.rst

@@ -10,11 +10,11 @@ This tutorial is aimed at two goals :
 
 * Presenting how to use Python scripts to control |Coriolis|.
 
-* Make a basic introduction about the |Hurricane| database and it's
+* Make a basic introduction about the |Hurricane| database and its
   concepts.
 
 While this tutorial is aimed at presenting the |Hurricane| database,
-do not feel limited to it. You can use |Hurricane| objects as attributes
+do not feel limited by it. You can use |Hurricane| objects as attributes
 of |Python| objects or use |Python| containers to store them.
 The only limitation is that you may not use |Hurricane| classes as base
 classes in |Python|.
@@ -36,7 +36,7 @@ don't. Thus we summarize below the more important ones:
 ===============  =====================================================
 **Class**        **Meaning**
 ===============  =====================================================
-Cell_            The model. A Cell do not have terminals, only nets
+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
@@ -58,7 +58,7 @@ Mostly:
 * C++ namespaces are exported as |Python| modules.
 * The *scope resolution operator* :fboxtt:`::` converts into :fboxtt:`.`.
 * C++ blocks (between braces :fboxtt:`{}`) are replaced by indentations.
-* In C++, names are manageds through a dedicated ``Name`` class.
+* In C++, names are managed through a dedicated ``Name`` class.
   It has not been exported to the |Python| interface, you only have
   to use ``string``.
 * Coordinates are expressed in ``DbU`` which are ``long`` with a special

documentation/PythonTutorial/Netlist.rst

@@ -40,10 +40,10 @@ parameters:
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 An Instance_ as one Plug_ for each external net of the *master cell*.
-The plug allows to create a **logical** connexion bewteen a Net_ of
+The plug allows to create a **logical** connection bewteen a Net_ of
 ``fulladder`` and a net from an Instance_ *master cell*.
 
-A plug is somewhat equivalent to an *instance terminal* in others
+A plug is somewhat equivalent to an *instance terminal* in other
 well known databases.
 
 Therefore, a plug is related to two nets:
@@ -54,13 +54,13 @@ Therefore, a plug is related to two nets:
 
 #. The net of ``fulladder`` the plug is connected to. This can
    be set, it is how we build the netlist. To set the net, use
-   the function ``plug.setNet( net )``. It the argument is ``None``,
+   the function ``plug.setNet( net )``. If the argument is ``None``,
    the plug is *disconnected*.
 
 To find the plug of an instance associated to a given net in
 the *master cell*, use ``instance.getPlug( masterNet )``.
 The ``masterNet`` argument being an object of class net (not
-it's name).
+its name).
 
 Building the :cb:`a` net of ``fulladder``:
 
@@ -81,7 +81,7 @@ Building the :cb:`a` net of ``fulladder``:
 	  terminals). There is a strict bijection between external
 	  nets and plugs.
 
-	  While it may be restrictive, it enforce cleaner designs
+	  While it may be restrictive, it enforces cleaner designs
           and make it possible for the HyperNet_ concept/class.
 
 
@@ -124,7 +124,7 @@ of the *master cell*. A transformation is composed of two operations :
 
 The transformation is a change of coordinate system, be aware that if the
 abutment box lower left corner of the *master* cell is **not** at ``(0,0)``
-the result of the Transformation may not be what you expect. To simplificate
+the result of the Transformation may not be what you expect. To simplify
 the computation of the transformation of an instance, always place the
 lower left corner of the abutment box at ``(0,0)``
 
@@ -138,7 +138,7 @@ that the abutment box lower left corner is at ``(0,0)`` (same for the
 instance to left of the second row.
 
 Setting the translation on an Instance_ is not enough to make it be displayed,
-we also must set it's *placement status* to ``Instance.PlacementStatus.PLACED``. 
+we also must set its *placement status* to ``Instance.PlacementStatus.PLACED``. 
 
 .. code-block:: Python
 
@@ -151,15 +151,15 @@ we also must set it's *placement status* to ``Instance.PlacementStatus.PLACED``.
 6.4.3 Nets -- From Plugs to RoutingPads
 ---------------------------------------
 
-As was stated before, Plugs_ represent a logical connexion between two
+As was stated before, Plugs_ represent a logical connection between two
-levels of hierarchy. To make the physical connexion to the *master net*
+levels of hierarchy. To make the physical connection to the *master net*
 in the instance, we now must create, in the ``fulladder``, a special
 component which is a kind of *reference* to a component of the
 *master net* (in the master cell).
 
 The so called *special component* is a RoutingPad_.
 
-The ``RoutingPad`` can be considered as an equivalent to ``pin`` in others
+The ``RoutingPad`` can be considered as an equivalent to ``pin`` in other
 well known databases.
 
 .. code-block:: Python
@@ -169,9 +169,9 @@ well known databases.
 			 , RoutingPad.BiggestArea )
 
 For the second parameter, we must pass an Occurrence_. Occurrence objects will
-be explained in detail later, for now, suffice to say that we must construct the
+be explained in detail later, for now, let say that we must construct the
 Occurrence object with one parameter : the Plug_ for which we want to create a
-physical connexion.
+physical connection.
 
 The RoutingPad_ ``rp`` will be a component of the ``a`` net.
 
@@ -179,7 +179,7 @@ The third argument ask the constructor of the RoutingPad_ to select in the
 master net, the component which has the biggest area.
 
 .. note:: **Component selection.** Not all the components of a net can be
-	  selected for connexion through a RoutingPad_. The candidates must
+	  selected for connection through a RoutingPad_. The candidates must
 	  have been flagged with the NetExternalComponents_ class.
 
 	  See `3.6.3 Creating a Component`_.

documentation/PythonTutorial/RealDesigns.rst

@@ -6,9 +6,9 @@
 7. Working in real mode
 =======================
 
-The AllianceFramework_ only manage *symbolic* layout as |Alliance| do.
+The AllianceFramework_ only manages *symbolic* layout as |Alliance| does.
 But |Coriolis| is also able to work directly in *real* mode, meaning
-that distances will be expresseds in microns instead of lambdas.
+that distances will be expressed in microns instead of lambdas.
 
 The *real* mode will be illustrated by working with the FreePDK45_.
 
@@ -32,7 +32,7 @@ another.
    library = LefImport.load( DKsdir + '/FreePDK45/osu_soc/lib/files/gscl45nm.lef' )		
 
 
-.. note:: **Technology checking.**  The first imported |LEF| file must contains the
+.. note:: **Technology checking.**  The first imported |LEF| file must contain the
 	  technology. The technology described in the |LEF| file will be checked
 	  against the one configured in the running instance of |Coriolis| to look
 	  for any discrepencies.
@@ -42,8 +42,8 @@ another.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The |Blif| format is generated by the Yosys_ logic synthetizer. Here again, it is
-pretty straightforward: call the static function ``Blif.load()``. If you did make
+pretty straightforward: call the static function ``Blif.load()``. If you made
-your synthesis on a cell library not managed by AllianceFramework_, For example
+your synthesis on a cell library not managed by AllianceFramework_, for example
 the one of the FreePDK45, you must load it prior to calling the |Blif| loader.
 
 .. code-block:: Python

documentation/PythonTutorial/ToolEngines.rst

@@ -6,7 +6,7 @@
 8. Tool Engines (CRL Core)
 ==========================
 
-The ToolEngine_ class is the base class for all tools developpeds in
+The ToolEngine_ class is the base class for all tools developped in
 |Coriolis|. In the rest of the tutorial we will use the names ``tool``
 or ``engine`` as synonyms.
 
@@ -55,7 +55,7 @@ You can configure the placer in two ways:
 Like for |Etesian|, you have to create the engine on the cell then call
 the sequence of functions detailed below.
 
-.. note:: **Kite vs. Katana.** There are currently two router in |Coriolis|,
+.. note:: **Kite vs. Katana.** There are currently two routers in |Coriolis|,
 	  |Kite| is the old one and digital only. |Katana| is a re-implementation
 	  with support for mixed routing (digital **and** analog).
 	  Until |Katana| is fully implemented we keep both of them.
@@ -81,7 +81,7 @@ the sequence of functions detailed below.
 The example file ``toolengines.py`` can be found in the ``share/doc/coriolis2/examples/scripts/``
 directory (under the the root of the |Coriolis| installation).
 
-This script automatically place and route the ``fulladder`` netlist as seen
+This script automatically places and routes the ``fulladder`` netlist as seen
 previously. The call to the ToolEngines_ is made inside the new function
 ``placeAndRoute()``.
 

documentation/PythonTutorial/pdfHeader.rst

@@ -4,17 +4,64 @@
 .. include:: ./definitions.rst
 
 
-=========================
-Hurricane+Python Tutorial
-=========================
 
-|pagestylefancy|
+.. raw:: latex
+
+  \newpage
+
+  \pagestyle{empty} 
+
+  \begin{center}
+
+  \begin{figure}[t]
+  \begin{center}
+    \includegraphics[scale=0.4]{../etc/images/logoLIP6_SU_CNRS.pdf}
+  \end{center}
+  \end{figure}
+
+  \vspace{2cm}
+
+  \huge \textsc{Sorbonne Université}
+  
+  \vspace{1cm}
+  
+  \huge {\textsc{lip6} Laboratory}
+  \vspace{3cm}
+
+  \Huge \textsc{Hurricane+Python}
+  \vspace{1cm}
+
+  \Huge \textbf{Tutorial}
+  \vspace{1cm}
+
+  \huge {Jean-Paul \textsc{Chaput}}
+  \vspace{4cm}
+
+  \begin{figure}[!h]
+  \begin{center}
+    \includegraphics[scale=1.0]{../etc/images/logoCC.pdf}
+  \end{center}
+  \end{figure}
+
+  \normalsize 
+
+  This work is licensed under a\\
+  Creative Commons Attribution-NonCommercial-ShareALike 4.0 International License.\\
+  Creative Commons License \href{https://creativecommons.org/licenses/by-nc-sa/4.0/} {creativecommons.org/licenses/by-nc-sa/4.0/}
+
+  \end{center}
+
+  \newpage
+  \pagestyle{fancy} 
+
 
 |noindent|
 **First, a small disclaimer.** This tutorial  assume that you are already familiar
 with the concepts  of |VLSI| designs, such as  *netlist*, *layout*, *instances*
 and hierarchical design.
 
+|pagestylefancy|
+
 
 .. contents::
 

documentation/UsersGuide/Configuration.rst

@@ -20,7 +20,7 @@ Coriolis Configuration & Initialisation
 General Software Architecture
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-|Coriolis| has been build with respect of the classical paradigm that the
+|Coriolis| has been built with respect of the classical paradigm that the
 computational instensive parts have been written in C++, and almost
 everything else in |Python|. To build the |Python| interface we used
 two methods:
@@ -67,7 +67,7 @@ The initialization process is done by executing, in order, the following file(s)
 | **3** | The user's local setting         | :cb:`<CWD>/.coriolis2/techno.py`             |
 +-------+----------------------------------+----------------------------------------------+
 
-Thoses files must provides only one variable, the name of the technology. Each technology
+Those files must provide only one variable, the name of the technology. Each technology
 will provide configuration for both the symbolic part and the real part. |Coriolis| can
 work with purely symbolic technology (``symbolic/cmos``) in that case, the real technology
 part is a dummy one.
@@ -85,9 +85,9 @@ Second Stage: Technology Configuration Loading
 |noindent|
 The :cb:`technology` variable is set by the first stage and it's the name of the
 technology. A directory of that name, with all the configuration files,
-must exists in the configuration directory (:cb:`/etc/coriolis2`).
+must exist in the configuration directory (:cb:`/etc/coriolis2`).
 In addition to the technology-specific directories, a :cb:`common/` directory is
-there to provides a trunk for all the identical datas across the various technologies.
+there to provide a trunk for all the identical data across the various technologies.
 The initialization process is done by executing, in order, the following file(s):
 
 +-------+----------------------------------+-----------------------------------------------+
@@ -186,9 +186,9 @@ variable, and if not found, default to ``/soc/alliance``.
 
 
 |noindent| The example above shows the system configuration file, with all the
-available settings. Some important remarks about thoses settings:
+available settings. Some important remarks about those settings:
 
-* In it's configuration file, the user do not need to redefine all the settings,
+* In its configuration file, the user does not need to redefine all the settings,
   just the one he wants to change. In most of the cases, the ``SYSTEM_LIBRARY``,
   the ``WORKING_LIBRARY`` and the special net names (at this point there is not
   much alternatives for the others settings).
@@ -205,25 +205,25 @@ available settings. Some important remarks about thoses settings:
     it, whithout changing the search path order. If no library of that name
     already exists, it is appended.
 
-  A library is identified by it's name, this name is the last component of the
+  A library is identified by its name, this name is the last component of the
   path name. For instance: ``/soc/alliance/sxlib`` will be named ``sxlib``.
   Implementing the |Alliance| specification, when looking for a |Cell| ``name``,
-  the system will browse sequentially trought the library list and returns
+  the system will browse sequentially through the library list and returns
   the first |Cell| whose name match.
 
 * For ``POWER``, ``GROUND``, ``CLOCK`` and ``BLOCKAGE`` net names, a regular
   expression (|GNU| regexp) is expected.
 
 .. * The ``helpers.sysConfDir`` variable is supplied by the helpers, it is the
-..   directory in which the system-wide configuration files are locateds.
+..   directory in which the system-wide configuration files are located.
 ..   For a standard installation it would be: ``/soc/coriolis2``.
 .. 
 .. .. * Trick and naming convention about ``SYMBOLIC_TECHNOLOGY``, ``REAL_TECHNOLOGY``
-..   and ``DISPLAY``. In the previous releases, thoses files where to read by
+..   and ``DISPLAY``. In the previous releases, those files were to be read by
 ..   XML parsers, and still do if you triggers the XML compatibility mode.
 ..   But now, they have Python conterparts. In the configuration files, you
 ..   still have to name them as XML files, the Python file name will be
-..   deduced from this one with thoses two translation rules: 
+..   deduced from this one with those two translation rules: 
 .. 
 ..   #. In the filename, all dots, except for the last (the file extention), 
 ..      are replaced by underscores.
@@ -252,11 +252,11 @@ A typical user's configuration file would be: ::
 Tools Configuration Helpers
 ---------------------------
 
-All the tools uses the same helper to load their configuration (a.k.a. 
+All the tools use the same helper to load their configuration (a.k.a. 
 *Configuration Helper*). Currently the following configuration system-wide
 configuration files are defined:
 
-* :cb:`misc.conf`: commons settings or not belonging specifically to a tool.
+* :cb:`misc.conf`: common settings or not belonging specifically to a tool.
 * :cb:`etesian.conf`: for the |Etesian| tool.
 * :cb:`kite.conf`: for the |Kite| tool.
 * :cb:`stratus1.conf`: for the |stratus1| tool.
@@ -303,18 +303,18 @@ Here is the contents of :cb:`etesian.conf`: ::
 
 Taxonomy of the file:
 
-* It must contains, at least, the two tables:
+* It must contain, at least, the two tables:
 
-  * ``parametersTable``, defines & initialise the configuration variables.
+  * ``parametersTable``, defines & initialises the configuration variables.
 
   * ``layoutTables``, defines how the various parameters will be displayed
     in the configuration window (:ref:`The Settings Tab`).
 
 * The ``parametersTable``, is a tuple (list) of tuples. Each entry in the list
-  describe a configuration parameter. In it's simplest form, it's a quadruplet
+  describes a configuration parameter. In its simplest form, it's a quadruplet
   :cb:`(TypeOption, 'paramId', ParameterType, DefaultValue)` with:
 
-  #. ``TypeOption``, tells that this tuple describe a parameter.
+  #. ``TypeOption``, tells that this tuple describes a parameter.
 
   #. ``paramId``, the identifier of the parameter. Identifiers are defined
      by the tools. The list of parameters is detailed in each tool section.
@@ -334,7 +334,7 @@ Taxonomy of the file:
 Hacking the Configuration Files
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Asides from the symbols that gets used by the configuration helpers like
+Aside from the symbols that get used by the configuration helpers like
 :cb:`allianceConfig` or :cb:`parametersTable`, you can put pretty much anything
 in :cb:`<CWD>/.coriolis2/settings.py` (that is, written in |Python|).
 

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 consist in pulling the |git| repository then
+In a nutshell, building source consistis in pulling the |git| repository then
 running the |ccb| installer. 
 
 .. note::
@@ -50,7 +50,7 @@ For other distributions, refer to their own packaging system.
 Fixed Directory Tree
 ~~~~~~~~~~~~~~~~~~~~
 
-In order to simplificate the work of the |ccb| installer, the source, build
+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
@@ -162,7 +162,7 @@ Installing on |RedHat| or compatible distributions
                                                 --doc --make="-j1 install"
     
    We need to perform a separate installation of the documentation because it
-   do not support to be generated with a parallel build. So we compile & install in a first
+   does not support to be generated with a parallel build. So we compile & install in a first
    stage in ``-j4`` (or whatever) then we generate the documentation in ``-j1``
 
 Under |RHEL6| or clones, you must build using the |devtoolset|, the version is to
@@ -228,8 +228,8 @@ As |cgt| is a |Python| script, the right command to run |gdb| is: ::
 ..       dummy@lepka:coriolis> ./bootstrap/ccb.py --project=coriolis \
 ..                                                --make="-j4 install" --debug
 .. 
-..   Be aware that it may requires newer versions of the dependencies and may introduce
+..   Be aware that it may require newer versions of the dependencies and may introduce
-..   incompatibilites with the stable version.
+..   incompatibilities with the stable version.
 
 |newpage|
 
@@ -283,11 +283,11 @@ Then proceed with the generic install instructions.
 Packaging Coriolis
 ~~~~~~~~~~~~~~~~~~
 
-Packager should not uses |ccb|, instead ``bootstrap/Makefile.package`` is provided
+Packager should not use |ccb|, instead ``bootstrap/Makefile.package`` is provided
 to emulate a top-level ``autotool`` makefile. Just copy it in the root of the
 |Coriolis| git repository (``~/corriolis-2.x/src/coriolis/``) and build.
 
-Sligthly outaded packaging configuration files can also be found under ``bootstrap/``:
+Sligthly outdated packaging configuration files can also be found under ``bootstrap/``:
 
 * ``bootstrap/coriolis2.spec.in`` for |rpm| based distributions.
 * ``bootstrap/debian`` for |Debian| based distributions.

documentation/UsersGuide/LicenseCredits.rst

@@ -48,7 +48,7 @@ copyright© |UPMC| 2008-2018, |SorbonneUniversite| 2018-2019
 and released under the |GPL| license.
 
 Others important contributors to |Coriolis| are Christophe |Alexandre|,
-Hugo |Clement|, Marek |Sroka| and Wu |Yifei|.
+Roselyne |Chotin|, Hugo |Clement|, Marek |Sroka| and Wu |Yifei|.
 
 The |Katana| router makes use of the |Flute| software, which is
 copyright© Chris C. N. |Chu| from the Iowa State University

documentation/UsersGuide/Releases.rst

@@ -84,7 +84,7 @@ Release v2.1
    |Etesian| and its legalization and detailed placement tools.
 #. Added a Blif format parser to process circuits generated by the Yosys and ABC
    logic synthetizers.
-#. The multiples user defined configuration files are now grouped under
+#. The multiple user defined configuration files are now grouped under
    a common hidden (dot) directory ``.coriolis2`` and the file extension
    is back from ``.conf`` to ``.py``.
 

documentation/UsersGuide/ScriptsPlugins.rst

@@ -27,7 +27,7 @@ either languages.
 A script could be run directly in text mode from the command line or through
 the graphical interface (see :ref:`Python Scripts in Cgt`).
 
-Asides for this requirement, the python script can contain anything valid
+Aside for this requirement, the python script can contain anything valid
 in |Python|, so don't hesitate to use any package or extention.
 
 Small example of Python/Stratus script: ::
@@ -104,7 +104,7 @@ The top-level hierarchy must contains the instances of all the I/O pads and
 
 |bcenter| |ChipStructure-1| |ecenter|
 
-The designer must provide a configuration file that define the rules for the
+The designer must provide a configuration file that defines the rules for the
 placement of the top-level hierarchy (that is, the pads and the core).
 This file must be named after the chip's name, by appending ``_chip.py``
 (obviously, it is a |Python| file). For instance if the chip netlist file
@@ -230,11 +230,11 @@ Configuration parameters, defaults are defined in ``etc/coriolis2/<STECHNO>/plug
 Clock Tree
 ----------
 
-Insert a clock tree into a block. The clock tree uses the H strategy.
+Inserts a clock tree into a block. The clock tree uses the H strategy.
 The clock net is splitted into sub-nets, one for each branch of the
 tree.
 
-* On **chips** design, the sub-nets are createds in the model of the
+* On **chip** design, the sub-nets are created in the model of the
   core block (then trans-hierarchically flattened to be shown at
   chip level).
 * On **blocks**, the sub nets are created directly in the top block.
@@ -251,21 +251,21 @@ tree.
 
 The clock tree plugin works in four steps:
 
-#. Build the clock tree: creates the top-block abutment box, compute the
+#. Builds the clock tree: creates the top-block abutment box, compute the
-   levels of H tree neededs and place the clock buffers.
+   required levels of H tree and places the clock buffers.
 #. Once the clock buffers are placed, calls the placer (|etesian|) to place
-   the ordinary standart cells, whithout disturbing clock H-tree buffers.
+   the ordinary standard cells, whithout disturbing clock H-tree buffers.
 #. At this point we know the exact positions of all the DFFs, so we can
    connect them to the nearest H-tree leaf clock signal.
-#. Leaf clock signals that are not connecteds to any DFFs are removed.
+#. Leaf clock signals that are not connected to any DFFs are removed.
 
 Netlist reorganisation:
 
-* Obviously the top block or chip core model netlist is modificated to
+* Obviously the top block or chip core model netlist is modified to
-  contains all the clock sub-nets. The interface is *not* changed.
+  contain all the clock sub-nets. The interface is *not* changed.
 * If the top block contains instances of other models *and* those models
-  contains DFFs that get re-connecteds to the clock sub-nets (from the
+  contain DFFs that get re-connected to the clock sub-nets (from the
-  top level). Change 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 ``_clocked`` suffix.
   For example, the sub-block model ``ram.vst`` will become ``ram_clocked.vst``.
@@ -273,7 +273,7 @@ Netlist reorganisation:
 .. note::
   If you are to re-run the clock tree plugin on a netlist, be careful
   to erase any previously generated ``_clocked`` file (both netlist and
-  layout: ``rm *.clocked.{ap,vst}``). And restart |cgt| to clear it's
+  layout: ``rm *.clocked.{ap,vst}``). And restart |cgt| to clear its
   memory cache.
 
 Configuration parameters, defaults are defined in ``etc/coriolis2/<STECHNO>/plugins.conf``.
@@ -303,8 +303,8 @@ Configuration parameters, defaults are defined in ``etc/coriolis2/<STECHNO>/plug
 Recursive-Save (RSave)
 ----------------------
 
-Perform a recursive top down save of all the models from the top cell
+Performs a recursive top down save of all the models from the top cell
-loaded in |cgt|. Force a write of any non-terminal model. This plugin is used
+loaded in |cgt|. Forces a write of any non-terminal model. This plugin is used
 by the clock tree plugin after the netlist clock sub-nets creation.
 
 

documentation/UsersGuide/pdfHeader.rst

@@ -3,13 +3,59 @@
 .. include:: ../etc/definitions.rst
 
 
-=======================
+
-Coriolis User's Guide
+.. raw:: latex
-=======================
+
+  \newpage
+
+  \pagestyle{empty} 
+
+  \begin{center}
+
+  \begin{figure}[t]
+  \begin{center}
+    \includegraphics[scale=0.4]{../etc/images/logoLIP6_SU_CNRS.pdf}
+  \end{center}
+  \end{figure}
+
+  \vspace{2cm}
+
+  \huge \textsc{Sorbonne Université}
+  
+  \vspace{1cm}
+  
+  \huge {\textsc{lip6} Laboratory}
+  \vspace{3cm}
+
+  \Huge \textsc{Coriolis}
+  \vspace{1cm}
+  \Huge \textbf{User's Guide}
+  \vspace{1cm}
+
+  \huge {Jean-Paul \textsc{Chaput}}
+  \vspace{4cm}
+
+  \begin{figure}[!h]
+  \begin{center}
+    \includegraphics[scale=1.0]{../etc/images/logoCC.pdf}
+  \end{center}
+  \end{figure}
+
+  \normalsize 
+
+  This work is licensed under a\\
+  Creative Commons Attribution-NonCommercial-ShareALike 4.0 International License.\\
+  Creative Commons License \href{https://creativecommons.org/licenses/by-nc-sa/4.0/} {creativecommons.org/licenses/by-nc-sa/4.0/}
+
+  \end{center}
+
+  \newpage
+  \pagestyle{fancy} 
 
 |pagestylefancy|
 
 
+
 .. contents::
 
 |newpage|

documentation/etc/SoC-ReST.tex

@@ -100,6 +100,7 @@
 
  \newcommand{\LIP}                {\textsc{lip6}\xspace}
  \newcommand{\SoC}                {\textsc{S}o\textsc{C}\xspace}
+ \newcommand{\CIAN}                {\textsc{cian}\xspace}
 
  \renewcommand{\headrulewidth}{0.2mm}
  \renewcommand{\footrulewidth}{0.2mm}
@@ -107,7 +108,8 @@
  \renewcommand{\subsectionmark}[1]{}
  \lhead[]{Coriolis Documentation}
  \rhead[]{\today}
- \lfoot[]{\LIP/\SoC \href{https://www-soc.lip6.fr/}{www-soc.lip6.fr}}
+% \lfoot[]{\LIP/\SoC \href{https://www-soc.lip6.fr/}{www-soc.lip6.fr}}
+ \lfoot[]{\LIP/\CIAN \href{https://www-soc.lip6.fr/en/team-cian/}{www-soc.lip6.fr/en/team-cian}}
  \rfoot[]{\thepage}
  \cfoot[]{}
 

documentation/etc/definitions.rst

@@ -58,6 +58,7 @@
 .. |Alexandre|                      replace:: :sc:`Alexandre`
 .. |Belloeil|                       replace:: :sc:`Belloeil`
 .. |Chaput|                         replace:: :sc:`Chaput`
+.. |Chotin|                         replace:: :sc:`Chotin`
 .. |Chu|                            replace:: :sc:`Chu`
 .. |Clement|                        replace:: :sc:`Clement`
 .. |Dupuis|                         replace:: :sc:`Dupuis`