dfe4d80b60
In the Cell/Instance hierarchy, the "terminal" and "leaf cell" concepts
where not clearly defined and partially overlapping. Now, "Terminal" is
the refer to the physical hierarchy (layout) and "TerminalNetlist" to
the logical hierarchy (netlist). The logical hierarchy can be less deep
than the physical one thanks to a Cell dedicated cell flags. Collections
related to the physical hierarchy keep their old names, the one related
to the logical hierarchy are renamed from "Leaf" to "TerminalNetlist".
The name "Leaf" was too ambiguous (leaf for *what* hierarchy).
* Change: In Hurricane::Device, set the "TerminalNetlist" flag once and
for all. No need set it in all the derived classes again.
* New: In Hurricane::MultiCapacitor, added new parameter "dummy" to
create dummies around the capacity matrix.
* Change: In Hurricane::Cell, remove "Leaf" related methods, replace
them by "TerminalNetlist" one, especially Collections. Now we have
two clear sets of Collections to walkthough the layout or the
netlist.
Change the "Terminal" flag into "TerminalNetlist".
* Change: In Hurricane::CellCollections, rename "Leaf" into
"TerminalNetlist" collections and apply the new semantic to the
locators.
* Change: In Hurricane::DataBase, Leaf to TerminalInstance renaming.
* Change: In Hurricane::DeepNet, Leaf to TerminalInstance renaming.
* Change: In Hurricane::HyperNet, Leaf to TerminalInstance renaming.
* Change: In Hurricane::Instance, Leaf to TerminalInstance renaming.
* Change: In Hurricane::Viewer::HierarchyInformations, Leaf to
TerminalInstance renaming.
* Change: In CRL::AllianceFramework, Leaf to TerminalInstance renaming.
* Change: In CRL::Catalog, Leaf to TerminalInstance renaming.
* Change: In CRL::ApParser, Leaf to TerminalInstance renaming.
* Change: In EtesianEngine::AddFeeds, Leaf to TerminalInstance renaming.
* Bug: In EtesianEngine::resetPlacement, move there the loop over
non terminal netlist instances to flag fully placed sub-blocks
as terminal for the netlist. Only then remove the feed cells
from unplaced instances. Previously, the feed cells where stripped
even from already placed instances.
* Change: In Katana, Leaf to TerminalInstance renaming.
* Bug: In Bora::PyDSlicingNode, allow the range parameter to be the
Python None object when we do not want to pass one but need to
have it as positional parameter.
* Change: In Cumulus/clocktree/ClockTree.py, Leaf to TerminalInstance
renaming.
|
||
|---|---|---|
| anabatic | ||
| bootstrap | ||
| bora | ||
| coloquinte | ||
| crlcore | ||
| cumulus | ||
| documentation | ||
| equinox | ||
| etesian | ||
| flute | ||
| hurricane | ||
| ispd | ||
| karakaze | ||
| katabatic | ||
| katana | ||
| kite | ||
| knik | ||
| lefdef | ||
| mauka | ||
| metis | ||
| nimbus | ||
| oroshi | ||
| solstice | ||
| stratus1 | ||
| tutorial | ||
| unicorn | ||
| unittests | ||
| vlsisapd | ||
| .gitignore | ||
| Makefile | ||
| README.rst | ||
README.rst
.. -*- Mode: rst -*-
===============
Coriolis README
===============
Coriolis is a free database, placement tool and routing tool for VLSI design.
Purpose
=======
Coriolis provides several tools to perform the layout of VLSI circuits. Its
main components are the Hurricane database, the Etesian placer and the Katana
router, but other tools can use the Hurricane database and the parsers
provided.
The user interface <cgt> is the prefered way to use Coriolis, but all
Coriolis tools are Python modules and thus scriptable.
Documentation
=============
The complete documentation is available here, both in pdf & html:
./documentation/output/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://www-soc.lip6.fr/sesi-docs/coriolis2-docs/coriolis2/en/latex/users-guide/UsersGuide.pdf
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 detects its location and setups the UNIX
environment appropriately, then lauches ``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