不知重会是何年：来自四旬老母的技术指导

题记：四旬老母是个技术实力派富婆，实力是一颗颗TO熬出来了，而论及富有，是富到那种如果她有心，驴乐意去韩国或泰国重造后去侍奉的地步。四旬老母有严重拖延症，在驴臭不要脸持之以恒地催逼下，终于得四旬老母多年修炼之真经。深谢四旬老母之垂怜，祝四旬老母容颜永驻。

Floorplan

要做好floorplan需要掌握哪些知识跟技能？

首先熟悉data flow对摆floorplan 有好处，对于减少chip的congestion 是有帮助的，但是也不是必需的，尤其是EDA工具快速发展的当今，比如Innovus 最新的MP特性，可以自动对cell和macro 一起做place，结果相当不错，省了很多事情。

其次，需要了解 design的 power mesh，工艺的DRC rule ，IP 的base layer的spacing rule，memory能否abut ，IP channel 里摆放的cell 供电够不够，最小的spacing 可以到多少， channel里的resource 够不够， analog IP 摆放的位置跟pad 的关系， customer routing 好不好出，这些都是做 top floorplan 时需要预先考虑的。

通常，遇到floorplan问题，大致的debug步骤跟方法有哪些？

Floorplan 的问题主要会导致overflow 偏高，或者timing 较差。timing较差的话可以通过看timing path 分析DFF和IP的关系，来得出IP摆放是否合理。如果用的是Innovus, 可以用ameba view 来查看 module 的分布，看看什么module 被扯的很散来得出IP没有摆放合理。

如果是overflow 比较差，可以通过查看overflow 的hotspot 来观察hotspot的分布，还有 hotspot所在的module。现在innovus 对于hot spot的module都可以很好地通过降低module local density的方法处理得很好。一般的 hotspot 基本上都是由穿过该区域的routing 引起的，这样就需要考虑到IP的摆放是不是有违dataflow。

如何衡量floorplan的QA?

Floorplan的QA 主要是在不影响timing 和congestion的前提下合理布局使得芯片面积可以尽量小。net length, timing result 都是衡量floorplan的标准

innovus 提供了很多方便的button来摆放memory 比如等距离alignIP ，对齐IP，非常灵活。
另外有很多IP之间的customer routing 需要在floorplan阶段就考虑进去， innovus 在customer routing 上也有很方便的各种button ，比如从选中的线取名字autofill the net name. 可以指定想用的via type，指定宽度或者NDRrule 自动加 shielding, 在画线的时候还可以show 出 target pin与当前所画shape 之间的飞线，还可以auto snap shape 到pin上，这些都可以省去很多手工操作。
另外通过预先画好region，再planDesign的方式控制同一个hierarchy的memory 摆在一起。
更简单的方法就是通过mix\_place 设好 memory的spacing rule，还有加soft blocakge和 hard blockage的range，就可以直接把memory和 standard cell 摆好，完全不需要手工操作。

WeChat Image_20210422101747.jpg

Placement

要做好placement需要掌握哪些知识跟技能？

place基本分两步来做： coase placement 跟 opt. 这些东西在innovus 只要设好了process相关的default setting，如果不是特别critical 的design， tool都会handle的很好，不需要手工干预什么。

遇到critical的design，需要分析local density，congestion 和timing，需要注意的是，在place 阶段 clock都是ideal的，所以很多icg 的timing 是看不精确的，只有到cts 做完之后才能看到这些icg 的精确timing，所以需要对critical icg 额外地加一些clock gating check的margin。

通常，遇到placement问题，大致的debug步骤跟方法有哪些？

placement 遇到的主要问题是timing，还有一些place导致的潜在的DRC问题。

如果是timing问题，首先看timing report，如果logic level很长，那就需要大概估算下当前的frequecy 是不是可以meet，需不需要前端重新综合；如果本身logic level 不长，但是有很多buffer在path上，那要看下这条path是属于一个hierarchy还是多个hierarchy，属于一个hierarchy的话在ameba view里看下这个hierarchy 在place之后的分布，如果分布的比较散，注意看下是因为什么原因导致分布的不好，一般有可能是IO的place 和macro的floorplan没有做好，把跟两块都有联系的logic 扯的太远，所以需要调整floorplan。如果调整floorplan也无法解决，可以尝试加useful skew 的方法来meet timing。
另外在stdcell 区域看到的congestion的hot spot要格外注意，有可能是复杂的mux 放在一起导致的，需要加额外的module padding，或者需要前端禁用pin density高的cell 重新综合。

如何衡量placement的QA?

placement的目标是在帮后续优化留够margin的基础上尽可地提高density 使chip面积最小化。place的QA主要靠后续CTS, routing的结果来衡量。如果一个design place timing没问题，但是到了routing 却发现route不通那也没啥用。

Innovus的placement可以根据congestion有效降低local density。

Innovus在根据timing做place 方面的表现非常抢眼，可以根据对timing critical的path进行集中的place达到合理的module分布。
Innovus还提供了early clock flow，即在place 之前就把ccopt的setting和ccopt spec 读进design，然后设一些earlyclock flow的setting，那么在coarse place之后， tool就会根据目前flip flop的摆放开始build tree， NDR的routing 所需要的资源也会比一般的place 估计的更准一点。clock routing 引入的congestion 也可以在早期得到处理。
Innovus可以在place阶段通过auto useful skew 自动进行clock latency的调整，使得timing critical的design 的timing 不再难做。此步骤会生成latency.sdc的文件，用该文件报的timing就是已经把clock latency算在内而得出的。之后在生成ccopt spec的时候，该文件也会自动转换成ccopt spec里的clock pin的insertion delay, ccopt也会honor这个skew. early clockflow 和 auto useful skew 是一对好伙伴，一起使用效果更好哟。
在advanced node上一些因为place导致的后期的routing和pg pin access （via pillar）和pg 之间的DRC， innovus 也可以在早期就detect到，通过checkPlace还可以报出这些violation。
Innovus还有个比较厉害的功能叫layer promotion 会自动把critical path 的early global routing 的layer promote 到高层去，使得一样的距离net上的delay更小。而且这个layer 的promotion 会一直keep到routing stage 会在真正的routing 的时候 honor这些routing 的promotion。

WeChat Image_20210422101820.jpg

CTS

要做好CTS需要掌握哪些知识跟技能？

common sense就是知道CTS在干嘛， CTS就是build所有clock的clock tree 使得理想情况下clock能同时到达所有的FF，然而现实没那么理想，到各个FF的clock总是有长有短，所以只要求这个长短在一定的范围内即可，这个范围将要吞掉一部分在place中留下的margin。
要了解自己的design，知道其中的clock哪些是main clock, 哪些是test clock 或者频率较低的clock。对不同的clock 做不同的constrain 和setting 可以使CTS更加有效。比如对不critical的clock 不必设很严格的NDR，不用很大的width和spacing可以节省routing resource。此外要预知clock 对clock gating timing的影响，这些影响是在ideal clock 的时候看不到的。所以需要做一些特殊的setting使得这些icg 更靠近root 端以减小CTS对clock gating的影响。
要知道design中哪些clock之间有talk，那么这些clock 需要balance。IP内部的clock latency 需要设多少insertion\_delay等，情况太复杂不能一一赘述，总之一切都是以setup和hold能meet为首要目标。

通常，遇到CTS问题，大致的debug步骤跟方法有哪些？

CTS承上启下，遇到的问题一般情况比较复杂，既有可能跟place相关也有可能跟routing相关，因为default的CTS流程都会将clock routing上，然后做完clock routing之后再重新fix一下skew 和transition。

通常CTS遇到的问题，就是skew 比较大， latency比较长，

对于latency比较长，可以根据design 大小分析这个latency是不是合理，也可以看log 在第一步clusterting做完报出来的clock latency的最大值，如果clustering 做完latency 还比较小那么可以看看log 是在哪一步导致latency 突然变长进行具体分析。
可以查看skew在每一步的变化，在innovus 的log里可以搜索“Primary reporting” 这样的关键字来查看每一步做完之后 latency 和skew的变化，来分析是哪一步导致的问题。大多数问题都是在clock routing之后出现的，这个时候需要分析clock routing的setting是否合理，NDR是不是足够，还有看看clock cell有没有给对， driven是不是够大。
对于skew 较大、latency过长的问题还需要分析design的clock structure，看看有没有不需要balance的FF，比如一些clock generator 的FF 可以设ignore pin 从clock tree 中去掉。如果设了ignore pin 那么CTS是会修Clock transition 但不会跟别的FF做balance，如果设了exclude pin 那么就是完全不修transition在后面postcts 的时候修data transition。还有一些counter 可以设skew group，即这些FF相互之间balance 但是不跟别的FF balance，那么保证的counter之间的timing 可以meet 还可以不跟别的FF balance 不会被physical上较远的FF拉长。

如何衡量CTS的QA?

CTS的QA主要就是latency和skew ，好的CTS做完不会导致hold 插很多buffer，就说明skew是合理的。另外就是保证common path足够长，这个都是tool 在不复杂的情况下能保证的。如果情况复杂，就需要人为的干预做一些anchor buffer 并且fix 住， guide CCOPT 更好的balance。

Innovus 最NB的就是CCOPT， CCOPT的NB之处就是concurrent 优化timing和build tree，在build tree的过程中看timing 优化timing 然后重写skew tree 来meet timing。 ccopt 看到的critical 不是path 而是critical loop。一个timing loop里的slack之和除以stage number 具体可以参看user guide :).
做了ccopt 之后就可以很好地处理一下在place阶段处理不好的clock gating 的timing还有怎么都修不掉的setup，但是前提是得保证你的SDC 足够正确，要不然有false path 让ccopt 看到它会很努力的修这些false path，导致别的path 都被skew 了一轮，而且还会导致比较长的run time。所以好东西一定要好好的用起来哟。

WeChat Image_20210422101850.jpg

Route

要做好Route需要掌握哪些知识跟技能？

routing当然了解design 最高能routing到多少层，哪些层是double pattern，哪些层是厚的metal。还有 std cell 出pin多少层。当然这些你也可以不需要掌握，只要PG打好就是一个routeDesign 的事儿，至少你得知道你的process 吧，在route 的setting 里把相应的process指定好基本上default 的setting 就能handle 一个design了。

通常，遇到Route问题，大致的debug步骤跟方法有哪些？

遇到的问题主要有 runtime太久， run完之后short 和DRC 太多，还有就是routing之后timing degrade的问题。

run time如果太久的话可以查看下过程中的log里的DRC在哪个layer 或者是哪种类型，如果是底层layer比较多可以在routing之前的db上做个checkPlace 看看有没有一些place 没做好导致的routing DRC。如果出现在高层layer或者某种类型的DRC特别多，可以设少一点的end iteration 重新run下，快速得到一个中间结果看看高层的layer是什么问题导致DRC无法修掉。
在充分的routing和repair之后发现DRC和short比较多的情况下，也需要分析类型比较多的DRC是怎么导致的，如果是因为cell的摆放引起的，那么可以看checkPlace 能不能报出这些问题，如果能报出可以用refinePlace 重新把cell 移开，如果checkPlace 报不出可以自己写一些edge rule来挪开这些cell。
另外还有一些是从thin的layer 到thick layer跳层的大孔比thin layer的track 大，导致这些via 和thin layer routing的short 或者spacing的DRC。这些问题可以通过调整routing 的setting 来解决。
还有一些DRC可能是因为tool 的repair iteration不够引起的，可以通过ecoRoute-fix\_drc 再修一轮来fix 这些剩下来的DRC。
routing之后的timing degrade 是一个普遍的问题，原因很多，有的是因为congestion 区域太多，使得tool 自动detour了经过这片区域的net，使得net length 变长timing degrade. 还有就是SI 引起的timing degrade。这些问题都可以通过postroute 通过size up 一些cell 来修回来。

如何衡量Route的QA?

routing的DRC和timing 是routing 要meet的目标。 DRC要在手工可修的范围；timing 即使degrade也要在所留的margin之内。那么这样的routing就达标了。

Innovus routing最大的优势就是 DRC和calibre的correlation 非常的好，基本上calibre上的DRC在innovus 里都能被识别到。
另外目前的innovus routing还可以做到在routing的过程中优化timing使得routing的结果和postRoute 的结果 correlation 非常好。

WeChat Image_20210422101921.jpg