diff --git a/README b/README deleted file mode 100644 index 6df0c876..00000000 --- a/README +++ /dev/null @@ -1,32 +0,0 @@ -Coriolis is a free database, placement tool and routing tool for VLSI designs. - -Purpose -======= - -Coriolis provides several tools to perform the layout of VLSI circuits. -Its main components are the Hurricane database, the Etesian placer and the Kite router, -but other tools can use the Hurricane database and the parsers provided. - -The user interface cgt is the prefered way to use Coriolis, but all -Coriolis tools are python modules and thus scriptable. - -Documentation -============= - -The full documentation is available [online](https://soc-extras.lip6.fr/en/coriolis/coriolis2-users-guide/) and, once built, as documentation/UsersGuide/UsersGuide.html. Basic build instructions are given below. - -Building and running Coriolis -============================= - -To build Coriolis, ensure the prerequisites are met, including cmake, boost, bison, flex, Qt, libxml2 and a C++11 compiler. - -Copy the sources or clone the git repository as ~/coriolis-2.x/src/coriolis -Then in this directory run the build command: - - ./bootstrap/ccb.py --project=coriolis --make="-jN install" - -After the build succeeds, to run the graphical interface: - - eval `~/coriolis-2.x/src/coriolis/bootstrap/coriolisEnv.py` - cgt -V - diff --git a/README.rst b/README.rst new file mode 100644 index 00000000..2755934d --- /dev/null +++ b/README.rst @@ -0,0 +1,84 @@ +.. -*- Mode: rst -*- + + +=============== +Coriolis README +=============== + + +Coriolis is a free database, placement tool and routing tool for VLSI designs. + + +Purpose +======= + +Coriolis provides several tools to perform the layout of VLSI circuits. Its +main components are the Hurricane database, the Etesian placer and the Kite +router, but other tools can use the Hurricane database and the parsers +provided. + +The user interface is the prefered way to use Coriolis, but all +Coriolis tools are Python modules and thus scriptables. + + +Documentation +============= + +The complete documentation is available here, both in pdf & html: + + ./documentation/UsersGuide/UsersGuide.html + ./documentation/UsersGuide/UsersGuide.pdf + +The documentation of the latest *stable* version is also +available online. It may be quite outdated from the *devel* +version. + + https://soc-extras.lip6.fr/en/coriolis/coriolis2-users-guide/ + + +Building Coriolis +================= + +To build Coriolis, ensure the following prerequisites are met: + +* Python 2.7. +* cmake. +* boost. +* bison & flex. +* Qt 4 or 5. +* libxml2. +* A C++11 compliant compiler. + +The build system relies on a fixed directory tree from the root +of the user currently building it. Thus first step is to get a clone of +the repository in the right place. Proceed as follow: :: + + ego@home:~$ mkdir -p ~/coriolis-2.x/src + ego@home:~$ cd ~/coriolis-2.x/src + ego@home:src$ git clone https://www-soc.lip6.fr/git/coriolis.git + ego@home:src$ cd coriolis + +If you want to use the *devel* branch: :: + + ego@home:coriolis$ git checkout devel + +Then, build the tool, where ``N`` is your number of threads: :: + + ego@home:coriolis$ ./bootstrap/ccb.py --project=coriolis --make="-jN install" + +Coriolis gets installed at the root of the following tree: :: + + ~/coriolis-2.x/./Release.Shared/install/ + +Where ```` is the name of your operating system and ```` your +distribution. + + +Using Coriolis +============== + +A helper is provided to setup the environment ``coriolisEnv.py``: :: + + ego@home:~$ eval `~/coriolis-2.x/src/coriolis/bootstrap/coriolisEnv.py` + ego@home:~$ cgt -V + diff --git a/bootstrap/builder/Configuration.py b/bootstrap/builder/Configuration.py index cff28ff2..070877f6 100644 --- a/bootstrap/builder/Configuration.py +++ b/bootstrap/builder/Configuration.py @@ -191,6 +191,9 @@ class Configuration ( object ): print "[WARNING] Unrecognized OS: \"%s\"." % lines[0][:-1] print " (using: \"%s\")" % self._osType + + if self._libSuffix == '64' and not os.path.exists('/usr/lib64'): + self._libSuffix = None return diff --git a/bootstrap/coriolisEnv.py b/bootstrap/coriolisEnv.py index 4c0f2d40..d3cefae1 100755 --- a/bootstrap/coriolisEnv.py +++ b/bootstrap/coriolisEnv.py @@ -116,6 +116,9 @@ def guessOs (): ldLibraryPath = os.getenv('LD_LIBRARY_PATH') if not ldLibraryPath or 'devtoolset' in ldLibraryPath: useDevtoolset2 = False + + if libDir == 'lib64' and not os.path.exists('/usr/lib64'): + libDir = 'lib' return (osType,libDir,useDevtoolset2) diff --git a/documentation/UsersGuide/UsersGuide.html b/documentation/UsersGuide/UsersGuide.html new file mode 100644 index 00000000..affefcb6 --- /dev/null +++ b/documentation/UsersGuide/UsersGuide.html @@ -0,0 +1,2076 @@ + + + + + + + + + + + +
+ + + + + + + + + + + + + + +


+
+

Coriolis User's Guide

+


+
+ The pdf version of this document is available here:
+ Coriolis User's Guide +
+

+
+

Credits & License

+

Hurricane +Rémy Escassut & + Christian Masson

+
+

Etesian +Gabriel Gouvine

+
+

Stratus +Sophie Belloeil

+
+

Knik +Damien Dupuis

+
+

Kite, + Unicorn +Jean-Paul Chaput

+


+

The Hurricane data-base is copyright© Bull 2000-2015 and is +released under the terms of the lgpl license. All other tools are +copyright© upmc 2008-2015 and released under the gpl +license.

+

Others important contributors to Coriolis are Christophe Alexandre, +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 +(http://home.eng.iastate.edu/~cnchu/).

+

+
+
+

Release Notes

+
+

Release 1.0.1475

+

This is the first preliminary release of the Coriolis 2 framework.

+

This release mainly ships the global router Knik and the detailed router +Kite. Together they aim to replace the Alliance Nero router. +Unlike Nero, Kite is based on an innovating routing modeling and ad-hoc +algorithm. Although it is released under gpl license, the source code +will be avalaible later. +

+

Contents of this release:

+
    +
  1. A graphical user interface (viewer only).
    2. +
  2. The Knik global router.
    3. +
  3. The Kite detailed router.
    4. +
+

Supported input/output formats:

+
    +
  • Alliance vst (netlist) & ap (physical) formats.
    • +
  • Even if there are some references to the Cadence lefdef format, its +support is not included because it depends on a library only available +to Si2 affiliated members.
    • +
+
+
+

Release 1.0.1963

+

Release 1963 is alpha. All the tools from Coriolis 1 have been ported into +this release.

+

Contents of this release:

+
    +
  1. The Stratus netlist capture language (GenLib replacement).
    2. +
  2. The Mauka placer (still contains bugs).
    3. +
  3. A graphical user interface (viewer only).
    4. +
  4. The Knik global router.
    5. +
  5. The Kite detailed router.
    6. +
  6. Partially implemented python support for configuration files +(alternative to xml).
    7. +
  7. A documentation (imcomplete/obsoleted in Hurricane's case).
    8. +
+
+
+

Release 1.0.2049

+

Release 2049 is Alpha.

+

Changes of this release:

+
    +
  1. The Hurricane documentation is now accurate. Documentation +for the Cell viewer and CRLcore has been added.
    2. +
  2. More extensive Python support for all the components of +Coriolis.
    3. +
  3. Configuration is now completly migrated under Python. +xml loaders can still be useds for compatibilty.
    4. +
  4. The cgt main has been rewritten in Python.
    5. +
+
+
+

Release v2.0.1

+
    +
  1. Migrated the repository from svn to git, and release complete sources. +As a consequence, we drop the distribution packaging support and give +public read-only access to the repository.
    2. +
  2. Deep rewrite of the Katabatic database and Kite detailed router, +achieve a speedup factor greater than 20...
    3. +
+
+
+

Release v2.1

+
    +
  1. Replace the old simulated annealing placer Mauka by the analytical placer +Etesian and its legalization and detailed placement tools.
    2. +
  2. Added a Blif format parser to process circuits generated by the Yosys and ABC +logic synthetizers.
    3. +
  3. The multiples user defined configuration files are now grouped under +a common hidden (dot) directory .coriolis2 and the file extension +is back from .conf to .py.
    4. +
+ + + + +

+
+
+
+

Installation

+
+

Note

+

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 +running the ccb installer.

+

Main building prerequisites:

+
    +
  • cmake
    • +
  • C++11-capable compiler
    • +
  • python2.7
    • +
  • boost
    • +
  • libxml2
    • +
  • yacc & lex
    • +
  • Qt 4 or Qt 5
    • +
+

Building documentation prerequisites:

+
    +
  • doxygen
    • +
  • latex
    • +
  • latex2html
    • +
  • python-docutils (for reStructuredText)
    • +
+

Optional libraries:

+
    +
  • Lemon (used by the detailed placer)
    • +
  • LEF/DEF (from SI2)
    • +
+

The Coloquinte component requires the lemon component from coin-or (Coin Or Home). +A repository of coin-or packages backported from Fedora 21 is available here:

+ +

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 +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 ~/ or $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.

+ ++++ + + + + + + + + + + + + + + + + + + + + + + +
Sources
+
Sources root
+
under git
+
+
+
~/coriolis-2.x/src
+
~/coriolis-2.x/src/coriolis
+
+
Architecture Dependant Build
+
Linux, SL 7, 64 bits
+
Linux, SL 6, 32 bits
+
Linux, SL 6, 64 bits
+
Linux, Fedora, 64 bits
+
Linux, Fedora, 32 bits
+
FreeBSD 8, 32 bits
+
FreeBSD 8, 64 bits
+
Windows 7, 32 bits
+
Windows 7, 64 bits
+
Windows 8.x, 32 bits
+
Windows 8.x, 64 bits
+
+
+
~/coriolis-2.x/Linux.el7_64/Release.Shared/build/<tool>
+
~/coriolis-2.x/Linux.slsoc6x/Release.Shared/build/<tool>
+
~/coriolis-2.x/Linux.slsoc6x_64/Release.Shared/build/<tool>
+
~/coriolis-2.x/Linux.fc_64/Release.Shared/build/<tool>
+
~/coriolis-2.x/Linux.fc/Release.Shared/build/<tool>
+
~/coriolis-2.x/FreeBSD.8x.i386/Release.Shared/build/<tool>
+
~/coriolis-2.x/FreeBSD.8x.amd64/Release.Shared/build/<tool>
+
~/coriolis-2.x/Cygwin.W7/Release.Shared/build/<tool>
+
~/coriolis-2.x/Cygwin.W7_64/Release.Shared/build/<tool>
+
~/coriolis-2.x/Cygwin.W8/Release.Shared/build/<tool>
+
~/coriolis-2.x/Cygwin.W8_64/Release.Shared/build/<tool>
+
+
Architecture Dependant Install
Linux, SL 6, 32 bits~/coriolis-2.x/Linux.slsoc6x/Release.Shared/install/
FHS Compliant Structure under Install
+
Binaries
+
Libraries (Python)
+
Include by tool
+
Configuration files
+
Doc, by tool
+
+
+
.../install/bin
+
.../install/lib
+
.../install/include/coriolis2/<project>/<tool>
+
.../install/etc/coriolis2/
+
.../install/share/doc/coriolis2/en/html/<tool>
+
+
+
+

Note

+

Alternate build types: the Release.Shared means an optimized build +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 +and Python modules (which must be dynamic).

+
+

+
+
+

Building Coriolis

+

The first step is to create the source directory and pull the git repository:

+
+dummy@lepka:~$ mkdir -p ~/coriolis-2.x/src
+dummy@lepka:~$ cd ~/coriolis-2.x/src
+dummy@lepka:~$ git clone https://www-soc.lip6.fr/git/coriolis.git
+
+

Second and final step, build & install:

+
+dummy@lepka:src$ ./bootstrap/ccp.py --project=coriolis \
+                                    --make="-j4 install"
+dummy@lepka:src$ ./bootstrap/ccb.py --project=coriolis \
+                                    --doc --make="-j1 install"
+
+

We need two steps because the documentation do not support to be generated with +a parallel build. So we compile & install in a first step in -j4 (or whatever) +then we generate the documentation in -j1

+

Under rhel6 or clones, you must build using the devtoolset2:

+
+dummy@lepka:src$ ./bootstrap/ccp.py --project=coriolis \
+                                    --devtoolset-2 --make="-j4 install"
+
+

If you want to uses Qt 5 instead of Qt 4, you may add the --qt5 argument.

+

The complete list of ccb functionalities can be accessed with the --help argument. +It also may be run in graphical mode (--gui).

+
+

Building the Devel Branch

+

In the Coriolis git repository, two branches are present:

+
    +

  • The master branch, which contains the latest stable version. This is the +one used by default if you follow the above instructions.

    +
    • +

  • The devel branch, which obviously contains the latest commits from the +development team. To use it instead of the master one, do the following +command just after the first step:

    +
    +dummy@lepka:~$ git checkout devel
+dummy@lepka:src$ ./bootstrap/ccp.py --project=coriolis \
+                                    --make="-j4 install" --debug
+
    +

    Be aware that it may requires 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 +command to run gdb on it is:

    +
    +dummy@lepka:work$ gdb python core.XXXX
+
    +
    • +
+

+
+
+

Additionnal Requirement under MacOS

+

Coriolis make uses of the 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:

+
+dummy@macos:~$ port install boost +python27
+dummy@macos:~$ port select python python27
+dummy@macos:-$ export DYLD_FRAMEWORK_PATH=/opt/local/Library/Frameworks
+
+

The last two lines tell MacOS to use the Python from MacPorts and not from +the system.

+

Then proceed with the generic install instructions.

+
+
+
+

Packaging Coriolis

+

Packager should not uses 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/:

+
    +
  • bootstrap/coriolis2.spec.in for rpm based distributions.
    • +
  • bootstrap/debian for Debian based distributions.
    • +
+
+
+

Hooking up into Alliance

+

Coriolis relies on Alliance for the cell libraries. So after installing or +packaging, you must configure it so that it can found those libraries.

+

This is done by editing the one variable cellsTop in the Alliance helper +(see Alliance Helper). This variable must point to the directory of the +cells libraries. In a typical installation, this is generally +/usr/share/alliance/cells.

+
+
+

Setting up the Environment (coriolisEnv.py)

+

To simplify the tedious task of configuring your environment, a helper is provided +in the bootstrap source directory (also installed in the directory +.../install/etc/coriolis2/) :

+
+~/coriolis-2.x/src/coriolis/bootstrap/coriolisEnv.py
+
+

Use it like this:

+
+dummy@lepka:~> eval `~/coriolis-2.x/src/coriolis/bootstrap/coriolisEnv.py`
+
+
+

Note

+

Do not call that script in your environement initialisation. +When used under rhel6 or clones, it needs to be run in the devtoolset2 +environement. The script then launch a new shell, which may cause an +infinite loop if it's called again in, say ~/.bashrc.

+

Instead you may want to create an alias:

+
+alias c2r='eval "`~/coriolis-2.x/src/coriolis/bootstrap/coriolisEnv.py`"'
+
+
+

+
+
+
+

Documentation

+

The general index of the documentation for the various parts of Coriolis +are avalaibles here Coriolis Tools Documentation.

+
+

Note

+

Python Documentation: +Most of the documentation is related to the C++ API and implemetation of +the tools. However, the Python bindings have been created so they +mimic as closely as possible the C++ interface, so the documentation +applies to both languages with only minor syntactic changes.

+
+
+

General Software Architecture

+

Coriolis has been build 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:

+
    +
  • For self-contained modules boost::python (mainly in vlsisapd).
    • +
  • For all modules based on Hurricane, we created our own wrappers due +to very specific requirements such as shared functions between modules +or C++/Python secure bi-directional object deletion.
    • +
+

Coriolis Software Schematic

+
+
+
+

Coriolis Configuration & Initialisation

+

All configuration & initialization files are Python scripts, despite their +.conf extention. From a syntactic point of view, there is no difference +between the system-wide configuration files and the user's configuration, +they may use the same Python helpers. +

+

Configuration is done in two stages:

+
    +
  1. Selecting the symbolic technology.
    2. +
  2. Loading the complete configuration for the given technology.
    3. +
+
+

First Stage: Symbolic Technology Selection

+

+The initialization process is done by executing, in order, the following +file(s):

+ +++++ + + + + + + + + + + + + + + + + + + + + +
OrderMeaningFile
1The system setting/etc/coriolis2/techno.conf
2The user's global setting${HOME}/.coriolis2/techno.py
3The user's local setting<CWD>/.coriolis2/techno.py
+

Thoses files must provides only two variables, the name of the symbolic technology +and the one of the real technology. For example:

+
+# -*- Mode:Python -*-
+
+symbolicTechno = 'cmos'
+realTechno     = 'hcmos9'
+
+
+
+

Second Stage: Technology Configuration Loading

+

+The TECHNO variable is set by the first stage and it's the name of the +symbolic technology. A directory of that name, with all the configuration files, +must exists in the configuration directory. In addition to the technology-specific +directories, a common/ directory is there to provides a trunk for all the +identical datas across the various technologies. The initialization process is done +by executing, in order, the following file(s):

+ +++++ + + + + + + + + + + + + + + + + + + + + +
OrderMeaningFile
1The system initialization/etc/coriolis2/<TECHNO>/<TOOL>.conf
2The user's global initialization${HOME}/.coriolis2/settings.py
3The user's local initialization<CWD>/.coriolis2/settings.py
+
+

Note

+

The loading policy is not hard-coded. It is implemented +at Python level in /etc/coriolis2/coriolisInit.py, and thus may be easily be +amended to whatever site policy.

+

The truly mandatory requirement is the existence of coriolisInit.py +which must contain a coriolisConfigure() function with no argument.

+
+
+
+

Configuration Helpers

+

To ease the writing of configuration files, a set of small helpers +is available. They allow to setup the configuration parameters through +simple assembly of tuples. The helpers are installed under the directory:

+
+<install>/etc/coriolis2/
+
+

Where <install>/ is the root of the installation.

+

+
+

Alliance Helper

+

The configuration file must provide a allianceConfig tuple of +the form:

+
+cellsTop = '/usr/share/alliance/cells/'
+
+allianceConfig = \
+    ( ( 'SYMBOLIC_TECHNOLOGY', helpers.sysConfDir+'/technology.symbolic.xml'   )
+    , ( 'REAL_TECHNOLOGY'    , helpers.sysConfDir+'/technology.cmos130.s2r.xml')
+    , ( 'DISPLAY'            , helpers.sysConfDir+'/display.xml'               )
+    , ( 'CATALOG'            , 'CATAL')
+    , ( 'WORKING_LIBRARY'    , '.')
+    , ( 'SYSTEM_LIBRARY'     , ( (cellsTop+'sxlib'   , Environment.Append)
+                               , (cellsTop+'dp_sxlib', Environment.Append)
+                               , (cellsTop+'ramlib'  , Environment.Append)
+                               , (cellsTop+'romlib'  , Environment.Append)
+                               , (cellsTop+'rflib'   , Environment.Append)
+                               , (cellsTop+'rf2lib'  , Environment.Append)
+                               , (cellsTop+'pxlib'   , Environment.Append) ) )
+    , ( 'SCALE_X'            , 100)
+    , ( 'IN_LO'              , 'vst')
+    , ( 'IN_PH'              , 'ap')
+    , ( 'OUT_LO'             , 'vst')
+    , ( 'OUT_PH'             , 'ap')
+    , ( 'POWER'              , 'vdd')
+    , ( 'GROUND'             , 'vss')
+    , ( 'CLOCK'              , '^ck.*')
+    , ( 'BLOCKAGE'           , '^blockageNet*')
+    )
+
+

The example above shows the system configuration file, with all the +available settings. Some important remarks about thoses settings:

+
    +

  • In it's configuration file, the user do 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).

    +
    • +

  • SYSTEM_LIBRARY setting: Setting up the library search path. +Each library entry in the tuple will be added to the search path according +to the second parameter:

    +
      +
    • Environment::Append: append to the search path.
      • +
    • Environment::Prepend: insert in head of the search path.
      • +
    • Environment::Replace: look for a library of the same name and replace +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 +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 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. +For a standard installation it would be: /soc/coriolis2.

    +
    • +
+ + + + + + + + + + + + + + + + +

A typical user's configuration file would be:

+
+import os
+
+homeDir = os.getenv('HOME')
+
+allianceConfig = \
+    ( ('WORKING_LIBRARY'    , homeDir+'/worklib')
+    , ('SYSTEM_LIBRARY'     , ( (homeDir+'/mylib', Environment.Append) ) )
+    , ('POWER'              , 'vdd.*')
+    , ('GROUND'             , 'vss.*')
+    )
+
+
+
+

Tools Configuration Helpers

+

All the tools uses the same helper to load their configuration (a.k.a. +Configuration Helper). Currently the following configuration system-wide +configuration files are defined:

+
    +
  • misc.conf: commons settings or not belonging specifically to a tool.
    • +
  • etesian.conf: for the Etesian tool.
    • +
  • kite.conf: for the Kite tool.
    • +
  • stratus1.conf: for the Stratus1 tool.
    • +
+

Here is the contents of etesian.conf:

+
+# Etesian parameters.
+parametersTable = \
+    ( ('etesian.aspectRatio'    , TypePercentage, 100    , { 'min':10, 'max':1000 } )
+    , ('etesian.spaceMargin'    , TypePercentage, 5      )
+    , ('etesian.uniformDensity' , TypeBool      , False  )
+    , ('etesian.routingDriven'  , TypeBool      , False  )
+    , ("etesian.effort"         , TypeEnumerate , 2
+      , { 'values':( ("Fast"    , 1)
+                   , ("Standard", 2)
+                   , ("High"    , 3)
+                   , ("Extreme" , 4) ) }
+      )
+    , ("etesian.graphics"       , TypeEnumerate , 2
+      , { 'values':( ("Show every step"  , 1)
+                   , ("Show lower bound" , 2)
+                   , ("Show result only" , 3) ) }
+      )
+    )
+
+layoutTable = \
+    ( (TypeTab   , 'Etesian', 'etesian')
+
+    , (TypeTitle , 'Placement area')
+    , (TypeOption, "etesian.aspectRatio"   , "Aspect Ratio, X/Y (%)", 0 )
+    , (TypeOption, "etesian.spaceMargin"   , "Space Margin"         , 1 )
+    , (TypeRule  ,)
+    , (TypeTitle , 'Etesian - Placer')
+    , (TypeOption, "etesian.uniformDensity", "Uniform density"      , 0 )
+    , (TypeOption, "etesian.routingDriven" , "Routing driven"       , 0 )
+    , (TypeOption, "etesian.effort"        , "Placement effort"     , 1 )
+    , (TypeOption, "etesian.graphics"      , "Placement view"       , 1 )
+    , (TypeRule  ,)
+    )
+
+

Taxonomy of the file:

+
    +
  • It must contains, at least, the two tables:
      +
    • parametersTable, defines & initialise the configuration variables.
      • +
    • layoutTables, defines how the various parameters will be displayed +in the configuration window (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 +(TypeOption, 'paramId', ParameterType, DefaultValue) with:
      +
    1. TypeOption, tells that this tuple describe a parameter.
      2. +
    2. paramId, the identifier of the parameter. Identifiers are defined +by the tools. The list of parameters is detailed in each tool section.
      3. +
    3. ParameterType, the kind of parameter. Could be:
        +
      • TypeBool, boolean.
        • +
      • TypeInt, signed integer.
        • +
      • TypeEnumerate, enumerated type, needs extra entry.
        • +
      • TypePercentage, percentage, expressed between 0 and 100.
        • +
      • TypeDouble, float.
        • +
      • TypeString, character string.
        • +
      +
      4. +
    4. DefaultValue, the default value for that parameter.
      5. +
    +
    • +
+
+
+
+

Hacking the Configuration Files

+

Asides from the symbols that gets used by the configuration helpers like +allianceConfig or parametersTable, you can put pretty much anything +in <CWD>/.coriolis2/settings.py (that is, written in Python).

+

For example:

+
+# -*- Mode:Python -*-
+
+defaultStyle = 'Alliance.Classic [black]'
+
+# Regular Coriolis configuration.
+parametersTable = \
+    ( ('misc.catchCore'           , TypeBool      , False  )
+    , ('misc.info'                , TypeBool      , False  )
+    , ('misc.paranoid'            , TypeBool      , False  )
+    , ('misc.bug'                 , TypeBool      , False  )
+    , ('misc.logMode'             , TypeBool      , True   )
+    , ('misc.verboseLevel1'       , TypeBool      , False  )
+    , ('misc.verboseLevel2'       , TypeBool      , True   )
+    , ('misc.traceLevel'          , TypeInt       , 1000   )
+    )
+
+# Some ordinary Python script...
+import os
+
+print '       o  Cleaning up ClockTree previous run.'
+for fileName in os.listdir('.'):
+  if fileName.endswith('.ap') or (fileName.find('_clocked.') >= 0):
+    print '          - <%s>' % fileName
+    os.unlink(fileName)
+
+

See Python Interface to Coriolis for more details those capabilities.

+
+
+
+

CGT - The Graphical Interface

+

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 +is not yet placed.
      • +
    • Execute Stratus Scripts.
      • +
    • Menu to run the tools (placement, routage).
      • +
    +
    • +
+

Features are detailed in Viewer & Tools.

+

Viewer Basic Snapshot

+
    +
  • The Controller, which allows:
      +
    • Tweak what is displayer 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. +They are closely related to Configuration & Initialisation.
      • +
    +
    • +
+

Controller Basic Snapshot

+
+
+

Viewer & Tools

+
+

Stratus Netlist Capture

+

Stratus is the replacement for GenLib procedural netlist capture language. +It is designed as a set of Python classes, and comes with it's own documentation +(Stratus Documentation)

+
+
+

The Hurricane Data-Base

+

The Alliance flow is based on the mbk data-base, which has one data-structure +for each view. That is, Lofig for the logical view and Phfig for the physical +view. The place and route tools were responsible for maintaining (or not) the +coherency between views. Reflecting this weak coupling between views, each one +was stored in a separate file with a specific format. The logical view is stored +in a vst file in vhdl format and the physical in an ap file in an ad-hoc format.

+

The Coriolis flow is based on the Hurricane data-base, which has a unified +structure for logical and physical view. That data structure is the Cell object. +The Cell can have any state between pure netlist and completly placed and +routed design. Although the memory representation of the views has deeply +changed we still use the Alliance files format, but they now really represent +views of the same object. The point is that one must be very careful about +view coherency when going to and from Coriolis.

+

As for the second release, Coriolis can be used only for three purposes :

+
    +
  • Placing a design, in which case the netlist view must be present.
    • +
  • Routing a design, in that case the netlist +view and the layout view must be present and layout view must contain +a placement. Both views must have the same name. When saving the routed design, +it is advised to change the design name otherwise the original unrouted placement +in the layout view will be overwritten.
    • +
  • Viewing a design, the netlist view must be present, if a layout +view is present it still must have the same name but it can be in any +state.
    • +
+
+
+

Synthetizing and loading a design

+

Coriolis supports several file formats. It can load all file format +from the Alliance toolchain (.ap for layout, behavioural and structural vhdl .vbe and .vst), +BLIF netlist format as well as benchmark formats from the ISPD contests.

+

It can be compiled with LEF/DEF support, although it requires acceptance of the SI2 license +and may not be compiled in your version of the software.

+
+

Synthesis under Yosys

+

You can create a BLIF file from the Yosys synthetizer, which can be imported under Coriolis. +Most libraries are specified as a .lib liberty file and a .lef LEF file. +Yosys opens most .lib files with minor modifications, but LEF support in Coriolis relies on SI2. +If Coriolis hasn't been compiled against it, the library is given in Alliance .ap format. +Some free libraries already provide both .ap and .lib files.

+

Once you have installed a common library under Yosys and Coriolis, just synthetize your design +with Yosys and import it (as Blif without the extension) under Coriolis to perform place&route.

+
+
+

Synthesis under Alliance

+

Alliance is an older toolchain but has been extensively used for years. Coriolis can import +and write Alliance designs and libraries directly.

+
+
+
+

Etesian -- Placer

+

The Etesian placer is a state of the art (as of 2015) analytical placer. It is +within 5% of other placers' solutions, but is normally a bit worse than ePlace. +This Coriolis tool is actually an encapsulation of Coloquinte which is the placer.

+
+

Note

+

Instance Uniquification Unsupported: a same logical instance cannot have +two different placements. So, either you manually make a clone of it or you +supply a placement for it. We need to implement uniquification in the +Hurricane database.

+
+

+Hierarchical Placement

+

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 +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).

+

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.

+

Etesian Abutment Box

+

+Computing the Placement Area

+

The placement area is computed using the etesian.aspectRatio and etesian.spaceMargin +parameters only if the top-cell has an empty abutment box. If the top-cell abutment +box has to be set, then it is propagated to all the instances models recursively.

+

+Reseting the Placement

+

Once a placement has been done, the placer cannot reset it (will be implemented +later). To perform a new placement, you must restart cgt. In addition, if you +have saved the placement on disk, you must erase any .ap file, which are +automatically reloaded along with the netlist (.vst).

+

+Limitations

+

Etesian supports standard cells and fixed macros. As for the Coriolis 2.1 version, +it doesn't support movable macros, and you must place every macro beforehand. +Timing and routability analysis are not included either, and the returned placement +may be unroutable.

+

+
+

Etesian Configuration Parameters

+ +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Parameter IdentifierTypeDefault
Etesian Parameters
etesian.aspectRatioTypePercentage100
Define the height on width H/W aspect +ratio, can be comprised between 10 and 1000
etesian.spaceMarginTypePercentage5
The extra white space added to the total area +of the standard cells
etesian.uniformDensityTypeBoolFalse
Whether the cells will be spread envenly +across the area or allowed to form denser +clusters
etesian.effortTypeInt2
Sets the balance between the speed of the +placer and the solution quality
etesian.routingDrivenTypeBoolFalse
Whether the tool will try routing iterations +and whitespace allocation to improve +routability; to be implemented
etesian.graphicsTypeInt2

How often the display will be refreshed +More refreshing slows the placer.

+
    +
  • 1 shows both upper and lower bounds
    • +
  • 2 only shows lower bound results
    • +
  • 3 only shows the final results
    • +
+
+
+
+
+

Knik -- Global Router

+

The quality of Knik global routing solutions are equivalent to those of FGR 1.0. +For an in-depth description of Knik algorithms, you may download the thesis of +D. Dupuis avalaible from here~: Knik Thesis.

+

The global router is (not yet) deterministic. To circumvent this limitation, +a global routing solution can be saved to disk and reloaded for later uses.

+

A global routing is saved into a file with the same name as the design and a +kgr extention. It is in Box Router output format.

+

Menus:

+
    +

  •

    menu_KiteSaveGlobalRouting.
    • +

  •

    menu_KiteLoadGlobalRouting.
    • +
+
+
+

Kite -- Detailed Router

+

Kite no longer suffers from the limitations of Nero. It can route big designs +as its runtime and memory footprint is almost linear (with respect to the number +of gates). It has successfully routed design of more than 150K gates. +

+

However, this first release comes with the temporary the following +restrictions:

+
    +
  • Works only with SxLib standard cell gauge.
    • +
  • Works always with 4 routing metal layers (M2 through M5).
    • +
  • Do not allow (take into account) pre-routed wires on signals +other than power or ground.
    • +
+
+

Note

+

Slow Layer Assignment. Most of the time, the layer assignment stage is +fast (less than a dozen seconds), but in some instances it can take more +than a dozen minutes. This is a known bug and will be corrected in later +releases.

+
+

After each run, Kite displays a set of completion ratios which must all +be equal to 100% if the detailed routing has been successfull. +In the event of a failure, on a saturated design, you may decrease the +edge saturation ratio (argument --edge) to balance more evenly the design +saturation. That is, the maximum saturation decrease at the price of a wider +saturated area and increased wirelength. This is the saturation of the +global router Knik, and you may increase/decrease by steps of 5%, +which represent one track. The maximum capacity of the SxLib gauge is +10 tracks in two layers, that makes 20 tracks by Knik edge.

+

Routing a design is done in four ordered steps:

+
    +
  1. Detailed pre-route

    menu_KiteDetailedPreRoute.
    2. +
  2. Global routing

    menu_KiteGlobalRoute.
    3. +
  3. Detailed routing

    menu_KiteDetailedRoute.
    4. +
  4. Finalize routing

    menu_KiteFinalizeRoute.
    5. +
+

It is possible to supply to the router a complete wiring for some nets that the user's +wants to be routed according to a specific topology. The supplied topology must respect +the building rules of the Katabatic database (contacts must be, terminals, turns, h-tee +& v-tee only). During the first step Detailed Pre-Route the router will solve +overlaps between the segments, without making any dogleg. If no pre-routed topologies +are present, this step may be ommited. Any net routed at this step is then fixed and +become unmovable for the later stages.

+

After the detailed routing step the Kite data-structure is still active +(the Hurricane wiring is decorated). The finalize step performs the removal of +the Kite data-structure, and it is not advisable to save the design before +that step.

+

You may visualize the density (saturation) of either Knik (on edges) or +Kite (on GCells) until the routing is finalized. Special layers appears +to that effect in the The Layers&Go Tab.

+
+

Kite Configuration Parameters

+

As Knik is only called through Kite, it's parameters also have +the kite. prefix.

+

The Katabatic parameters control the layer assignment step.

+

All the defaults value given below are from the default Alliance technology +(cmos and SxLib cell gauge/routing gauge).

+ +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Parameter IdentifierTypeDefault
Katabatic Parameters
katabatic.topRoutingLayerTypeStringMETAL5
Define the highest metal layer that will be +used for routing (inclusive).
katabatic.globalLengthThresholdTypeInt1450
This parameter is used by a layer assignment +method which is no longer used (did not give +good results)
katabatic.saturateRatioTypePercentage80
If M(x) density is above this ratio, +move up feedthru global segments up from +depth x to x+2
katabatic.saturateRpTypeInt8
If a GCell contains more terminals +(RoutingPad) than that number, force a +move up of the connecting segments to those +in excess
Knik Parameters
kite.hTracksReservedLocalTypeInt3
To take account the tracks needed inside a +GCell to build the local routing, decrease +the capacity of the edges of the global +router. Horizontal and vertical locally +reserved capacity can be distinguished for +more accuracy.
kite.vTracksReservedLocalTypeInt3
cf. kite.hTracksReservedLocal
Kite Parameters
kite.eventsLimitTypeInt4000002
The maximum number of segment displacements, +this is a last ditch safety against infinite +loop. It's perhaps a little too low for big +designs
kite.ripupCostTypeInt3
Differential introduced between two ripup +cost to avoid a loop between two ripped up +segments
kite.strapRipupLimitTypeInt16
Maximum number of ripup for strap segments
kite.localRipupLimitTypeInt9
Maximum number of ripup for local segments
kite.globalRipupLimitTypeInt5
Maximum number of ripup for global segments, +when this limit is reached, triggers topologic +modification
kite.longGlobalRipupLimitTypeInt5
Maximum number of ripup for long global +segments, when this limit is reached, triggers +topological modification
+
+
+
+

Executing Python Scripts in Cgt

+

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 +dotted module notation.

+
+

A Python/Stratus script must contains 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: CellViewer) is limited to basic capabilities +only.

+

Any script given on the command line will be run immediatly after the +initializations and before any other argument is processed.

+

For more explanation on Python scripts see Python Interface to Coriolis.

+
+
+

Printing & Snapshots

+

Printing or saving into a pdf is fairly simple, just uses 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

+

There is also two mode of printing selectable through the Controller +Settings -> Misc -> Printer/Snapshot Mode:

+ +++++ + + + + + + + + + + + + + + +
ModeDPI (approx.)Intended Usage
Cell Mode150For single Cell printing or very small designs. +Patterns will be bigger and more readable.
Design Mode300For designs (mostly commposed of wires and cells +outlines).
+
+

Note

+

The pdf file size +Be aware that the generated pdf files are indeed only pixmaps. +So they can grew very large if you select paper format above A2 +or similar.

+
+

+Saving into an image is subject to the same remarks as for pdf.

+
+
+

Memento of Shortcuts in Graphic Mode

+

The main application binary is cgt.

+ +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CategoryKeysAction
Moves
+
Up, +Down
+
Left, +Right
+
+		Shift the view in the according direction
FitfFit to the Cell abutment box
RefreshCTRL+LTriggers a complete display redraw
Gotogapperture is the minimum side of the area +displayed around the point to go to. It's an +alternative way of setting the zoom level
Zoomz, +mRespectively zoom by a 2 factor and unzoom +by a 2 factor
+
BigMouse
+
Area Zoom
+
+		You can perform a zoom to an area. +Define the zoom area by holding down the left +mouse button while moving the mouse.
Selection
+
BigMouse
+
Area Selection
+
+		You can select displayed objects under an area. +Define the selection area by holding down the +right mouse button while moving the mouse.
+
BigMouse
+
Toggle Selection
+
+		You can toggle the selection of one object under +the mouse position by pressing CTRL and +pressing down the right mouse button. A popup +list of what's under the position shows up into +which you can toggle the selection state of one +item.
SToggle the selection visibility
ControllerCTRL+I

Show/hide the controller window.

+

It's the Swiss Army Knife of the viewer. +From it, you can fine-control the display and +inspect almost everything in your design.

+
Rulersk, +ESCOne stroke on k enters the ruler mode, in +which you can draw one ruler. You can exit the +ruler mode by pressing ESC. Once in ruler +mode, the first click on the left mouse button +sets the ruler's starting point and the second +click the ruler's end point. The second click +exits automatically the ruler mode.
KClears all the drawn rulers
PrintCTRL+PCurrently rather crude. It's a direct copy of +what's displayed in pixels. So the resulting +picture will be a little blurred due to +anti-aliasing mechanism.
Open/CloseCTRL+OOpens a new design. The design name must be +given without path or extention.
CTRL+WClose the current viewer window, but do not quit +the application.
CTRL+QCTRL+Q quit the application +(closing all windows).
HierarchyCTRL+DownGo 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.
CTRL+UpGo one hierarchy level up. if we have entered +the current model through CTRL+Down +reload the previous model (the one +in which this model is instanciated).
+
+
+

Cgt Command Line Options

+

Appart from the obvious --text options, all can be used for text and graphical mode.

+ ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ArgumentsMeaning
-t|--textInstruct cgt to run in text mode.
-L|--log-modeDisable the uses of ansi escape sequence on +the tty. Useful when the output is +redirected to a file.
-c <cell>|--cell=<cell>The name of the design to load, without +leading path or extention.
-g|--load-globalReload a global routing solution from disk. +The file containing the solution must be named +<cell>.kgr.
--save-globalSave the global routing solution, into a file +named <design>.kgr.
-e <ratio>|--edge=<ratio>Change the edge capacity for the global +router, between 0 and 1 (Knik).
-G|--global-routeRun the global router (Knik).
-R|--detailed-routeRun the detailed router (Kite).
-s|--save-design=<routed>The design into which the routed layout will +be saved. It is strongly recommanded to choose +a different name from the source (unrouted) +design.
--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 +millions of iteration which should suffice to +any design of 100K. gates. For bigger +designs you may wants to increase this limit.
--stratus-script=<module>Run the Python/Stratus script module. +See Python Scripts in Cgt.
+

Some Examples :

+
    +

  • Run both global and detailed router, then save the routed design :

    +
    +> cgt -v -t -G -R --cell=design --save-design=design_kite
+
    +
    • +

  • Load a previous global solution, run the detailed router, then save the +routed design :

    +
    +> cgt -v -t --load-global -R --cell=design --save-design=design_kite
+
    +
    • +

  • Run the global router, then save the global routing solution :

    +
    +> cgt -v -t -G --save-global --cell=design
+
    +
    • +
+
+
+

Miscellaneous Settings

+ +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Parameter IdentifierTypeDefault
Verbosity/Log Parameters
misc.infoTypeBoolFalse
Enable display of info level message +(cinfo stream)
misc.bugTypeBoolFalse
Enable display of bug level message +(cbug stream), messages can be a little +scarry
misc.logModeTypeBoolFalse
If enabled, assume that the output device +is not a tty and suppress any escaped +sequences
misc.verboseLevel1TypeBoolTrue
First level of verbosity, disable level 2
misc.verboseLevel2TypeBoolFalse
Second level of verbosity
Development/Debug Parameters
misc.traceLevelTypeInt0
Display trace information below that level +(ltrace stream)
misc.catchCoreTypeBoolFalse
By default, cgt do not dump core. +To generate one set this flag to True
+

+
+
+
+

The Controller

+

The Controller window is composed of seven tabs:

+
    +
  1. The Look Tab to select the display style.
    2. +
  2. The Filter Tab the hierarchical levels to be displayed, the look of +rubbers and the dimension units.
    3. +
  3. The Layers&Go Tab to selectively hide/display layers.
    4. +
  4. The Netlist Tab to browse through the netlist. Works in association +with the Selection tab.
    5. +
  5. The Selection Tab allow to view all the currently selected elements.
    6. +
  6. The Inspector Tab browse through either the DataBase, the Cell or +the current selection.
    7. +
  7. The Settings Tab access all the tool's configuration settings.
    8. +
+
+

The Look Tab

+

You can select how the layout will be displayed. There is a special one +Printer.Coriolis specifically designed for Printing & Snapshots. +You should select it prior to calling the print or snapshot dialog boxes.

+

Controller Basic Snapshot

+
+
+

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 +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 +cells) is disabled by default when you load a hierarchical design and enabled +when you load a single Cell.

+

You can choose what kind of form to give to the rubbers and the type of +unit used to display coordinates.

+
+

Note

+

What are Rubbers: Hurricane uses Rubbers to materialize +physical gaps in net topology. That is, if some wires are missing to +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...

+
+

Controller Basic Snapshot

+
+
+

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 +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 +information. One good exemple is the density map of the detailed router, +to easily locate congested areas.
    • +
+

For each layer/Go there are two check boxes:

+
    +
  • The normal one triggers the display.
    • +
  • The red-outlined allows objects of that layer to be selectable or not.
    • +
+

Controller Basic Snapshot

+
+
+

The Netlist Tab

+

The Netlist tab shows the list of nets... By default the tab is not +synched with the displayed Cell. To see the nets you must check the +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 +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.

+

Controller Basic Snapshot
+
Controller Basic Snapshot

+
+
+

The Selection Tab

+

The Selection tab list all the components currently selecteds. They +can be filtered thanks to the filter pattern.

+

Used in conjunction with the Netlist Sync Selection you will all see +all the components part of net.

+

In this list, you can toggle individually the selection of component by +pressing the t key. When unselected in this way a component is not +removed from the the selection list but instead displayed in red italic. +To see where a component is you may make it blink by repeatedly press +the t key...

+

Controller Basic Snapshot

+
+
+

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:

+
    +
  • DataBase: Starts from the whole Hurricane DataBase.
    • +
  • Cell: Inspect the currently loaded Cell.
    • +
  • Selection: Inspect the object currently highlited in the Selection tab.
    • +
+

Once an entry point has been activated, you may recursively expore all +it's 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 +is deleted, you will crash the application...

+
+
+

Note

+

Implementation Detail: the inspector support is done with +Slot, Record and getString().

+
+

Controller Basic Snapshot
+
Controller Basic Snapshot
 +
Controller Basic Snapshot

+
+
+

The Settings Tab

+

Here comes the description of the Settings tab.

+

Controller Basic Snapshot

+
+
+
+

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

+

Summary of the C++ Documentation

+

A script could be run directly in text mode from the command line or through +the graphical interface (see Python Scripts in Cgt).

+

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

+
+from Hurricane import *
+from Stratus   import *
+
+def doSomething ():
+    # ...
+    return
+
+def ScriptMain ( **kw ):
+  editor = None
+  if kw.has_key('editor') and kw['editor']:
+    editor = kw['editor']
+    stratus.setEditor( editor )
+
+  doSomething()
+  return
+
+if __name__ == "__main__" :
+  kw           = {}
+  success      = ScriptMain( **kw )
+  shellSuccess = 0
+  if not success: shellSuccess = 1
+
+  sys.exit( shellSuccess )
+      ScriptMain ()
+
+

This typical script can be executed in two ways:

+
    +

  1. Run directly as a Python script, thanks to the

    +
    +if __name__ == "__main__" :
+
    +

    part (this is standart Python). It is a simple adapter that will +calls ScriptMain().

    +
    2. +

  2. Through cgt, either in text or graphical mode. In that case, the +ScriptMain() is directly called trough a sub-interpreter. +The arguments of the script are passed through the **kw dictionnary.

    + ++++ + + + + + + + + + + + + + + + +
    **kw Dictionnary
    Parameter Key/NameContents type
    '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 +currently loaded in the viewer, if any.
    'editor'The viewer from which the script is run, when +lauched through cgt.
    +
    3. +
+
+
+

Plugins

+

Plugins are Python scripts specially crafted to integrate with cgt. +Their entry point is a ScriptMain() method as described in +Python Interface to Coriolis. They can be called by user scripts +through this method.

+
+

Chip Placement

+

Automatically perform 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 +exactly one instance of the chip's core model.

+

Chip Top Structure

+

The designer must provide a configuration file that define 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 +is called amd2901_crl.vst, then the configuration file must be named +amd2901_crl_chip.vst.

+

Example of chip placement configuration file (for AM2901):

+
+chip = \
+  { 'pads.south'     : [ 'p_a3'     , 'p_a2'     , 'p_a1'     , 'p_r0'
+                       , 'p_vddick0', 'p_vssick0', 'p_a0'     , 'p_i6'
+                       , 'p_i8'     , 'p_i7'     , 'p_r3'     ]
+  , 'pads.east'      : [ 'p_zero'   , 'p_i0'     , 'p_i1'     , 'p_i2'
+                       , 'p_vddeck0', 'p_vsseck0', 'p_q3'     , 'p_b0'
+                       , 'p_b1'     , 'p_b2'     , 'p_b3'     ]
+  , 'pads.north'     : [ 'p_noe'    , 'p_y3'     , 'p_y2'     , 'p_y1'
+                       , 'p_y0'     , 'p_vddeck1', 'p_vsseck1', 'p_np'
+                       , 'p_ovr'    , 'p_cout'   , 'p_ng'     ]
+  , 'pads.west'      : [ 'p_cin'    , 'p_i4'     , 'p_i5'     , 'p_i3'
+                       , 'p_ck'     , 'p_d0'     , 'p_d1'     , 'p_d2'
+                       , 'p_d3'     , 'p_q0'     , 'p_f3'     ]
+  , 'core.size'      : ( 1500, 1500 )
+  , 'chip.size'      : ( 3000, 3000 )
+  , 'chip.clockTree' : True
+  }
+
+

The file must contain one dictionnary named chip.

+ ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Chip Dictionnary
Parameter Key/NameValue/Contents type
'pad.south'Ordered list (left to right) of pad instances names +to put on the south side of the chip
'pad.east'Ordered list (down to up) of pad instances names +to put on the east side of the chip
'pad.north'Ordered list (left to right) of pad instances names +to put on the north side of the chip
'pad.west'Ordered list (down to up) of pad instances 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 +enough to accomodate all the pads
'chip.clockTree'Whether to generate a clock tree or not. This calls +the ClockTree plugin
+

Configuration parameters, defaults are defined in etc/coriolis2/<STECHNO>/plugins.conf.

+ +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Parameter IdentifierTypeDefault
Chip Plugin Parameters
chip.block.rails.countTypeInt5
The minimum number of rails around the core +block. Must be odd and suppérior to 5. +One rail for the clock and at least two pairs +of power/grounds
chip.block.rails.hWidthTypeInt12
The horizontal with of the rails
chip.block.rails.vWidthTypeInt12
The vertical with of the rails
chip.block.rails.hSpacingTypeInt6
The spacing, edge to edge of two adjacent +horizontal rails
chip.block.rails.vSpacingTypeInt6
The spacing, edge to edge of two adjacent +vertical rails
chip.pad.pckTypeStringpck_px
The model name of the pad connected to the +chip external clock
chip.pad.pvddeckTypeStringpvddeck_px
The model name of the pad connected to the +vdde (external power) and suppling it to +the core
chip.pad.pvsseckTypeStringpvsseck_px
The model name of the pad connected to the +vsse (external ground) and suppling it to +the core
chip.pad.pvddickTypeStringpvddick_px
The model name of the pad connected to the +vddi (internal power) and suppling it to +the core
chip.pad.pvssickTypeStringpvssick_px
The model name of the pad connected to the +vssi (internal ground) and suppling it to +the core
+
+

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.

+
+
+
+

Clock Tree

+

Insert 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 +core block (then trans-hierarchically flattened to be shown at +chip level).

    +
    • +

  • On blocks, the sub nets are created directly in the top block.

    +
    • +

  • The sub-nets are named according to a simple geometrical scheme. +A common prefix ck_htree, then one postfix by level telling +on which quarter of plane the sub-clock is located:

    +
      +
    1. _bl: bottom left plane quarter.
      2. +
    2. _br: bottom right plane quarter.
      3. +
    3. _tl: top left plane quarter.
      4. +
    4. _tr: top right plane quarter.
      5. +
    +

    We can have ck_htree_bl, ck_htree_bl_bl, ch_htree_bl_tl and so on.

    +
    • +
+

The clock tree plugin works in four steps:

+
    +
  1. Build the clock tree: creates the top-block abutment box, compute the +levels of H tree neededs and place the clock buffers.
    2. +
  2. Once the clock buffers are placed, calls the placer (Etesian) to place +the ordinary standart cells, whithout disturbing clock H-tree buffers.
    3. +
  3. 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.
    4. +
  4. Leaf clock signals that are not connecteds to any DFFs are removed.
    5. +
+

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.
    • +
  • 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 +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.
    • +
+
+

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 +memory cache.

+
+

Configuration parameters, defaults are defined in etc/coriolis2/<STECHNO>/plugins.conf.

+ +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Parameter IdentifierTypeDefault
ClockTree Plugin Parameters
clockTree.minimumSideTypeInt300
The minimum size below which the clock tree +will stop to perform quadri-partitions
clockTree.bufferTypeStringbuf_x2
The buffer model to use to drive sub-nets
clockTree.placerEngineTypeStringEtesian
The placer to use. Other value is Mauka +the simulated annealing placer which will go +into retirement very soon
+
+
+

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 +by the clock tree plugin after the netlist clock sub-nets creation.

+
+
+
+

A Simple Example: AM2901

+

To illustrate the capabilities of Coriolis tools and Python scripting, a small +example, derived from the Alliance AM2901 is supplied.

+

This example contains only the synthetized netlists and the doChip.py script +which perform the whole P&R of the design.

+

You can generate the chip using one of the following method:

+
    +

  1. Command line mode: directly run the script:

    +
    +dummy@lepka:AM2901$ ./doChip -V --cell=amd2901
+
    +
    2. +

  2. Graphic mode: launch cgt, load chip netlist amd2901 (the top cell) +then run the Python script doChip.py.

    +
    3. +
+
+

Note

+

Between two consecutive run, be sure to erase the netlist/layout generateds:

+
+dummy@lepka:AM2901$ rm *_clocked*.vst *.ap
+
+
+
+
+
+ + diff --git a/documentation/UsersGuide/UsersGuide.pdf b/documentation/UsersGuide/UsersGuide.pdf new file mode 100644 index 00000000..ee6f7d6a Binary files /dev/null and b/documentation/UsersGuide/UsersGuide.pdf differ diff --git a/documentation/UsersGuide/UsersGuide.rst b/documentation/UsersGuide/UsersGuide.rst index 93e1bb1d..74e0adfa 100644 --- a/documentation/UsersGuide/UsersGuide.rst +++ b/documentation/UsersGuide/UsersGuide.rst @@ -478,8 +478,7 @@ In the |Coriolis| |git| repository, two branches are present: command just after the first step: :: dummy@lepka:~$ git checkout devel - dummy@lepka:src$ ./bootstrap/ccp.py --project=importeds \ - --project=coriolis \ + dummy@lepka:src$ ./bootstrap/ccp.py --project=coriolis \ --make="-j4 install" --debug Be aware that it may requires newer versions of the dependencies and may introduce diff --git a/unicorn/src/coriolis.py b/unicorn/src/coriolis.py index af97f7ba..2abc07ca 100755 --- a/unicorn/src/coriolis.py +++ b/unicorn/src/coriolis.py @@ -82,7 +82,7 @@ osType = uname( ['-s'] ) arch = uname( ['-m'] ) libDir = '/lib' -if arch == 'x86_64': libDir = '/lib64' +if arch == 'x86_64' and os.path.exists('/usr/lib64'): libDir = '/lib64' pythonSitePackages = os.path.join( *(distutils.sysconfig.get_python_lib(1).split('/')[-3:]) )