Katabatic - Routing Toolbox


Classes | Enumerations | Enumerator | Functions
Global Routing Loading

Translation rules to build detailed routing from global. More...

Classes

class  GCellTopology
 Build the wiring for a Net inside a GCell (internal). More...
 

Enumerations

enum  LocalFunctionFlag {
  NoFlags = 0x00000000 ,
  HAccess = 0x00000002,
  VSmall = 0x00000004,
  HSmall = 0x00000008,
  Punctual = 0x00000010 ,
  DoSourceContact = 0x00000100,
  DoTargetContact = 0x00000200
}
 

Functions

unsigned int checkRoutingPadSize (Component *anchor)
 
static void doRp_AutoContacts (GCell *, Component *, AutoContact *&source, AutoContact *&target, unsigned int flags)
 
static AutoContactdoRp_Access (GCell *, Component *, unsigned int flags)
 
static AutoContactdoRp_AccessPad (RoutingPad *, unsigned int flags)
 
static void doRp_StairCaseH (GCell *, Component *rp1, Component *rp2)
 
static void doRp_StairCaseV (GCell *, Component *rp1, Component *rp2)
 
void _do_xG_1Pad ()
 
void _do_xG ()
 
void _do_1G_1M1 ()
 
void _do_1G_xM1 ()
 
void _do_xG_1M1_1M2 ()
 
void _do_xG_xM1_xM3 ()
 
void _do_xG_xM2 ()
 
void _do_1G_1M3 ()
 
void _do_xG_xM3 ()
 
void singleGCell (KatabaticEngine *ktbt, Net *net)
 

Detailed Description

Translation rules to build detailed routing from global.

This module documents how the global routing built by Knik is loaded into the Katabatic data-base. It is intented for developpers only.

Enumeration Type Documentation

◆ LocalFunctionFlag

A set of flags for all functions of the LoadGrByNet module. They can be combined to form the flags argument of functions. the functions will ignore flags that are not intended to them.

For HSmall, VSmall & Punctual see checkRoutingPadSize().

Enumerator
NoFlags 

A simple alias over zero to explicitly tell that no flag at all is passed to the function.

HAccess 

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.

VSmall 

The RoutingPad vertically covers a very small number of access points, so it is likely overconstrained for direct horizontal connexion.

HSmall 

The RoutingPad horizontally covers a very small number of access points, so it is likely overconstrained for direct vertical connexion.

Punctual 

The RoutingPad covers only an access point in either direction.

DoSourceContact 

When creating Katabatic::AutoContactTerminal on non-punctual RoutingPad, this flag request the creation of a contact on the source point.

DoTargetContact 

When creating Katabatic::AutoContactTerminal on non-punctual RoutingPad, this flag request the creation of a contact on the target point.

Function Documentation

◆ checkRoutingPadSize()

unsigned int checkRoutingPadSize ( Component 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:

  • HSmall : less than 3 pitches in horizontal direction.
  • VSmall : less than 3 pitches in vertical direction.
  • Punctual : one pitch in either directions.

The component can be a RoutingPad, a Vertical or an Horizontal.

checkRoutingPadSize.png
checkRoutingPadSize()

References Component::getLayer(), anonymous_namespace{LoadGrByNet.cpp}::HSmall, anonymous_namespace{LoadGrByNet.cpp}::Punctual, toLambda(), and anonymous_namespace{LoadGrByNet.cpp}::VSmall.

Referenced by GCellTopology::doRp_Access().

◆ doRp_AutoContacts()

void doRp_AutoContacts ( GCell gcell,
Component rp,
AutoContact *&  source,
AutoContact *&  target,
unsigned int  flags 
)
static
Parameters
gcellThe GCell into which create the AutoContact.
rpThe Component we want to access.
sourceThe AutoContact created on the source (returned).
targetThe AutoContact created on the target (returned).
flagsManaged by this function:
  • LocalFunctionFlag::DoSourceContact
  • LocalFunctionFlag::DoTargetContact

Create the AutoContact directly anchored on the Component (terminal). Three cases are manageds:

  1. Ordinary (non-punctual) METAL1 terminal: an AutoContactTerminal is anchored on the RoutingPad.
  2. Punctual METAL1 terminal, 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 normal AutoContactTerminal is also created.
  3. non METAL1 terminal, as for the punctual METAL1, 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).

To avoid creating a fixed protection over a RoutingPad multiple times, the RoutingPad and it's associated protection is stored in a static map : __routingPadAutoSegments.

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 do not prevent them to move afterwards, even those created on source/target on a non-punctual RoutingPad.

Remark: For clarity we describe the layer management of this function in term
of METAL, but it is the RoutingGauge depth which is actually used.
doRp_AutoContacts.png
doRp_AutoContacts()

References Katabatic::CntFixed, AutoContactTerminal::create(), AutoSegment::create(), anonymous_namespace{LoadGrByNet.cpp}::DoSourceContact, anonymous_namespace{LoadGrByNet.cpp}::DoTargetContact, Session::getContactLayer(), Grid< GCellT >::getGCell(), KatabaticEngine::getGCellGrid(), Session::getKatabatic(), Component::getLayer(), Katabatic::KbHorizontal, Katabatic::SegFixed, and AutoSegment::setFlags().

Referenced by GCellTopology::_do_1G_1M3(), GCellTopology::_do_xG_1M1_1M2(), GCellTopology::_do_xG_xM1_xM3(), GCellTopology::_do_xG_xM2(), GCellTopology::_do_xG_xM3(), GCellTopology::doRp_Access(), GCellTopology::doRp_StairCaseH(), GCellTopology::doRp_StairCaseV(), and anonymous_namespace{LoadGrByNet.cpp}::singleGCell().

◆ doRp_Access()

AutoContact * doRp_Access ( GCell gcell,
Component rp,
unsigned int  flags 
)
static
Parameters
gcellThe GCell into which create the AutoContact.
rpThe Component onto which anchor the access contact.
flagsRelevant flags are:
  • HAccess, the terminal is to be accessed through an horizontal segment.
  • VSmall, force the terminal to be considered as small in the vertical direction.

If HAccess is set, the Component is to be accessed trough an horizontal segment. If unset, the access is done vertically.

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 VSmall), a local horizontal AutoSegment is added to slacken the vertical constraints.

doRp_Access.png
doRp_Access()

References anonymous_namespace{LoadGrByNet.cpp}::checkRoutingPadSize(), AutoContactTurn::create(), AutoSegment::create(), GCellTopology::doRp_AutoContacts(), Session::getContactLayer(), Component::getNet(), anonymous_namespace{LoadGrByNet.cpp}::HAccess, anonymous_namespace{LoadGrByNet.cpp}::HSmall, Katabatic::KbHorizontal, Katabatic::KbVertical, and anonymous_namespace{LoadGrByNet.cpp}::VSmall.

Referenced by GCellTopology::_do_1G_1M1(), GCellTopology::_do_1G_xM1(), GCellTopology::_do_xG_xM1_xM3(), GCellTopology::_do_xG_xM2(), and GCellTopology::_do_xG_xM3().

◆ doRp_AccessPad()

AutoContact * doRp_AccessPad ( RoutingPad rp,
unsigned int  flags 
)
static
Parameters
rpThe Component onto which anchor the access contact.
flagsRelevant flags are:
  • HAccess, the terminal is to be accessed through an horizontal segment.
  • VSmall, force the terminal to be considered as small in the vertical direction.
Returns
A Katabatic::AutoContactTerminal .

The Component rp is a RoutingPad which belongs to a pad cell. This case occurs when we are routing a complete chip. This method build, from the rp a stack of articulated punctual segments and contacts to reach the default H/V routing layers (usually METAL2 & METAL3). This may be needed when the pad terminal is in METAL5, for instance.

The returned AutoContactTerminal is anchored on the last punctual segment build.

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.

Remark: The segments and contacts added to ensure the layer connexity are not
put into the Katabatic database. They are plain Hurricane objects, invisibles from it.

References Contact::create(), Horizontal::create(), Vertical::create(), AutoContactTerminal::create(), Hook::detach(), Component::getBodyHook(), RoutingPad::getBoundingBox(), RoutingPad::getCenter(), Session::getContactLayer(), Grid< GCellT >::getGCell(), KatabaticEngine::getGCellGrid(), Box::getHeight(), Session::getKatabatic(), RoutingPad::getLayer(), Component::getNet(), RoutingPad::getOccurrence(), Transformation::getOrientation(), Occurrence::getPath(), Session::getRoutingLayer(), Path::getTransformation(), Box::getWidth(), Box::getXMax(), Box::getXMin(), Box::getYMax(), Box::getYMin(), anonymous_namespace{LoadGrByNet.cpp}::HAccess, Katabatic::KbHorizontal, Point::setX(), and Point::setY().

Referenced by GCellTopology::_do_xG_1Pad().

◆ doRp_StairCaseH()

void doRp_StairCaseH ( GCell gcell,
Component rp1,
Component rp2 
)
static

Build the wiring to connect to horizontal Component. Two cases:

  • The Component are aligneds, then only a straight wire is created.
  • They are not aligned, then a complete dogleg is created.
doRp_StairCaseH.png
doRp_StairCaseH()

References AutoContactTurn::create(), AutoSegment::create(), GCellTopology::doRp_AutoContacts(), anonymous_namespace{LoadGrByNet.cpp}::DoSourceContact, anonymous_namespace{LoadGrByNet.cpp}::DoTargetContact, Session::getContactLayer(), Component::getLayer(), Component::getNet(), Component::getX(), AutoContact::getY(), Katabatic::KbHorizontal, and Katabatic::KbVertical.

Referenced by GCellTopology::_do_xG_xM2().

◆ doRp_StairCaseV()

void doRp_StairCaseV ( GCell gcell,
Component rp1,
Component rp2 
)
static

Build the wiring to connect to vertical Components. Two cases:

  • The Components are aligneds, then only a straight wire is created.
  • They are not aligned, then a complete dogleg is created.
doRp_StairCaseV.png
doRp_StairCaseV()

References AutoContactTurn::create(), AutoSegment::create(), GCellTopology::doRp_AutoContacts(), anonymous_namespace{LoadGrByNet.cpp}::DoSourceContact, anonymous_namespace{LoadGrByNet.cpp}::DoTargetContact, Session::getContactLayer(), Component::getLayer(), Component::getNet(), AutoContact::getX(), Component::getY(), Katabatic::KbHorizontal, and Katabatic::KbVertical.

Referenced by GCellTopology::_do_xG_xM3().

◆ _do_xG_1Pad()

void _do_xG_1Pad ( )
private

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.

So this method mostly calls GCellTopology::doRp_AccessPad() to create the AutoContactTerminal, then calls GCellTopology::_do_xG(), except for straight lines which are managed directly.

References GCellTopology::_do_xG(), AutoContactTurn::create(), AutoSegment::create(), GCellTopology::doRp_AccessPad(), AutoContact::getBodyHook(), Session::getContactLayer(), anonymous_namespace{LoadGrByNet.cpp}::HAccess, Katabatic::KbHorizontal, Katabatic::KbVertical, and anonymous_namespace{LoadGrByNet.cpp}::NoFlags.

◆ _do_xG()

void _do_xG ( )
private

Construct the topology, when there is only global wires (no local terminals).

Some topology are not handled because they must not be managed by this function:

  • One global: nonsensical because there also must be a terminal.
  • Two aligned globals: in that case we do a straight wire without any AutoContact (handled by the source/target of the wire).
_do_xG.png
_do_xG()

References AutoContactVTee::create(), AutoContactTurn::create(), AutoContactHTee::create(), AutoSegment::create(), Session::getContactLayer(), Katabatic::KbHorizontal, and Katabatic::KbVertical.

Referenced by GCellTopology::_do_xG_1Pad().

◆ _do_1G_1M1()

void _do_1G_1M1 ( )
private

Construct a topology where there is one global and one RoutingPad in METAL1. The METAL1 is assumed to be vertical.

Remark: When accessing the RoutingPad through an horizontal global segment
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.
_do_1G_1M1.png
_do_1G_1M1()

References GCellTopology::doRp_Access(), anonymous_namespace{LoadGrByNet.cpp}::HAccess, anonymous_namespace{LoadGrByNet.cpp}::NoFlags, and anonymous_namespace{LoadGrByNet.cpp}::VSmall.

◆ _do_1G_xM1()

void _do_1G_xM1 ( )
private

Construct a topology where there is one global and any number of RoutingPad in METAL1. The METAL1 is assumed to be vertical.

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.

_do_1G_xM1.png
_do_1G_xM1()

References AutoContactTurn::create(), AutoSegment::create(), GCellTopology::doRp_Access(), Component::getBoundingBox(), Session::getContactLayer(), Box::getHeight(), anonymous_namespace{LoadGrByNet.cpp}::HAccess, Katabatic::KbHorizontal, and anonymous_namespace{LoadGrByNet.cpp}::NoFlags.

◆ _do_xG_1M1_1M2()

void _do_xG_1M1_1M2 ( )
private

Construct a topology where there is at least one global (and up to 4), one METAL1 RoutingPad (assumed V) and one METAL2 RoutingPad (assumed H).

In this topology, we want to try to reuse the METAL2 RoutingPad as a feedtrough in the horizontal routage. Thus:

  • The METAL1 and METAL2 RoutingPad are connected through a separate wiring.
  • The south & west global wiring is attached to the leftmost contact of the METAL2.
  • The north & east global wiring is attached to the rightmost contact of the METAL2.

South/west and north/south can be build independantly. Depending on the number of globals, they can consist of:

  • Nothing (no south nor west).
  • An AutoContact (west present).
  • An horizontal plus a turn (south present).
  • An horizontal plus a HTee (south & west present).
Remark: Not all configurations are represented below.
_do_xG_1M1_1M2.png
_do_xG_1M1_1M2()

References AutoContactTurn::create(), AutoContactHTee::create(), AutoSegment::create(), GCellTopology::doRp_AutoContacts(), anonymous_namespace{LoadGrByNet.cpp}::DoSourceContact, anonymous_namespace{LoadGrByNet.cpp}::DoTargetContact, Session::getContactLayer(), Session::getRoutingLayer(), Katabatic::KbHorizontal, Katabatic::KbVertical, and anonymous_namespace{LoadGrByNet.cpp}::NoFlags.

◆ _do_xG_xM1_xM3()

void _do_xG_xM1_xM3 ( )
private

Construct a topology where there is at least one global (and up to 4), at least one METAL1 RoutingPad (assumed V) and at least one METAL3 RoutingPad (assumed V).

In this topology, we want to try to reuse the METAL3 RoutingPad as a feedtrough in the vertical routage. Thus:

  • The METAL1 and METAL3 RoutingPad are connected through a separate wiring made of separate horizontals.
  • The south-west global wiring is attached to the leftmost RoutingPad if there isn't south or to the first METAL3 otherwise.
  • The north-east global wiring is attached to the rightmost RoutingPad if there isn't north or to the first METAL3 otherwise.

South/west and north/south can be build independantly. Depending on the number of globals, they can consist of:

  • Nothing (no south nor west).
  • An AutoContact on the leftmost RoutingPad (west present).
  • An AutoContact on the first METAL3 (only south present).
  • An AutoContact plus a vertical plus a VTee (south & west present).
_do_xG_xM1_xM3.png
_do_xG_xM1_xM3()

References AutoContactVTee::create(), AutoContactTurn::create(), AutoContactHTee::create(), AutoSegment::create(), GCellTopology::doRp_Access(), GCellTopology::doRp_AutoContacts(), anonymous_namespace{LoadGrByNet.cpp}::DoSourceContact, anonymous_namespace{LoadGrByNet.cpp}::DoTargetContact, Component::getBoundingBox(), Session::getContactLayer(), Box::getHeight(), Session::getRoutingLayer(), anonymous_namespace{LoadGrByNet.cpp}::HAccess, Katabatic::KbHorizontal, Katabatic::KbVertical, and anonymous_namespace{LoadGrByNet.cpp}::NoFlags.

◆ _do_xG_xM2()

void _do_xG_xM2 ( )
private

Construct a topology where there is at least one global (and up to 4), and any number of METAL2 RoutingPads (assumeds H).

In this topology, we want to try to reuse the METAL2 RoutingPad as a feedtrough in the horizontal routage. Thus:

  • The RoutingPad are connecteds trough a separate staircase (or straight wire if aligneds).
  • The south-west global wiring is attached to the leftmost RoutingPad if there isn't south or to the biggest horizontal RoutingPad otherwise.
  • The north-east global wiring is attached to the rightmost RoutingPad if there isn't south or to the biggest horizontal RoutingPad otherwise.
_do_xG_xM2.png
_do_xG_xM2()

References AutoContactVTee::create(), AutoSegment::create(), GCellTopology::doRp_Access(), GCellTopology::doRp_AutoContacts(), GCellTopology::doRp_StairCaseH(), anonymous_namespace{LoadGrByNet.cpp}::DoSourceContact, Component::getBoundingBox(), Session::getContactLayer(), Box::getWidth(), Katabatic::KbVertical, and anonymous_namespace{LoadGrByNet.cpp}::NoFlags.

◆ _do_1G_1M3()

void _do_1G_1M3 ( )
private

Construct a topology where there is one global and one METAL3 RoutingPad (assumeds V).

In this topology, we reuse the METAL3 RoutingPad as a feedtrough in the vertical routage. Thus:

  • 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.
  • If the global is east or west and the RoutingPad is sufficiently extended in the vertical direction, we connect an horizontal in the normal way.
  • If the global is not sufficiently extended, we add a turn to give some slack to the global.
_do_1G_1M3.png
_do_1G_1M3()

References AutoContactTurn::create(), AutoSegment::create(), GCellTopology::doRp_AutoContacts(), anonymous_namespace{LoadGrByNet.cpp}::DoSourceContact, anonymous_namespace{LoadGrByNet.cpp}::DoTargetContact, Session::getContactLayer(), AutoContact::getX(), anonymous_namespace{LoadGrByNet.cpp}::HAccess, Katabatic::KbHorizontal, Katabatic::KbVertical, and anonymous_namespace{LoadGrByNet.cpp}::NoFlags.

◆ _do_xG_xM3()

void _do_xG_xM3 ( )
private

Construct a topology where there at least one global and two METAL3 RoutingPad (assumed V).

In this topology, we reuse the METAL3 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:

  • All RoutingPads are linked two by two trough vertical staircases.
  • The south-west global wiring is attached to the bottommost RoutingPad (without vertical slack). If a misalignment is detected, then a dogleg is added.
  • The north-east global wiring is attached to the topmost RoutingPad (without vertical slack).

South/west and north/south can be build independantly. Depending on the number of globals, they can consist of:

  • Nothing (no south nor west).
  • An sliding AutoContact on the bottommost RoutingPad (west present).
  • An fixed AutoContact on the bottommost RoutingPad (only south present).
  • An fixed AutoContact plus a vertical plus a VTee (south & west present).
_do_xG_xM3.png
_do_xG_xM3()

References AutoContactVTee::create(), AutoContactTurn::create(), AutoSegment::create(), GCellTopology::doRp_Access(), GCellTopology::doRp_AutoContacts(), GCellTopology::doRp_StairCaseV(), anonymous_namespace{LoadGrByNet.cpp}::DoSourceContact, anonymous_namespace{LoadGrByNet.cpp}::DoTargetContact, Session::getContactLayer(), DbU::getValueString(), AutoContact::getX(), anonymous_namespace{LoadGrByNet.cpp}::HAccess, Katabatic::KbHorizontal, Katabatic::KbVertical, and anonymous_namespace{LoadGrByNet.cpp}::NoFlags.

◆ singleGCell()

void singleGCell ( KatabaticEngine ktbt,
Net net 
)


Generated by doxygen 1.8.14 on Mon Feb 3 2020 Return to top of page
Katabatic - Routing Toolbox Copyright © 2008-2016 UPMC. All rights reserved