今天给大家分享下最近几个典型的数字后端项目案例，希望对大家的学习和工作有所帮助。

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

Q1:星主，有啥办法可以看到refinePlace或者ecoPlace都动到了那些inst吗，log里只会有mean和max move，是不是只能写脚本抓全部inst，看看前后inst位置有没有变化?

工具本身不支持报告所有被挪动的instance。但一般做timing eco阶段我们要密切关注log中报告的instance挪动的数量。这个数量要尽量小，否则对于高性能设计很容易出现timing恶化的情况。

顺带分享下高性能设计在做Timing ECO或Function ECO时的一个策略——做之前先把原先的所有instance都fixed住，这样可以确保后续refinePlace或ecoPlace过程不会动到其他不该动的instance。


set all_cells [get_cells -hier -filter "@is_hierarchical == false " -physical ]
set fixed_cells [filter_coll $all_cells "@is_fixed == true"]
set_attr $all_cells is_fixed true -q
source  $timing_eco_script
place_eco_cells  -eco_changed_cells -legalize_only -legalize_mode

refinePlace和ecoPlace使用区别和联系
Q2:老师好，我t28项目routeopt一直优化不下去，我重新做了三次，routeopt连续优化了五次，第一次优化需要4个小时，wns从-2.0ns多变成-0.6ns，之后再优化一直在在0.6左右，wns最好的一次在400多ps，您可以看看是什么原因吗 ?

在这里插入图片描述
单纯从上面的timing summary报告，我们发现WNS最大的是在reg2reg group path上，而且WNS高达-674ps！

而且我们看到当前设计的Density也才62.5%。这说明当前violation并非面积不够导致的。

接下来我们具体来看看这条674ps timing violation的具体路径以及layout上这条path是如何走的。

在这里插入图片描述
史上最全的数字IC后端设计实现培训教程（整理版）

把这条timing path高亮在layout上后如下图所示：

在这里插入图片描述

从这里很直观看到绕线后存在比较严重的routing detour！

从上面那条timing path的具体路径也可以看到存在一大堆的buffer和inverter。下图所示框出来的部分全部都是普通inverter（从逻辑设计角度，这些inverter都是不需要的）！

在这里插入图片描述

这里也可以用咱们直播课讲的快速获取timing path逻辑深度和普通buffer，inverter的脚本来快速获取到buffer和inverter的级数。

在这里插入图片描述

从上面获取的结果得知，这条timing path上存在30颗buffer，inverter! 所以这条timing path是极度不合理的。

那为了定位哪个阶段开始timing变成了，我们需要打开postCTS后的时序summary。

从下面这个postCTS的timing summary报告看到postCTS做完timing是一片大好！所以问题就出现在绕线阶段。

在这里插入图片描述

Q3:拿到一个新工艺，PR物理实现阶段要使用的ENDCAP Cell，Tap Cell，Antenna Cell，长clock tree使用的clock inverter cell应该如何确定？这些cell名字要从哪里获取到？还有我们训练营项目中设置的那些dont use cell 列表又是从哪里获取的呢？

在这里插入图片描述

Q4：请问如下所示的Metal Short应该如何修复？

在这里插入图片描述

Q5: 在做T12nm A55 chipfinish后发现存在好几个VDD_CORE的open问题，而且看起来是出现在power off domain中带secondary pg pin的tap cell VPP pin上，请问应该如何修复？另外做Calibre LVS检查也报告了有个io port和VSS short问题，高亮如下图所示，请问这个是什么问题呢，应该如何进行修复？

在这里插入图片描述

从高亮的图形及位置很明显是报在tap cell的VPP pin上。而且这个学员发现这个M1 VPP Pin已经通过via1，m2，via2和m3连通了，所以该学员认为这个不能算open。
我们说判断一个pg pin（逻辑连接到VDD_CORE）是否open，核心是看它和最高层的VDD_CORE是否有实际的物理连接通路。所以，在咱们T12nm A55项目中这个M3还需要连接到M9的VDD_CORE!

下图所示为其他tap cell VPP Pin连接正常的截图。从这张图可以看到连接Tap Cell VPP pin的M3会通过via3过渡到M4，然后在拉到power switch cell上的Global VDD_CORE mesh上（M1到M9的物理通路就建立起来了）。

在这里插入图片描述

关于pd_dwn_ack串链信号跟VSS Short问题，小编通过选中这个io port，发现它的逻辑net是VSS，这就说明这根信号目前是连接到1’b0！但对于需要连接到1’b0的信号，都必须通过Tie Low cell再到VSS。
这类串链信号如果设计中的确要用到，则需要连接到power switch cell上的Nsleep信号上。

在这里插入图片描述

所以这里大概率就是该学员在PR Flow中没有做addTieHiLo这个步骤。而且对于设计中包含多个power domain的设计，还需要分别对每个power domain来添加tie cell。
setTieHiLoMode -prefix Tie -maxFanout 8 -maxDistance 20 -cell “TIEHBWP16P90CPD TIELBWP16P90CPD”

##addTieHiLo

addTieHiLo -powerDomain PD_PSO
addTieHiLo -powerDomain PD_AW_ON

Q6: 星主，用的是innovus请教个两个问题①我的模块是细长的模块，模块高度达到8000um，我想极限做短时钟latency 有没有什么方案？②我看了cts skewgroup报告，比如skewgroup报告里某个时钟显示的最大latency 700ps，但我打开cts timingreport 报告里面，从port端口到该时钟某个reg的latency达到了900ps，和skewgroup里不一致，这个是什么原因？
细长的模块通常有DDR，显示相关控制芯片。这种形状通常会有明显的timing和congestion问题。
想得到timing和drc上一个比较好的结果，我们就需要从以下几方面入手：
1）clock tree长度做到最短。clock tree上主干时钟的clock cell都需要手工引导工具做摆放。这种做法类似咱们社区复杂时钟clock gen项目使用的manually place clock cell方法来做短clock tree长度。
2）设计中的各个module摆放也需要按照data flow人工干预，比如通过添加region等方式。

clock tree latency不一致主要有两个原因：
skew group report里面的clock tree latency是不包含ocv derating的
PR flow中使用useful skew也会导致工具会调整clock tree长度来优化timing

Q7: 匿名用户提问：星主，想请问通常会对icg 的enable close pin 设定负的insertion delay去减少icg 的setup time 问题，还是对于icg带的sink 端设insertion delay 才是正确的？

对ICG的clock pin设置insertion delay，但需要注意这样设置后，clock tree只能长到ICG 时钟pin，从ICG输出到后面寄存器Clock pin这段会漏clock tree。所以需要在ICG输出定义时钟，并把ICG和后面带的寄存器摆放在一起。

clock skew特别大，都是什么原因引起的？