最后的攻坚 之版图实现第五步 -- route

在经历了前面的place、cts和一些优化以后，工具进入到了route阶段，这也是apr里边的重要的auto-route步骤。

工具在这里很聪明，使用了化繁为简的策咯来实现绕线。生活中也有一个类似的问题，大家可以思考一下，如何把一个杂乱无章的毛线球快速的理顺？

通常的做法是，先解决主要问题，然后再是次要问题，最终是逐步修正细节。ICC的绕线很好的体现了这个化繁为简的策咯。

由于数据库的复杂程度不同，工具要想解决非常复杂的场景，那么就一定要将各种场景进行归一化，这种归一化的过程就是简化问题。为此，ICC工具构建了下面的一些名词和步骤来完成绕线：

· Glink

· gCell

· GRCs

· Overflow

· Global-route

· Track/layer

· Track-assignment

· Detail-route

· Verify route

喝口咖啡，一个个的来梳理下：

• Glink：Global link，

这是一个标准的曼哈顿距离模型：通过Glink任何连线都只有水平和竖直两种方向，这也是给后期做routingcongestion核算的一个重要参考信息。数据库里所有的连接关系都会以Glink的形式存在。作为真实route的起点信息。如下图所示：

• gCell: grid Cell ,

这个是工具在数据库里创建的虚拟格点cell，这是一个非常高效的处理。每一个die的形状大小都不一样，为了更好的进行绕线，工具基于工艺的信息，把die分割成无数个gCell的小边框。通常这个gCell的大小，是一个基于工艺site_row的数值的一个正方形。由于绕线都是基于绕线layer的，所以在每一个绕线层，die就被分割成了无数个小正方形，整个数据库包含的gCell的总数量计算公式是：

gCell_rount = layer_count * die_area/ (site_row_width * site_row_width)

如图所示

在上边的示例图里，如果考虑到有n层layer，那么数据库里就会有

gCells_count=  n * 254

而后，工具在每一个gCell的边界上核算穿过每个gCell边界上的Glink连接的需求，从而计算真实的routingcongestion

• GRCs：Global Routing Cells

这个就是将gCells分割回每层的一个信息，由于实际的绕线是通盘考虑的，gCells会更加的真实，就是支持绕线跳层，而GRCs是基于每层的计算，这个更适用于评估当前层次的routingcongestion。

• Overflow:

工具会对每一层的GRCs进行评估，所有穿过这个虚拟cell边界的需求和供给之间的差，公式如下

Overflow  = requirement – demand

工具会对可以看到，这个值可正：需求大于供给；可零：需求等于共计；可负：需求小于供给。对于后两种，绕线资源都是足够的，不是问题。如果为正值，这个就是真正意义上的congestion了。如下图：overflow为3的一个示例：

这里有24个水平方向的穿线（glink）需求，但是实际上只能提供21个资源，在所有的水平绕线稍层上（m2/m4/m6/m8），所以这里的overflow就是3

由于GRCs和overflow的评估是基于单个绕线层的，就水平方向而言，如果通过打开不同的layer，在同样数据库里overflow的结果是会发生变化的。视图里的overflow是所有打开版层overflow的总和，所以，开的层越多，数值大overflow的数量就越多，例如下图，注意看一下overflow3在打开不同版层时的细微变化：

• Global-route

这个是工具在绕线初始阶段，所使用的一个主命令，它的目的就是化繁为简，在经历过这个命令后，数据库里就会保存到Glink、gCell、GRCs和overflow的信息，并且在globalrouting 的结束，都会输出如下图的信息：

这是一个信息量很大的report，一起来梳理一下它的具体含义。

首先，工具将绕线的资源分为了两个方向，在一些工艺里边，允许板层的prefer-routing和none-prefer-routing并存，但是有些工艺不允许这么做，简单起见，假设当下的工艺是不允许none-prefer-routing的，那么，所有的绕线资源就是，这个层做对应的绕线方向的所有track数量的总和。

这个report里边，Both direction的数量，就是水平和竖直数量的总和，比如overflow的数值

Overflow:  4697  (Both) = 4606 (H)  + 91  (V)

Max，这个好理解，就是两个方向里边最大的GRCs overflow 的值。

GRCs   : 这里边有两个GRCs的地方。如下图：

第一个GRCs （GRCs = 21），是指所有overflow是2（Max）的GRCs的数量。

第二个GRCs （GRCs =  5681），是指所有overflow的GRCs的数量综合，（0< overflow <=Max）,在这个例子里，Max为2，所以细节就是，overflow 为2的GRCs是21个，overflow为1的GRCs是5660个，

在上图的最后一列有一个百分比，0.06%，这是说，在这个方向（版层）下，所有带来overflow的GRCs占所有当前方向（版层）整个GRCs的百分比，所以可以反推出来，当前方向（版层）的GRCs大概就是

9468333=5681 / 0.06%

这个数值对理解设计的数据有一定的帮助。

再看一下下图GRCs的report图例

对于两个方向的GRCs总和的计算公式如下：

5822  (Both) = 5681 (H) + 141 (V)

• Track/layer

Track是一个在floorplan里边出现的概念，是指当前绕线层的绕线可以使用的“轨道”信息。layer就是常说的绕线版层。由于工艺制作的区别，在某些工艺下，在不同的layer，所有track都是一样的，在近些年来的更为高级的工艺下，track开始在不同的layer出现了区别，layer越低，track之间的pitch就越小，layer越高则反之。

这个track就是前边核算overflow的供给。

基于上述理论，在规定的长度内（site_row），每一层的供给是可以不同的，如下如所示：在单位长度内M2和M4的track供给数量的区别很明显

• track assignment

有了global routing的信息，track assignment就简单了，穿过这个GRCs的glink连接被实现到了每层的对应的track上，但是，要注意一点，工具为了简化这一步骤，只是做了简单的track  assignment，所以，实现的速度很快，但是会有很多net shape都是overlap的结果，类似下图的结果

在这个有3个overflow的区域，这里有一个占用同一个track的两个net shape，这就是典型的short的绕线。

到这里为止，可以感觉到overflow对真实绕线的影响了吧。固然，一般的设计都不可能保证GRCs overflow是零（如果是零，理论上，在trackassignment之后，就不会有任何的short出现了，那样的数据库就真厉害了！），但是工具之所以这样做，只是为了简化track的步骤，后面还有大招，来修复细节问题。这就是下面要说到的。Detailroute

• Detail-route

能看到这里的同学都是好同学J

讲了半天，这里的detail route其实才是大家通常最先接触到的真实的router，在老一点的icc版本里边，就是就route_detail，由于新的工艺的要求，icc推出了一个route_zrt_detail的命令，来满足更复杂的工艺需求，原先的绕线就称为了classicrouter。现今，进入了icc2的时代，这个命令，又变成了route_detail，但本质上其实就是route_zrt_detail的演化版本。历史捋清楚了，下面就来看一下，这个命令的厉害。

书接上文，在track assignment结束后，由于工具的策咯不同，虽然所有的netshape都被创建了，但是由于GRCsoverflow的影响和绕线细节等问题，会出现大量的DRC问题。例如下例：

可以看到，这里会有非常多的DRC和short，基于前面的理论，这个现象其实也没有超出预期太多

所以，icc这个时候就会调用detail route来对这些DRC进行精修。这个就是detailroute要干的事情。

本质上来讲，如果绕线资源不够，short是不能被修复的，因为就单个GRC  cell而言，供给是一定的，需求也是死的，这两个是的差异是天生的，不能被克服的。

有趣的是，工具在将一切分割后的节点（track assignment），它又可以经寂静分隔开的GRCs进行二次、三次等重排。言下之意就是，在当前GRCcell出现问题的地方，可以去周边的GRC寻找出路，这其实就是典型的面积换short：迂回（detour），如下图的short演进过程：

这个从ICC的命令log可以清楚地看到这个动作的影响，如下例

可以明显的看到，数据库的总线长在不断的增加，但是对应的short实在不断地减少，如下图：

Detail  route之后再来看一下那两根short的绕线，如下图：

工具通过跳层。和迂回有效地解决了short。

这个GRCs的重组和的策咯看似简单，但是非常高效，通过借道和迂回可以有效地解决short。当然，天下没有免费的午餐，任何的detour都会增加timing的问题，这个时候，就需要postroute的优化，和PT的timing ECO了。但整体上来说，这个代价是值得的，通常都可以保证physical和timing同步收敛。

由于工具对GRCs的重组是有一定范围的，加上timing driven的需求，并非所有的short都可以被解决，尤其是在某些local short 数量很多的区域，工具是无能为力的。例如，如果要在一个非常密集的区域里，需要解决很多short，就要迂回绕线非常多的net，可以想象，要完全躲开这个高密度区域，才能解决这些short，这对于timing是很不利的。简而言之：没有解不掉的short，只有修不干净的timing。

除过对于short的修复，Detail route黑可以修复各种各样类型的DRC问题。简单的一个类型列表如下

• Verify_route

在detail route完成后，用户就可以使用verifyroute来检查绕线质量了，通过观察这个结果，来整体评估数据库的绕线质量，主要的关注点，还是那句老话：控制short。当然，别的类型也有注意，尤其是数量巨大的时候，有时候，由于某些配置的不合理，会导致在某些层的绕线质量显著增加，甚至会出现open，这个时候就要去好好的debug了。