3fb746fbef
* Change: In Hurricane::Error constructors disable the backtrace generation.
(*very* slow).
* Change: In Hurricane::Library::getHierarchicalname(), more compact
naming. Remove the name of the root library.
* New: In Hurricane::Net, new type "FUSED", for component with no net.
More efficient than having one net for each.
* Change: In CellViewer, BreakpointWidget, use Angry Birds icons.
* Change: In CellWidget::State, use the hierarchical name (cached) as key
to the state. This allow to load two cells with the same name but from
different libraries in the widget history.
* Change: In PyGraphics, export "isEnabled()" and "isHighDpi()" functions.
* Change: In CRL/etc/symbolic/cmos/plugin.conf, and
CRL/etc/common/plugin.conf use the physical dimensions converters.
* Change: In CRL/etc/symbolic/cmos/technology.conf, make the GDS layer
table coherent with the default Alliance cmos.rds.
* New: CRL/python/helpers/io.py, put ErrorMessage new implementation here,
along with a new ErrorWidget written in PyQt4. It seems finally that
PyQt4 can be used alongside Coriolis Qt widgets.
New ErrorMessage.catch() static function to manage all exceptions
in except clauses.
* Change: In CRL/python/helpers/, no longer use ErrorMessage.wrapPrint(),
directly print it.
Rewrite the utilities to display Python stack traces "textStacktrace()"
and "showStacktrace()".
* Change: In CRL::AllianceFramework, shorten the names of the libraries.
* Change: In CRL::ApParser & CRL::ApDriver, more accurate translation between
Alliance connectors (C record) and Hurricane::Pin objects. Pin are no
longer made square but thin and oriented in the connecting direction.
Use the new fused net for unnamed components.
* New: In CRL::GdsParser, implementation of SREF parsing, i.e. instances.
Due to the unordered nature of the GDS stream, instances creation are
delayed until the whole stream has been parsed and only then are they
created.
For the sake of reading back Alliance s2r GDS, we assume that any
TEXT following a boundary is the Net name the boundary (component)
belongs to.
Create abutment box for Cells, computed from the bounding box, so
the Hurricane QuadTree could work properly.
Make use of the fused net for unnamed components.
* New: In Cumulus/plugins/chip, complete rewrite of the I/O pad management.
Now we can mix real (foundry) pads and a symbolic core.
To cleanly support the de-coupling between the real part and the
symbolic one we introduce a new intermediary hierarchical level, the
corona. We have now:
Chip --> Pads + Corona --> Core.
At chip level (and if we are using real pads) the layout is fully
real (excepting the corona).
The Corona contains everything that is symbolic. It has symbolic
wires extending outward the abutment box to make contact with the
real wires coming from the pads.
In the pad ring we can use corners instances (or not), pad spacers
or directly draw wires between connectors ring pads.
Provide two flavors: placement only or full place & route.
WARNING: If routing in a second step, *do not route* the *Chip* but
the *Corona*.
* Change: In Cumulus/plugins/clocktree, give the modified Cell an
additional extension of "_cts" (Clock Tree Synthesis) instead of
"_clocked", to follow the common convention.
* New: In cumulus/plugins/S2R.py, encapsulate call to Alliance S2R and
reload the translated Cell in the editor.
* New: In cumulus/plugins/core2chip, provide an utility to automatically
create a chip from a core. To work this plugins must have a basic
understanding of the pad functionalities which may differs from
foundry to foundry. So a base class CoreToChip is created, then for
each supported pad foundry a derived class is added. Currently we
support AMS c35b4 and Alliance symbolic cmos.
* Bug: In Anabatic::Configuration, read the right configuration parameter
"anabatic.topRoutinglayer" (Katana), and not the one for Katabatic...
* Change: In Unicorn/cgt.py, process the plugins in alphabetical order
to ensure a reproductible ordering of the menus...
|
||
|---|---|---|
| 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 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/_build/html/index.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