一個前端數字IC工程師的一天

這是IC君的第9篇原創文章 （同步於公眾號 icstudy）

一個數模混合設計工程師的日常一天

集成電路設計（Integrated Circuit，簡稱IC）一般分為數字IC設計、模擬IC設計和數模混合IC設計。數字IC設計一般又會進一步細分為前端設計（Front-end Design）和後端設計（Backend Design）。

前端數字IC工程師的工作一般包括電路規範（Spec.）的撰寫，電路架構的設計，電路的實現以及驗證、綜合出符合要求的電路網表（netlist），最後按一定的工作規範要求提交netlist 給後端部門。

作為一個前端設計工程師的一天是怎樣度過的呢？

早上九點打卡進入公司，到了公司座位後，多年養成的習慣是首先打開郵箱瀏覽一下郵件，看看昨天下班後有沒有收到新的郵件，是否有比較緊急的事情需要優先處理的。今天還算不錯，只有幾封郵件，沒有特別緊急的事情；不過有一封郵件是驗證部門同事發的，郵件內容是我負責的一個IP昨天跑完的某個test case 有結果不對。

瀏覽完郵件後，就要對今天的工作任務做個簡單的計劃。每天早上花5~10分鐘進行簡單工作計劃是很有必要的，既可以避免漏掉一些重要的事情，又可以清楚知道當天工作內容的輕重緩急。

今天主要有三件事：

一、同仁負責的一個IP 有一個bug，需要對neltist 進行ECO 改掉，約好今天協助他一起解掉；

二、前面說的負責IP 有test case 結果不對，需要今天跟驗證部門的同事儘快溝通解決掉；

三、今天下午四點有個技術討論會，這是昨天就已經約好的會議。

工作計劃安排好後，就是擼起袖子加油幹了。

首先介紹下ECO，ECO修改是基於標準單元設計流程中的一步。如下圖所示：

ECO（Engineering Change Order）中文意思是工程改變命令，這一步實際上是正常設計流程的一個例外。它是對設計的layout進行局部的小範圍的修改和重新布線，而不影響到設計的其它部分的布局布線，所以其它部分的時序信息沒有改變。

根據功能的不同，ECO 可以分為功能改變和非功能改變。功能改變是指由於來自客戶對設計的追加需求（spec改變）或者設計的最後階段發現晶元存在 bug 的情況下進行的 ECO; 而非功能改變則是為了在不改變 RTL 網表的基礎上修復部分時序以及串擾等問題而 做的 ECO。大規模的IC設計中，ECO是比較有效率的省時的方法，通常都會被採用。

昨天已經跟同事了解到，bug 是因為跨時鐘域引起的，改起來比較簡單。但是因為這個bug 是在netlist 交給後端部門後發現的，為了節省時間，不能再重新synthesis，只能通過ECO 的方法來改正。Bug不可避免，也無法知道會在什麼時候被發現，所以ECO 是前端設計必須掌握的一項重要技能。ECO 完neltist之後，還要進行LEC( Logic Equivalence Checker是Cadence的一款形式驗證軟體) 檢查，通過了LEC檢查，才算是ECO 完成。LEC環境設置好後，丟job下去跑，等結果出來確認即可。這時就可以去做別的工作了。

接下來要去debug 驗證部門同事反饋的testcase了。開始debug 之前先跟驗證部門同事做了簡單的溝通，確認了testcase 的設置情況，他建立這支case 要驗證的電路功能，以及他是否有輸出（dump） 我們想要的RTL waveform。這樣的溝通對提高工作效率是非常有必要的，有經驗的designer有時候可以通過這樣的溝通，猜測出電路大概發生了什麼問題，debug起來效率會事半功倍。簡單的溝通之後，大致了解了case的狀況，不過我並沒有想出bug 的可能原因。因為RTL 是跟C model 做比對（這個IP建立了C model的演算法模型），採用最基本的debug 手段，用verdi 打開這個testbench跑出來的波形，同時用gdb（C語言unix下的調試工具） 運行cmodel，從發生mismatch 的點一步一步往前查。對於電子專業的學生來說，寫RTL代碼看波形debug都輕車熟路，但是對C語言就不一定很熟練，C程序的debug可能也不很熟悉。如果還是學生或者工作有需要，建議C語言還是要花點時間來提高的。經過C model和RTL 的逐級電路比對確認後，發現有個運算式的RTL代碼有飽和溢出現象，但是C model裡面沒有位寬的限制，所以結果沒有問題。跟演算法部門溝通確認後，C model和RTL 要都做相同的飽和處理。回過來想想，bug的發生是design的時候，考慮不夠嚴謹，導致位寬計算有誤，而運算結果溢出有要滿足比較嚴苛的條件，驗證都不容易能驗到。

搞完這兩件事之後，就到下午的技術討論會了。技術討論會的主題是跟驗證部門同事討論非同步界面處理的驗證問題。非同步界面信號能不能從一個時鐘域傳到另外一個時鐘域，大多時候是概率問題，驗證很難全面驗證電路是否正確。會議討論的很激烈，剛提出一種驗證方法很快就有人提出疑問，在不斷的提議和不斷的釋疑過程中，大家慢慢形成了共識。

這就是一個前端數字IC設計工程師的普通一天。設計、驗證、debug只是工作的一部分，當然是重要的一部分；技術討論，跨部門溝通，還有定期或非定期的頭腦風暴同樣不可或缺。隨著工作年資的增長，或許還要承擔一定的技術傳承。

用到的工具：DC(design compiler) /LEC/ RTL/VCS/ verdi /GDB /C語言

更多文章 請關注 （wx公眾號 icstudy）

推薦閱讀：