.TH "pageNotes" 3 "Mon Apr 27 2020" "Version 1.0" "Kite - Detailed Router" \" -*- nroff -*- .ad l .nh .SH NAME pageNotes \- Notes .SH "Summary" .PP .IP "\(bu" 2 \fBVarious Things to Remeber\fP .IP "\(bu" 2 \fBPending Modifications\fP .IP "\(bu" 2 \fBModifications History\fP .IP "\(bu" 2 \fBChanges in the general architecture\fP .IP " \(bu" 4 \fBChanges in KiteEngine class design\fP .IP " \(bu" 4 \fBChanges in DataNegociate class design\fP .IP " \(bu" 4 \fBChanges in TrackElement class design\fP .IP " \(bu" 4 \fBChanges in TrackSegment class design\fP .IP " \(bu" 4 \fBChanges in AutoSegment class design\fP .IP " \(bu" 4 \fBChanges in AutoContact class design\fP .PP .IP "\(bu" 2 \fBBug Solving Memento\fP .IP "\(bu" 2 \fBEvaluation with Cadence NanoRoute\fP .PP .SH "Various Things to Remember" .PP .IP "\(bu" 2 \fBDeterminism checking\&.\fP The trace level to get only determinism related log is \fC500\fP\&. Each line for the determinism is prepended with 'Deter|', possible with some leading spaces\&. .IP "\(bu" 2 The router only sees/manages the aligned segment sets (through a pseudo- decorator on their canonical segment)\&. So the non-canonical segments and the contacts should not be handled at all at this level\&. .IP "\(bu" 2 Do do confuse the Session::Event, events that modificate the state of the \fBKite\fP database (insert, move or remove \fBTrackSegment\fP in \fBTrack\fP) and the \fBRoutingEvent\fP class which request that a segment must be processed\&. .IP "\(bu" 2 In the various processing method of \fBRoutingEvent\fP, when a \fBTrackSegment\fP can be inserted inside a \fBTrack\fP a Session::Event is generated but no further \fBRoutingEvent\fP, this end the placement processus of segment (until it is ripped-up)\&. .IP "\(bu" 2 AutoSegment do not invalidate their S/T anchor contacts\&. .IP "\(bu" 2 AutoContact invalidate their anchored upon AutoSegment\&. .IP "\(bu" 2 Now that the Hurricane database is deterministic, the router seems to be likewise\&. .IP "\(bu" 2 \fBReduce/raise mechanism\fP\&. To manage \fIsame layer\fP dogleg this mechanism has been implemented\&. When a candidate dogleg perpandicular segment length shrink below one pitch it is removed from any track to become \fIinvisible\fP\&. Conversely, when a reduced segment length expand over one pitch generate a new \fBRoutingEvent\fP to insert it\&. All this is managed in the \fBSession::revalidate()\fP method\&. .PP .SH "Pending Modifications" .PP .IP "\(bu" 2 In \fBSegmentAction::doAction()\fP, completly disable the movement of \fBTrackSegment\fP on it's target \fBTrack\fP axis\&. This should not be needed as, if the algorithm as worked correctly, the next time it's \fBRoutingEvent\fP is processed, the target \fBTrack\fP will have a free space to insert into\&. Then the \fBTrack\fP insertion will set the \fBTrackSegment\fP axis\&. .IP "\(bu" 2 Has to complete the lazy evaluation of the \fBTrackSegment\fP / \fBDataNegociate\fP / \fBRoutingEvent\fP\&. There is still some redundancy when the key of the \fBRoutingEvent\fP is updated\&. .IP "\(bu" 2 In \fBAutoContact::updateTopology()\fP & \fBAutoContact::updateGeometry()\fP we could avoid to systematically run through the Hooks to cache the connected segments\&. This can be done once at the first call of either method (whichever comes first) on the first revalidate\&. Afterwards the cache can be updated only by \fBAutoContact::updateTopology()\fP\&. .IP "\(bu" 2 The canonization is done in two places, directly on a set of aligneds AutoSegments through \fBAutoSegment::canonize()\fP and for the whole net Session::_canonize(), which is called after the initial creation and each time the topology is modificated\&. The later may be suppressed if we uses more intelligently the former, and gain some more speedup\&. .PP .SH "Modifications History" .PP .SS "Changes in the general architecture" .IP "\(bu" 2 \fBLazy Update\&.\fP Update of \fBDataNegociate\fP and \fBRoutingEvent\fP are now delayed until the event is processed, and systematically done at this point\&. Thus, the explicit invalidation of those objects is no longer needed\&. The revalidation is no longer triggered by the revalidation of \fBTrackSegment\fP\&. .PP .SS "Changes in KiteEngine class design" .IP "\(bu" 2 Suppress the lookup table of \fBHurricane::Segment\fP toward \fBTrackSegment\fP\&. Instead uses the Observer mecanism between \fBKatabatic::AutoSegment\fP and \fBTrackSegment\fP\&. .PP .SS "Changes in DataNegociate class design" .IP "\(bu" 2 Merge in the separate class \fCCost\fP\&. .IP "\(bu" 2 Suppress the \fCSlackState::Desalignate\fP, due to the simplificated structure of the AutoSegment/AutoContacts (no more collapseds, or forced alignements)\&. .IP "\(bu" 2 Displace the computation and caching of the perpandiculars and perpandicular free interval from \fBRoutingEvent\fP into \fBDataNegociate\fP\&. Allows code factorization with the attractors computation, and data size reduction as there is exaclty one \fBDataNegociate\fP but there may be more than one \fBRoutingEvent\fP for the same \fBTrackSegment\fP\&. .PP .SS "Changes in TrackElement class design" .IP "\(bu" 2 Due to the simplificated structure of the Katabatic contacts (terminal, turn, vtee & htee), there's no longer collapsed AutoSegment or \fIexpandable\fP contacts\&. The \fBdesalignate\fP feature, relaxing constraints due to collapsed segments or contacts with more than three segments, is no longer implemented\&. \fBHave to redevelop a method to break long segments linked\fP \fBby HTee or VTee\&.\fP .PP .SS "Changes in TrackSegment class design" .IP "\(bu" 2 The method \fCTrackSegment::_postModify()\fP is merged with \fBTrackSegment::_postDoglegs()\fP as, in the context of \fBTrackSegment\fP the only used topological modifications goes through the creation of one or more dogleg\&. .PP .SS "Changes in AutoSegment class design" .IP "\(bu" 2 In \fBAutoSegment::_makeDogleg()\fP, update the local/global status of the involved AutoSegment and re-canonize only what is necessary\&. Thus, guarantee that the net's topology is still valid after this method call and no topological update is needed at \fBSession\fP level (should be \fImuch\fP faster)\&. In this method, the code sharing between AutoHorizontal and AutoVertical can still be increased (update mechanisms are identicals)\&. .IP "\(bu" 2 The \fCid\fP support is now also implemented at Hurricane level\&. We may choose to use as a replacement of the one already present in AutoSegment\&. But in that case, we at least must cache the id in the AutoSegment\&. So we will not gain in memory footprint, the only benefit would be to have coherent id number throughout all the tools, but the sequentiality will be lost (this may not be a big issue)\&. .PP .SS "Changes in AutoContact class design" .IP "\(bu" 2 In \fBAutoSegment::invalidate()\fP, no longer uses collection to walk through attached AutoSegment, directly uses the cache\&. Much simple and efficient as we exactly know what is attached on every kind of contact\&. .PP .SH "Bug Solving Memento" .PP \fBLUT lookup change:\fP When breaking a \fBTrackSegment\fP, the break may not occurs in the associated canonical AutoSegment\&. In that case the \fCdogleg[O]\fP will not match the one that is looked up for the broken (canonical) segment\&. Thus it was not a bug but a misunderstanding\&.\&.\&. .PP \fBOverlap of perpandiculars after a dogleg creation:\fP The axis of the new parallel was not set to the axis of it's parent\&. This was due to the uses of \fBAutoSegment::setAxis()\fP in AutoHorizontal::_makeDogleg() which silently do nothing on non-canonical AutoSegment, and at this point, the re-canonisation did not yet take place\&. Now Uses AutoSegment::_setAxis() the atomic variant wich works inconditionnaly\&. .SH "Evaluation with Cadence NanoRoute" .PP To perform a comparison with NanoRoute the procedure is as follow: .PP .IP "\(bu" 2 Export the design in Alliance \fCDEF\fP format\&. It will generate both \fCDEF\fP file and the supporting \fCLEF\fP file containing the technology and the abstract of all the standard cell of the design\&. As Alliance uses symbolic units (lambda), they are translated with the simple rule: \fB1 lambda == 1 micron\fP\&. .IP "\(bu" 2 Run the commands in NanoRoute: .IP " \(bu" 4 \fCloadLefFile design\&.lef\fP .IP " \(bu" 4 \fCloadDefFile design\&.def\fP .IP " \(bu" 4 \fCgenerateTracks\fP .IP " \(bu" 4 \fCgenerateVias\fP .IP " \(bu" 4 \fCsetNanoRouteMode -quiet -drouteFixAntenna 0\fP .IP " \(bu" 4 \fCsetNanoRouteMode -quiet -drouteStartIteration default\fP .IP " \(bu" 4 \fCsetNanoRouteMode -quiet -routeTopRoutingLayer default\fP .IP " \(bu" 4 \fCsetNanoRouteMode -quiet -routeBottomRoutingLayer 2\fP .IP " \(bu" 4 \fCsetNanoRouteMode -quiet -drouteEndIteration default\fP .IP " \(bu" 4 \fCsetNanoRouteMode -quiet -routeWithTimingDriven false\fP .IP " \(bu" 4 \fCsetNanoRouteMode -quiet -routeWithSiDriven false\fP .IP " \(bu" 4 \fCrouteDesign -globalDetail\fP .PP .IP "\(bu" 2 To perform as fair a comparison as possible, those commands disable antenna effect protection and disable the use of the \fCM1\fP as a routing layer (\fC-routeBottomRoutingLayer 2\fP)\&. Those commands are issued through the graphical interface of NanoRoute\&. .PP .PP \fITo see the resulting layout, do not forget to switch the view mode\&.\fP