Translation rules to build detailed routing from global\&.
This module documents how the global routing built by \fCKnik\fP is loaded into the \fC\fBKatabatic\fP\fP data-base\&. It is intented for developpers only\&.
.SH"Enumeration Type Documentation"
.PP
.SS"enum \fBLocalFunctionFlag\fP"
A set of flags for all functions of the LoadGrByNet module\&. They can be combined to form the \fIflags\fP argument of functions\&. the functions will ignore flags that are not intended to them\&.
.PP
For \fCHSmall\fP, \fCVSmall\fP & \fCPunctual\fP see \fBcheckRoutingPadSize()\fP\&.
.PP
\fBEnumerator\fP
.in+1c
.TP
\fB\fINoFlags \fP\fP
A simple alias over zero to explicitly tell that no flag at all is passed to the function\&.
.TP
\fB\fIHAccess \fP\fP
The constructed topology will be accessed through an horizontal segment\&. The absence of this flag tell that the access will be done trough a vertical\&.
.TP
\fB\fIVSmall \fP\fP
The RoutingPad vertically covers a very small number of access points, so it is likely overconstrained for direct horizontal connexion\&.
.TP
\fB\fIHSmall \fP\fP
The RoutingPad horizontally covers a very small number of access points, so it is likely overconstrained for direct vertical connexion\&.
.TP
\fB\fIPunctual \fP\fP
The RoutingPad covers only an access point in either direction\&.
.TP
\fB\fIDoSourceContact \fP\fP
When creating \fBKatabatic::AutoContactTerminal\fP on non-punctual RoutingPad, this flag request the creation of a contact \fIon the source point\fP\&.
.TP
\fB\fIDoTargetContact \fP\fP
When creating \fBKatabatic::AutoContactTerminal\fP on non-punctual RoutingPad, this flag request the creation of a contact \fIon the target point\fP\&.
.SH"Function Documentation"
.PP
.SS"unsigned int checkRoutingPadSize (\fBComponent\fP * rp)"
Look at the geometrical size of the Component and assess if it's span is too narrow either horizontally or vertically\&. Return a combination of flags indicating it's state:
.IP"\(bu"2
HSmall : less than 3 pitches in horizontal direction\&.
.IP"\(bu"2
VSmall : less than 3 pitches in vertical direction\&.
.IP"\(bu"2
Punctual : one pitch in either directions\&.
.PP
.PP
The component can be a RoutingPad, a Vertical or an Horizontal\&.
.PP
checkRoutingPadSize()
.PP
References Component::getLayer(), anonymous_namespace{LoadGrByNet\&.cpp}::HSmall, anonymous_namespace{LoadGrByNet\&.cpp}::Punctual, toLambda(), and anonymous_namespace{LoadGrByNet\&.cpp}::VSmall\&.
\fIgcell\fP The GCell into which create the AutoContact\&.
.br
\fIrp\fP The Component we want to access\&.
.br
\fIsource\fP The AutoContact created on the \fCsource\fP (\fIreturned\fP)\&.
.br
\fItarget\fP The AutoContact created on the \fCtarget\fP (\fIreturned\fP)\&.
.br
\fIflags\fP Managed by this function:
.IP"\(bu"2
LocalFunctionFlag::DoSourceContact
.IP"\(bu"2
LocalFunctionFlag::DoTargetContact
.PP
.RE
.PP
Create the AutoContact directly anchored on the Component (terminal)\&. Three cases are manageds:
.IP"1."4
\fBOrdinary (non-punctual) \fCMETAL1\fP terminal\fP: an AutoContactTerminal is anchored on the RoutingPad\&.
.IP"2."4
\fBPunctual \fCMETAL1\fP terminal\fP, the access must never be blocked by other routing\&. To ensure it, we create a fixed AutoSegment (anchored on two AutoContactTerminal) to cover it\&. The \fInormal\fP AutoContactTerminal is also created\&.
.IP"3."4
\fBnon \fCMETAL1\fP terminal\fP, as for the punctual \fCMETAL1\fP, a fixed protection is added over the RoutingPad\&. If we access horizontally a vertical RoutingPad or vertically an horizontal one, an extra AutoContactTerminal is added (to allow is displacement along the RoutingPad)\&.
.PP
.PP
To avoid creating a fixed protection over a RoutingPad multiple times, the RoutingPad and it's associated protection is stored in a static \fCmap\fP : \fC__routingPadAutoSegments\fP\&.
.PP
Conversely, because an AutoContactTerminal can only be connected to one segment, each time this function is called a new terminal will be created (or maybe two in case of non-punctual terminals)\&. If only one AutoContact is requested, it is created centered on the RoutingPad\&. The initial position of AutoContact \fIdo not prevent them to move afterwards\fP, even those created on source/target on a non-punctual RoutingPad\&.
.PP
\fBRemark: For clarity we describe the layer management of this function in term\fP
.RS4
of \fCMETAL\fP, but it is the RoutingGauge depth which is actually used\&.
\fIgcell\fP The GCell into which create the AutoContact\&.
.br
\fIrp\fP The Component onto which anchor the access contact\&.
.br
\fIflags\fP Relevant flags are:
.IP"\(bu"2
HAccess, the terminal is to be accessed through an horizontal segment\&.
.IP"\(bu"2
VSmall, force the terminal to be considered as small in the vertical direction\&.
.PP
.RE
.PP
If \fCHAccess\fP is set, the Component is to be accessed trough an horizontal segment\&. If unset, the access is done vertically\&.
.PP
Create an AutoContact to access a Component (terminal)\&. If the Component is not to be accessed through an horizontal segment, and do not cover a large span in the horizontal direction (flag \fCVSmall\fP), a local horizontal AutoSegment is added to slacken the vertical constraints\&.
Referenced by GCellTopology::_do_1G_1M1(), GCellTopology::_do_1G_xM1(), GCellTopology::_do_xG_xM1_xM3(), GCellTopology::_do_xG_xM2(), and GCellTopology::_do_xG_xM3()\&.
.SS"\fBAutoContact\fP * doRp_AccessPad (\fBRoutingPad\fP * rp, unsigned int flags)\fC [static]\fP"
.PP
\fBParameters:\fP
.RS4
\fIrp\fP The Component onto which anchor the access contact\&.
.br
\fIflags\fP Relevant flags are:
.IP"\(bu"2
HAccess, the terminal is to be accessed through an horizontal segment\&.
.IP"\(bu"2
VSmall, force the terminal to be considered as small in the vertical direction\&.
.PP
.RE
.PP
\fBReturns:\fP
.RS4
A \fBKatabatic::AutoContactTerminal\fP\&.
.RE
.PP
The Component \fCrp\fP is a RoutingPad which belongs to a pad cell\&. This case occurs when we are routing a complete chip\&. This method build, from the \fCrp\fP a stack of articulated punctual segments and contacts to reach the default H/V routing layers (usually \fCMETAL2\fP & \fCMETAL3\fP)\&. This may be needed when the pad terminal is in \fCMETAL5\fP, for instance\&.
.PP
The returned AutoContactTerminal is anchored on the last punctual segment build\&.
.PP
The GCell into which the AutoContactTerminal is created may be under the pads area\&. However, it will be right on the border of the GCell\&. The global router vertexes of GCell under the pad area are marked as blocked so will never be used for routing\&.
.PP
\fBRemark: The segments and contacts added to ensure the layer connexity are not\fP
.RS4
put into the \fBKatabatic\fP database\&. They are plain Hurricane objects, invisibles from it\&.
Construct the topology, when there is only global wires and one local terminal, but coming from a Pad\&. As thoses connectors will always be on one border of the GCell they can be considered as a kind of global\&.
.PP
So this method mostly calls \fBGCellTopology::doRp_AccessPad()\fP to create the AutoContactTerminal, then calls \fBGCellTopology::_do_xG()\fP, except for straight lines which are managed directly\&.
Construct the topology, when there is only global wires (no local terminals)\&.
.PP
Some topology are not handled because they must not be managed by this function:
.PD0
.IP"\(bu"2
One global: nonsensical because there also must be a terminal\&.
.IP"\(bu"2
Two aligned globals: in that case we do a straight wire without any AutoContact (handled by the source/target of the wire)\&.
.PP
.PP
_do_xG()
.PP
References AutoContactVTee::create(), AutoContactTurn::create(), AutoContactHTee::create(), AutoSegment::create(), Session::getContactLayer(), Katabatic::KbHorizontal, and Katabatic::KbVertical\&.
.PP
Referenced by GCellTopology::_do_xG_1Pad()\&.
.SS"void _do_1G_1M1 ()\fC [private]\fP"
Construct a topology where there is \fIone\fP global and one RoutingPad in \fCMETAL1\fP\&. The \fCMETAL1\fP is assumed to be vertical\&.
.PP
\fBRemark: When accessing the RoutingPad through an horizontal global segment\fP
.RS4
and the vertical extension of the segment is small, the global is still directly attached to the terminal, inducing a high constraint on it\&. We left to job of slackening it to the router\&.
.RE
.PP
_do_1G_1M1()
.PP
References GCellTopology::doRp_Access(), anonymous_namespace{LoadGrByNet\&.cpp}::HAccess, anonymous_namespace{LoadGrByNet\&.cpp}::NoFlags, and anonymous_namespace{LoadGrByNet\&.cpp}::VSmall\&.
.SS"void _do_1G_xM1 ()\fC [private]\fP"
Construct a topology where there is \fIone\fP global and any number of RoutingPad in \fCMETAL1\fP\&. The \fCMETAL1\fP is assumed to be vertical\&.
.PP
The RoutingPads are linked together two by two\&. If the horizontal segments are not aligned by the router, part of the routage will be done through the RoutingPad itself\&. The global incoming segment will connected to the leftmost, rightmost or centermost RoutingPad according from wich side it comes from\&.
Construct a topology where there is at least one global (and up to 4), one \fCMETAL1\fP RoutingPad (assumed V) and one \fCMETAL2\fP RoutingPad (assumed H)\&.
.PP
In this topology, we want to try to reuse the \fCMETAL2\fP RoutingPad as a feedtrough in the horizontal routage\&. Thus:
.IP"\(bu"2
The \fCMETAL1\fP and \fCMETAL2\fP RoutingPad are connected through a separate wiring\&.
.IP"\(bu"2
The south & west global wiring is attached to the leftmost contact of the \fCMETAL2\fP\&.
.IP"\(bu"2
The north & east global wiring is attached to the rightmost contact of the \fCMETAL2\fP\&.
.PP
.PP
South/west and north/south can be build independantly\&. Depending on the number of globals, they can consist of:
.IP"\(bu"2
Nothing (no south nor west)\&.
.IP"\(bu"2
An AutoContact (west present)\&.
.IP"\(bu"2
An horizontal plus a turn (south present)\&.
.IP"\(bu"2
An horizontal plus a HTee (south & west present)\&.
.PP
.PP
\fBRemark: Not all configurations are represented below\&.\fP
Construct a topology where there is at least one global (and up to 4), at least one \fCMETAL1\fP RoutingPad (assumed V) and at least one \fCMETAL3\fP RoutingPad (assumed V)\&.
.PP
In this topology, we want to try to reuse the \fCMETAL3\fP RoutingPad as a feedtrough in the vertical routage\&. Thus:
.IP"\(bu"2
The \fCMETAL1\fP and \fCMETAL3\fP RoutingPad are connected through a separate wiring made of separate horizontals\&.
.IP"\(bu"2
The south-west global wiring is attached to the leftmost RoutingPad if there isn't south or to the first \fCMETAL3\fP otherwise\&.
.IP"\(bu"2
The north-east global wiring is attached to the rightmost RoutingPad if there isn't north or to the first \fCMETAL3\fP otherwise\&.
.PP
.PP
South/west and north/south can be build independantly\&. Depending on the number of globals, they can consist of:
.IP"\(bu"2
Nothing (no south nor west)\&.
.IP"\(bu"2
An AutoContact on the leftmost RoutingPad (west present)\&.
.IP"\(bu"2
An AutoContact on the first \fCMETAL3\fP (only south present)\&.
.IP"\(bu"2
An AutoContact plus a vertical plus a VTee (south & west present)\&.
Construct a topology where there is one global and one \fCMETAL3\fP RoutingPad (assumeds V)\&.
.PP
In this topology, we reuse the \fCMETAL3\fP RoutingPad as a feedtrough in the vertical routage\&. Thus:
.IP"\(bu"2
If the global is either north or south, we directly connect to the north end or south end of the RoutingPad\&. The vertical global will have no slack at all we assume that METAL3 terminals are only from blocks and are aligneds vertically\&.
.IP"\(bu"2
If the global is east or west \fIand\fP the RoutingPad is sufficiently extended in the vertical direction, we connect an horizontal in the normal way\&.
.IP"\(bu"2
If the global is not sufficiently extended, we add a turn to give some slack to the global\&.
Construct a topology where there at least one global and two \fCMETAL3\fP RoutingPad (assumed V)\&.
.PP
In this topology, we reuse the \fCMETAL3\fP RoutingPad as a feedtrough in the vertical routage\&. We assume that the most likely relative position of the RoutingPads is to be aligned vertically\&. Thus:
.IP"\(bu"2
All RoutingPads are linked two by two trough vertical staircases\&.
.IP"\(bu"2
The south-west global wiring is attached to the bottommost RoutingPad (without vertical slack)\&. If a misalignment is detected, then a dogleg is added\&.
.IP"\(bu"2
The north-east global wiring is attached to the topmost RoutingPad (without vertical slack)\&.
.PP
.PP
South/west and north/south can be build independantly\&. Depending on the number of globals, they can consist of:
.IP"\(bu"2
Nothing (no south nor west)\&.
.IP"\(bu"2
An sliding AutoContact on the bottommost RoutingPad (west present)\&.
.IP"\(bu"2
An fixed AutoContact on the bottommost RoutingPad (only south present)\&.
.IP"\(bu"2
An fixed AutoContact plus a vertical plus a VTee (south & west present)\&.
All the RoutingPads of the net are concentrated under a single GCell\&. This function assumes that all the terminals are in \fCMETAL1\fP (vertical), and link them two by two by horizontal wires\&.
