jcarr
/
coriolis
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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

This commit is contained in:
Jean-Paul Chaput 2019-06-04 14:52:21 +02:00
parent 8ad910301d ab517fbfac
commit bc88fe0075
14 changed files with 118 additions and 118 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
documentation/PythonTutorial/AdvancedTopics.rst
View File

@ -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.

4
documentation/PythonTutorial/CgtScript.rst
View File

@ -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:

6
documentation/PythonTutorial/Collections.rst
View File

@ -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``,
they may unexpectedly shadow cells from the libraries.
Be also aware that cell files that may remain in the ``WORK_LIB``,
may unexpectedly shadow cells from the libraries.
.. code-block:: Python

2
documentation/PythonTutorial/Introduction.rst
View File

@ -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
=============== =====================================================

4
documentation/PythonTutorial/Netlist.rst
View File

@ -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.

BIN
documentation/PythonTutorial/PythonTutorial.pdf
View File

Binary file not shown.

2
documentation/PythonTutorial/index.rst
View File

@ -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.

2
documentation/PythonTutorial/pdfHeader.rst
View File

@ -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.

4
documentation/UsersGuide/Configuration.rst
View File

@ -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.

30
documentation/UsersGuide/Installation.rst
View File

@ -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|: ::

16
documentation/UsersGuide/Releases.rst
View File

@ -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
obsolete menues.
#. Makes |Katana| the default global & detailed router. Put |Knik| & |Kite| in the
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.

50
documentation/UsersGuide/ScriptsPlugins.rst
View File

@ -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
the pads which simplificate it's configuration and accessorily avoid
.. note:: The ``corona`` also avoids the router to actually have to manage directly
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

BIN
documentation/UsersGuide/UsersGuide.pdf
View File

Binary file not shown.

114
documentation/UsersGuide/ViewerTools.rst
View File

@ -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
more and more difficult as the capacity of the edges decrease, and at some point
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 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
it must be reachable through the ``PYTHONPATH``. You may uses the
So you must give the name of your script whithout ``.py`` extension and
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 |
| | | is an *instance* under the cursor position, load |
| | | it's *model* Cell in place of the current one. |
| **Hierarchy** | |CTRL_Down| | Goes one hierarchy level down. That is, if there |
| | | is an *instance* under the cursor position, loads |
| | | 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 |
| | against looping. The limit is sets to 4 |
| | router will stop. This is mainly a failsafe |
| | 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 |
| | is not a ``tty`` and suppress any escaped |
| | If enabled, assumes that the output device |
| | 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 Inspector Tab`_ browse through either the DataBase, the Cell or
#. `The Selection Tab`_ allows to view all the currently selected elements.
#. `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.
They have been made *very* visibles as big violet lines...
For example, after the detailed routing no *rubber* should remain.
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.
* **Selection**: Inspect the object currently highlited in the *Selection* tab.
* **Cell**: Inspects the currently loaded Cell.
* **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