f537a10d45
* New: In Hurricane, added first support for DataBase native import/export
using JSON.
We choose RapidJSON, in SAX mode, to manage the JSON format low level
Read/Write. Thus, it's Git repository http://github.com/miloyip/rapidjson
must be added under ~/coriolis-2.x/src and manually build and installed
in the Coriolis installation tree (to be integrated in ccb later).
Two mode are being supported:
1. Cell mode: one Cell only is saved. In that mode, Entities
referred by Occurrences are "outside" the file. They are coded
through their "signature" (mostly, all the values of their
attributes). The ids saved in the file cannot be restored
identically as we cannot predict when and in which context the
Cell will be reloaded.
2. Design Blob mode: the whole design hierarchy, down and including
the standard cells is saved. This way the design is completly
self contained and Entities ared referred through their ids.
A design blob can only be loaded immediatly after starting cgt
as the DataBase *must* be empty. This way we restore the whole
design hierarchy with *exactly* the same ids.
Now, Hurricane object should provide a "toJson()" method for driving
JSON, and be associated with a JsonObject derived class for parsing.
* New: In Hurricane, ability to force the next id that will be used for a
DBo (used by Design Blob Mode).
* New: In Hurricane, in DataBase, added getCell() and getLibrary() functions
to allow the hierarchical access of a Cell/Library in native mode
(i.e. whithout the requirement of AllianceFramework).
* New: In Hurricane, In CellViewer, added menu entry for Save/Load of
JSON Design Blobs. Added at this level because we consider it as the
"native" format of Hurricane.
* New: In Unicorn, added support of import/export of JSON Cell.
* Bug: In Hurricane, in Instance, when cloning an Instance or uniquifying
it's master Cell, we forgot about the Occurrences (through shared pathes).
When an instance is cloned the Shared pathes still points toward the
original Instance. And when it's the master Cell that is uniquifyed
it's the Entities pointed to that remains in the original Cell.
This is a software design problem. It is difficult to define what
policy to adopt when uniquifying: basically that means that one
Occurence is either moved onto the clone or duplicated. Furthermore,
it is not trivial to known what Occurrence is pointing on the
uniquifyed/cloned item. Have to think about it a little more.
* Bug: In Etesian, in EtesianEngine, build the flattened nets and their
RoutingPads *after* uniquifying (through slaving bounding boxes).
This way we avoid the Occurrences problem described above.
* Bug: In Etesian, in EtesianEngine, invalidate the RoutingPad after
processing the placement so they are put into the right quadtree.
This problem is due to the fact that the RoutingPads do not belong
to the Instance that they refer. And when this instance is moved
around, she doesn't inform the RoutingPad that is has moved.
More software architecture design to review...
|
||
|---|---|---|
| bootstrap | ||
| coloquinte | ||
| crlcore | ||
| cumulus | ||
| documentation | ||
| equinox | ||
| etesian | ||
| hurricane | ||
| ispd | ||
| katabatic | ||
| 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.
* A C++11 compliant compiler.
The build system relies on a fixed directory tree from the root
of the user currently building it. Thus first step is to get a clone of
the repository in the right place. Proceed as follow: ::
ego@home:~$ mkdir -p ~/coriolis-2.x/src
ego@home:~$ cd ~/coriolis-2.x/src
ego@home:src$ git clone https://www-soc.lip6.fr/git/coriolis.git
ego@home:src$ cd coriolis
If you want to use the *devel* branch: ::
ego@home:coriolis$ git checkout devel
Then, build the tool: ::
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