2012-11-16 06:49:47 -06:00
|
|
|
|
|
|
|
|
.. -*- Mode: rst -*-
|
|
|
|
|
|
|
|
|
|
.. role:: ul
|
|
|
|
|
.. role:: cb
|
|
|
|
|
.. role:: sc
|
2014-03-10 08:06:31 -05:00
|
|
|
.. role:: fboxtt
|
2012-11-16 06:49:47 -06:00
|
|
|
|
|
|
|
|
.. Acronyms & names.
|
|
|
|
|
.. |GNU| replace:: :sc:`gnu`
|
|
|
|
|
.. |LGPL| replace:: :sc:`lgpl`
|
|
|
|
|
.. |GPL| replace:: :sc:`gpl`
|
|
|
|
|
.. |UPMC| replace:: :sc:`upmc`
|
|
|
|
|
.. |Bull| replace:: :sc:`Bull`
|
|
|
|
|
.. |Cadence| replace:: :sc:`Cadence`
|
|
|
|
|
.. |Si2| replace:: :sc:`Si2`
|
|
|
|
|
.. |LEFDEF| replace:: :sc:`lefdef`
|
|
|
|
|
.. |Flute| replace:: :sc:`Flute`
|
2014-05-13 10:15:29 -05:00
|
|
|
.. |MacOS| replace:: :sc:`MacOS`
|
2014-12-12 05:05:25 -06:00
|
|
|
.. |RHEL6| replace:: :sc:`rhel6`
|
2015-02-27 11:16:03 -06:00
|
|
|
.. |RHEL7| replace:: :sc:`rhel7`
|
2014-12-12 05:05:25 -06:00
|
|
|
.. |SL6| replace:: :sc:`Scientific Linux 6`
|
2015-02-27 11:16:03 -06:00
|
|
|
.. |SL7| replace:: :sc:`Scientific Linux 7`
|
|
|
|
|
.. |Scientific Linux| replace:: :sc:`Scientific Linux`
|
|
|
|
|
.. |RedHat| replace:: :sc:`RedHat`
|
|
|
|
|
.. |Fedora| replace:: :sc:`Fedora`
|
|
|
|
|
.. |FC13| replace:: :sc:`fc13`
|
|
|
|
|
.. |Debian| replace:: :sc:`Debian`
|
|
|
|
|
.. |Ubuntu| replace:: :sc:`Ubuntu`
|
2015-03-06 01:58:10 -06:00
|
|
|
.. |LEMON| replace:: :sc:`lemon`
|
|
|
|
|
.. |Coin-Or| replace:: :sc:`coin-or`
|
2012-11-16 06:49:47 -06:00
|
|
|
|
|
|
|
|
.. |Alexandre| replace:: :sc:`Alexandre`
|
|
|
|
|
.. |Belloeil| replace:: :sc:`Belloeil`
|
|
|
|
|
.. |Chaput| replace:: :sc:`Chaput`
|
|
|
|
|
.. |Chu| replace:: :sc:`Chu`
|
2015-02-27 11:16:03 -06:00
|
|
|
.. |Clement| replace:: :sc:`Clement`
|
2012-11-16 06:49:47 -06:00
|
|
|
.. |Dupuis| replace:: :sc:`Dupuis`
|
|
|
|
|
.. |Escassut| replace:: :sc:`Escassut`
|
2015-02-27 11:16:03 -06:00
|
|
|
.. |Gouvine| replace:: :sc:`Gouvine`
|
2012-11-16 06:49:47 -06:00
|
|
|
.. |Masson| replace:: :sc:`Masson`
|
2015-02-27 11:16:03 -06:00
|
|
|
.. |Sroka| replace:: :sc:`Sroka`
|
|
|
|
|
.. |Yifei| replace:: :sc:`Yifei`
|
2012-11-16 06:49:47 -06:00
|
|
|
|
|
|
|
|
.. |ANSI| replace:: :sc:`ansi`
|
|
|
|
|
.. |MIPS| replace:: :sc:`mips`
|
|
|
|
|
.. |Am2901| replace:: :sc:`Am2901`
|
|
|
|
|
.. |Hurricane| replace:: :sc:`Hurricane`
|
|
|
|
|
.. |HurricaneAMS| replace:: :sc:`HurricaneAMS`
|
|
|
|
|
.. |Alliance| replace:: :sc:`Alliance`
|
2015-04-05 04:35:06 -05:00
|
|
|
.. |Yosys| replace:: :sc:`Yosys`
|
2012-11-16 06:49:47 -06:00
|
|
|
.. |GenLib| replace:: :sc:`GenLib`
|
|
|
|
|
.. |Nero| replace:: :sc:`Nero`
|
|
|
|
|
.. |Druc| replace:: :cb:`Druc`
|
2015-02-27 11:16:03 -06:00
|
|
|
.. |Coloquinte| replace:: :sc:`Coloquinte`
|
2012-11-16 06:49:47 -06:00
|
|
|
.. |Coriolis| replace:: :sc:`Coriolis`
|
|
|
|
|
.. |Coriolis1| replace:: :sc:`Coriolis 1`
|
|
|
|
|
.. |Coriolis2| replace:: :sc:`Coriolis 2`
|
|
|
|
|
.. |VLSISAPD| replace:: :sc:`vlsisapd`
|
|
|
|
|
.. |CRLcore| replace:: :sc:`CRLcore`
|
|
|
|
|
.. |Cyclop| replace:: :sc:`Cyclop`
|
|
|
|
|
.. |Nimbus| replace:: :sc:`Nimbus`
|
|
|
|
|
.. |hMetis| replace:: :sc:`hMetis`
|
|
|
|
|
.. |Mauka| replace:: :sc:`Mauka`
|
2015-02-27 11:16:03 -06:00
|
|
|
.. |Etesian| replace:: :sc:`Etesian`
|
2012-11-16 06:49:47 -06:00
|
|
|
.. |Knik| replace:: :sc:`Knik`
|
2014-03-10 08:06:31 -05:00
|
|
|
.. |Katabatic| replace:: :sc:`Katabatic`
|
2012-11-16 06:49:47 -06:00
|
|
|
.. |Kite| replace:: :sc:`Kite`
|
|
|
|
|
.. |Stratus| replace:: :sc:`Stratus`
|
|
|
|
|
.. |Stratus1| replace:: :sc:`Stratus1`
|
|
|
|
|
.. |Stratus2| replace:: :sc:`Stratus2`
|
|
|
|
|
.. |Unicorn| replace:: :sc:`Unicorn`
|
2014-03-10 08:06:31 -05:00
|
|
|
.. |ccb| replace:: :cb:`ccb`
|
2012-11-16 06:49:47 -06:00
|
|
|
.. |cgt| replace:: :cb:`cgt`
|
|
|
|
|
.. |Chams| replace:: :sc:`Chams`
|
|
|
|
|
.. |OpenChams| replace:: :sc:`OpenChams`
|
|
|
|
|
.. |Pharos| replace:: :cb:`Pharos`
|
|
|
|
|
.. |API| replace:: :sc:`api`
|
|
|
|
|
.. |STL| replace:: :sc:`stl`
|
|
|
|
|
.. |XML| replace:: :sc:`xml`
|
|
|
|
|
.. |pdf| replace:: :sc:`pdf`
|
|
|
|
|
.. |UTF-8| replace:: :sc:`utf-8`
|
|
|
|
|
.. |Python| replace:: :sc:`Python`
|
|
|
|
|
.. |Linux| replace:: :sc:`Linux`
|
2014-05-13 10:15:29 -05:00
|
|
|
.. |MacPorts| replace:: :sc:`MacPorts`
|
2014-12-12 05:05:25 -06:00
|
|
|
.. |devtoolset2| replace:: :cb:`devtoolset2`
|
2014-05-13 10:15:29 -05:00
|
|
|
.. |boost| replace:: :cb:`boost`
|
2012-11-16 06:49:47 -06:00
|
|
|
.. |Qt| replace:: :sc:`qt`
|
|
|
|
|
.. |tty| replace:: :cb:`tty`
|
2014-03-10 08:06:31 -05:00
|
|
|
.. |svn| replace:: :cb:`svn`
|
|
|
|
|
.. |git| replace:: :cb:`git`
|
|
|
|
|
.. |rpm| replace:: :cb:`rpm`
|
2015-02-27 11:16:03 -06:00
|
|
|
.. |gdb| replace:: :cb:`gdb`
|
|
|
|
|
|
2015-03-06 01:58:10 -06:00
|
|
|
.. |KeyUp| replace:: :fboxtt:`Up`
|
|
|
|
|
.. |KeyDown| replace:: :fboxtt:`Down`
|
|
|
|
|
.. |KeyLeft| replace:: :fboxtt:`Left`
|
|
|
|
|
.. |KeyRight| replace:: :fboxtt:`Right`
|
|
|
|
|
.. |KeyF| replace:: :fboxtt:`f`
|
|
|
|
|
.. |KeyL| replace:: :fboxtt:`l`
|
|
|
|
|
.. |KeyG| replace:: :fboxtt:`g`
|
|
|
|
|
.. |KeyZ| replace:: :fboxtt:`z`
|
|
|
|
|
.. |KeyM| replace:: :fboxtt:`m`
|
|
|
|
|
.. |KeyI| replace:: :fboxtt:`i`
|
|
|
|
|
.. |KeyK| replace:: :fboxtt:`k`
|
|
|
|
|
.. |KeyP| replace:: :fboxtt:`p`
|
|
|
|
|
.. |KeyO| replace:: :fboxtt:`o`
|
|
|
|
|
.. |KeyW| replace:: :fboxtt:`w`
|
|
|
|
|
.. |KeyQ| replace:: :fboxtt:`q`
|
|
|
|
|
.. |KeyCapK| replace:: :fboxtt:`K`
|
|
|
|
|
.. |KeyCapS| replace:: :fboxtt:`S`
|
|
|
|
|
.. |Plus| replace:: :fboxtt:`+`
|
|
|
|
|
.. |KeyESC| replace:: :fboxtt:`ESC`
|
|
|
|
|
.. |CTRL| replace:: :fboxtt:`CTRL`
|
2015-02-27 11:16:03 -06:00
|
|
|
.. |CTRL_L| replace:: :fboxtt:`CTRL+L`
|
2015-03-06 01:58:10 -06:00
|
|
|
.. |CTRL_I| replace:: :fboxtt:`CTRL+I`
|
|
|
|
|
.. |CTRL_P| replace:: :fboxtt:`CTRL+P`
|
|
|
|
|
.. |CTRL_O| replace:: :fboxtt:`CTRL+O`
|
|
|
|
|
.. |CTRL_W| replace:: :fboxtt:`CTRL+W`
|
|
|
|
|
.. |CTRL_Q| replace:: :fboxtt:`CTRL+Q`
|
|
|
|
|
.. |CTRL_Down| replace:: :fboxtt:`CTRL+Down`
|
|
|
|
|
.. |CTRL_Up| replace:: :fboxtt:`CTRL+Up`
|
|
|
|
|
.. |CTRL_Left| replace:: :fboxtt:`CTRL+Left`
|
|
|
|
|
.. |CTRL_Right| replace:: :fboxtt:`CTRL+Right`
|
2012-11-16 06:49:47 -06:00
|
|
|
|
|
|
|
|
.. URLs
|
2015-03-06 01:58:10 -06:00
|
|
|
.. _FGR: http://vlsicad.eecs.umich.edu/BK/FGR/
|
|
|
|
|
.. _Box Router: http://www.cerc.utexas.edu/~thyeros/boxrouter/boxrouter.htm
|
|
|
|
|
.. _hMETIS: http://glaros.dtc.umn.edu/gkhome/views/metis
|
|
|
|
|
.. _Knik Thesis: http://www-soc.lip6.fr/en/users/damiendupuis/PhD/
|
|
|
|
|
.. _Coin Or Home: http://www.coin-or.org/index.html
|
2012-11-16 06:49:47 -06:00
|
|
|
|
2012-12-03 06:31:41 -06:00
|
|
|
.. _coriolis2-1.0.2049-1.slsoc6.i686.rpm: http://asim.lip6.fr/pub/coriolis/2.0/coriolis2-1.0.2049-1.slsoc6.i686.rpm
|
|
|
|
|
.. _coriolis2-1.0.2049-1.slsoc6.x86_64.rpm: http://asim.lip6.fr/pub/coriolis/2.0/coriolis2-1.0.2049-1.slsoc6.x86_64.rpm
|
|
|
|
|
.. _coriolis2-1.0.2049-1.fc16.i686.rpm: http://asim.lip6.fr/pub/coriolis/2.0/coriolis2-1.0.2049-1.fc16.i686.rpm
|
|
|
|
|
.. _coriolis2-1.0.2049-1.fc16.x86_64.rpm: http://asim.lip6.fr/pub/coriolis/2.0/coriolis2-1.0.2049-1.fc16.x86_64.rpm
|
|
|
|
|
.. _coriolis2_1.0-2049-1_.i386.rpm (10.04): http://asim.lip6.fr/pub/coriolis/2.0/Ubuntu/10.04/coriolis2_1.0-2049-1_i386.rpm
|
|
|
|
|
.. _coriolis2_1.0-2049-1_.amd64.rpm (10.04): http://asim.lip6.fr/pub/coriolis/2.0/Ubuntu/10.04/coriolis2_1.0-2049-1_i386.rpm
|
|
|
|
|
.. _coriolis2_1.0-2049-1_.i386.rpm (12.04): http://asim.lip6.fr/pub/coriolis/2.0/Ubuntu/12.04/coriolis2_1.0-2049-1_i386.rpm
|
|
|
|
|
.. _coriolis2_1.0-2049-1_.amd64.rpm (12.04): http://asim.lip6.fr/pub/coriolis/2.0/Ubuntu/12.04/coriolis2_1.0-2049-1_i386.rpm
|
2012-11-16 06:49:47 -06:00
|
|
|
|
|
|
|
|
.. Standard CAO/VLSI Concepts.
|
|
|
|
|
.. |netlist| replace:: *netlist*
|
|
|
|
|
.. |netlists| replace:: *netlists*
|
|
|
|
|
.. |layout| replace:: *layout*
|
|
|
|
|
.. |layouts| replace:: *layouts*
|
|
|
|
|
.. |CMOS| replace:: :sc:`cmos`
|
|
|
|
|
.. |VHDL| replace:: :sc:`vhdl`
|
|
|
|
|
.. |NWELL| replace:: :sc:`nwell`
|
|
|
|
|
.. |POWER| replace:: :sc:`power`
|
|
|
|
|
.. |GROUND| replace:: :sc:`ground`
|
|
|
|
|
|
|
|
|
|
.. MBK Concepts
|
|
|
|
|
.. |MBK| replace:: :sc:`mbk`
|
|
|
|
|
.. |LOFIG| replace:: :cb:`Lofig`
|
|
|
|
|
.. |PHFIG| replace:: :cb:`Phfig`
|
|
|
|
|
.. |SxLib| replace:: :sc:`SxLib`
|
|
|
|
|
|
|
|
|
|
.. Hurricane Concepts.
|
|
|
|
|
.. |hypernet| replace:: *hypernet*
|
|
|
|
|
.. |hypernets| replace:: *hypernets*
|
|
|
|
|
.. |Cell| replace:: *Cell*
|
|
|
|
|
.. |Rings| replace:: *Rings*
|
|
|
|
|
.. |QuadTrees| replace:: *QuadTrees*
|
|
|
|
|
.. |Collections| replace:: *Collections*
|
|
|
|
|
.. |ap| replace:: :cb:`ap`
|
|
|
|
|
.. |vst| replace:: :cb:`vst`
|
|
|
|
|
.. |kgr| replace:: :cb:`kgr`
|
|
|
|
|
.. |dot_conf| replace:: :cb:`.conf`
|
|
|
|
|
|
|
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
|medskip|
|
|
|
|
|
|
2012-11-16 06:49:47 -06:00
|
|
|
=====================
|
|
|
|
|
Coriolis User's Guide
|
|
|
|
|
=====================
|
|
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
|medskip|
|
|
|
|
|
|
|
|
|
|
.. raw:: html
|
|
|
|
|
|
|
|
|
|
<div id="centered">
|
|
|
|
|
The pdf version of this document is available here:<br>
|
|
|
|
|
<a href="https://www-soc.lip6.fr/sesi-docs/coriolis2-docs/coriolis2/en/latex/users-guide/UsersGuide.pdf">Coriolis User's Guide</a>
|
|
|
|
|
</div>
|
2012-11-16 06:49:47 -06:00
|
|
|
|
|
|
|
|
.. contents::
|
|
|
|
|
|
|
|
|
|
|newpage|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Credits & License
|
|
|
|
|
=================
|
|
|
|
|
|
|
|
|
|
.. raw:: html
|
|
|
|
|
|
|
|
|
|
<p class="credit"><span class="left"><span class="sc">Hurricane</span></span>
|
|
|
|
|
<span class="right">Rémy <span class="sc">Escassut</span> &
|
|
|
|
|
Christian <span class="sc">Masson</span></span></p>
|
|
|
|
|
<br>
|
2015-02-27 11:16:03 -06:00
|
|
|
<p class="credit"><span class="left"><span class="sc">Etesian</span></span>
|
|
|
|
|
<span class="right">Gabriel <span class="sc">Gouvine</span></span></p>
|
2012-11-16 06:49:47 -06:00
|
|
|
<br>
|
|
|
|
|
<p class="credit"><span class="left"><span class="sc">Stratus</span></span>
|
|
|
|
|
<span class="right">Sophie <span class="sc">Belloeil</span></span></p>
|
|
|
|
|
<br>
|
|
|
|
|
<p class="credit"><span class="left"><span class="sc">Knik</span></span>
|
|
|
|
|
<span class="right">Damien <span class="sc">Dupuis</span></span></p>
|
|
|
|
|
<br>
|
|
|
|
|
<p class="credit"><span class="left"><span class="sc">Kite</span>,
|
|
|
|
|
<span class="sc">Unicorn</span></span></span>
|
|
|
|
|
<span class="right">Jean-Paul <span class="sc">Chaput</span></span></p>
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.. raw:: latex
|
|
|
|
|
|
|
|
|
|
\begin{center}\begin{minipage}[t]{.8\textwidth}
|
|
|
|
|
\noindent\DUrole{sc}{Hurricane} \dotfill Rémy \DUrole{sc}{Escassut} \&
|
2015-04-05 16:43:01 -05:00
|
|
|
Christian \DUrole{sc}{Masson} \\
|
2015-02-27 11:16:03 -06:00
|
|
|
\noindent\DUrole{sc}{Etesian} \dotfill Gabriel \DUrole{sc}{Gouvine} \\
|
2012-11-16 06:49:47 -06:00
|
|
|
\noindent\DUrole{sc}{Stratus} \dotfill Sophie \DUrole{sc}{Belloeil} \\
|
|
|
|
|
\noindent\DUrole{sc}{Knik} \dotfill Damien \DUrole{sc}{Dupuis} \\
|
|
|
|
|
\noindent\DUrole{sc}{Kite},
|
|
|
|
|
\DUrole{sc}{Unicorn} \dotfill Jean-Paul \DUrole{sc}{Chaput} \\
|
|
|
|
|
\end{minipage}\end{center}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|medskip|
|
|
|
|
|
|
2015-02-27 11:16:03 -06:00
|
|
|
The |Hurricane| data-base is copyright© |Bull| 2000-2015 and is
|
2012-11-16 06:49:47 -06:00
|
|
|
released under the terms of the |LGPL| license. All other tools are
|
2015-02-27 11:16:03 -06:00
|
|
|
copyright© |UPMC| 2008-2015 and released under the |GPL|
|
2012-11-16 06:49:47 -06:00
|
|
|
license.
|
|
|
|
|
|
2015-02-27 11:16:03 -06:00
|
|
|
Others important contributors to |Coriolis| are Christophe |Alexandre|,
|
|
|
|
|
Hugo |Clement|, Marek |Sroka| and Wu |Yifei|.
|
|
|
|
|
|
2012-11-16 06:49:47 -06:00
|
|
|
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/).
|
|
|
|
|
|
|
|
|
|
|newpage|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Release Notes
|
|
|
|
|
=============
|
|
|
|
|
|
|
|
|
|
Release 1.0.1475
|
|
|
|
|
~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
This is the first preliminary release of the |Coriolis2| 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.
|
|
|
|
|
|medskip|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|noindent| Contents of this release:
|
|
|
|
|
|
|
|
|
|
1. A graphical user interface (viewer only).
|
|
|
|
|
2. The |Knik| global router.
|
|
|
|
|
3. The |Kite| detailed router.
|
|
|
|
|
|
|
|
|
|
|noindent| 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 |Coriolis1| have been ported into
|
|
|
|
|
this release.
|
|
|
|
|
|
|
|
|
|
|noindent| Contents of this release:
|
|
|
|
|
|
|
|
|
|
#. The |Stratus| netlist capture language (|GenLib| replacement).
|
|
|
|
|
#. The |Mauka| placer (still contains bugs).
|
|
|
|
|
#. A graphical user interface (viewer only).
|
|
|
|
|
#. The |Knik| global router.
|
|
|
|
|
#. The |Kite| detailed router.
|
|
|
|
|
#. Partially implemented python support for configuration files
|
|
|
|
|
(alternative to |XML|).
|
|
|
|
|
#. A documentation (imcomplete/obsoleted in |Hurricane|'s case).
|
|
|
|
|
|
|
|
|
|
|
2012-12-03 06:31:41 -06:00
|
|
|
Release 1.0.2049
|
2012-11-16 06:49:47 -06:00
|
|
|
~~~~~~~~~~~~~~~~
|
|
|
|
|
|
2012-12-03 06:31:41 -06:00
|
|
|
Release `2049` is Alpha.
|
2012-11-16 06:49:47 -06:00
|
|
|
|
|
|
|
|
|noindent| Changes of this release:
|
|
|
|
|
|
|
|
|
|
#. The |Hurricane| documentation is now accurate. Documentation
|
|
|
|
|
for the Cell viewer and |CRLcore| has been added.
|
|
|
|
|
#. 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.
|
|
|
|
|
#. The |cgt| main has been rewritten in Python.
|
|
|
|
|
|
|
|
|
|
|
2015-03-06 01:58:10 -06:00
|
|
|
Release v2.0.1
|
|
|
|
|
~~~~~~~~~~~~~~
|
2014-03-10 08:06:31 -05:00
|
|
|
|
|
|
|
|
#. 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.
|
|
|
|
|
#. Deep rewrite of the |Katabatic| database and |Kite| detailed router,
|
|
|
|
|
achieve a speedup factor greater than 20...
|
|
|
|
|
|
|
|
|
|
|
2015-03-06 01:58:10 -06:00
|
|
|
**Release v2.1**
|
2015-02-27 11:16:03 -06:00
|
|
|
~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
#. Replace the old simulated annealing placer |Mauka| by an analytic placer
|
|
|
|
|
|Etesian|.
|
|
|
|
|
#. 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``.
|
2015-04-05 16:43:01 -05:00
|
|
|
|
|
|
|
|
.. #. Under |RHEL7| / |SL7|, there is a known bug in the graphical visualizer.
|
|
|
|
|
.. When shifting to the left, the right-half part of the screen gets
|
|
|
|
|
.. badly redrawn. Uses |CTRL_L| to refresh. It will be corrected as soon
|
|
|
|
|
.. as possible.
|
2015-02-27 11:16:03 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-16 06:49:47 -06:00
|
|
|
|newpage|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Installation
|
|
|
|
|
============
|
|
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
.. 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
|
|
|
|
|
* g++
|
|
|
|
|
* boost
|
|
|
|
|
* libxml2
|
|
|
|
|
* yacc & lex.
|
2015-02-27 11:16:03 -06:00
|
|
|
* Qt 4 or Qt 5.
|
2014-03-10 08:06:31 -05:00
|
|
|
* LEF/DEF (optional).
|
|
|
|
|
* doxygen.
|
|
|
|
|
* latex
|
|
|
|
|
* latex2html.
|
|
|
|
|
* python-docutils (for reStructuredText).
|
2015-03-06 01:58:10 -06:00
|
|
|
|
2015-04-08 10:45:45 -05:00
|
|
|
The |Coloquinte| component requires the |LEMON| component from |Coin-Or| (`Coin Or Home`_).
|
2015-03-06 01:58:10 -06:00
|
|
|
A repository of |Coin-Or| packages backported from |Fedora| 21 is available here:
|
|
|
|
|
|
|
|
|
|
* |SL6|: `ftp://pub/linux/distributions/slsoc/slsoc/soc/addons/i386/RPMS <http://ftp.lip6.fr/pub/linux/distributions/slsoc/slsoc/soc/addons/i386/repoview>`_
|
|
|
|
|
* |SL7|: `ftp://pub/linux/distributions/slsoc/soc/7/addons/x86_64/RPMS <http://ftp.lip6.fr/pub/linux/distributions/slsoc/soc/7/addons/x86_64/repoview>`_
|
|
|
|
|
|
|
|
|
|
For other distributions, refer to their own packaging system.
|
|
|
|
|
|
|
|
|
|
|newpage|
|
2014-03-10 08:06:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
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 :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.
|
|
|
|
|
|
|
|
|
|
+--------------------------+-----------------------------------------------------------------------------+
|
|
|
|
|
| **Sources** |
|
|
|
|
|
+--------------------------+-----------------------------------------------------------------------------+
|
|
|
|
|
| | Sources root | | ~/coriolis-2.x/src |
|
|
|
|
|
| | **under git** | | ~/coriolis-2.x/src/coriolis |
|
|
|
|
|
+--------------------------+-----------------------------------------------------------------------------+
|
|
|
|
|
| **Architecture Dependant Build** |
|
|
|
|
|
+--------------------------+-----------------------------------------------------------------------------+
|
2015-02-27 11:16:03 -06:00
|
|
|
| | Linux, SL 7, 64 bits | | ~/coriolis-2.x/Linux.el7_64/Release.Shared/build/<tool> |
|
2014-03-10 08:06:31 -05:00
|
|
|
| | Linux, SL 6, 32 bits | | ~/coriolis-2.x/Linux.slsoc6x/Release.Shared/build/<tool> |
|
|
|
|
|
| | Linux, SL 6, 64 bits | | ~/coriolis-2.x/Linux.slsoc6x_64/Release.Shared/build/<tool> |
|
2015-02-27 11:16:03 -06:00
|
|
|
| | Linux, Fedora, 64 bits | | ~/coriolis-2.x/Linux.fc_64/Release.Shared/build/<tool> |
|
|
|
|
|
| | Linux, Fedora, 32 bits | | ~/coriolis-2.x/Linux.fc/Release.Shared/build/<tool> |
|
2014-03-10 08:06:31 -05:00
|
|
|
| | FreeBSD 8, 32 bits | | ~/coriolis-2.x/FreeBSD.8x.i386/Release.Shared/build/<tool> |
|
|
|
|
|
| | FreeBSD 8, 64 bits | | ~/coriolis-2.x/FreeBSD.8x.amd64/Release.Shared/build/<tool> |
|
2014-07-13 06:14:49 -05:00
|
|
|
| | Windows 7, 32 bits | | ~/coriolis-2.x/Cygwin.W7/Release.Shared/build/<tool> |
|
|
|
|
|
| | Windows 7, 64 bits | | ~/coriolis-2.x/Cygwin.W7_64/Release.Shared/build/<tool> |
|
|
|
|
|
| | Windows 8.x, 32 bits | | ~/coriolis-2.x/Cygwin.W8/Release.Shared/build/<tool> |
|
|
|
|
|
| | Windows 8.x, 64 bits | | ~/coriolis-2.x/Cygwin.W8_64/Release.Shared/build/<tool> |
|
2014-03-10 08:06:31 -05:00
|
|
|
+--------------------------+-----------------------------------------------------------------------------+
|
|
|
|
|
| **Architecture Dependant Install** |
|
|
|
|
|
+--------------------------+-----------------------------------------------------------------------------+
|
|
|
|
|
| Linux, SL 6, 32 bits | ~/coriolis-2.x/Linux.slsoc6x/Release.Shared/install/ |
|
|
|
|
|
+--------------------------+-----------------------------------------------------------------------------+
|
|
|
|
|
| **FHS Compliant Structure under Install** |
|
|
|
|
|
+--------------------------+-----------------------------------------------------------------------------+
|
|
|
|
|
| | Binaries | | .../install/bin |
|
|
|
|
|
| | Libraries (Python) | | .../install/lib |
|
|
|
|
|
| | Include by tool | | .../install/include/coriolis2/<project>/<tool> |
|
|
|
|
|
| | Configuration files | | .../install/etc/coriolis2/ |
|
|
|
|
|
| | Doc, by tool | | .../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).
|
|
|
|
|
|
2015-03-06 01:58:10 -06:00
|
|
|
|newpage|
|
|
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
|
|
|
|
|
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: ::
|
|
|
|
|
|
2015-04-08 10:45:45 -05:00
|
|
|
dummy@lepka:src$ ./bootstrap/ccp.py --project=coriolis \
|
2015-02-27 11:16:03 -06:00
|
|
|
--make="-j4 install"
|
2015-03-06 01:58:10 -06:00
|
|
|
dummy@lepka:src$ ./bootstrap/ccb.py --project=coriolis \
|
|
|
|
|
--doc --make="-j1 install"
|
2014-03-10 08:06:31 -05:00
|
|
|
|
|
|
|
|
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``
|
|
|
|
|
|
2015-02-27 11:16:03 -06:00
|
|
|
Under |RHEL6| or clones, you must build using the |devtoolset2|: ::
|
|
|
|
|
|
2015-04-08 10:45:45 -05:00
|
|
|
dummy@lepka:src$ ./bootstrap/ccp.py --project=coriolis \
|
2015-02-27 11:16:03 -06:00
|
|
|
--devtoolset-2 --make="-j4 install"
|
|
|
|
|
|
|
|
|
|
If you want to uses Qt 5 instead of Qt 4, you may add the ``--qt5`` argument.
|
|
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
The complete list of |ccb| functionalities can be accessed with the ``--help`` argument.
|
|
|
|
|
It also may be run in graphical mode (``--gui``).
|
|
|
|
|
|
|
|
|
|
|
2014-07-13 06:14:49 -05:00
|
|
|
Building the Devel Branch
|
|
|
|
|
-------------------------
|
|
|
|
|
|
|
|
|
|
In the |Coriolis| |git| repository, two branches are present:
|
|
|
|
|
|
|
|
|
|
* The :cb:`master` branch, which contains the latest stable version. This is the
|
|
|
|
|
one used by default if you follow the above instructions.
|
|
|
|
|
|
|
|
|
|
* The :cb:`devel` branch, which obviously contains the latest commits from the
|
|
|
|
|
development team. To use it instead of the :cb:`master` one, do the following
|
|
|
|
|
command just after the first step: ::
|
|
|
|
|
|
|
|
|
|
dummy@lepka:~$ git checkout devel
|
2015-03-06 01:58:10 -06:00
|
|
|
dummy@lepka:src$ ./bootstrap/ccp.py --project=importeds \
|
|
|
|
|
--project=coriolis \
|
2015-02-27 11:16:03 -06:00
|
|
|
--make="-j4 install" --debug
|
2014-07-13 06:14:49 -05:00
|
|
|
|
2014-12-12 05:05:25 -06:00
|
|
|
Be aware that it may requires newer versions of the dependencies and may introduce
|
2014-07-13 06:14:49 -05:00
|
|
|
incompatibilites with the stable version.
|
|
|
|
|
|
2015-02-27 11:16:03 -06:00
|
|
|
In the (unlikely) event of a crash of |cgt|, as it is a |Python| script, the right
|
|
|
|
|
command to run |gdb| on it is: ::
|
2014-12-12 05:05:25 -06:00
|
|
|
|
2015-02-27 11:16:03 -06:00
|
|
|
dummy@lepka:work$ gdb python core.XXXX
|
2014-12-12 05:05:25 -06:00
|
|
|
|
2015-03-06 01:58:10 -06:00
|
|
|
|newpage|
|
|
|
|
|
|
2014-07-13 06:14:49 -05:00
|
|
|
|
2014-05-13 10:15:29 -05:00
|
|
|
Additionnal Requirement under |MacOS|
|
|
|
|
|
-------------------------------------
|
|
|
|
|
|
|
|
|
|
|Coriolis| make uses 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|: ::
|
|
|
|
|
|
|
|
|
|
dummy@macos:~$ port install boost +python27
|
|
|
|
|
dummy@macos:~$ port select python python27
|
2014-12-12 05:05:25 -06:00
|
|
|
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.
|
2014-05-13 10:15:29 -05:00
|
|
|
|
|
|
|
|
Then proceed with the generic install instructions.
|
|
|
|
|
|
|
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
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.
|
2012-11-16 06:49:47 -06:00
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
Sligthly outaded packaging configuration files can also be found under ``bootstrap/``:
|
2012-11-16 06:49:47 -06:00
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
* ``bootstrap/coriolis2.spec.in`` for |rpm| based distributions.
|
|
|
|
|
* ``bootstrap/debian`` for |Debian| based distributions.
|
2012-12-03 06:31:41 -06:00
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
|
|
|
|
|
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 :cb:`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
|
|
|
|
|
:cb:`/usr/share/alliance/cells`.
|
|
|
|
|
|
|
|
|
|
|
2014-07-13 06:14:49 -05:00
|
|
|
Setting up the Environment (coriolisEnv.py)
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2014-03-10 08:06:31 -05:00
|
|
|
|
|
|
|
|
To simplify the tedious task of configuring your environment, a helper is provided
|
2014-12-12 05:05:25 -06:00
|
|
|
in the ``bootstrap`` source directory (also installed in the directory
|
|
|
|
|
``.../install/etc/coriolis2/``) : ::
|
2014-03-10 08:06:31 -05:00
|
|
|
|
2014-12-12 05:05:25 -06:00
|
|
|
~/coriolis-2.x/src/coriolis/bootstrap/coriolisEnv.py
|
2014-03-10 08:06:31 -05:00
|
|
|
|
|
|
|
|
Use it like this: ::
|
|
|
|
|
|
2014-12-12 05:05:25 -06:00
|
|
|
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 :cb:`~/.bashrc`.
|
|
|
|
|
|
|
|
|
|
Instead you may want to create an alias: ::
|
|
|
|
|
|
|
|
|
|
alias c2r='eval "`~/coriolis-2.x/src/coriolis/bootstrap/coriolisEnv.py`"'
|
2012-11-16 06:49:47 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|newpage|
|
|
|
|
|
|
|
|
|
|
|
2012-12-03 06:31:41 -06:00
|
|
|
Documentation
|
|
|
|
|
=============
|
|
|
|
|
|
|
|
|
|
The general index of the documentation for the various parts of Coriolis
|
2014-03-10 08:06:31 -05:00
|
|
|
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.
|
|
|
|
|
|
Make the Python interface closely mirroring the C++ one.
* Change: In Isobar, the Python interface was not exactly mirroring the
C++ one, now it is the case. The Python code should look likes almost
exactly like the C++ one, the only differences remaining being due
to the languages respective syntaxes. Note that in the case of
constructor functions, it leads to a slightly longer notation in
Python that it could have been (mimic the ".create()" static
member). Main modifications:
1. Mirror the static constructor syntax with create():
Cell( ... ) ==> Cell.create( ... )
2. Correct hierarchy for constants in Instance, Net, Pin
& Transformation. For example:
Hurricane.PlacementStatusFIXED
==> Hurricane.Instance.PlacementStatus.FIXED
Hurricane.OrientationID
==> Hurricane.Transformation.Orientation.ID
Hurricane.TypeLOGICAL ==> Hurricane.Net.Type.LOGICAL
Hurricane.DirectionIN ==> Hurricane.Net.Direction.IN
* Change: In CRL Core, correction to match the improved Python API
in the configutation helpers.
* Change: In Cumulus, correction to match the improved Python API.
* Change: In Stratus, correction to match the improved Python API.
* Change: In Documenation, update for the new Python interface
(both user's guide & examples).
* Note: We must port those changes into Chams for it to continue
to run.
* Change: In Documenation, update the Python script support part.
2014-06-28 10:37:59 -05:00
|
|
|
General Software Architecture
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2014-03-10 08:06:31 -05:00
|
|
|
|
|
|
|
|
|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 :cb:`boost::python` (mainly in :cb:`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.
|
2012-12-03 06:31:41 -06:00
|
|
|
|
Make the Python interface closely mirroring the C++ one.
* Change: In Isobar, the Python interface was not exactly mirroring the
C++ one, now it is the case. The Python code should look likes almost
exactly like the C++ one, the only differences remaining being due
to the languages respective syntaxes. Note that in the case of
constructor functions, it leads to a slightly longer notation in
Python that it could have been (mimic the ".create()" static
member). Main modifications:
1. Mirror the static constructor syntax with create():
Cell( ... ) ==> Cell.create( ... )
2. Correct hierarchy for constants in Instance, Net, Pin
& Transformation. For example:
Hurricane.PlacementStatusFIXED
==> Hurricane.Instance.PlacementStatus.FIXED
Hurricane.OrientationID
==> Hurricane.Transformation.Orientation.ID
Hurricane.TypeLOGICAL ==> Hurricane.Net.Type.LOGICAL
Hurricane.DirectionIN ==> Hurricane.Net.Direction.IN
* Change: In CRL Core, correction to match the improved Python API
in the configutation helpers.
* Change: In Cumulus, correction to match the improved Python API.
* Change: In Stratus, correction to match the improved Python API.
* Change: In Documenation, update for the new Python interface
(both user's guide & examples).
* Note: We must port those changes into Chams for it to continue
to run.
* Change: In Documenation, update the Python script support part.
2014-06-28 10:37:59 -05:00
|
|
|
|CoriolisSoftSchema|
|
|
|
|
|
|
2012-12-03 06:31:41 -06:00
|
|
|
|
2012-11-16 06:49:47 -06:00
|
|
|
Coriolis Configuration & Initialisation
|
|
|
|
|
=======================================
|
|
|
|
|
|
|
|
|
|
All configuration & initialization files are Python scripts, despite their
|
|
|
|
|
|dot_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.
|
|
|
|
|
|medskip|
|
|
|
|
|
|
2014-05-21 17:13:17 -05:00
|
|
|
Configuration is done in two stages:
|
|
|
|
|
|
|
|
|
|
#. Selecting the symbolic technology.
|
|
|
|
|
#. Loading the complete configuration for the given technology.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
First Stage: Symbolic Technology Selection
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
2012-11-16 06:49:47 -06:00
|
|
|
|noindent|
|
|
|
|
|
The initialization process is done by executing, in order, the following
|
|
|
|
|
file(s):
|
|
|
|
|
|
|
|
|
|
+-------+----------------------------------+----------------------------------------------+
|
|
|
|
|
| Order | Meaning | File |
|
|
|
|
|
+=======+==================================+==============================================+
|
2015-02-27 11:16:03 -06:00
|
|
|
| **1** | The system setting | :cb:`/etc/coriolis2/techno.conf` |
|
2014-05-21 17:13:17 -05:00
|
|
|
+-------+----------------------------------+----------------------------------------------+
|
2015-02-27 11:16:03 -06:00
|
|
|
| **2** | The user's global setting | :cb:`${HOME}/.coriolis2/techno.py` |
|
2014-05-21 17:13:17 -05:00
|
|
|
+-------+----------------------------------+----------------------------------------------+
|
2015-02-27 11:16:03 -06:00
|
|
|
| **3** | The user's local setting | :cb:`<CWD>/.coriolis2/techno.py` |
|
2014-05-21 17:13:17 -05:00
|
|
|
+-------+----------------------------------+----------------------------------------------+
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
|noindent|
|
|
|
|
|
The :cb:`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 :cb:`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):
|
|
|
|
|
|
|
|
|
|
+-------+----------------------------------+----------------------------------------------+
|
|
|
|
|
| Order | Meaning | File |
|
|
|
|
|
+=======+==================================+==============================================+
|
|
|
|
|
| **1** | The system initialization | :cb:`/etc/coriolis2/<TECHNO>/<TOOL>.conf` |
|
2012-11-16 06:49:47 -06:00
|
|
|
+-------+----------------------------------+----------------------------------------------+
|
2015-02-27 11:16:03 -06:00
|
|
|
| **2** | The user's global initialization | :cb:`${HOME}/.coriolis2/settings.py` |
|
2012-11-16 06:49:47 -06:00
|
|
|
+-------+----------------------------------+----------------------------------------------+
|
2015-02-27 11:16:03 -06:00
|
|
|
| **3** | The user's local initialization | :cb:`<CWD>/.coriolis2/settings.py` |
|
2012-11-16 06:49:47 -06:00
|
|
|
+-------+----------------------------------+----------------------------------------------+
|
|
|
|
|
|
|
|
|
|
.. note:: *The loading policy is not hard-coded.* It is implemented
|
2015-02-27 11:16:03 -06:00
|
|
|
at Python level in :cb:`/etc/coriolis2/coriolisInit.py`, and thus may be easily be
|
2012-11-16 06:49:47 -06:00
|
|
|
amended to whatever site policy.
|
|
|
|
|
|
|
|
|
|
The truly mandatory requirement is the existence of :cb:`coriolisInit.py`
|
|
|
|
|
which *must* contain a :cb:`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
|
2014-03-10 08:06:31 -05:00
|
|
|
simple assembly of tuples. The helpers are installed under the directory: ::
|
|
|
|
|
|
|
|
|
|
<install>/etc/coriolis2/
|
2012-11-16 06:49:47 -06:00
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
Where :cb:`<install>/` is the root of the installation.
|
|
|
|
|
|
2015-03-06 01:58:10 -06:00
|
|
|
|newpage|
|
|
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
|
|
|
|
|
.. _Alliance Helper:
|
2012-11-16 06:49:47 -06:00
|
|
|
|
|
|
|
|
|Alliance| Helper
|
|
|
|
|
-----------------
|
|
|
|
|
|
|
|
|
|
The configuration file must provide a :cb:`allianceConfig` tuple of
|
|
|
|
|
the form: ::
|
|
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
cellsTop = '/usr/share/alliance/cells/'
|
2012-11-16 06:49:47 -06:00
|
|
|
|
|
|
|
|
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*')
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|noindent| 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:
|
|
|
|
|
|
|
|
|
|
* :cb:`Environment::Append`: append to the search path.
|
|
|
|
|
|
|
|
|
|
* :cb:`Environment::Prepend`: insert in head of the search path.
|
|
|
|
|
|
|
|
|
|
* :cb:`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``.
|
|
|
|
|
|
2015-02-27 11:16:03 -06:00
|
|
|
.. * Trick and naming convention about ``SYMBOLIC_TECHNOLOGY``, ``REAL_TECHNOLOGY``
|
|
|
|
|
.. and ``DISPLAY``. In the previous releases, thoses files where to read by
|
|
|
|
|
.. XML parsers, and still do if you triggers the XML compatibility mode.
|
|
|
|
|
.. But now, they have Python conterparts. In the configuration files, you
|
|
|
|
|
.. still have to name them as XML files, the Python file name will be
|
|
|
|
|
.. deduced from this one with thoses two translation rules:
|
|
|
|
|
..
|
|
|
|
|
.. #. In the filename, all dots, except for the last (the file extention),
|
|
|
|
|
.. are replaced by underscores.
|
|
|
|
|
..
|
|
|
|
|
.. #. The ``.xml`` extention is substituted by a ``.conf``.
|
|
|
|
|
..
|
|
|
|
|
.. For the symbolic technology, it would give: ::
|
|
|
|
|
..
|
|
|
|
|
.. /soc/coriolis2/technology.symbolic.xml
|
|
|
|
|
.. --> /soc/coriolis2/technology_symbolic.conf
|
2012-11-16 06:49:47 -06:00
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
|
|
* :cb:`misc.conf`: commons settings or not belonging specifically to a tool.
|
2015-02-27 11:16:03 -06:00
|
|
|
* :cb:`etesian.conf`: for the |Etesian| tool.
|
2012-11-16 06:49:47 -06:00
|
|
|
* :cb:`kite.conf`: for the |Kite| tool.
|
|
|
|
|
* :cb:`stratus1.conf`: for the |stratus1| tool.
|
|
|
|
|
|
2015-02-27 11:16:03 -06:00
|
|
|
Here is the contents of :cb:`etesian.conf`: ::
|
2012-11-16 06:49:47 -06:00
|
|
|
|
2015-02-27 11:16:03 -06:00
|
|
|
# Etesian parameters.
|
2012-11-16 06:49:47 -06:00
|
|
|
parametersTable = \
|
2015-02-27 11:16:03 -06:00
|
|
|
( ('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) ) }
|
|
|
|
|
)
|
2012-11-16 06:49:47 -06:00
|
|
|
)
|
|
|
|
|
|
|
|
|
|
layoutTable = \
|
2015-02-27 11:16:03 -06:00
|
|
|
( (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 )
|
2012-11-16 06:49:47 -06:00
|
|
|
, (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
|
2014-03-10 08:06:31 -05:00
|
|
|
in the configuration window (`The Settings Tab`_).
|
2012-11-16 06:49:47 -06:00
|
|
|
|
|
|
|
|
* 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
|
|
|
|
|
:cb:`(TypeOption, 'paramId', ParameterType, DefaultValue)` with:
|
|
|
|
|
|
|
|
|
|
#. ``TypeOption``, tells that this tuple describe a parameter.
|
|
|
|
|
|
|
|
|
|
#. ``paramId``, the identifier of the parameter. Identifiers are defined
|
|
|
|
|
by the tools. The list of parameters is detailed in each tool section.
|
|
|
|
|
|
|
|
|
|
#. ``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.
|
|
|
|
|
|
|
|
|
|
#. ``DefaultValue``, the default value for that parameter.
|
|
|
|
|
|
|
|
|
|
|
Make the Python interface closely mirroring the C++ one.
* Change: In Isobar, the Python interface was not exactly mirroring the
C++ one, now it is the case. The Python code should look likes almost
exactly like the C++ one, the only differences remaining being due
to the languages respective syntaxes. Note that in the case of
constructor functions, it leads to a slightly longer notation in
Python that it could have been (mimic the ".create()" static
member). Main modifications:
1. Mirror the static constructor syntax with create():
Cell( ... ) ==> Cell.create( ... )
2. Correct hierarchy for constants in Instance, Net, Pin
& Transformation. For example:
Hurricane.PlacementStatusFIXED
==> Hurricane.Instance.PlacementStatus.FIXED
Hurricane.OrientationID
==> Hurricane.Transformation.Orientation.ID
Hurricane.TypeLOGICAL ==> Hurricane.Net.Type.LOGICAL
Hurricane.DirectionIN ==> Hurricane.Net.Direction.IN
* Change: In CRL Core, correction to match the improved Python API
in the configutation helpers.
* Change: In Cumulus, correction to match the improved Python API.
* Change: In Stratus, correction to match the improved Python API.
* Change: In Documenation, update for the new Python interface
(both user's guide & examples).
* Note: We must port those changes into Chams for it to continue
to run.
* Change: In Documenation, update the Python script support part.
2014-06-28 10:37:59 -05:00
|
|
|
Hacking the Configuration Files
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
Asides from the symbols that gets used by the configuration helpers like
|
|
|
|
|
:cb:`allianceConfig` or :cb:`parametersTable`, you can put pretty much anything
|
2015-02-27 11:16:03 -06:00
|
|
|
in :cb:`<CWD>/.coriolis2/settings.py` (that is, written in |Python|).
|
Make the Python interface closely mirroring the C++ one.
* Change: In Isobar, the Python interface was not exactly mirroring the
C++ one, now it is the case. The Python code should look likes almost
exactly like the C++ one, the only differences remaining being due
to the languages respective syntaxes. Note that in the case of
constructor functions, it leads to a slightly longer notation in
Python that it could have been (mimic the ".create()" static
member). Main modifications:
1. Mirror the static constructor syntax with create():
Cell( ... ) ==> Cell.create( ... )
2. Correct hierarchy for constants in Instance, Net, Pin
& Transformation. For example:
Hurricane.PlacementStatusFIXED
==> Hurricane.Instance.PlacementStatus.FIXED
Hurricane.OrientationID
==> Hurricane.Transformation.Orientation.ID
Hurricane.TypeLOGICAL ==> Hurricane.Net.Type.LOGICAL
Hurricane.DirectionIN ==> Hurricane.Net.Direction.IN
* Change: In CRL Core, correction to match the improved Python API
in the configutation helpers.
* Change: In Cumulus, correction to match the improved Python API.
* Change: In Stratus, correction to match the improved Python API.
* Change: In Documenation, update for the new Python interface
(both user's guide & examples).
* Note: We must port those changes into Chams for it to continue
to run.
* Change: In Documenation, update the Python script support part.
2014-06-28 10:37:59 -05:00
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
2012-11-16 06:49:47 -06:00
|
|
|
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`_.
|
|
|
|
|
|
|
|
|
|
|ViewerSnapShot_1|
|
|
|
|
|
|
|
|
|
|
* 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.
|
|
|
|
|
|
|
|
|
|
|ControllerSnapShot_1|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.. _Viewer & Tools:
|
|
|
|
|
|
|
|
|
|
Viewer & Tools
|
|
|
|
|
==============
|
|
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
|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`_)
|
|
|
|
|
|
|
|
|
|
|
2012-11-16 06:49:47 -06:00
|
|
|
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|.
|
|
|
|
|
|
2015-04-05 04:35:06 -05:00
|
|
|
As for the second release, |Coriolis| can be used only for three purposes :
|
2012-11-16 06:49:47 -06:00
|
|
|
|
2015-04-05 04:35:06 -05:00
|
|
|
* **Placing a design**, in which case the |netlist| view must be present.
|
2012-11-16 06:49:47 -06:00
|
|
|
* **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.
|
|
|
|
|
|
|
|
|
|
|
2015-04-05 04:35:06 -05:00
|
|
|
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. Although |Yosys| opens
|
|
|
|
|
most .lib files with minor modifications, Coriolis may be compiled without LEF support, in
|
|
|
|
|
which case you need .ap files.
|
|
|
|
|
In this case, you need to export your .lef library as .ap files or compile your Coriolis version
|
|
|
|
|
with LEF support.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
2015-02-27 11:16:03 -06:00
|
|
|
Etesian -- Placer
|
|
|
|
|
~~~~~~~~~~~~~~~~~
|
2012-11-16 06:49:47 -06:00
|
|
|
|
2015-04-05 04:35:06 -05:00
|
|
|
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.
|
2012-11-16 06:49:47 -06:00
|
|
|
|
2015-03-06 01:58:10 -06:00
|
|
|
.. note:: *Instance Uniquification Unsupported:* a same logical instance cannot have
|
2012-11-16 06:49:47 -06:00
|
|
|
two different placements. So, either you manually make a clone of it or you
|
2015-03-06 01:58:10 -06:00
|
|
|
supply a placement for it. We need to implement uniquification in the
|
|
|
|
|
|Hurricane| database.
|
|
|
|
|
|
2012-11-16 06:49:47 -06:00
|
|
|
|
2015-03-06 01:58:10 -06:00
|
|
|
|noindent|
|
|
|
|
|
**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-1|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|noindent|
|
|
|
|
|
**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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|noindent|
|
2014-03-10 08:06:31 -05:00
|
|
|
**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 :cb:`.ap` file, which are
|
|
|
|
|
automatically reloaded along with the netlist (:cb:`.vst`).
|
|
|
|
|
|
2015-04-05 04:35:06 -05:00
|
|
|
|noindent|
|
|
|
|
|
**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.
|
|
|
|
|
|
2015-03-06 01:58:10 -06:00
|
|
|
|newpage|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Etesian Configuration Parameters
|
|
|
|
|
--------------------------------
|
|
|
|
|
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
| Parameter Identifier | Type | Default |
|
|
|
|
|
+===================================+==================+============================+
|
|
|
|
|
| **Etesian Parameters** |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
|``etesian.aspectRatio`` | TypePercentage | :cb:`100` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | Define the height on width ``H/W`` aspect |
|
|
|
|
|
| | ratio, can be comprised between 10 and 1000 |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
|``etesian.spaceMargin`` | TypePercentage | :cb:`5` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | The extra white space added to the total area |
|
|
|
|
|
| | of the standard cells |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
|``etesian.uniformDensity`` | TypeBool | :cb:`False` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | Whether the cells will be spread envenly |
|
|
|
|
|
| | across the area or allowed to form denser |
|
|
|
|
|
| | clusters |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
|``etesian.effort`` | TypeInt | :cb:`2` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | Sets the balance between the speed of the |
|
|
|
|
|
| | placer and the solution quality |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
2015-04-05 04:35:06 -05:00
|
|
|
|``etesian.routingDriven`` | TypeBool | :cb:`False` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | Whether the tool will try routing iterations |
|
|
|
|
|
| | and whitespace allocation to improve |
|
|
|
|
|
| | routability; to be implemented |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
2015-03-06 01:58:10 -06:00
|
|
|
|``etesian.graphics`` | TypeInt | :cb:`2` |
|
|
|
|
|
| +------------------+----------------------------+
|
2015-04-05 04:35:06 -05:00
|
|
|
| | How often the display will be refreshed |
|
|
|
|
|
| | More refreshing slows the placer. |
|
2015-03-06 01:58:10 -06:00
|
|
|
| | |
|
2015-04-05 04:35:06 -05:00
|
|
|
| | * ``1`` shows both upper and lower bounds |
|
|
|
|
|
| | * ``2`` only shows lower bound results |
|
|
|
|
|
| | * ``3`` only shows the final results |
|
2015-03-06 01:58:10 -06:00
|
|
|
+-----------------------------------+-----------------------------------------------+
|
|
|
|
|
|
2012-11-16 06:49:47 -06:00
|
|
|
|
|
|
|
|
Knik -- Global Router
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
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`_.
|
|
|
|
|
|
2012-11-16 06:49:47 -06:00
|
|
|
The global router is (not yet) deterministic. To circumvent this limitation,
|
2014-03-10 08:06:31 -05:00
|
|
|
a global routing *solution* can be saved to disk and reloaded for later uses.
|
2012-11-16 06:49:47 -06:00
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|noindent| Menus:
|
|
|
|
|
|
|
|
|
|
* |menu_P&R| |rightarrow| |menu_StepByStep| |rightarrow| |menu_KiteSaveGlobalRouting|.
|
|
|
|
|
* |menu_P&R| |rightarrow| |menu_StepByStep| |rightarrow| |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.
|
|
|
|
|
|medskip|
|
|
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
|noindent| However, this first release comes with the temporary the following
|
|
|
|
|
restrictions:
|
2012-11-16 06:49:47 -06:00
|
|
|
|
|
|
|
|
* 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|.
|
|
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
.. 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.
|
|
|
|
|
|
2012-11-16 06:49:47 -06:00
|
|
|
After each run, |Kite| displays a set of *completion ratios* which must all
|
|
|
|
|
be equal to `100%` if the detailed routing has been successfull.
|
2014-03-10 08:06:31 -05:00
|
|
|
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
|
2012-11-16 06:49:47 -06:00
|
|
|
saturation. That is, the maximum saturation decrease at the price of a wider
|
2014-03-10 08:06:31 -05:00
|
|
|
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.
|
2012-11-16 06:49:47 -06:00
|
|
|
|
Add NetRoutingState (Property) on Nets to tell Kite what to do.
* New: In Katabatic, add the ability to decorate some (i.e. few) nets
with a state that indicate to Katabatic & Kite what to do with it.
The possible states are:
1. Fixed : all the wire are in fixed positions. The router cannot
move them and account them as obstacles.
2. ManualGlobalRoute : a user-defined topology is supplied. The
wires still have to be detailed route in "Detailed Pre-Route"
but will be skipped for the global routing and fixed for the
general Detailed route.
3. AutomaticGlobalRoute : ordinary nets, to be global routed then
detail routed.
4. Excluded : do not try to global or detail route thoses nets.
5. MixedPreRoute : mask combining Fixed and ManualGlobalRoute.
Not all nets have this property, only those that needs a special
processing.
To ease the access to the state, it is nested inside a
PrivateProperty in the net (NetRoutingProperty), with an extension
access class (NetRoutingExtension).
* New: In Kite, take account of NetRoutingState. Pointers to the
net's states are strored inside an internal map for faster access.
The property is *not* deleted when Kite is destroyed. The property
will remains until the Net itself is destroyed.
As a consequence, the lists that where passed to high level
function are removed as the information can now be accessed directly
through the net NetRoutingProperty.
* New: In Unicorn, in CgtMain, comply with the update interface.
* New: In documentation, update the User's Guide to explain the Pre-routed
step of Kite.
2014-07-02 07:36:58 -05:00
|
|
|
Routing a design is done in four ordered steps:
|
|
|
|
|
|
|
|
|
|
#. Detailed pre-route |menu_P&R| |rightarrow| |menu_StepByStep| |rightarrow| |menu_KiteDetailedPreRoute|.
|
|
|
|
|
#. Global routing |menu_P&R| |rightarrow| |menu_StepByStep| |rightarrow| |menu_KiteGlobalRoute|.
|
|
|
|
|
#. Detailed routing |menu_P&R| |rightarrow| |menu_StepByStep| |rightarrow| |menu_KiteDetailedRoute|.
|
|
|
|
|
#. Finalize routing |menu_P&R| |rightarrow| |menu_StepByStep| |rightarrow| |menu_KiteFinalizeRoute|.
|
|
|
|
|
|
|
|
|
|
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 :fboxtt:`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.
|
2012-11-16 06:49:47 -06:00
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
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 :cb:`kite.` prefix.
|
|
|
|
|
|
|
|
|
|
The |Katabatic| parameters control the layer assignment step.
|
|
|
|
|
|
Make the Python interface closely mirroring the C++ one.
* Change: In Isobar, the Python interface was not exactly mirroring the
C++ one, now it is the case. The Python code should look likes almost
exactly like the C++ one, the only differences remaining being due
to the languages respective syntaxes. Note that in the case of
constructor functions, it leads to a slightly longer notation in
Python that it could have been (mimic the ".create()" static
member). Main modifications:
1. Mirror the static constructor syntax with create():
Cell( ... ) ==> Cell.create( ... )
2. Correct hierarchy for constants in Instance, Net, Pin
& Transformation. For example:
Hurricane.PlacementStatusFIXED
==> Hurricane.Instance.PlacementStatus.FIXED
Hurricane.OrientationID
==> Hurricane.Transformation.Orientation.ID
Hurricane.TypeLOGICAL ==> Hurricane.Net.Type.LOGICAL
Hurricane.DirectionIN ==> Hurricane.Net.Direction.IN
* Change: In CRL Core, correction to match the improved Python API
in the configutation helpers.
* Change: In Cumulus, correction to match the improved Python API.
* Change: In Stratus, correction to match the improved Python API.
* Change: In Documenation, update for the new Python interface
(both user's guide & examples).
* Note: We must port those changes into Chams for it to continue
to run.
* Change: In Documenation, update the Python script support part.
2014-06-28 10:37:59 -05:00
|
|
|
All the defaults value given below are from the default |Alliance| technology
|
|
|
|
|
(:cb:`cmos` and :cb:`SxLib` cell gauge/routing gauge).
|
|
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
| Parameter Identifier | Type | Default |
|
|
|
|
|
+===================================+==================+============================+
|
|
|
|
|
| **Katabatic Parameters** |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
Make the Python interface closely mirroring the C++ one.
* Change: In Isobar, the Python interface was not exactly mirroring the
C++ one, now it is the case. The Python code should look likes almost
exactly like the C++ one, the only differences remaining being due
to the languages respective syntaxes. Note that in the case of
constructor functions, it leads to a slightly longer notation in
Python that it could have been (mimic the ".create()" static
member). Main modifications:
1. Mirror the static constructor syntax with create():
Cell( ... ) ==> Cell.create( ... )
2. Correct hierarchy for constants in Instance, Net, Pin
& Transformation. For example:
Hurricane.PlacementStatusFIXED
==> Hurricane.Instance.PlacementStatus.FIXED
Hurricane.OrientationID
==> Hurricane.Transformation.Orientation.ID
Hurricane.TypeLOGICAL ==> Hurricane.Net.Type.LOGICAL
Hurricane.DirectionIN ==> Hurricane.Net.Direction.IN
* Change: In CRL Core, correction to match the improved Python API
in the configutation helpers.
* Change: In Cumulus, correction to match the improved Python API.
* Change: In Stratus, correction to match the improved Python API.
* Change: In Documenation, update for the new Python interface
(both user's guide & examples).
* Note: We must port those changes into Chams for it to continue
to run.
* Change: In Documenation, update the Python script support part.
2014-06-28 10:37:59 -05:00
|
|
|
|``katabatic.topRoutingLayer`` | TypeString | :cb:`METAL5` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | Define the highest metal layer that will be |
|
|
|
|
|
| | used for routing (inclusive). |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
2014-03-10 08:06:31 -05:00
|
|
|
|``katabatic.globalLengthThreshold``| TypeInt | :cb:`1450` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | This parameter is used by a layer assignment |
|
|
|
|
|
| | method which is no longer used (did not give |
|
|
|
|
|
| | good results) |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
| ``katabatic.saturateRatio`` | TypePercentage | :cb:`80` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | If ``M(x)`` density is above this ratio, |
|
|
|
|
|
| | move up feedthru global segments up from |
|
|
|
|
|
| | depth ``x`` to ``x+2`` |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
| ``katabatic.saturateRp`` | TypeInt | :cb:`8` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | If a GCell contains more terminals |
|
|
|
|
|
| | (:cb:`RoutingPad`) than that number, force a |
|
|
|
|
|
| | move up of the connecting segments to those |
|
|
|
|
|
| | in excess |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
| **Knik Parameters** |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
Make the Python interface closely mirroring the C++ one.
* Change: In Isobar, the Python interface was not exactly mirroring the
C++ one, now it is the case. The Python code should look likes almost
exactly like the C++ one, the only differences remaining being due
to the languages respective syntaxes. Note that in the case of
constructor functions, it leads to a slightly longer notation in
Python that it could have been (mimic the ".create()" static
member). Main modifications:
1. Mirror the static constructor syntax with create():
Cell( ... ) ==> Cell.create( ... )
2. Correct hierarchy for constants in Instance, Net, Pin
& Transformation. For example:
Hurricane.PlacementStatusFIXED
==> Hurricane.Instance.PlacementStatus.FIXED
Hurricane.OrientationID
==> Hurricane.Transformation.Orientation.ID
Hurricane.TypeLOGICAL ==> Hurricane.Net.Type.LOGICAL
Hurricane.DirectionIN ==> Hurricane.Net.Direction.IN
* Change: In CRL Core, correction to match the improved Python API
in the configutation helpers.
* Change: In Cumulus, correction to match the improved Python API.
* Change: In Stratus, correction to match the improved Python API.
* Change: In Documenation, update for the new Python interface
(both user's guide & examples).
* Note: We must port those changes into Chams for it to continue
to run.
* Change: In Documenation, update the Python script support part.
2014-06-28 10:37:59 -05:00
|
|
|
| ``kite.hTracksReservedLocal`` | TypeInt | :cb:`3` |
|
2014-03-10 08:06:31 -05:00
|
|
|
| +------------------+----------------------------+
|
Make the Python interface closely mirroring the C++ one.
* Change: In Isobar, the Python interface was not exactly mirroring the
C++ one, now it is the case. The Python code should look likes almost
exactly like the C++ one, the only differences remaining being due
to the languages respective syntaxes. Note that in the case of
constructor functions, it leads to a slightly longer notation in
Python that it could have been (mimic the ".create()" static
member). Main modifications:
1. Mirror the static constructor syntax with create():
Cell( ... ) ==> Cell.create( ... )
2. Correct hierarchy for constants in Instance, Net, Pin
& Transformation. For example:
Hurricane.PlacementStatusFIXED
==> Hurricane.Instance.PlacementStatus.FIXED
Hurricane.OrientationID
==> Hurricane.Transformation.Orientation.ID
Hurricane.TypeLOGICAL ==> Hurricane.Net.Type.LOGICAL
Hurricane.DirectionIN ==> Hurricane.Net.Direction.IN
* Change: In CRL Core, correction to match the improved Python API
in the configutation helpers.
* Change: In Cumulus, correction to match the improved Python API.
* Change: In Stratus, correction to match the improved Python API.
* Change: In Documenation, update for the new Python interface
(both user's guide & examples).
* Note: We must port those changes into Chams for it to continue
to run.
* Change: In Documenation, update the Python script support part.
2014-06-28 10:37:59 -05:00
|
|
|
| | 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.vTracksReservedLocal`` | TypeInt | :cb:`3` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | cf. ``kite.hTracksReservedLocal`` |
|
2014-03-10 08:06:31 -05:00
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
| **Kite Parameters** |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
| ``kite.eventsLimit`` | TypeInt | :cb:`4000002` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | 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.ripupCost`` | TypeInt | :cb:`3` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | Differential introduced between two ripup |
|
|
|
|
|
| | cost to avoid a loop between two ripped up |
|
|
|
|
|
| | segments |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
| ``kite.strapRipupLimit`` | TypeInt | :cb:`16` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | Maximum number of ripup for *strap* segments |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
| ``kite.localRipupLimit`` | TypeInt | :cb:`9` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | Maximum number of ripup for *local* segments |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
| ``kite.globalRipupLimit`` | TypeInt | :cb:`5` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | Maximum number of ripup for *global* segments,|
|
|
|
|
|
| | when this limit is reached, triggers topologic|
|
|
|
|
|
| | modification |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
| ``kite.longGlobalRipupLimit`` | TypeInt | :cb:`5` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | Maximum number of ripup for *long global* |
|
|
|
|
|
| | segments, when this limit is reached, triggers|
|
|
|
|
|
| | topological modification |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
|
2012-11-16 06:49:47 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
.. _Python Scripts in Cgt:
|
|
|
|
|
|
|
|
|
|
Executing Python Scripts in Cgt
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
Python/Stratus scripts can be executed either in text or graphical mode.
|
|
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
.. note:: **How Cgt Locates Python Scripts:**
|
2012-11-16 06:49:47 -06:00
|
|
|
|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.
|
|
|
|
|
|
Make the Python interface closely mirroring the C++ one.
* Change: In Isobar, the Python interface was not exactly mirroring the
C++ one, now it is the case. The Python code should look likes almost
exactly like the C++ one, the only differences remaining being due
to the languages respective syntaxes. Note that in the case of
constructor functions, it leads to a slightly longer notation in
Python that it could have been (mimic the ".create()" static
member). Main modifications:
1. Mirror the static constructor syntax with create():
Cell( ... ) ==> Cell.create( ... )
2. Correct hierarchy for constants in Instance, Net, Pin
& Transformation. For example:
Hurricane.PlacementStatusFIXED
==> Hurricane.Instance.PlacementStatus.FIXED
Hurricane.OrientationID
==> Hurricane.Transformation.Orientation.ID
Hurricane.TypeLOGICAL ==> Hurricane.Net.Type.LOGICAL
Hurricane.DirectionIN ==> Hurricane.Net.Direction.IN
* Change: In CRL Core, correction to match the improved Python API
in the configutation helpers.
* Change: In Cumulus, correction to match the improved Python API.
* Change: In Stratus, correction to match the improved Python API.
* Change: In Documenation, update for the new Python interface
(both user's guide & examples).
* Note: We must port those changes into Chams for it to continue
to run.
* Change: In Documenation, update the Python script support part.
2014-06-28 10:37:59 -05:00
|
|
|
A Python/Stratus script must contains a function called ``ScriptMain()``
|
2012-11-16 06:49:47 -06:00
|
|
|
with one optional argument, the graphical editor into which it may be
|
Make the Python interface closely mirroring the C++ one.
* Change: In Isobar, the Python interface was not exactly mirroring the
C++ one, now it is the case. The Python code should look likes almost
exactly like the C++ one, the only differences remaining being due
to the languages respective syntaxes. Note that in the case of
constructor functions, it leads to a slightly longer notation in
Python that it could have been (mimic the ".create()" static
member). Main modifications:
1. Mirror the static constructor syntax with create():
Cell( ... ) ==> Cell.create( ... )
2. Correct hierarchy for constants in Instance, Net, Pin
& Transformation. For example:
Hurricane.PlacementStatusFIXED
==> Hurricane.Instance.PlacementStatus.FIXED
Hurricane.OrientationID
==> Hurricane.Transformation.Orientation.ID
Hurricane.TypeLOGICAL ==> Hurricane.Net.Type.LOGICAL
Hurricane.DirectionIN ==> Hurricane.Net.Direction.IN
* Change: In CRL Core, correction to match the improved Python API
in the configutation helpers.
* Change: In Cumulus, correction to match the improved Python API.
* Change: In Stratus, correction to match the improved Python API.
* Change: In Documenation, update for the new Python interface
(both user's guide & examples).
* Note: We must port those changes into Chams for it to continue
to run.
* Change: In Documenation, update the Python script support part.
2014-06-28 10:37:59 -05:00
|
|
|
running (will be set to ``None`` in text mode). The Python interface to
|
|
|
|
|
the editor (type: :cb:`CellViewer`) is limited to basic capabilities
|
|
|
|
|
only.
|
2014-03-10 08:06:31 -05:00
|
|
|
|
2012-11-16 06:49:47 -06:00
|
|
|
Any script given on the command line will be run immediatly *after* the
|
|
|
|
|
initializations and *before* any other argument is processed.
|
|
|
|
|
|
Make the Python interface closely mirroring the C++ one.
* Change: In Isobar, the Python interface was not exactly mirroring the
C++ one, now it is the case. The Python code should look likes almost
exactly like the C++ one, the only differences remaining being due
to the languages respective syntaxes. Note that in the case of
constructor functions, it leads to a slightly longer notation in
Python that it could have been (mimic the ".create()" static
member). Main modifications:
1. Mirror the static constructor syntax with create():
Cell( ... ) ==> Cell.create( ... )
2. Correct hierarchy for constants in Instance, Net, Pin
& Transformation. For example:
Hurricane.PlacementStatusFIXED
==> Hurricane.Instance.PlacementStatus.FIXED
Hurricane.OrientationID
==> Hurricane.Transformation.Orientation.ID
Hurricane.TypeLOGICAL ==> Hurricane.Net.Type.LOGICAL
Hurricane.DirectionIN ==> Hurricane.Net.Direction.IN
* Change: In CRL Core, correction to match the improved Python API
in the configutation helpers.
* Change: In Cumulus, correction to match the improved Python API.
* Change: In Stratus, correction to match the improved Python API.
* Change: In Documenation, update for the new Python interface
(both user's guide & examples).
* Note: We must port those changes into Chams for it to continue
to run.
* Change: In Documenation, update the Python script support part.
2014-06-28 10:37:59 -05:00
|
|
|
For more explanation on Python scripts see `Python Interface to Coriolis`_.
|
2012-11-16 06:49:47 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
Printing & Snapshots
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
Printing or saving into a |pdf| is fairly simple, just uses the **File -> Print**
|
2015-03-06 01:58:10 -06:00
|
|
|
menu or the |CTRL_P| shortcut to open the dialog box.
|
2012-11-16 06:49:47 -06:00
|
|
|
|
|
|
|
|
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**:
|
|
|
|
|
|
|
|
|
|
=============== ================= =====================================================
|
|
|
|
|
Mode DPI (approx.) Intended Usage
|
|
|
|
|
--------------- ----------------- -----------------------------------------------------
|
|
|
|
|
**Cell Mode** 150 For single ``Cell`` printing or very small designs.
|
|
|
|
|
Patterns will be bigger and more readable.
|
|
|
|
|
**Design Mode** 300 For 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|noindent|
|
|
|
|
|
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|.
|
|
|
|
|
|
|
|
|
|
+---------------+-------------------+-----------------------------------------------------------+
|
|
|
|
|
| Category | Keys | Action |
|
|
|
|
|
+===============+===================+===========================================================+
|
2015-03-06 01:58:10 -06:00
|
|
|
| **Moves** | | |KeyUp|, | Shift the view in the according direction |
|
|
|
|
|
| | |KeyDown| | |
|
|
|
|
|
| | | |KeyLeft|, | |
|
|
|
|
|
| | |KeyRight| | |
|
2012-11-16 06:49:47 -06:00
|
|
|
+---------------+-------------------+-----------------------------------------------------------+
|
2015-03-06 01:58:10 -06:00
|
|
|
| **Fit** | |KeyF| | Fit to the Cell abutment box |
|
2012-11-16 06:49:47 -06:00
|
|
|
+---------------+-------------------+-----------------------------------------------------------+
|
2015-03-06 01:58:10 -06:00
|
|
|
| **Refresh** | |CTRL_L| | Triggers a complete display redraw |
|
2012-11-16 06:49:47 -06:00
|
|
|
+---------------+-------------------+-----------------------------------------------------------+
|
2015-03-06 01:58:10 -06:00
|
|
|
| **Goto** | |KeyG| | *apperture* is the minimum side of the area |
|
2012-11-16 06:49:47 -06:00
|
|
|
| | | displayed around the point to go to. It's an |
|
|
|
|
|
| | | alternative way of setting the zoom level |
|
|
|
|
|
+---------------+-------------------+-----------------------------------------------------------+
|
2015-03-06 01:58:10 -06:00
|
|
|
| **Zoom** | |KeyZ|, | Respectively zoom by a 2 factor and *unzoom* |
|
|
|
|
|
| | |KeyM| | by a 2 factor |
|
2012-11-16 06:49:47 -06:00
|
|
|
| +-------------------+-----------------------------------------------------------+
|
|
|
|
|
| | | |BigMouse| | You can perform a zoom to an area. |
|
|
|
|
|
| | | Area Zoom | Define the zoom area by *holding down the left |
|
|
|
|
|
| | | mouse button* while moving the mouse. |
|
|
|
|
|
+---------------+-------------------+-----------------------------------------------------------+
|
|
|
|
|
| **Selection** | | |BigMouse| | You can select displayed objects under an area. |
|
|
|
|
|
| | | Area Selection | Define the selection area by *holding down the |
|
|
|
|
|
| | | right mouse button* while moving the mouse. |
|
|
|
|
|
| +-------------------+-----------------------------------------------------------+
|
|
|
|
|
| | | |BigMouse| | You can toggle the selection of one object under |
|
2015-03-06 01:58:10 -06:00
|
|
|
| | | Toggle Selection| the mouse position by pressing |CTRL| and |
|
2012-11-16 06:49:47 -06:00
|
|
|
| | | 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. |
|
|
|
|
|
| +-------------------+-----------------------------------------------------------+
|
2015-03-06 01:58:10 -06:00
|
|
|
| | |KeyCapS| | Toggle the selection visibility |
|
2012-11-16 06:49:47 -06:00
|
|
|
+---------------+-------------------+-----------------------------------------------------------+
|
2015-03-06 01:58:10 -06:00
|
|
|
| **Controller**| |CTRL_I| | Show/hide the controller window. |
|
2012-11-16 06:49:47 -06:00
|
|
|
| | | |
|
|
|
|
|
| | | It's the Swiss Army Knife of the viewer. |
|
|
|
|
|
| | | From it, you can fine-control the display and |
|
|
|
|
|
| | | inspect almost everything in your design. |
|
|
|
|
|
+---------------+-------------------+-----------------------------------------------------------+
|
2015-03-06 01:58:10 -06:00
|
|
|
| **Rulers** | |KeyK|, | One stroke on |KeyK| enters the ruler mode, in |
|
|
|
|
|
| | |KeyESC| | which you can draw one ruler. You can exit the |
|
|
|
|
|
| | | ruler mode by pressing |KeyESC|. Once in ruler |
|
2012-11-16 06:49:47 -06:00
|
|
|
| | | 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. |
|
|
|
|
|
| +-------------------+-----------------------------------------------------------+
|
2015-03-06 01:58:10 -06:00
|
|
|
| | |KeyCapK| | Clears all the drawn rulers |
|
2012-11-16 06:49:47 -06:00
|
|
|
+---------------+-------------------+-----------------------------------------------------------+
|
2015-03-06 01:58:10 -06:00
|
|
|
| **Print** | |CTRL_P| | Currently rather crude. It's a direct copy of |
|
|
|
|
|
| | | what's displayed in pixels. So the resulting |
|
2012-11-16 06:49:47 -06:00
|
|
|
| | | picture will be a little blurred due to |
|
|
|
|
|
| | | anti-aliasing mechanism. |
|
|
|
|
|
+---------------+-------------------+-----------------------------------------------------------+
|
2015-03-06 01:58:10 -06:00
|
|
|
| **Open/Close**| |CTRL_O| | Opens a new design. The design name must be |
|
|
|
|
|
| | | given without path or extention. |
|
2012-11-16 06:49:47 -06:00
|
|
|
| +-------------------+-----------------------------------------------------------+
|
2015-03-06 01:58:10 -06:00
|
|
|
| | |CTRL_W| | Close the current viewer window, but do not quit |
|
|
|
|
|
| | | the application. |
|
2012-11-16 06:49:47 -06:00
|
|
|
| +-------------------+-----------------------------------------------------------+
|
2015-03-06 01:58:10 -06:00
|
|
|
| | |CTRL_Q| | `CTRL+Q` quit the application |
|
|
|
|
|
| | | (closing all windows). |
|
2012-11-16 06:49:47 -06:00
|
|
|
+---------------+-------------------+-----------------------------------------------------------+
|
2015-03-06 01:58:10 -06:00
|
|
|
| **Hierarchy** | |CTRL_Down| | Go one hierarchy level down. That is, if there |
|
|
|
|
|
| | | is an *instance* under the cursor position, load |
|
2012-11-16 06:49:47 -06:00
|
|
|
| | | it's *model* Cell in place of the current one. |
|
|
|
|
|
| +-------------------+-----------------------------------------------------------+
|
2015-03-06 01:58:10 -06:00
|
|
|
| | |CTRL_Up| | Go one hierarchy level up. if we have entered |
|
|
|
|
|
| | | the current model through |CTRL_Down| |
|
|
|
|
|
| | | reload the previous model (the one |
|
2012-11-16 06:49:47 -06:00
|
|
|
| | | 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.
|
|
|
|
|
|
|
|
|
|
+-----------------------------+------------------------------------------------+
|
|
|
|
|
| Arguments | Meaning |
|
|
|
|
|
+=============================+================================================+
|
|
|
|
|
| `-t|--text` | Instruct |cgt| to run in text mode. |
|
|
|
|
|
+-----------------------------+------------------------------------------------+
|
|
|
|
|
| `-L|--log-mode` | Disable 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-global` | Reload a global routing solution from disk. |
|
|
|
|
|
| | The file containing the solution must be named |
|
|
|
|
|
| | `<cell>.kgr`. |
|
|
|
|
|
+-----------------------------+------------------------------------------------+
|
|
|
|
|
| `--save-global` | Save 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-route` | Run the global router (|Knik|). |
|
|
|
|
|
+-----------------------------+------------------------------------------------+
|
|
|
|
|
| `-R|--detailed-route` | Run 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
|
|
|
|
|
|
|
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
Miscellaneous Settings
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
+---------------------------------------+------------------+----------------------------+
|
|
|
|
|
| Parameter Identifier | Type | Default |
|
|
|
|
|
+=======================================+==================+============================+
|
|
|
|
|
| **Verbosity/Log Parameters** |
|
|
|
|
|
+---------------------------------------+------------------+----------------------------+
|
|
|
|
|
| ``misc.info`` | TypeBool | :cb:`False` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | Enable display of *info* level message |
|
|
|
|
|
| | (:cb:`cinfo` stream) |
|
|
|
|
|
+---------------------------------------+------------------+----------------------------+
|
|
|
|
|
| ``misc.bug`` | TypeBool | :cb:`False` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | Enable 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 |
|
|
|
|
|
| | sequences |
|
|
|
|
|
+---------------------------------------+------------------+----------------------------+
|
|
|
|
|
| ``misc.verboseLevel1`` | TypeBool | :cb:`True` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | First level of verbosity, disable level 2 |
|
|
|
|
|
+---------------------------------------+------------------+----------------------------+
|
|
|
|
|
| ``misc.verboseLevel2`` | TypeBool | :cb:`False` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | Second level of verbosity |
|
|
|
|
|
+---------------------------------------+------------------+----------------------------+
|
|
|
|
|
| **Development/Debug Parameters** |
|
|
|
|
|
+---------------------------------------+------------------+----------------------------+
|
|
|
|
|
| ``misc.traceLevel`` | TypeInt | :cb:`0` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | Display trace information *below* that level |
|
|
|
|
|
| | (:cb:`ltrace` stream) |
|
|
|
|
|
+---------------------------------------+------------------+----------------------------+
|
|
|
|
|
| ``misc.catchCore`` | TypeBool | :cb:`False` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | By default, |cgt| do not dump core. |
|
|
|
|
|
| | To generate one set this flag to :cb:`True` |
|
|
|
|
|
+---------------------------------------+------------------+----------------------------+
|
|
|
|
|
|
2015-03-06 01:58:10 -06:00
|
|
|
|newpage|
|
|
|
|
|
|
|
|
|
|
|
2012-11-16 06:49:47 -06:00
|
|
|
.. _The Controller:
|
|
|
|
|
|
|
|
|
|
The Controller
|
|
|
|
|
==============
|
|
|
|
|
|
|
|
|
|
The *Controller* window is composed of seven tabs:
|
|
|
|
|
|
|
|
|
|
#. `The Look Tab`_ to select the display style.
|
|
|
|
|
#. `The Filter Tab`_ the hierarchical levels to be displayed, the look of
|
|
|
|
|
rubbers and the dimension units.
|
|
|
|
|
#. `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 current selection.
|
|
|
|
|
#. `The Settings Tab`_ access all the tool's configuration settings.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.. _The Look Tab:
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|ControllerLook_1|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.. _The Filter Tab:
|
|
|
|
|
|
|
|
|
|
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...
|
|
|
|
|
|
|
|
|
|
|ControllerFilter_1|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.. _The Layers&Go Tab:
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|ControllerLayersGos_1|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.. _The Netlist Tab:
|
|
|
|
|
|
|
|
|
|
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*.
|
|
|
|
|
|
|
|
|
|
|ControllerNetlist_1|
|
|
|
|
|
|ViewerNetlist_1|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.. _The Selection Tab:
|
|
|
|
|
|
|
|
|
|
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...
|
|
|
|
|
|
|
|
|
|
|ControllerSelection_1|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.. _The Inspector Tab:
|
|
|
|
|
|
|
|
|
|
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
|
2015-04-05 04:35:06 -05:00
|
|
|
anything, do not modify the DataBase. If any object under inspection
|
2012-11-16 06:49:47 -06:00
|
|
|
is deleted, you will crash the application...
|
|
|
|
|
|
|
|
|
|
.. note:: *Implementation Detail:* the inspector support is done with
|
|
|
|
|
``Slot``, ``Record`` and ``getString()``.
|
|
|
|
|
|
|
|
|
|
|ControllerInspector_1|
|
|
|
|
|
|ControllerInspector_2|
|
|
|
|
|
|ControllerInspector_3|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.. _The Settings Tab:
|
|
|
|
|
|
|
|
|
|
The Settings Tab
|
|
|
|
|
~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
Here comes the description of the *Settings* tab.
|
|
|
|
|
|
|
|
|
|
|ControllerSettings_1|
|
|
|
|
|
|
|
|
|
|
|
Make the Python interface closely mirroring the C++ one.
* Change: In Isobar, the Python interface was not exactly mirroring the
C++ one, now it is the case. The Python code should look likes almost
exactly like the C++ one, the only differences remaining being due
to the languages respective syntaxes. Note that in the case of
constructor functions, it leads to a slightly longer notation in
Python that it could have been (mimic the ".create()" static
member). Main modifications:
1. Mirror the static constructor syntax with create():
Cell( ... ) ==> Cell.create( ... )
2. Correct hierarchy for constants in Instance, Net, Pin
& Transformation. For example:
Hurricane.PlacementStatusFIXED
==> Hurricane.Instance.PlacementStatus.FIXED
Hurricane.OrientationID
==> Hurricane.Transformation.Orientation.ID
Hurricane.TypeLOGICAL ==> Hurricane.Net.Type.LOGICAL
Hurricane.DirectionIN ==> Hurricane.Net.Direction.IN
* Change: In CRL Core, correction to match the improved Python API
in the configutation helpers.
* Change: In Cumulus, correction to match the improved Python API.
* Change: In Stratus, correction to match the improved Python API.
* Change: In Documenation, update for the new Python interface
(both user's guide & examples).
* Note: We must port those changes into Chams for it to continue
to run.
* Change: In Documenation, update the Python script support part.
2014-06-28 10:37:59 -05:00
|
|
|
.. _Python Interface to Coriolis:
|
|
|
|
|
|
|
|
|
|
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 <file:../../../index.html>`_
|
|
|
|
|
|
|
|
|
|
A script could be run directly in text mode from the command line or through
|
|
|
|
|
the graphical interface (see `Python Scripts in Cgt`_).
|
|
|
|
|
|
2015-04-05 04:35:06 -05:00
|
|
|
Asides for this requirement, the python script can contain anything valid
|
Make the Python interface closely mirroring the C++ one.
* Change: In Isobar, the Python interface was not exactly mirroring the
C++ one, now it is the case. The Python code should look likes almost
exactly like the C++ one, the only differences remaining being due
to the languages respective syntaxes. Note that in the case of
constructor functions, it leads to a slightly longer notation in
Python that it could have been (mimic the ".create()" static
member). Main modifications:
1. Mirror the static constructor syntax with create():
Cell( ... ) ==> Cell.create( ... )
2. Correct hierarchy for constants in Instance, Net, Pin
& Transformation. For example:
Hurricane.PlacementStatusFIXED
==> Hurricane.Instance.PlacementStatus.FIXED
Hurricane.OrientationID
==> Hurricane.Transformation.Orientation.ID
Hurricane.TypeLOGICAL ==> Hurricane.Net.Type.LOGICAL
Hurricane.DirectionIN ==> Hurricane.Net.Direction.IN
* Change: In CRL Core, correction to match the improved Python API
in the configutation helpers.
* Change: In Cumulus, correction to match the improved Python API.
* Change: In Stratus, correction to match the improved Python API.
* Change: In Documenation, update for the new Python interface
(both user's guide & examples).
* Note: We must port those changes into Chams for it to continue
to run.
* Change: In Documenation, update the Python script support part.
2014-06-28 10:37:59 -05:00
|
|
|
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
|
|
|
|
|
|
2015-02-27 11:16:03 -06:00
|
|
|
def ScriptMain ( **kw ):
|
|
|
|
|
editor = None
|
|
|
|
|
if kw.has_key('editor') and kw['editor']:
|
|
|
|
|
editor = kw['editor']
|
|
|
|
|
stratus.setEditor( editor )
|
Make the Python interface closely mirroring the C++ one.
* Change: In Isobar, the Python interface was not exactly mirroring the
C++ one, now it is the case. The Python code should look likes almost
exactly like the C++ one, the only differences remaining being due
to the languages respective syntaxes. Note that in the case of
constructor functions, it leads to a slightly longer notation in
Python that it could have been (mimic the ".create()" static
member). Main modifications:
1. Mirror the static constructor syntax with create():
Cell( ... ) ==> Cell.create( ... )
2. Correct hierarchy for constants in Instance, Net, Pin
& Transformation. For example:
Hurricane.PlacementStatusFIXED
==> Hurricane.Instance.PlacementStatus.FIXED
Hurricane.OrientationID
==> Hurricane.Transformation.Orientation.ID
Hurricane.TypeLOGICAL ==> Hurricane.Net.Type.LOGICAL
Hurricane.DirectionIN ==> Hurricane.Net.Direction.IN
* Change: In CRL Core, correction to match the improved Python API
in the configutation helpers.
* Change: In Cumulus, correction to match the improved Python API.
* Change: In Stratus, correction to match the improved Python API.
* Change: In Documenation, update for the new Python interface
(both user's guide & examples).
* Note: We must port those changes into Chams for it to continue
to run.
* Change: In Documenation, update the Python script support part.
2014-06-28 10:37:59 -05:00
|
|
|
|
|
|
|
|
doSomething()
|
|
|
|
|
return
|
|
|
|
|
|
|
|
|
|
if __name__ == "__main__" :
|
2015-02-27 11:16:03 -06:00
|
|
|
kw = {}
|
|
|
|
|
success = ScriptMain( **kw )
|
|
|
|
|
shellSuccess = 0
|
|
|
|
|
if not success: shellSuccess = 1
|
|
|
|
|
|
|
|
|
|
sys.exit( shellSuccess )
|
|
|
|
|
ScriptMain ()
|
Make the Python interface closely mirroring the C++ one.
* Change: In Isobar, the Python interface was not exactly mirroring the
C++ one, now it is the case. The Python code should look likes almost
exactly like the C++ one, the only differences remaining being due
to the languages respective syntaxes. Note that in the case of
constructor functions, it leads to a slightly longer notation in
Python that it could have been (mimic the ".create()" static
member). Main modifications:
1. Mirror the static constructor syntax with create():
Cell( ... ) ==> Cell.create( ... )
2. Correct hierarchy for constants in Instance, Net, Pin
& Transformation. For example:
Hurricane.PlacementStatusFIXED
==> Hurricane.Instance.PlacementStatus.FIXED
Hurricane.OrientationID
==> Hurricane.Transformation.Orientation.ID
Hurricane.TypeLOGICAL ==> Hurricane.Net.Type.LOGICAL
Hurricane.DirectionIN ==> Hurricane.Net.Direction.IN
* Change: In CRL Core, correction to match the improved Python API
in the configutation helpers.
* Change: In Cumulus, correction to match the improved Python API.
* Change: In Stratus, correction to match the improved Python API.
* Change: In Documenation, update for the new Python interface
(both user's guide & examples).
* Note: We must port those changes into Chams for it to continue
to run.
* Change: In Documenation, update the Python script support part.
2014-06-28 10:37:59 -05:00
|
|
|
|
2015-02-27 11:16:03 -06:00
|
|
|
This typical script can be executed in two ways:
|
|
|
|
|
|
|
|
|
|
#. 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 :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.
|
|
|
|
|
|
|
|
|
|
+----------------------+-----------------------------------------------+
|
|
|
|
|
| \*\*kw Dictionnary |
|
|
|
|
|
+----------------------+-----------------------------------------------+
|
|
|
|
|
| Parameter Key/Name | Contents 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|. |
|
|
|
|
|
+----------------------+-----------------------------------------------+
|
Make the Python interface closely mirroring the C++ one.
* Change: In Isobar, the Python interface was not exactly mirroring the
C++ one, now it is the case. The Python code should look likes almost
exactly like the C++ one, the only differences remaining being due
to the languages respective syntaxes. Note that in the case of
constructor functions, it leads to a slightly longer notation in
Python that it could have been (mimic the ".create()" static
member). Main modifications:
1. Mirror the static constructor syntax with create():
Cell( ... ) ==> Cell.create( ... )
2. Correct hierarchy for constants in Instance, Net, Pin
& Transformation. For example:
Hurricane.PlacementStatusFIXED
==> Hurricane.Instance.PlacementStatus.FIXED
Hurricane.OrientationID
==> Hurricane.Transformation.Orientation.ID
Hurricane.TypeLOGICAL ==> Hurricane.Net.Type.LOGICAL
Hurricane.DirectionIN ==> Hurricane.Net.Direction.IN
* Change: In CRL Core, correction to match the improved Python API
in the configutation helpers.
* Change: In Cumulus, correction to match the improved Python API.
* Change: In Stratus, correction to match the improved Python API.
* Change: In Documenation, update for the new Python interface
(both user's guide & examples).
* Note: We must port those changes into Chams for it to continue
to run.
* Change: In Documenation, update the Python script support part.
2014-06-28 10:37:59 -05:00
|
|
|
|
|
|
|
|
|
2015-03-06 01:58:10 -06:00
|
|
|
Plugins
|
|
|
|
|
=======
|
|
|
|
|
|
|
|
|
|
Plugins are |Python| scripts specially crafted to integrate with |cgt|.
|
|
|
|
|
Their entry point is a :cb:`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.
|
|
|
|
|
|
|
|
|
|
|ChipStructure-1|
|
|
|
|
|
|
|
|
|
|
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/Name | Value/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 Identifier | Type | Default |
|
|
|
|
|
+===================================+==================+============================+
|
|
|
|
|
| **Chip Plugin Parameters** |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
|``chip.block.rails.count`` | TypeInt | :cb:`5` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | 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.hWidth`` | TypeInt | :cb:`12` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | The horizontal with of the rails |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
|``chip.block.rails.vWidth`` | TypeInt | :cb:`12` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | The vertical with of the rails |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
|``chip.block.rails.hSpacing`` | TypeInt | :cb:`6` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | The spacing, *edge to edge* of two adjacent |
|
|
|
|
|
| | horizontal rails |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
|``chip.block.rails.vSpacing`` | TypeInt | :cb:`6` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | The spacing, *edge to edge* of two adjacent |
|
|
|
|
|
| | vertical rails |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
|``chip.pad.pck`` | TypeString | :cb:`pck_px` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | The model name of the pad connected to the |
|
|
|
|
|
| | chip external clock |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
|``chip.pad.pvddeck`` | TypeString | :cb:`pvddeck_px` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | The model name of the pad connected to the |
|
|
|
|
|
| | ``vdde`` (external power) and suppling it to |
|
|
|
|
|
| | the core |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
|``chip.pad.pvsseck`` | TypeString | :cb:`pvsseck_px` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | The model name of the pad connected to the |
|
|
|
|
|
| | ``vsse`` (external ground) and suppling it to |
|
|
|
|
|
| | the core |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
|``chip.pad.pvddick`` | TypeString | :cb:`pvddick_px` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | The model name of the pad connected to the |
|
|
|
|
|
| | ``vddi`` (internal power) and suppling it to |
|
|
|
|
|
| | the core |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
|``chip.pad.pvssick`` | TypeString | :cb:`pvssick_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:
|
|
|
|
|
|
|
|
|
|
#. ``_bl``: bottom left plane quarter.
|
|
|
|
|
#. ``_br``: bottom right plane quarter.
|
|
|
|
|
#. ``_tl``: top left plane quarter.
|
|
|
|
|
#. ``_tr``: top right plane quarter.
|
|
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
|
|
#. Build the clock tree: creates the top-block abutment box, compute the
|
|
|
|
|
levels of H tree neededs and place the clock buffers.
|
|
|
|
|
#. Once the clock buffers are placed, calls the placer (|etesian|) to place
|
|
|
|
|
the ordinary standart cells, whithout disturbing clock H-tree buffers.
|
|
|
|
|
#. At this point we know the exact positions of all the DFFs, so we can
|
|
|
|
|
connect them to the nearest H-tree leaf clock signal.
|
|
|
|
|
#. Leaf clock signals that are not connecteds to any DFFs are removed.
|
|
|
|
|
|
|
|
|
|
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 Identifier | Type | Default |
|
|
|
|
|
+===================================+==================+============================+
|
|
|
|
|
| **ClockTree Plugin Parameters** |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
|``clockTree.minimumSide`` | TypeInt | :cb:`300` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | The minimum size below which the clock tree |
|
|
|
|
|
| | will stop to perform quadri-partitions |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
|``clockTree.buffer`` | TypeString | :cb:`buf_x2` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | The buffer model to use to drive sub-nets |
|
|
|
|
|
+-----------------------------------+------------------+----------------------------+
|
|
|
|
|
|``clockTree.placerEngine`` | TypeString | :cb:`Etesian` |
|
|
|
|
|
| +------------------+----------------------------+
|
|
|
|
|
| | 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.
|
|
|
|
|
|
|
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
A Simple Example: AM2901
|
|
|
|
|
========================
|
2012-11-16 06:49:47 -06:00
|
|
|
|
2014-03-10 08:06:31 -05:00
|
|
|
To illustrate the capabilities of |Coriolis| tools and |Python| scripting, a small
|
|
|
|
|
example, derived from the |Alliance| :cb:`AM2901` is supplied.
|
2012-11-16 06:49:47 -06:00
|
|
|
|
2015-03-06 01:58:10 -06:00
|
|
|
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:
|
|
|
|
|
|
|
|
|
|
#. **Command line mode:** directly run the script: ::
|
|
|
|
|
|
|
|
|
|
dummy@lepka:AM2901$ ./doChip -V --cell=amd2901
|
|
|
|
|
|
|
|
|
|
#. **Graphic mode:** launch |cgt|, load chip netlist ``amd2901`` (the top cell)
|
|
|
|
|
then run the |Python| script :cb:`doChip.py`.
|
|
|
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
Between two consecutive run, be sure to erase the netlist/layout generateds: ::
|
|
|
|
|
|
|
|
|
|
dummy@lepka:AM2901$ rm *_clocked*.vst *.ap
|
