From d641607ac3c9e546b17d469a5f61a1e97e7552a2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marie-Minerve=20Lou=C3=ABrat?= Date: Fri, 24 May 2019 13:55:23 +0200 Subject: [PATCH] Typos corrigees dans Python Tutorial for Hurricane database --- .../PythonTutorial/AdvancedTopics.rst | 2 +- .../PythonTutorial/CellNetComponent.rst | 22 +++++++-------- documentation/PythonTutorial/CgtScript.rst | 6 ++-- documentation/PythonTutorial/Collections.rst | 12 ++++---- documentation/PythonTutorial/Environment.rst | 14 +++++----- documentation/PythonTutorial/Introduction.rst | 8 +++--- documentation/PythonTutorial/Netlist.rst | 28 +++++++++---------- documentation/PythonTutorial/RealDesigns.rst | 10 +++---- documentation/PythonTutorial/ToolEngines.rst | 6 ++-- 9 files changed, 54 insertions(+), 54 deletions(-) diff --git a/documentation/PythonTutorial/AdvancedTopics.rst b/documentation/PythonTutorial/AdvancedTopics.rst index 61ec706d..8a1e69ed 100644 --- a/documentation/PythonTutorial/AdvancedTopics.rst +++ b/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. diff --git a/documentation/PythonTutorial/CellNetComponent.rst b/documentation/PythonTutorial/CellNetComponent.rst index 087ed3fe..f0d38e72 100644 --- a/documentation/PythonTutorial/CellNetComponent.rst +++ b/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`_. diff --git a/documentation/PythonTutorial/CgtScript.rst b/documentation/PythonTutorial/CgtScript.rst index 27027ee2..2d81325b 100644 --- a/documentation/PythonTutorial/CgtScript.rst +++ b/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: diff --git a/documentation/PythonTutorial/Collections.rst b/documentation/PythonTutorial/Collections.rst index e9ad4f0a..3505dc24 100644 --- a/documentation/PythonTutorial/Collections.rst +++ b/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. -If you want to create or delete en element, do it outside of the collection +subtly, some element of the Collection_ may be skipped or processed twice. +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. diff --git a/documentation/PythonTutorial/Environment.rst b/documentation/PythonTutorial/Environment.rst index e8ce2573..703b3486 100644 --- a/documentation/PythonTutorial/Environment.rst +++ b/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 `/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 ``/etc/coriolis2``. For example, to use the 45nm FreeDPK which is in: :: diff --git a/documentation/PythonTutorial/Introduction.rst b/documentation/PythonTutorial/Introduction.rst index fa4c1de0..bbcd0144 100644 --- a/documentation/PythonTutorial/Introduction.rst +++ b/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 diff --git a/documentation/PythonTutorial/Netlist.rst b/documentation/PythonTutorial/Netlist.rst index 0d9c99dc..3460905c 100644 --- a/documentation/PythonTutorial/Netlist.rst +++ b/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. @@ -112,7 +112,7 @@ until it is placed. -------------------- To place an Instance, we apply a Transformation_ to the coordinate system -of the *master cell*. A transformation is composed of two operations : +of the *master cell*. A transformation is composed of two operations: #. An Orientation_, which can be a symmetry or a rotation (or a combination of those two). The Orientation **is applied first** to the coordinate @@ -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 -levels of hierarchy. To make the physical connexion to the *master net* +As was stated before, Plugs_ represent a logical connection between two +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`_. diff --git a/documentation/PythonTutorial/RealDesigns.rst b/documentation/PythonTutorial/RealDesigns.rst index 1bbe68a8..b9315184 100644 --- a/documentation/PythonTutorial/RealDesigns.rst +++ b/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 -your synthesis on a cell library not managed by AllianceFramework_, For example +pretty straightforward: call the static function ``Blif.load()``. If you made +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 diff --git a/documentation/PythonTutorial/ToolEngines.rst b/documentation/PythonTutorial/ToolEngines.rst index 9b3f68b8..fe3a75d4 100644 --- a/documentation/PythonTutorial/ToolEngines.rst +++ b/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()``.