146 lines
9.1 KiB
Groff
146 lines
9.1 KiB
Groff
.TH "pageNotes" 3 "Sun Nov 21 2021" "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
|