在研究生階段曾流過(guò)很多次片，感覺(jué)后端設(shè)計(jì)中最關(guān)鍵的就是后端Flow了，尤其是PR階段，與PR相比，綜合階段的腳本就簡(jiǎn)單太多了。

為了實(shí)現(xiàn)流片，當(dāng)時(shí)從零開(kāi)始搭了從RTL一直到GDS還有signoff、DFT...的完整flow，中間曾發(fā)現(xiàn)過(guò)一些非常Critical的Flow bug或者工藝上一些非常值得注意的點(diǎn)，感覺(jué)非常嚇人，因?yàn)檫@些很可能導(dǎo)致芯片變成磚頭，幾十萬(wàn)的流片費(fèi)很可能就打水漂了。

個(gè)人覺(jué)得沒(méi)有Bug的Flow是不可能存在的，無(wú)非是它的影響大小的問(wèn)題，所幸的是當(dāng)時(shí)的流片都成功了。雖然基于當(dāng)時(shí)開(kāi)發(fā)的Flow設(shè)計(jì)出的芯片流片測(cè)試得到的結(jié)果是成功的，可是隨著認(rèn)知的深入，發(fā)現(xiàn)其實(shí)之前研究生階段開(kāi)發(fā)的Flow還是有一些問(wèn)題的，也有很多可以?xún)?yōu)化的空間，比如可以進(jìn)一步提高Flow的可重用性以及靈活性。再比如Signoff的時(shí)候都應(yīng)該Check哪些東西（非常關(guān)鍵），這些內(nèi)容在來(lái)了Nvidia之后，發(fā)現(xiàn)需要Check的東西蠻多的，當(dāng)時(shí)研究生的時(shí)候signoff的內(nèi)容不夠完整。

尤其是signoff的時(shí)候一些input file的準(zhǔn)確性如何去保證，這個(gè)非常關(guān)鍵，因?yàn)槿绻鹖nput file本身就存在一些問(wèn)題的話(huà)，那么你signoff的結(jié)果即使是PASS的，那么也是沒(méi)有意義的。之前公司里面也發(fā)現(xiàn)了一個(gè)會(huì)影響RC / Timing signoff的Bug，它并沒(méi)有被其他任何的signoff Check所抓出來(lái)，因此感覺(jué)問(wèn)題非常恐怖，深感后端需要注意的東西非常多，一定要小心，多持懷疑態(tài)度??！。

另外，在研究生的時(shí)候，也有發(fā)現(xiàn)Foundary提供的某些輸入文件之間不是特別的Match（其實(shí)可以寫(xiě)一些腳本來(lái)自動(dòng)check），這里分享一個(gè)StarRC跑LEF DEF flow的時(shí)候遇到的一個(gè)例子以及Debug的步驟與經(jīng)驗(yàn)。

Foundary提供的RC提取文件有以下幾個(gè)：

Sample_map文件內(nèi)容如下：

DEF文件和nxtgrd文件如下：

顯然是不能用上面的那個(gè)Mapping file的。

而上面那個(gè)Mapping file是給itf2tluplus轉(zhuǎn)換用的?。。?/p>

那么StarRC的這個(gè)Mapping file應(yīng)該怎么寫(xiě)呢？

審核編輯：劉清