数字IC后端培训教程之数字后端项目典型案例分析

今天给大家分享下最近小编帮助学员解决的几个经典数字IC后端项目问题。希望能够对大家的学习和工作有所帮助。

数字IC后端项目典型问题之后端实战项目问题记录（2025.04.24）

数字IC后端设计实现培训教程（整理版）

Q1: 老师好，我这个placement后from A7CORE0的path报了-3ns的wns，高亮了这条路径之后是这样的，为啥a7core0的pin不直接连到iso cell，而是在a7core子模块上绕了一大圈再连到isolation cell？

在这里插入图片描述

这里有timing violation主要是长线带来的transition问题和delay问题。通过时序报告和layout高亮的路径上看，这条路径上没有任何的buffer和inverter，但工具在做early global route的时候却给规划了这么一条虚拟走线。

在这里插入图片描述
这种一半是属于工具early global route的bug。但我们自己在做子模块lef的时候也存在一定的瑕疵，某些layer的cell blockage没有盖全导致工具在cell blockage和pg pin中间见缝插针，规划了几根走线。

在这里插入图片描述

Q2:在跑Calibre LVS的时候出现了一条路径短路，是从vss到一个io口，在innovus里显示看了一会不知道咋看？

登录服务器端口看到这个学员已经把Calibre LVS Short报告导入到Innovus中，说明它已经掌握到LVS debug分析的基本流程。1）查看LVS short报告2）查看LVS GDS抽取报告3）查看LVS结果报告
在这里插入图片描述
随意选中一个short定位到具体位置后，从高亮的位置我们就可以看出PG Rail VSS和一颗cell输出pin对应的net短路了！而且是M1搭在一起了！

在这里插入图片描述
出现这个short主要原因是该学员在PR实现过程中使用了M1进行绕线！图中所示的short位置是Decap Cell的M1 VSS PG Pin。

如果使用的是普通Filler Cell也不会出现这个问题。但这个DRC正常在innovus中就可以检查出来的。我们接着在innovus中执行verify_drc，其结果如下图所示。

在这里插入图片描述
我们很清楚看到确实存在大量M1的short。

在这里插入图片描述
所以，我们如果想在当前database上做一些修复，我们可以在verify_drc后执行ecoRoute即可自动修复。当然我们还是建议在PR实现全流程严格控制global route和nanoroute的layer范围为M2-M6。

Q3: 跑完a7top routing后NanoRoute DRC Violation如下图所示。请问老师，这类DRC Violation应该如何分析和修复？

Innovus DRC Violation和Calibre DRC Violation分析和修复案例
在这里插入图片描述

通过DRC Violation定位，我们发现主要short集中在cpu2和cpu3附近。低层的M2-M5 Short Violation是因为该学员在摆放子模块两个power switch cell串链信号时使用了M1出pin，而子模块身上是盖了M1-M6的routing blockage。

在这里插入图片描述
所以低层的short可以通过调整子模块这两个io port的出pin layer（使用横向的Metal6即可）。值得注意的是子模块cortexa7core_1 改完io port位置后务必更新一个最新的lef给a7top，否则后续会出现open net的情况。

在这里插入图片描述
其他short主要位于以下红色框框区域。通过高亮可以发现这里的确存在异常——局部区域的cell density高达92%！

在这里插入图片描述
看到这里第一反应就是查看这个位置是否有region这种physical constraint。这里需要切换到floorplan view查看。因为某个module region规划得太小也很容易出现这种现象。

数字IC后端教程之Innovus hold violation几大典型问题
在这里插入图片描述
经过分析发现，该学员并没有在这个位置加region。

在这里插入图片描述
这时候我们就要分析为何工具在这个位置摆放了这么多cell?

这些cell是什么阶段加入的，加入的动机是什么？任何选中一颗cell后，我们可以报报看through这颗cell的timing path。

在这里插入图片描述

从这条timing path上看，我们就发现该区域存在大量PHC的buffer。从名字上看我们就知道这是工具修hold violation加入的。而且是为了修从cpu出发到顶层reg的hold violation而加入的。为了查看这个区域插入的hold buffer数量，我们可以在innovus中高亮出所有hold buffer（当然也可以通过dbQuery来获取指定区域的hold buffer）。从innovus显示的数据看，当前设计工具共插入了12304个hold buffer。

在这里插入图片描述
另外，我们还发现工具居然在子模块的output pin和isolation的I pin中间插了buffer! 也就是说即便要插hold buffer也不能插在当前这个位置。出现这个现象只有一个原因！a7top PR实现阶段使用的upf没有成功读入。

经过debug发现，该学员在跑placement时执行了free_power_intent命令！

为了对比不同阶段的hold buffer插入情况，我们又打开postCTS的数据，我们发现这个阶段做完hold violation fixing后总插入的hold buffer数量是7920个！

【思考题】为何两个阶段插入的hold buffer数量有个突变呢？

在这里插入图片描述
由于咱们提供的后端flow是在postCTS修hold之前会保存一个单独的database，所以我们此时可以打开修hold violation之前的hold情况。

经过分析发现的确存在FROM_CPU的hold violation，数值还比较大，而且TO_CPU的hold WNS都是大于0的！这是不是说明FROM_CPU和TO_CPU的timing往一边飘？是否有机会通过调整各个子模块的clock tree长度来优化呢？

在这里插入图片描述
所以，遇到这类情况，我们主要可以通过以下几种方法来修复。

1）调整clock tree，把顶层reg和子模块reg的clock tree做balance

2）PR Flow中控制CPU接口相关的hold violation fixing的范围，不要过修

3）在各个cpu子模块门口添加blockage array阵列（降低local density）

blockage array减轻congestion方法
最后，小编还发现如下这类timing path也存在过渡优化的情况！这类timing path完全可以设置multicycle path！

在这里插入图片描述
hold violation原因分析及hold violation修复方法
【思考题】在跑完placement后我们会检查isolation cell的input是否有被插入buffer或inverter，请问下图所示的路径是否正常？该学员反馈这类timing path存在异常，请问对吗？