cd60032d9c
The decoupling of the cell gauge and the routing gauge implies that
the METAL2 & METAL3 terminals of macro blocks cannot be aligned on
the routing tracks anymore. That is, an horizontal METAL2 terminal
will not be on a track axis, but offgrid, so we no longer can use
a METAL2 horizontal segment to connect to it. Making an adjustement
between the offgrid terminal and the on-grid segment has proven
too complex and generating difficult configuration for the router.
Moreover, METLA2 terminal could be fully inside a METAL2 blockage.
So now, when the gauges are decoupled, we connect the METAL2 and
METAL3 the same way we do for METAL1: *from above* in the perpandicular
direction and using a *sliding* VIA. We assume that those kind of
terminals in upper metals are quite long.
* New: In Hurricane::Rectilinear, export the isNonRectangle() method
to the Python interface.
* New: In CRL::RoutingGauge, add function isSuperPitched() with the
associated boolean attribute. Set to true when each pitch of
each layer is independant (not low fractional multiples).
* New: In AnabaticEngine, add the ability to temporarily disable the
canonize() operation (mainly used in dogleg creation).
* New: In AutoSegment::canonize(), do nothing if the operation is
disabled by AnabaticEngine.
* Bug: In Session::_revalidateTopology(), disable the canonization
during the topology updating of a net. Too early canonization
was occuring in makeDogleg() leading to incoherencies when
performing the later canonization stage over the complete net.
Mostly occured in the initial build stage of the net.
* New: In GCell, add function postGlobalAnnotate(), if a layer
is fully blocked (above 0.9), typically, under a blockage,
add a further capacity decrease of 2 on the edges. So we may
handle a modicum of doglegs.
* Bug; In GCell::addBlockage(), removeContact(), removeHSegment()
and removeVSegment(), forgot to set the Invalidated flag.
This may have lead to innacurate densities.
* Change: In GCell::updateDensity(), more complex setting of the
GoStraight flag. This flag is now set if we don't have two
*contiguous* below 60% of density. We need free contiguous
layers to make doglegs.
* New: In NetBuilder, now manage a current state flag along
with the state flag of the *source* GCell. This flag is used
to tell if the GCell needs it's *global* routing to be done
using the upper layers (METAL4 & METAL5) instead of the
lower ones.
* New: In NetBuilder::setStartHook(), set the state flag of the
GCell to ToUpperRouting when processing a global routing
articulation and one of the base layer is obstructed
above 0.9.
In GCell with terminals, also set ToUpperRouting when there
are some in METAL2 / METAL3 and the gauge is not super-pitched.
* New: In NetBuilder, function isInsideBlockage(), to check if a
terminal is completely or partially enclosed in a blockage.
* Change: In NetBuilderHV::doRp_AutoContact(), remove support for
trying to put on grid misaligned METAL2/METAL3.
Instead systematically access them from above.
Do not cover with fixed protection terminals that are already
enclosed in blockages.
* Bug: In NetBuilderHV::doRp_AutoContact(), always add the terminal
contact in the requested GCell and not the target/source one,
in case the terminal span several GCells.
* Change: In NetBuilderHV::doRp_Access(), create the local wiring
according to the RoutingPad layer.
* Change: In NetBuilderHV::_do_xG(), _do_2G(),
create the global wiring in upper layers, according to the
ToUpperRouting flag.
* Change: In NetBuilderHV::_do_xG_xM3(), now delegate to
_do_xG_xM3_baseRouting() and _do_xG_xM3_upperRouting() if the
density at terminal level is above 0.5.
* New: NetBuilderHV::_do_xG_xM3_baseRouting() and
_do_xG_xM3_upperRouting() separated function to manage the
local routing.
* Change: In NetBuilder::_do_globalSegment(), if the currently
processed GCell or it's source is in ToUpperRouting mode,
move up the global segment. Do *not* use the moveUp() function
which would create doglegs unwanted at this stage.
* New: In KatanaEngine::annotateGlobalGraph(), call postGlobalAnnotate()
on the GCell after the blockages have been taken into accound to
add the penalty.
* Bug: In Track::getPrevious(), correctly manage the 0 value for the
index argument. Strange it didn't show earlier.
Same goes for Track::expandFreeInterval().
|
||
|---|---|---|
| anabatic | ||
| bootstrap | ||
| bora | ||
| coloquinte | ||
| crlcore | ||
| cumulus | ||
| documentation | ||
| equinox | ||
| etesian | ||
| flute | ||
| hurricane | ||
| ispd | ||
| karakaze | ||
| katabatic | ||
| katana | ||
| kite | ||
| knik | ||
| lefdef | ||
| mauka | ||
| metis | ||
| nimbus | ||
| nix | ||
| oroshi | ||
| solstice | ||
| stratus1 | ||
| tutorial | ||
| unicorn | ||
| unittests | ||
| vlsisapd | ||
| .gitignore | ||
| COPYRIGHT.rst | ||
| LICENSE.rst | ||
| Makefile | ||
| README.rst | ||
| SUPPORT.rst | ||
| compat.nix | ||
| default.nix | ||
| flake.lock | ||
| flake.nix | ||
| shell.nix | ||
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 3.
* 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://gitlab.lip6.fr/vlsi-eda/coriolis.git
ego@home:src$ cd coriolis
Then, build the tool: ::
ego@home:coriolis$ make install
If you encounter issues, please consult SUPPORT.rst for tips.
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