文章右侧广告为官方硬广告，与吾爱IC社区无关，用户勿点。点击进去后出现任何损失与社区无关。
一转眼一年就过去了，今年你过的还好吗？有没有遇到生命中的贵人呢？如果有，请不要小气，大胆跟对方说声谢谢。真的只要这两个字就可以了。
人真的要时刻保持一颗感恩的心，感恩自己所拥有的一切，感恩那些曾经帮助过你的人，更要感恩那些总是给你设置障碍的人。因为他们都能够让你成才得更快，更早遇见那个更好的自己。
吾爱 IC 社区为了感恩各位读者一如既往的支持，还是老惯例，年底会有系列福利活动（年终千元现金红包抽奖 + 星球优惠活动）。年度现金抽奖活动下周会发布活动细则，敬请期待。
今天先分享社区知识星球的一个活动，这个活动是一直承诺给到大家的，而且一年正常就 2 次。所以，有兴趣的小伙伴要及时上车，错过就得再等大半年。另外，随着星球人数越来越多，为了给大家提供更好的服务，星球门票将逐步提高门槛，价格会越来越高。
目前知识星球已经拥有1420 位星友，即社区的老铁会员，已经是整个 IC 行业第一大付费高端技术交流社区, 终极目标是实现全员年薪百万。 **** 目前工作 8 年以上的优秀工程师都可以拿到 130 万 +****。 **如果各位还有没拿到这个薪资的，可以私信小编一对一辅导提薪 **（ic-backend2018）。
新用户优惠活动
新用户可以通过长按下方二维码领取 50 元 **** 优惠券加入知识星球。名额有限，仅有30个名额，先到先得。
老用户续费活动
如果你是星球老用户，可以长按下方二维码领取优惠券进行续费。后续续费价格一定比这个高。
介绍完知识星球活动后，今天小编给大家带来社区 IC 训练营项目的一个典型案例——ecoRoute 后 setup 的wns 变差近 50ns。
pt 修完 setup 和 hold time violation 后返回 eco 脚本到 Innovus 做 ecoRoute 之后的 timing report 如下图所示。从图中很清晰看到 reg2reg 这个 group setup 的 wns 高达 - 48.533ns。真的是惨不忍睹，其实我一看到这样的 report 就非常有信心，而且还非常开心，又有训练营实战案例了。
遇到这种这么大的 timing violation，一定是flow 上某个环节出大问题了。
那今天小编就跟大家分享下我是如何分析这个问题，解决这个问题的。希望今天的干货分享对大家有所帮助。
首先，一上来肯定就是调出 ecoRoute 的 log，目的很简单，就是找线索，收集证据，然后说服学员，最终提供解决方案。从 log 中先是看到如下的 WARN，这个警告是告诉我们功能检查被我们关掉了，即 flow 中的 LEC check 的开关被设置了 false。
这里顺带提一个脚本中把 CKND2D2BWP40P140 这个 cell size 成了 ND2D3BWP40P140。这个操作一定是在修 setup 或 transition。但这里存在一个潜在问题是把 clock cell 替换成普通 cell 了。
那什么时候我们需要把LEC check关掉呢？ 在我们做 ECO 时，可能的确需要把相位弄反，比如要把 buffer 换成 inverter。又或者对于 hierarchical flow，我们需要把子模块和顶层设计的相位都反相。虽然对于子模块来说，工具会看到时钟或者数据反相了，但由于拼起来相位还是不变的。
当然映入眼帘的第一个问题，并非是 timing 变差的原因。另外，这里小编重点看了 ecoChangeCell 和 ecoAddRepeater 脚本是否报错的情况。结论是 pt 返回来的脚本没有问题。这个检查是为了排除 PT 脚本出问题的可能性。
紧接着我们就可以看到另外一堆关于refinePlace的 Info，准确来说这里应该报 warnning。相信做过数字 IC 后端实现的工程师一定都见过这个警告。看到这里先别慌，我们继续往下看工具表演的内容。
翻了几千行之后，我们翻到了下图所示的 ERROR，代号 IMPSP-2021，内容是无法 legalize 70106 个 instance。这就是告诉我们当前工具发现有七万多的 instance 在搜索半径 115.200um 的范围内找不到 legal 的位置摆放。 同时还告诉你这可能是由于 padding overlap violation 引起的。当然很多时候原因不可信，仅供参考。
因此，在跑 flow 的过程中一定要看 log 的 ERROR。由于 innovus 的警告 warn 量太大，初学者往往无法辨别真假，所以警告部分内容只能通过慢慢积累经验来辨别真伪。
【思考题】为什么搜索半径是 115.2um？（128 条 row 高度）
同时，在 refinePlace 结束后工具会做一个 summary。主要内容有：
所以，小编之前一直叮嘱也出炉了相关的教程，在做 ecoRoute 时一定要特别关注工具 legalize 的 max cell displacement 或 max move 值。如果这个值超过 100um，就需要额外注意了。特别像咱们训练营的 CPU 高频设计，这个值还需要控制得更小。
下面这个案例分享也是社区 IC 训练营 Timing ECO setup degration 的专题，但情况不太一样，感兴趣的同学可以前往阅读。
Innovus 中 timing eco 后 setup margin 跑哪里去了?(知识星球福利活动)
如果在 place 过程或者 ecoRoute 阶段出现大批量的这种找不到合适位置的 WRAN，虽然最终不一定会有问题，但是整个 run time 会成倍增加。值得注意的是出现这种警告，工具最终也是有可能会把标准单元摆放好的，但可能会影响设计的 QoR。
在我们训练营项目中的 innovus 走 pt eco 流程时，走完 refinePlace 后紧接着要做checkPlace 的检查。这步就是用来检查整个设计中是否有 place 相关的 violation。
https://alidocs.dingtalk.com/i/team/QqWXw0n4YVY3gm31/docs/QqWXwVg3lZ9R5z31?corpId=dingcd9df953ab4a15574ac5d6980864d335# 「pt dmsa eco flow」
今天这个案例的 checkPlace 结果如上图最下面那段所示。这里面主要包括了以下几大重要信息。
关于 checkPlace 主要检查哪些事项以及各个 violation 的含义解析已经在下面这篇文章做过分享了。
我们正在招聘若干名年薪 100w + 的数字 IC 后端工程师
这里面重点提下，checkPlace 出来的结果一定要看 cell overlap 的情况。 如果这项不是 0，那一定有问题。需要打开 error broswer 来查看具体的 violation 情况。
看到这里，我们就非常明确了当前的 ecoRoute 结果是不可信的，因为 cell 都有上万个存在 overlap 的情况，更谈不上去 debug 具体 timing violation 的 path 了。
由于 pt 返回来的 eco 脚本没有毛病（上面第一步就检查过了），那么 legalize 出现问题大概率是设计中有大量 blockage 或者 region。当然还有一种情况是拿着插好 filler 的数据来做 refinePlace。真的有学员这么干，然后工具在做 refinePlace 时会报 density 超过 100% 的情况。这种其实一看就知道问题了。
所以，根据小编的项目经验，立马将 design 的 view 切换到 floorplan view，查看设计中是否有 region。因为小编知道这里面有个坑，当年第一次用 innovus 也是被坑过。好家伙，果然在预料之中，floorplan view 视图如下图所示。细心的同学一定发现这个 region 就是 dpu 模块的 region，而上面报一堆找不到 legal 位置的 cell 也是属于这个 dpu 这个 module。
那如何解决呢？
在做 refinePlace 之前移除这类 physical constriant。命令如下：
unplaceAllGuides
实际上 region 是用来 guide 工具做 placement 的一种 physical constraint。因此，placement 做完后就可以考虑删掉，对后续的 timing 优化没有太大的影响。
https://alidocs.dingtalk.com/i/team/QqWXw0n4YVY3gm31/docs/QqWXwVg3lgOV2z31?corpId=dingcd9df953ab4a15574ac5d6980864d335# 「guide，region，fence 概念解读」
经过这么一顿操作后，重新再来一遍，顺利把 pt 返回来的 eco 脚本顺利做进去了。接着就 happy 去抽 RC，继续跑 PT 检查 timing。经过检查发现 timing 真的被修复得差不多了。
之所以要在 pt eco 之前把 region 这些 physical constraint 删掉，主要原因是某些插入的 hold buffer 的 hierarchical name 可能是刚好是我们设置的 region 的 group 里，但它真正应该摆放的位置是在其他模块里，此时工具就会发现受 region 的限制，refinePlace 时会出现工具找不到合适的 legal 位置，从而可能会出现 setup 全线崩溃的情况。
https://alidocs.dingtalk.com/i/team/QqWXw0n4YVY3gm31/docs/QqWXwVg3lqEWRz31?corpId=dingcd9df953ab4a15574ac5d6980864d335# 「优化 Timing 方法之 path group 和 region 用法」
好了，今天的内容分享就到这里。另外，因为公众号更改推送规则，小编分享的每篇干货不一定能及时推送给各位。为了避免错过精彩内容，请关注星标公众号，点击 “在看”，点赞并分享到朋友圈，让推送算法知道你是社区的老铁，这样就不会错过任何精彩内容了。
如果你想和小编有更进一步的沟通交流的机会，欢迎加入小编知识星球，让我们一起学习成长，共同进步。相信在这里能让你成就一个更完美的自己。
小编知识星球简介（如果你渴望进步，期望高薪，喜欢交流，欢迎加入 ****）：
在这里，目前已经规划并正着手做的事情：
吾爱 IC 社区知识星球星主为公众号” 吾爱 IC 社区” 号主，从事数字 ic 后端设计实现工作近十年，拥有55nm,40nm,28nm,22nm,14nm等先进工艺节点成功流片经验，成功tapeout 过三十多颗芯片。
这里是一个数字 IC 设计实现高度垂直细分领域的知识社群，是数字 IC 设计实现领域中最大，最高端的知识交流和分享的社区，这里聚集了无数数字 ic 前端设计，后端实现，模拟 layout 工程师们。
在这里大家可以多建立连接，多交流，多拓展人脉圈，甚至可以组织线下活动。在这里你可以就数字 ic 后端设计实现领域的相关问题进行提问，也可以就职业发展规划问题进行咨询，也可以把困扰你的问题拿出来一起讨论交流。对于提问的问题尽量做到有问必答，如遇到不懂的，也会通过查阅资料或者请教专家来解答问题。在这里鼓励大家积极发表主题，提问，从而促进整个知识社群的良性循环。每个月小编会针对活跃用户进行打赏。
最重要的是在这里，能够借助这个知识社群，短期内实现年薪百万的梦想！不管你信不信，反正已经进来的朋友肯定是相信的！相遇是一种缘分，相识更是一种难能可贵的情分！如若有缘你我一定会相遇相识！知识星球二维码如下，可以扫描或者长按识别二维码进入。目前已经有 1423 位星球成员，感谢这1423位**童鞋的支持！欢迎各位渴望进步，期望高薪的铁杆粉丝加入！终极目标是打造实现本知识星球全员年薪百万的宏伟目标 **。
欢迎关注 “吾爱 IC 社区”
微信号：ic-backend2018
