StarRC LEF DEF flow错误Debug经验分享

在研究生阶段曾流过很多次片，感觉后端设计中最关键的就是后端Flow了，尤其是PR阶段，与PR相比，综合阶段的脚本就简单太多了。

为了实现流片，当时从零开始搭了从RTL一直到GDS还有signoff、DFT...的完整flow，中间曾发现过一些非常Critical的Flow bug或者工艺上一些非常值得注意的点，感觉非常吓人，因为这些很可能导致芯片变成砖头，几十万的流片费很可能就打水漂了。

个人觉得没有Bug的Flow是不可能存在的，无非是它的影响大小的问题，所幸的是当时的流片都成功了。虽然基于当时开发的Flow设计出的芯片流片测试得到的结果是成功的，可是随着认知的深入，发现其实之前研究生阶段开发的Flow还是有一些问题的，也有很多可以优化的空间，比如可以进一步提高Flow的可重用性以及灵活性。再比如Signoff的时候都应该Check哪些东西（非常关键），这些内容在来了Nvidia之后，发现需要Check的东西蛮多的，当时研究生的时候signoff的内容不够完整。

尤其是signoff的时候一些input file的准确性如何去保证，这个非常关键，因为如果input file本身就存在一些问题的话，那么你signoff的结果即使是PASS的，那么也是没有意义的。之前公司里面也发现了一个会影响RC / Timing signoff的Bug，它并没有被其他任何的signoff Check所抓出来，因此感觉问题非常恐怖，深感后端需要注意的东西非常多，一定要小心，多持怀疑态度！！。

另外，在研究生的时候，也有发现Foundary提供的某些输入文件之间不是特别的Match（其实可以写一些脚本来自动check），这里分享一个StarRC跑LEF DEF flow的时候遇到的一个例子以及Debug的步骤与经验。

Foundary提供的RC提取文件有以下几个：

Sample_map文件内容如下：

DEF文件和nxtgrd文件如下：

显然是不能用上面的那个Mapping file的。

而上面那个Mapping file是给itf2tluplus转换用的！！！

那么StarRC的这个Mapping file应该怎么写呢？

审核编辑：刘清