Q1：我需要将Innovus设计GDS导出到Virtuoso，但发现写出GDS的过程会报如下所示的警告。这里写出GDS使用的是Virtuoso (DFII) streamOut mapping文件！
Clock Gen模块Routing DRC，Timing分析及解决
streamOut tease.gds2 -mapFile cds2gds.map -libName DesignLib -structureName tp -stripes 1 -outputMacros -units 100 -mode ALL
Parse map file…
WARN: (IMPOGDS-391): Line 1: Illegal object Type drawing specified with layer NSWARN: (IMPOGDS-391): Line 2: Illegal object Type RES1 specified with layer NS
WARN: (IMPOGDS-391): Line 3: Illegal object Type FILTRGR1 specified with layer NSWARN: (IMPOGDS-391): Line 6: Illegal object Type drawing specified with layer DT
**WARN: (IMPOGDS-391): Line 7: Illegal object Type drawing specified with layer PI
这里的问题在于Virtuoso DFII这个layer map文件格式和Innovus需要的layer map格式不同！
cds2gds map文件内容如下：
------------------- cds2gds.map ---------------------
M1 drawing 15 0
M1 HOLE 15 3
M1 TRANS 15 18
M1 label 15 20
M1 res 15 22
M1 PR 15 26
M1 pin 15 32
M1 obs 15 34
M1 CHEXCL 15 35
M1 fill 15 36
M1 PLANE 15 45
M1 net 15 94
M1 vdd 15 0
M1 gnd 15 0
而Innovus需要的layer map格式如下所示：
--------------------------- streamOut.map -----------------------------
M1 NET 15 94
M1 SPNET 15 0
M1 PIN 15 32
M1 LEFPIN 15 32
M1 FILL 15 36
M1 FILLOPC 15 0
M1 VIA 15 0
M1 VIAFILL 15 0
M1 VIAFILLOPC 15 0
M1 LEFOBS 15 34
NAME M1/NET 15 20
NAME M1/SPNET 15 20
NAME M1/PIN 15 20
如果我们一开始连innovus这个layer map文件格式都没有，我们可以先用streamOut，不带mapFile选项，让工具写出一个默认通用的layer map文件，这个文件默认会输出在当前工作目录下，文件名为streamOut.map。
所以很容易看出这两个文件的差异之处。
小编已经把这两个文件的映射关系整理出来，具体如下所示。
vdd/gnd 0 (maps to metal SPNET)
pin 32 (maps to metal PIN)
obs 34 (maps to metal LEFOBS)
fill 36 (maps to metal FILL)
net 94 (maps to metal NET)
label 20 (maps to NAME/* in gdsStreamOut.map)
比如这里的label其实就是对应innovus layer map中的text。
一般来说foundary都会提供PR工具使用的layer map，包括ICC,ICC2,Innovus的layer map。但如果foundary确实不提供的，我们也可以根据Virtuoso DFII这个layer map文件来进行修改。
而且这个layer map还可以添加一些特殊的layer，比如TSMC 12nm M2/M3 P48 Layer，我们想要在GDS中看到PR阶段添加的P48 Layer，就必须在streamOut layer map中添加对应的映射mapping关系！
Q2: 在实际后端项目中，我们经常会遇到如下图所示的Macro或IP出pin位置的DRC Violation。
上图中的粉红色是M2的OBS，这个是在Macro lef中定义的。而且我们可以发现这些M2 OBS除了出pin位置预留出来，还有白色的一段间距，即出pin的M2 Metal和M2 OBS还有一个间距。
工具默认走线会走成上图右侧这种样式。出pin对应的走线工具要么直接用M2拉出来，要么就是在M2 pin上打VI2，再过渡到M3再拉出去。这里我们可以看到第一个Pin A走线后，工具会报它的走线M2和M2 OBS之间有Spacing的DRC Violation。但这种其实是假的DRC Violation。
一旦这种数量多起来，nanoroute engine就会花很大effort来优化这类假错，而忽略了那些真正需要修复的DRC Violation。
因此，遇到这种情况，我们需要更改这个Macro或IP的lef文件——将整个Macro都盖住M2 OBS，而且设置上SPACING 0。
这样处理后工具就不会报这类DRC Violation，也就不影响其他正常DRC的优化了。
- 在LEF文件中增加 “LAYER M2 SPACING 0”
- 在innovus 中使用如下命令来添加
add_cell_obs -cell -rect {x1 y1 x2 y2} -spacing 0
Q3: Route后Innovus中看到如下图所示的ViaInPin DRC Violation。请问这类DRC Violation应该如何修复？
数字IC后端手把手实战教程 | Innovus verify_drc VIA1 DRC Violation解析及脚本自动化修复方案
看到这个layout，我们马上就知道这是一个Double Pattern工艺。图中的红色是M2，红色带绿色边框的是M2的另外一张Mask（传说中的pre-color）。
而且看起来就像咱们社区T12nm的工艺！M1-M3是DPT Layer，M2有M2_Mask1和M2_Mask2。这类DRC Violation是报VIA2不在标准单元出pin范围内。大家还记得之前小编之前分享的Innovus，ICC和ICC2三个工具控制标准单元出pin走线的教程吗？这个也是一种解决方案。
如果使用上述routing选项后还是有很多这类ViaInPin DRC Violation，大概率是相关net有ndr约束。我们可以按照下面的流程来排查和解决。
如何用工具自动修复数字IC后端设计实现绕线后的Physical DRC
1）对于FinFet工艺，我们需要确认下工艺技术库tech lef/tech file中没有对低层M1-M3 DPT Layer设置MINCUT rule或一些特殊NDR宽度的约束
2）如果tehc lef/tech file中没有上述的MINCUT和特殊NDR的定义，我们需要检查相关net是否是用户自定义的NDR约束
3）获取设计中所有NDR Rule
innovus 32> dbGet head.rules.name NDR_2W1S
4）获取所有有NDR约束的net
set ndr_2w1s_net [dbGet [dbGet top.nets.rule.name NDR_2W1S -p2 ].name]
5）创建一个新的NDR Rule，定义Double Pattern Layer的宽度是2W，对应的Via数量为1个
add_ndr -width_multiplier {metal2:metal9 2} \ -min_cut {via1:via2 1 via3:via8 2} \ -name NDR_new_2W1S
6）对上述抓取到的net添加新的NDR Rule约束
foreach n1 $ndr_2w1s_net { setAttribute -net $n1 -non_default_rule NDR_new_2W1S }
7）删除以上所有有DRC Violation的Via
8）设置nanoroute换孔选项
setNanoRouteMode –droutePostRouteSwapVia none
9）重新走线，带上fix_drc选项
ecoRoute -fix_drc重新ecoRoute后的走线结果如下图所示，此时Via2完全在标准单元出pin M2 pin shape范围内。
Q4: 下图所示为咱们社区复杂时钟clock gen项目的PT时序报告。
1）当前这条timing path是setup还是hold的报告？
2）请根据这条timing path的报告指出在PR实现阶段存在哪些问题？
3）这样的timing问题是否可以直接用dmsa flow来修复？为什么？