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 AutoContact *	doRp_Access (GCell , Component , unsigned int flags)

static AutoContact *	doRp_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

enum 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

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()

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().

void doRp_AutoContacts	(	GCell *	gcell,
		Component *	rp,
		AutoContact *&	source,
		AutoContact *&	target,
		unsigned int	flags
	)

static

Parameters

gcell	The GCell into which create the AutoContact.
rp	The Component we want to access.
source	The AutoContact created on the `source` (returned).
target	The AutoContact created on the `target` (returned).
flags	Managed by this function: LocalFunctionFlag::DoSourceContact LocalFunctionFlag::DoTargetContact

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

Ordinary (non-punctual) METAL1 terminal: an AutoContactTerminal is anchored on the RoutingPad.
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.
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()

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().

AutoContact * doRp_Access	(	GCell *	gcell,
		Component *	rp,
		unsigned int	flags
	)

static

Parameters

gcell	The GCell into which create the AutoContact.
rp	The Component onto which anchor the access contact.
flags	Relevant 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()

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().

AutoContact * doRp_AccessPad	(	RoutingPad *	rp,
		unsigned int	flags
	)

static

Parameters

rp	The Component onto which anchor the access contact.
flags	Relevant 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(), 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().

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()

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().

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()

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().

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.

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 whithout any AutoContact (handled by the source/target of the wire).

_do_xG()

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

Referenced by GCellTopology::_do_xG_1Pad().

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()

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

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()

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.

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()

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.

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()

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.

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()

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.

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()

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.

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()

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.

void singleGCell	(	KatabaticEngine *	ktbt,
		Net *	net
	)

All the RoutingPads of the net are concentrated under a single GCell. This function assumes that all the terminals are in METAL1 (vertical), and link them two by two by horizontal wires.

References AutoContactTurn::create(), AutoSegment::create(), GCellTopology::doRp_AutoContacts(), anonymous_namespace{LoadGrByNet.cpp}::DoSourceContact, Session::getContactLayer(), Grid< GCellT >::getGCell(), KatabaticEngine::getGCellGrid(), RoutingGauge::getLayerDepth(), Session::getRoutingGauge(), Net::getRoutingPads(), Katabatic::KbHorizontal, Katabatic::KbVertical, and anonymous_namespace{LoadGrByNet.cpp}::NoFlags.

Katabatic - Routing Toolbox

Classes

Enumerations

Functions

Detailed Description

Enumeration Type Documentation

Function Documentation