StarRC LEF DEF flow錯誤Debug經驗分享

在研究生階段曾流過很多次片，感覺后端設計中最關鍵的就是后端Flow了，尤其是PR階段，與PR相比，綜合階段的腳本就簡單太多了。

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

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

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

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

Foundary提供的RC提取文件有以下幾個：

Sample_map文件內容如下：

DEF文件和nxtgrd文件如下：

顯然是不能用上面的那個Mapping file的。

而上面那個Mapping file是給itf2tluplus轉換用的?。?！

那么StarRC的這個Mapping file應該怎么寫呢？

審核編輯：劉清