当前位置：首页 > news >正文

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

news 来源：原创 2025/5/14 12:59:13

Q1:为了更高效过掉Calibre LVS，我们要求学员在chipfinish阶段需要先做Online LVS检查。该学员在做verifyConnectivity检查发现设计中存在大量的M1 VDD_CORE Un-Connect Pin的violation，具体violation如下图所示。

数字后端培训实战项目六大典型后端实现案例
在这里插入图片描述

根据Violation Browser可以很容易定位到这些violation都是出现在我们A55项目Tapcell上的M1 VPP Pin（Secondary PG Pin），而且的确这个M1 Pin没有和VDD_CORE有物理通路（缺VIA1）。
而我们项目的Secondary PG Pin走线是在powerplan阶段就做好的，为何这里会缺VIA1呢？

经过debug发现，powerplan.enc.dat中的确也有VIA1。但这个学员听咱们直播课一直强调powerplan做完后一定要做PG Connectivity检查并写GDS到Calibre 进行DRC检查这件事情，于是就开始插filler和添加dual power rail M1和M2之间的VIA1。

这个行为本身也没有问题，而且这个学员也记得这个加过dual power rail VIA1的项目数据仅仅是拿来验证PG连接性检查，但他在想不就一个VIA1嘛，我可以通过命令来批量删除。删除后仍然可以继续使用这个database来接着做后续其他流程。

set box [dbGet top.fPlan.box]
set via1_list [dbQuery -layers 1 -objType sViaInst -areas $box]

dbDeleteObj $via1_list

但他没想到的是设计中除了power rail上存在 special net VIA1，Tapcell的Secondary Pin也有VIA1，而且也是special route的类型。

routePGPinUseSignalRoute -nets VDD_CORE -pattern trunk -maxFanout 8 -nonDefaultRule vddl_rule}
setAttribute -net VDD_CORE -skip_Routing trueconvertNetToSNet -net VDD_CORE

数字后端实现之Innovus中open net原因解析及解决方案

那既然Tapcell上的VIA1 VDD_CORE也被删了，我们是不是可以再重新对secondary pg pin VPP进行绕线呢？

routePGPinUseSignalRoute -nets VDD_CORE -pattern trunk -maxFanout 8 -nonDefaultRule vddl_rule
使用上述命令绕线后的结果如下图所示。

在这里插入图片描述
数字IC后端设计实现之分段长clock tree经典案例

此时我们看到大量M2的drc violation。这里主要有两个原因：

1）原来secondary pg pin走线部分的net shape类型是patch wire

在这里插入图片描述

2）当前设计已经有信号走线，新绕的PG Routing与现有的signal routing存在drc violation

而且细心的同学还能看到当前DRC Violation还存在不同color的M2间距不够问题。这个就是我们一直所说的un-colorable问题。

在这里插入图片描述

所以不能在现有chipfinish的数据中再做一遍VPP pin的绕线。如果非要这么做，必须提前把原来VPP pin对应的net routing删掉，然后再重新做secondary pg pin的routing。

在这里插入图片描述

但你会发现即便这么做，你还会看到如下所示的drc violation——M2 min step violation。

在这里插入图片描述

仔细对比后你会发现部分VPP pin走线受边上信号线的影响，走出来的net shape pattern跟原来不一样了。

在这里插入图片描述

遇到这种情况还得根据DRC Violation Marker来筛选到影响到它走线的信号线。

在这里插入图片描述

那遇到本案例出现的VIA1丢失问题，我们是否还有更便捷的方法呢？
答案是有的。我们可以直接打开powerplan.enc.dat，通过defOut写出所有powerplan信息，再把这个def文件defIn到最新的database后重新做下ecoRoute即可。

在这里插入图片描述

Q2: 在低功耗四核A7 Top Hierarchical Flow实现中，子模块cortexa7core的ETM Model应该使用ideal还是postCTS的？还有placement阶段和CTS阶段a7core的etm lib是否需要更换？如何更换？

在这里插入图片描述

PreCTS阶段a7top可以使用子模块ideal的etm，此时不需要对子模块设置set_clock_latency。
如果这个阶段使用的是a7core postRoute的etm，那么就需要对cpu子模块设置一个负值的clock latency，其值约为子模块a7core内部clock tree的平均长度。

在这里插入图片描述

咱们社区a7top在preCTS阶段设置的子模块clock latency命令如下所示。

set_clock_latency -0.49 u_cortexa7/cortexa7core_0_u_cortexa7core_0/CLKIN
set_clock_latency -0.49 u_cortexa7/cortexa7core_1_u_cortexa7core_1/CLKIN
set_clock_latency -0.4 u_cortexa7/cortexa7core_2_u_cortexa7core_2/CLKIN
set_clock_latency -0.4 u_cortexa7/cortexa7core_3_u_cortexa7core_3/CLKIN

如果preCTS阶段使用的是子模块ideal etm，CTS阶段需要换成postRoute的etm。更换的方式可以使用类似mmmc创建方式，创建一个新的view即可。

Q3:对于下图所示的从CPU2到A7 Top顶层寄存器D的一条timing path，它的WNS是-73ps。请问应该如何看这个timing report，以及如何修复这类timing path的violation?

在这里插入图片描述