From 973dedc4a5e80e35aa3f332c3ab30a87f127576f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marie-Minerve=20Lou=C3=ABrat?= Date: Fri, 24 May 2019 13:24:11 +0200 Subject: [PATCH] Typos corrigees dans les fichiers du User Guide --- documentation/UsersGuide/Configuration.rst | 36 ++++++++++----------- documentation/UsersGuide/Installation.rst | 14 ++++---- documentation/UsersGuide/LicenseCredits.rst | 2 +- documentation/UsersGuide/Releases.rst | 2 +- documentation/UsersGuide/ScriptsPlugins.rst | 30 ++++++++--------- 5 files changed, 42 insertions(+), 42 deletions(-) diff --git a/documentation/UsersGuide/Configuration.rst b/documentation/UsersGuide/Configuration.rst index c40562d3..0f0533a1 100644 --- a/documentation/UsersGuide/Configuration.rst +++ b/documentation/UsersGuide/Configuration.rst @@ -22,7 +22,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: @@ -71,7 +71,7 @@ The initialization process is done by executing, in order, the following file(s) | **3** | The user's local setting | :cb:`/.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. @@ -89,9 +89,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): +-------+----------------------------------+-----------------------------------------------+ @@ -190,9 +190,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). @@ -209,25 +209,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. @@ -256,11 +256,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. @@ -306,18 +306,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. @@ -337,7 +337,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:`/.coriolis2/settings.py` (that is, written in |Python|). diff --git a/documentation/UsersGuide/Installation.rst b/documentation/UsersGuide/Installation.rst index cb264d3c..637cbf85 100644 --- a/documentation/UsersGuide/Installation.rst +++ b/documentation/UsersGuide/Installation.rst @@ -12,7 +12,7 @@ Installation As the sources are being released, the binary packaging is dropped. You still may find older version 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. Main building prerequisites: @@ -47,7 +47,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 @@ -124,8 +124,8 @@ Third and final step, build & install: :: --project=coriolis \ --doc --make="-j1 install" -We need to separate 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 +We need to perform a separate installation of the documentation because it +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 @@ -156,7 +156,7 @@ In the |Coriolis| |git| repository, two branches are present: dummy@lepka:src> ./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. In the (unlikely) event of a crash of |cgt|, as it is a |Python| script, the right @@ -187,11 +187,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. diff --git a/documentation/UsersGuide/LicenseCredits.rst b/documentation/UsersGuide/LicenseCredits.rst index a815e214..c07c0b0b 100644 --- a/documentation/UsersGuide/LicenseCredits.rst +++ b/documentation/UsersGuide/LicenseCredits.rst @@ -48,7 +48,7 @@ copyright© |UPMC| 2008-2018 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 |Knik| router makes use of the |Flute| software, which is copyright© Chris C. N. |Chu| from the Iowa State University diff --git a/documentation/UsersGuide/Releases.rst b/documentation/UsersGuide/Releases.rst index c86243a1..b66f89b3 100644 --- a/documentation/UsersGuide/Releases.rst +++ b/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``. diff --git a/documentation/UsersGuide/ScriptsPlugins.rst b/documentation/UsersGuide/ScriptsPlugins.rst index 8fe35c9e..2434eff2 100644 --- a/documentation/UsersGuide/ScriptsPlugins.rst +++ b/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//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 - levels of H tree neededs and place the clock buffers. +#. Builds the clock tree: creates the top-block abutment box, compute 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 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 - contains all the clock sub-nets. The interface is *not* changed. +* Obviously the top block or chip core model netlist is modified to + 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 - top level). Change both the model netlist and interface to propagate + contain DFFs that get re-connected to the clock sub-nets (from the + 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//plugins.conf``. @@ -303,8 +303,8 @@ Configuration parameters, defaults are defined in ``etc/coriolis2//plug Recursive-Save (RSave) ---------------------- -Perform 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 +Performs a recursive top down save of all the models from the top cell +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.