// -*- C++ -*-
namespace Kite {
/*! \mainpage Detailed Router Documentation
*
* This documentation adresses two level of explanations :
*
*
* - The \b API description which explains how to use Kite,
* thoses parts as flagged as \b API.
*
- The internal description which details how Kite do
* things. It's mostly intended for myself to help me not to
* forget how I've done things when debug time will come...
* It may also be valuable to people who may want to use
* or patch Kite for their own purpose (my secret hope).
*
*
* Additionnal documents:
* - \ref grpSynthHierarchy
*
* \defgroup grpSynthHierarchy Synthetic Hierarchy (API)
* \brief Simplificated class hierarchy
*
* \htmlinclude customHierarchy.html
*
*
* \defgroup AlgorithmOverview Algorithm Overview
* \brief Description of the algorithm
*
* The algorithm top-level is implemented in the \c NegociateWindow.
*
* First step : NegociateWindow::_loadRouting()
*
* - Load routing wires (\c AutoSegment) from \c KatabaticEngine
* inside the Kite \c GCell's. Then update the \c GCell's density.
*
- Sort the \c GCell's according to decreasing density (denser
* \c GCell's are to be routed first).
*
- Agglomerate clusters of contiguous GCell's whose density
* is superior to 0.7 to the seed GCell. See \c GCellRoutingSet
* for the mechanism.
*
* GCellRoutingSet receive an increasing order number. The higher
* the order the lower the density. This order is transmitted
* to the \c TrackSegment of the \c GCellRoutingSet to be taken into
* account by the track cost function.
*
*
* Second step : \c NegociateWindow::_runOnGCellRoutingSet()
*
* For each \c GCellRoutingSet in decreasing density, negociate the
* set of associated \c TrackSegment.
*
* - Build a \c RoutingEventQueue from the list of \c TrackSegment.
* The queue is responsible for allocating the \c RoutingEvent
* associated to each \c TrackSegment.
*
- The queue is sorted according to the "event level" then
* to the priority, which is for now the slack of the \c TrackSegment.
* That is, constrained \c TrackSegment are routed first.
*
- The queue is processed till it's empty (no unprocessed \c RoutingEvent
* remains).
*
* Processing a \c RoutingEvent is trying to insert a \c TrackSegment in
* a suitable Track. We proceed as follow :
*
* - The maximum ripup count for the to be inserted segment has
* been reached. Issue a severe warning and left unrouted
* this \c TrackSegment (for now).
*
- Compute the Tracks in which the \c TrackSegment can be inserted,
* then compute the insertion cost in each one. The candidates
* are ordered by the insertion cost.
*
- Now consider the lower cost \c Track. If there is a free interval
* for the \c TrackSegment. Issue a \c Session::addInsertEvent() then
* finish.
*
* If there is a "soft overlap", that is the overlaping
* \c TrackSegment already in the \c Track could be shrunk either to
* the left or the right so the new \c TrackSegment can be inserted.
* This is managed by \c RoutingEvent::_setAside(), for each soft
* overlaping \c TrackSegment, gets its perpandiculars and issue
* a displacement request for all of them. That is, re-post a
* \c RoutingEvent with updated constraints and remove the
* perpandicular from it's Track if it has already been routed.
* Note that no request is issued for the overlaping \c TrackSegment
* itself has it do not change of Track.
*
* If there is a "hard overlap", that is the two \c TrackSegment
* cannot share the same \c Track, remove the previous one from
* the \c Track and re-post a \c RoutingEvent. Note that, the
* cost object should have selected a \c TrackSegment which could
* be ripped-up. Otherwise the \c Track would'nt even be a candidate.
*
*
* When a TrackSegment is riped up, it is re-routed immediately
* afterward. This is done by increasing his event level.
*
*/
/*! \namespace Kite
* \brief The namespace dedicated to Kite.
*/
}