如果早知道這些IC面試題，我就可以跟Sir們談笑風生了！
關注路科驗證的都變成了IC大牛
你還在等什麼？
各大公司開始大規模招聘數字IC驗證設計師近幾年才開始出現，所以相比於IC前端設計工程師，網上關於IC驗證工程師的筆試面試經可謂十分稀缺。
在筆試面試中，公司會用盡手段去探知你能力的底線。你的項目和面試官契合，刨根問底以展現面試官對其項目的駕馭能力，同時考察你的掌握程度。時運不濟，面試官對你的項目不感興趣，拋開簡歷考察你的基礎知識，更背的，問一些他知道你不知道的專業問題。
關於基礎知識，路科小編們整理了能直戳面試官的知識點。希望會對師弟師妹們有所幫助。（經授權，知乎@大雄發表過一篇面經——數字IC驗證面試經驗及面試題總結，本文基於此文增加修改而來。）
------------------------------------------------------
筆試環節：
數字IC驗證和設計採用同一套筆試題，兩者的薪資也一樣，試題可能數字設計內容更多 ，做驗證的同學在筆試環節還是存在劣勢的，但也不是無計可施。筆試題一般側重基礎，大多為數字IC設計中最常用的方法和思想，現在也有少許公司開始出一些關於SV語法相關的考題。
面試環節：
由於大多公司並未基於驗證出筆試題，所以對IC驗證工程師而言，在面試階段會更多涉及一些SV與UVM相關的思想與應用。
總結起來,最常考的有：
RTL設計思想及代碼考察：
IC 開發flow 及個階段使用的工具。
信號的跨時鐘域同步。包括單比特和多比特，對於單比特自然用兩級寄存器同步最為方便。對於多比特，常考察非同步FIFO以及握手方法。要理解亞穩態的概念以及避免亞穩態的方法。
說到亞穩態，就不得不說setup time 和 hold time。一定要掌握兩種時鐘約束和分析時鐘約束的方法。清楚四種路徑（輸入到輸出，輸入到寄存器，寄存器到寄存器，寄存器到輸出），並能找到關鍵路徑。會計算最高的工作頻率。
分析和修復setup time validation（降低時鐘頻率，組合邏輯優化或拆分，提高工作電壓）和 hold time validation（插入buffer，更難修復）。
用verilog描述常用的電路結構，如：D觸發器，同步/非同步複位，計數器，分頻（奇數倍分頻，偶數倍分頻，小數分頻（如1.5倍）），同步FIFO，非同步FIFO, 序列檢測器（FSM實現）。
用verilog描述給出的代碼或者偽代碼（可能會給一段C代碼，然後據此寫出對於的verilog代碼）。
找出verilog代碼中的錯誤，如信號未進行跨時鐘域同步，無else分支會產生不期望的鎖存器等等。
阻塞，非阻塞賦值。
ROM、SRAM、DRAM、flash等各類存儲器的區別與應用。
掌握一些常用的協議，如I2C（能夠根據提示用verilog實現），SRAM協議、AMBA(AHB、AXI、APB、OCP)等。
同步複位與非同步複位的優缺點，非同步複位設計在使用時應當注意什麼？即非同步複位同步釋放設計，並要畫出非同步複位同步釋放的電路結構。
掌握一些常用的低功耗方法，如clock gating(能畫出電路結構圖)，了解DVFS，多閾值電壓技術，多電壓技術。
組合邏輯輸出需經過一級寄存器過濾毛刺。
clock switch glitch free 電路實現應用與分析（路科驗證前段時間的文章《什麼？你也不知道這麼基礎的知識點》中有提及）。
對FIFO的理解，同步FIFO 與非同步FIFO異同,談談如何判斷fifo的空滿狀態？對於非同步fifo，如何處理空滿時的同步問題？還可以採用什麼方法？計算非同步FIFO最小深度。
同步fifo讀寫時鐘相同，非同步fifo讀寫採用不同的時鐘。
嚴格的空滿判斷： w_ptr==r_ptr且讀寫迴環標誌位相同時為空， w_ptr==r_ptr且讀寫迴環標誌位不同時為滿。這在同步fifo中一般沒什麼問題，但是在非同步fifo中一般要做悲觀的空滿判斷，以免在fifo空時讀獲fifo滿時寫。
保守的空滿判斷：方向標誌與門限。設定了FIFO容量的75%作為上限，設定FIFO容量的25%為下限。當方向標誌超過門限便輸出滿/空標誌，其實這時輸出空滿標誌FIFO並不一定真的空/滿。
同步：讀寫指針轉化為格雷碼後再進行同步。
FIFO最小深度：考慮背靠背讀寫情況進行計算。
SV 語法考察
隊列和數組的區別和用法
結構體的使用
多線程fork ...join,fork ...join_any,fork ...join_none的用法差異
多線程的同步調度方法（事件、旗語、mailbox）
@signal觸發和wait(signal)的區別
對C++基礎的理解（類、繼承、多態）
帶約束的隨機類的語法和使用（權重約束和條件約束等都會考察）
在驗證環境中，C如何access和dut中寄存器，是如何聯繫的？以及DPI介面的使用（C方法到SV方法、SV方法到C方法的使用）
Verilog 提供VPI介面，可以將DUT的層次結構開放給外部的C/C++代碼,而systemverilog提供了更好的介面：DPI.
UVM的理解考察
1. 請談談你對UVM驗證方法學的理解。
UVM驗證方法學是基於systemverilog語言形成的一個高效的驗證方法。它的主要特點是提高了代碼的復用性，使得驗證人員能通過代碼移植復用修改快速搭建驗證平台，從而將主要精力放在具體測試用例的編寫上。另一方面，UVM封裝了很多好用的方法，這使得驗證人員不必過多關注底層實現，而且減少了驗證平台的調試時間。
2. 請談談UVM的驗證環境結構，各個組件間的關係。
3. 舉例談談UVM組件中的一些常用方法。
4. UVM component 和UVM object 的關係與差異？繼承和生命周期不同，component中有許多phase的函數，而object沒有。
5. UVM組件的通信方式（即TLM），TLM介面分類和用法，Peek和get方法的差異
6. 請談談virtual sequencer與sequencer的區別，以及為什麼要用virtualsequencer？
如果只有一個驅動端agent，顯然是不需要使用virtual sequencer的。
如果有多個驅動端agent，但是多個激勵之間並無協調關係，virtual sequencer 也並無必要。
如果有多個驅動端agent，而且多個激勵之間存在協調關係，那麼virtual sequencer就很有必要了。這個時候環境中需要包含一個甚至多個virtual sequencer了。
virtual sequence 和virtualsequencer的「virtual」有何含義呢？
Virtual sequencer 有三個屬性：
(1)Virtual sequencer控制其他的sequencer
(2)Virtual sequencer並不和任何driver相連
(3)Virtual sequencer本身並不處理item
並不像正常的sequencer那樣，將sequence item通過sequencer port傳遞給driver。Virtual sequencer通過一個指向subsequencer目標的句柄來指定sequencer。這裡的subsequencer就是和driver相連接的真實sequencer。所謂的virtual就是指真正的sequence並不是在Virtual sequencer里產生和傳遞的。一個virtual sequencer可以通過它的subsequencer產生許多種不同類型的tranction。而virtual sequencer的作用就是在協調不同的subsequencer中sequence的執行秩序了。
7. 為什麼會有sequence,sequencer,以及driver，為什麼要分開實現？這樣做有什麼好處？
最初的驗證平台，只需要driver即可，為什麼還需要sequence機制？
(1).如果事務在driver里定義，會產生一個問題。比如事務種類繁多，豈不是每次啟動一個事務，都要修改driver的main_phase代碼部分。
(2).如果定義多個driver，那麼會把UVM樹形結構搞的亂七八糟。所以，要從driver里剝離事務產生（具體包括事務定義、事務產生的步驟）的代碼部分。driver只負責事務驅動即可。
(3).補充一句，驗證的case_list，是用sequence機制去實現的；並保證了UVM樹形結構的單一性、統一性。使得可維護的能力大大加強。
上述解釋，也是sequence和sequence_item不屬於uvm_componet的原因。case相關的代碼改動，都在sequence和sequence_item里實現。
8.為什麼要盡量避免絕對路徑的使用？如何避免？
絕對路徑的使用大大減弱了驗證平台的可移植性。避免的方法是使用宏和interface.
9. 如何在driver中使用interface？為什麼？
由於driver是類，而在類中不允許直接使用interface，所以在類中使用的是virtual interface。然後再top_tb中通過uvm_config_db#(virtual)::set()…的方式將if set到driver 的vif.
10. 你了解UVM的factory與callback機制嗎？
callback機制最大的用處就是提高驗證平台可重用性。它通過將兩個項目不同的地方使用callback函數來做，而把相同的部分寫成一個完整的env，這樣重用時，只要改變相關的callback函數,env可以實現完全的重用。
此外，callback還用於構建異常的測試用例，通過factory機制的重載也可以實現這一點。
11. OVM和UVM有什麼區別？
OVM沒有寄存器解決方案，也有factory機制，然而cadance推出RGM之後補上了這一短板，但使用RGM需要額外下載，沒有成為OVM的一部分。OVM現在已經停止更新。
UVM幾乎完全繼承 OVM，同時又採納了synopsysVMM中的RAL寄存器解決方案，同時吸收了VMM的一些優秀的實現方式。由mentor和candence2008年聯合發布。
12. UVM各component之間是如何組織運行的，是串列的還是並行的？如果串列的，請問是通過什麼機制實現各組件之間的運行調度的？
關於UVM的運行機制，學過UVM的應該都很清楚了，無非是各組件之間的關係，以及Phase機制等等。UVM其實質是軟體，而軟體本質上都是順序運行的，dut硬體是並行運行的。關於各組件之間的運行調度，僅僅從《UVM實戰》這本書上是得不到答案的，時候我有翻看了SV綠皮書，感覺從中找到了答案。測試平台的調度是通過事件觸發驅動的（如@，
13. 介紹UVM的phase機制，buildphase 和connect phase的執行順序，run phase 與build phase的主要區別
build phase自頂向下，connect phase自底向上。
run phase 通常要耗時，build phase 不耗時。
14. UVM啟動一個sequence的方法
15. config_db的作用？以及其使用時傳遞的幾個參數的含義
基本驗證思想的理解
1, 請描述一下你所驗過的模塊的功能。
2. 請談談驗證的思想，驗證人員和設計人員思考問題的差異。
驗證永遠是不充分的，永遠是沒有最好的，用一個同事的話說，如果非要給驗證訂一個期限的話，我希望是一萬年。
目前通用的做法是看coverage.
(1) 看design spec
(2) 了解相關協議
(3) 編寫test plan及verificationspec
(4) 搭建驗證平台
(5) 依據testplan創建測試用例testcases
(6) 模擬和debug,包括環境和design的bug,花費時間最多。工具是VCS/verdi
debug的手段主要有：查看log，看波形
(7) regression 和覆蓋率
(8) code review
3. 你寫過assertion嗎？assertion分為哪幾種？簡單描述下assertion的用法。
Systemverilog斷言屬於驗證方法中的一種，斷言(assertions)就是對設計屬性(property行為)的描述，如果一個屬性不是我們期望的那樣，那麼斷言就會失敗。assertions與verilog相比，verilog是一種過程性語言。它的設計目的是硬體描述，它可以很好的控制時序，但是描述複雜的時序關係，代碼較為冗長，assertions是一種描述性語言，設計目的為模擬驗證，可以有很多內嵌的函數來測試特定的時序關係和自動收集覆蓋率數據。
SVA分為並發斷言和即時斷言兩種。並發斷言是基於時鐘周期的，在時鐘邊沿計算表達式，它可以放在模塊(module)，介面(interface)，或程序塊(program)的定義中，以關鍵詞「property」來定義，可以在靜態驗證工具和動態驗證工具中使用。即時斷言是基於事件的變化，表達式的計算像verilog中的組合邏輯賦值一樣，是立即被求值的，與時序無關，必須放在過程塊中定義。
並發assertions：
property a2b_p; //描述屬性
@(posedge sclk) $rose(a) ->[2:4]$rose(b);
endproperty
a2b_a: assert property(a2b_p); //assertproperty SVA的關鍵字表示並發斷言
a2b_c: cover property(a2b_p); //覆蓋語句
4. 你們項目中都會考慮哪些coverage?
Line coverage, condition coverage,branchcoverage, toggle coverage, statement coverage（FSM）
5. coverage一般不會直接達到100%，當你發現有condition未cover到的時候你該怎麼做？
編寫定向測試用例（direct case）
6.Function coverage和codecoverage的區別，以及它們分別對項目的意義。
這是兩個衡量驗證完成度的重要指標。Function coevrage 需要驗證工程師基於對於設計功能的理解，自己定義需要的cover groups，通過這種方式以確保一些重要的功能點被驗證到。基於我們寫的激勵，模擬器會自動收集code coverage，通過這種方式更直觀的衡量我們的驗證進度，但是code coverage只能保證我們的激勵會激活哪些代碼，而不能保證代碼的正確性，即使code coverage達到100%，也不能說明我們的RTL沒有BUG存在。
7.對一個加密模塊和解密模塊進行驗證，如果數據先進行加密緊接著進行解密，如果發現輸入數據與輸出數據相同，能不能說明這兩個加解密模塊功能姐沒有問題？為什麼？
看到這道題，當時的反應就是應該首先分別對加密模塊進行驗證，如果沒有問題，再一起進行驗證。但是面試官對這個問題貌似並不滿意，問我為什麼直接驗就不行呢？我當時一下子也說不出原因。
------------------------------------------------------
總結：
總體上講，基礎知識部分並不會很難，都是真實項目中常用的。其中關於System verilog 和UVM的考查內容，大部分都能在路桑之前的文章中找到答案和示例，讀者可以查看之前的文章。強烈期待路桑的紙質版圖書快點出版。師弟師妹們在找工作之前可以對照此面經，將自己的知識梳理一下，更從容的面對面試官的考核，希望大家都可以找到一份滿意的工作！
謝謝你對路科驗證的關注，也歡迎你分享和轉發真正的技術價值，你的支持是我們保持前行的動力。
TAG:路科驗證 |