48f3a2bc3c
* Bug: In Hurricane, in StaticObservable::getObserver(), if the slot
pointer is NULL, do not try to access the owner. Returns NULL, so
the caller can be aware of the situation...
* Change: In Hurricane, in BreakpointWidget & ExceptionWidget some
cosmetic changes (fonts and window sizes).
* Bug: In Anabatic, In AutoHorizontal::getConstraints(), take into account
the constraints from the source AutoContact, as it holds the constraints
transmitted by the RoutingPads and sets up by propageConstraintsFromRp().
It is likely to be a bug affecting the original Katabatic as well.
* Change: In Anabatic, in RawGCellsUnder(), check that the segment is not
completly oustside the cell abutment box and truncate the coordinates
to the part that is inside. Use the "shrink" if we reach the east/north
border.
* Change: In Anabatic, in Configuration, no more decorator because we will
use a true derived relationship. Katana *derives* from *Anabatic* and do
not *decorate* it, so the Configuration can do the same. It also implies
that we directly create a Katana engine, not an Anabatic one.
* Change: In Anabatic, in Session, do not allow the opening of the Session
in a standalone fashion (with a static method). Instead it must be opened
using the relevant method of the Anabatic/Katana engine. This ensure we
are opening the right Session type.
* Change: In Anabatic, in AutoSegment_Aligneds() collection the seed segment
is not part of the collection by default, but will be included if the
Flags::WithSelf is set.
* Change: In Configuration, all the flags value are now defined in two steps.
Declared in the header and initialized in the module. This is to prevent
the fact that on some cases, in relation with the Python "extern C" part
modules, we need a true allocated variable. It was causing weird linking
problems.
A side effect is that they can no longer be used as entry is switches,
have to replace them by if/else.
* New: In Anabatic, new GCell::getNeighborAt() utility function.
* Bug: In Anabatic, in GCell::doGrid(), tag all the GCells of the grid with
the grid type... Back annote all the edges capacity (north & east) with
the reserved local capacity.
* New: Complete portage of Kite over Anabatic. The new engine is christened
"Katana" for Kite-Analogic. When it's capabilities and performances
will be on a part with Kite, it is to completly replace it (and take
back the "Kite" name). Preliminary tests seems to show that, contrary
to intuition (because built on a more complex/slower grid), it is even
slightly faster than Kite 8-).
|
||
|---|---|---|
| anabatic | ||
| bootstrap | ||
| coloquinte | ||
| crlcore | ||
| cumulus | ||
| documentation | ||
| equinox | ||
| etesian | ||
| hurricane | ||
| ispd | ||
| katabatic | ||
| katana | ||
| kite | ||
| knik | ||
| mauka | ||
| metis | ||
| nimbus | ||
| solstice | ||
| stratus1 | ||
| unicorn | ||
| vlsisapd | ||
| .dir-locals.el | ||
| .gitignore | ||
| .projectile | ||
| Makefile | ||
| README.rst | ||
README.rst
.. -*- Mode: rst -*-
===============
Coriolis README
===============
Coriolis is a free database, placement tool and routing tool for VLSI designs.
Purpose
=======
Coriolis provides several tools to perform the layout of VLSI circuits. Its
main components are the Hurricane database, the Etesian placer and the Kite
router, but other tools can use the Hurricane database and the parsers
provided.
The user interface <cgt> is the prefered way to use Coriolis, but all
Coriolis tools are Python modules and thus scriptables.
Documentation
=============
The complete documentation is available here, both in pdf & html:
./documentation/UsersGuide/UsersGuide.html
./documentation/UsersGuide/UsersGuide.pdf
The documentation of the latest *stable* version is also
available online. It may be quite outdated from the *devel*
version.
https://soc-extras.lip6.fr/en/coriolis/coriolis2-users-guide/
Building Coriolis
=================
To build Coriolis, ensure the following prerequisites are met:
* Python 2.7.
* cmake.
* boost.
* bison & flex.
* Qt 4 or 5.
* libxml2.
* RapidJSON
* A C++11 compliant compiler.
The build system relies on a fixed directory tree from the root
of the user currently building it. Thus first step is to get a clone of
the repository in the right place. Proceed as follow: ::
ego@home:~$ mkdir -p ~/coriolis-2.x/src/support
ego@home:~$ cd ~/coriolis-2.x/src/support
ego@home:~$ git clone http://github.com/miloyip/rapidjson
ego@home:~$ git checkout ec322005072076ef53984462fb4a1075c27c7dfd
ego@home:~$ cd ~/coriolis-2.x/src
ego@home:src$ git clone https://www-soc.lip6.fr/git/coriolis.git
ego@home:src$ cd coriolis
If you want to use the *devel* branch: ::
ego@home:coriolis$ git checkout devel
Then, build the tool: ::
ego@home:coriolis$ make install
Coriolis gets installed at the root of the following tree: ::
~/coriolis-2.x/<OS>.<DISTRIB>/Release.Shared/install/
Where ``<OS>`` is the name of your operating system and ``<DISTRIB>`` your
distribution.
Using Coriolis
==============
The Coriolis main interface can be launched with the command: ::
ego@home:~: ~/coriolis-2.x/<OS>.<DISTRIB>/Release.Shared/install/bin/coriolis
The ``coriolis`` script is tasked to guess it's location and setup appropriatly
the UNIX environment, then lauch ``cgt`` (or *any* command, with the
``--run=<COMMAND>`` option).
Conversely, you can setup the current shell environement for Coriolis by
using the helper ``coriolisEnv.py``, then run any Coriolis tool: ::
ego@home:~$ eval `~/coriolis-2.x/src/coriolis/bootstrap/coriolisEnv.py`
ego@home:~$ cgt -V