ed557d9027
* Change: In Knik, in Vertex, add a "blocked" flag to signal disabled
vertexes in the grid (must not be used by the global router).
Modificate the Graph::getVertex() method so that when a vertex
is geometrically queried, if is a blocked one, return a non-blocked
neighbor. This mechanism is introduced to, at last, prevent the
global router to go *under* the pad in case of a commplete chip.
* New: In Katabatic, in AutoSegment, a new state has been added: "reduced".
A reduced segment is in the same layer as it's perpandiculars.
To be reduced, a segments has to be connected on source & target to
AutoContactTurn, both of the perpandiculars must be of the same layer
(below or above) and it's length must not exceed one pitch in the
perpandicular direction.
To reduce an AutoSegment, call ::reduce() and to revert the state,
call ::raise(). Two associated predicates are associated:
::canReduce() and ::mustRaise().
Note: No two adjacent segments can be reduced at the same time.
* Bug: In Katabatic, in GCellTopology, add a new method ::doRp_AccessPad()
to connect to the pads. Create wiring, fixed and non managed by
Katabatic, to connect the pad connector layer to the lowest routing
layers (depth 1 & 2). The former implementation was sometimes leading
to gaps (sheared contact) that *must not* occurs during the building
stage.
Remark: This bug did put under the light the fact that the initial
wiring must be created without gaps. Gaps are closed by making doglegs
on contacts. But this mechanism could only work when the database if
fully initialised (the cache is up to date). Otherwise various problems
arise, in the canonization process for example.
* New: In Katabatic, in AutoContactTerminal::getNativeConstraintBox(),
when anchored on a RoutingPad, now take account the potential rotation
of the Path's transformation. Here again, for the chip's pads.
* New: In Kite, support for reduced AutoSegment. TrackSegment associateds
to reduced AutoSegment are *not* inserted into track to become
effectively invisibles. When a segment becomes reduced, a TrackEvent
is generated to remove it. Conversely when it is raised a RoutingEvent
is created/rescheduled to insert it. All this is mostly managed inside
the Session::revalidate() method.
* New: In Kite, in KiteEngine::createGlobalGraph(), in case of a chip,
mark all global routing vertexes (Knik) that are under a pad, as blockeds.
* Bug: In Cumulus, in PadsCorona.Side.getAxis(), inversion between X and
Y coordinate of the chip size. Did not show until a non-square chip
was routed (i.e. our MIPS R3000).
* Change: In Stratus1, in st_placement.py add the ClockBuffer class for
backward compatibility with the MIPS32 bench. Have to review this
functionnality coming from the deprecated placeAndroute.py.
In st_instance.py, no longer creates the Plug ring of a Net.
In my opinion it just clutter the display until the P&R is called.
Can re-enable later as an option (in Unicorn).
* Change: In Unicorn, in cgt.py, more reliable way of loading then running
user supplied scripts. Borrowed from alliance-checker-toolkit doChip.py .
|
||
|---|---|---|
| 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