IC驗證工程師心得有哪些？

01-13

收集用

1. 講得很好，和我工作中的體會一一對應，值得一看。

晶元驗證工程師5年技術總結：1 SoC驗證

2. 知乎回答，很多有用的意見，從我的角度看來，空閑時間，去學習晶元架構和RTL設計應該是好的自我修鍊。

數字、模擬電路晶元的區別及其設計的前端和後端的分工區別？

3. IC設計的前端和後端

4. How relevant is Masters degree to climb up corporate ladder (In VLSI company like Qualcomm/Intel/Nvidia/ARM)? - Quora

5. What skills are required for a Graduate student in Computer Engineering to land an internship/job in VLSI industry? - Quora

6. Verification Academy 學習UVM的官方網站，有簡單介紹UVM的視頻

7. Simple UVM Testbench 最近發現的超級有趣的網站，可以在線寫Verilog、systemVerilog，在線模擬出結果，跟CS刷題的機器似的，不過用的是硬體編程語言。

8. 全球家77%手機產自中國：自主晶元不足3% 晶元設計是一個不僅需要經驗積累，也需要大量人力物力的工程，中國現在經驗積累不夠，相關方面人才培養也不夠，我也不知道該怎麼辦。。。

現階段的IC行業，數字IC驗證工程師非常緊缺，尤其是會UVM的驗證工程師那更是奇貨可居。但是最近和一些在校學生和剛入行的朋友們交流的時候，發現大多數人對數字IC驗證工程師的具體工作不甚了解，甚至還停留在寫verilog驗證的階段。

下面我就詳細羅列下數字IC驗證工程師的日常工作內容，希望能讓更多的人了解這個職位，進入這個職位，並喜歡上這個職位。當然每家IC設計公司會有不同，我只能盡量的列出比較通用的工作內容了，就算是拋磚引玉吧。

首先，IC設計公司一般都會把驗證分成幾個層次：

· IP level verification

· unit level / fullchip level verification

· gatelevel verification

每個層次的工作重點都略有不同，這裡就暫不詳細介紹，後面另開一篇文章來交流吧。但是大致的工作流程都是一致的。我重點以IP level simulation來作介紹。

上圖是一個SOC晶元的架構（先不管它是個啥），IP level verification就是對其中一個個小模塊來做驗證。你的工作主要有：

1.閱讀各種SPEC

最重要的一份spec是design spec，就是和你一起合作的好基友設計工程師寫的設計文檔，比如下面這種：

其中需要重點了解的內容是：

· fetures：這個模塊需要支持的性能列表。

· IO ports：這個模塊對外的IO埠。

· operation mode：這個模塊的主要工作模式。

除了這份詳細的設計文檔之外，如果這個IP需要用到很多協議，那你自然還要去閱讀一些協議文檔咯，比如AMBA匯流排協議，MIPI協議，DDR協議等。

2.撰寫verification spec

公司裡面，工程師做事情之前都需要出一份詳細的文檔，驗證工程師也不例外，你要出的文檔叫做verification spec，其中主要的內容包括：

· 驗證平台架構：以UVM驗證平台為例。

實際上，現在IC行業內，很多公司的驗證環境都不盡相同，比如有純C/C++的環境，有純UVM的環境，有UVM+C++的環境，甚至還有systemc的環境。總的來說，現在的趨勢都是在往UVM的驗證環境上轉。

· 測試用例（test plan）

test plan的出爐是一個高質量的工作，因為它決定了你驗證的工作量，最重要是它決定了你驗證的完整度。驗證工程師的終極目標就是：覆蓋所有的情況，不放過任何一個bug。

這份東西需要你和designer反覆的詳細討論，在後面的過程中，還需要進一步的優化補充這份文檔。

3.碼代碼，搭建驗證環境

verification spec完成之後，接下來就要開始碼代碼了，使用各種驗證語言去搭建驗證環境，常用的驗證語言有C/C++，systemC，systemverilog。

以現在主流的UVM驗證平台為例：大概要去碼完類似這樣的文件。

好的驗證平台是檢驗工程師優秀的一個重要標準，要考慮實用性、擴展性。

好消息是，公司裡面有很多已有的驗證環境，你可以模仿，在已有的基礎上進行修改就可以了。

4.創建test cases

根據前面完成的詳細test plan去創建驗證需要用的test cases，每家公司對test cases的命名有一定規則，比如長這樣的：

有些公司就直接用數字來給test cases命名。還有些公司，直接用腳本來生成test cases，只要把關鍵的一些設置調好，用腳本一刷，case就全部生成了。當然每種創建cases的方法各有優缺點，你進去公司之後，也只能入鄉隨俗。

5. debug

驗證環境和測試用例都搭建好了，下一步重點就是模擬和debug了。前面搭環境的時間其實大概只佔20%，debug才是最花時間的。

模擬所用到的工具主要有：

· mentor：questasim

· cadence：NC-sim

· synopsys：VCS

幾款工具一個比一個好，當然價格也是一個比一個貴。工欲善其事必先利其器，要想提高你的模擬和debug效率，工具裡面好的功能也要好好研究下的。

debug主要目的是尋找RTL的bug，當然前面搭建的驗證平台也會存在很多bug，最終的目標就是所有的test cases都能完全模擬通過。

最主要的debug手段有：

· 查看log文件：模擬結束會生成很多結果文件。

· 看波形：最常用工具就是verdi了。

每家公司對於驗證工程師debug的要求不盡相同，比如AMD，就要求驗證工程師能找到最終的root cause，而大多數公司只要求驗證工程師能基本定位，然後designer去詳細debug。

6. regression和coverage

到了項目的後期，所有的case都pass過了，並且比較穩定了，下一步就要開始跑regression和coverage了。

所謂regression就是把所有的case同時跑一遍，因為大多數case裡面會有很多random的機制，所以在不斷重跑的過程中，會隨機性的出現case fail。這也是regression的主要目的，就是抓出那些極端情況下出現的debug。

coverage主要包括code coverage和function coverage等，每家公司的要求都不盡相同。

每家公司跑regression和coverage都會使用腳本來完成，怎麼高效順利跑完，是最關鍵的問題，

最終的結果一般會以網頁的形式呈現，直觀明了。

7. support

前面屬於驗證工程師的常規任務差不多就完成了，support屬於進階版的。比如項目用的database出問題了，跑模擬用的flow碰到問題了，經常就會叫驗證工程師去support，幫忙解決問題。

當然搞不定也無所謂，但是如果你經常能幫同事搞定這些問題，那你在公司的地位就能與日俱增，升職加薪就更有籌碼了。

8. meeting

作為驗證工程師，和其他工程師一樣，經常還有無窮無盡的會議要開，各種review，各種討論。

如果你作為會議組織者，請記得事先做好充分的準備噢，不然很容易被人鄙視的。

大致的工作內容就羅列這些了，當然還有很多不能列完全，比如驗證工程師經常需要移植驗證環境，把從別家公司買了的東西移植到自家公司環境中。

希望以上這些能給未入行或者剛入行的驗證工程師們帶來些許幫忙。另外，數字IC驗證工程師在行業內非常吃香，大家好好乾吧，錢途無量噢。

更多IC學習及分享，請點擊www.eecourse.com

再推薦一個學習UVM的好網站，UVM - ClueLogic

如果你能訪問google的話，就能使用 edaplayground 來運行上面的代碼了。

另外，我個人喜歡把一些知識點和經驗寫到我的blog里。

edaplayground introduction