// -*- C++ -*- namespace Kite { /*! \mainpage Detailed Router Documentation * * This documentation adresses two level of explanations : * * <ul> * <li>The \b API description which explains how to use Kite, * thoses parts as flagged as \b API. * <li>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). * </ul> * * 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. * * <b>First step :</b> NegociateWindow::_loadRouting() * <ol> * <li>Load routing wires (\c AutoSegment) from \c KatabaticEngine * inside the Kite \c GCell's. Then update the \c GCell's density. * <li>Sort the \c GCell's according to decreasing density (denser * \c GCell's are to be routed first). * <li>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. * </ol> * * <b>Second step :</b> \c NegociateWindow::_runOnGCellRoutingSet() * * For each \c GCellRoutingSet in decreasing density, negociate the * set of associated \c TrackSegment. * <ol> * <li>Build a \c RoutingEventQueue from the list of \c TrackSegment. * The queue is responsible for allocating the \c RoutingEvent * associated to each \c TrackSegment. * <li>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. * <li>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 : * <ul> * <li>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). * <li>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. * <li>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 <i>"soft overlap"</i>, 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 <i>"hard overlap"</i>, 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. * </ul> * * When a TrackSegment is riped up, it is re-routed immediately * afterward. This is done by increasing his event level. * </ol> */ /*! \namespace Kite * \brief The namespace dedicated to Kite. */ }