進程與線程
1、system verilog中，進程之間的同步不可以采用（Semaphore），可以采用（Event, Mailbox, Fork/join）.
解析：Semaphore是一種線程仲裁結構，不能用關於內部事件同步。
測試點與測試用例 & 覆蓋率
1、測試用例是用來覆蓋測試點的，一個用例只能覆蓋一個測試點（錯誤）。
解析：用例和測試點不是一一對應的。一個用例可以用來覆蓋多個測試點。一個測試點有時候也需要多個用例來覆蓋。比如測試FIFO的兩個測試點：1.空信號生成 2.滿信號生成，使用一個測試用例，在復位之后發出FIFO深度相同數量的寫數據，不進行讀。一個用例就能同時檢測到空信號和滿信號覆蓋兩個測試點。
2、下面關於代碼覆蓋率描述錯誤的是（AB）
A．代碼覆蓋率達到百分之一百說明代碼bug已消除
B．代碼覆蓋率包括功能覆蓋率
C．代碼覆蓋率包括條件覆蓋率
D．代碼覆蓋率包括語句覆蓋率
解析：覆蓋率是衡量設計驗證完成程度的指標，並不是驗證的目的。任何覆蓋率達到100%並不代表芯片bug已消除。代碼覆蓋率包括行覆蓋率、條件覆蓋率、狀態機覆蓋率和翻轉覆蓋率。功能覆蓋率反映開發出來的需要覆蓋的功能點覆蓋的比例。斷言覆蓋率測量斷言被觸發的頻繁程度。
形式（formal verification）驗證
1、（形式驗證）是一張系統驗證手段，通過它來判斷兩個設計是否等價，從而判斷一個設計在修改前后的功能是否保持一致。
解析：形式驗證formality主要應用在：1. RTL與綜合網表的比對。因為主要的測試用例都是基於RTL，RTL修改簡單，迭代速度快，是一切功能的源頭。保證了RTL仿真的正確性加上RTL與網表的形式驗證，基本可以保證RTL測試過的測試點在網表階段沒有問題。2. 網表與網表比對：物理實現各階段網表功能一致性（綜合->時鍾樹->布局布線->TIMING/DRC ECO）。如果有功能ECO，保證ECO之后的網表功能與ECO之前的網表一致也是必不可少的，因為基於網表的修改風險較大，也更不可控，人為確認不夠穩。
2、形式驗證(formalverification)不存在驗證覆蓋率的問題，其目的是為了比較兩個design的功能，並確認他們的功能是否100%相等。（正確）
解析：形式驗證的基本流程是通過切割電路，划分出一系列的比較點。在划分出比較點之后，工具會對兩個design的所有比較點進行match，有match不上的點則無法進行比較。然后進行兩個design的比較。有比不過的點，則比較失敗。因此如果將所有的比較點比較通過作為驗證成功的標志，那么需要保證所有的比較點都能match上，並且進行了比較。Formal要求match的比例達到100%，但這里並不存在覆蓋率這一說。
隨機驗證 & 功能驗證 & 動態驗證
1、為保證充分性，隨機驗證的輸入不能帶有約束條件，必須使用全隨機（錯誤）。
解析：如果全隨機，會大量消耗驗證及其資源，正確的做法是通過約束條件使隨機值落在驗證測試點感興趣的區域，減少無謂的機器資源消耗。
2、在異步設計中對跨時鍾處理的信號，功能驗證時一般需要考慮以下哪些因素（信號高電平有效還是低電平有效、信號變化的最小寬度、時鍾頻率），不需要考慮的是（相位和抖動）。
解析：功能驗證關注會影響功能並且不需要借助門級延遲等信息就可以判斷對錯的點。高低電平肯定是可以檢測的。信號變化的最小寬度，在低頻采高頻的場景下功能仿真可以仿出漏采現象。時鍾頻率也是功能驗證需要關注並且可以控制的，不同時鍾頻率的跨時鍾域是否有頻率不同導致的功能與預期不一致，這些是可以測到的。
3、下面屬於動態驗證范疇的是（modelsim仿真、后仿），不屬於的是（形式驗證、STA）。
解析：所謂動態驗證即驗證結果依賴於向量輸入，動態改變。形式驗證和STA都不依賴於具體測試用例。
DFT
1、以下哪些活動屬於DFT的內容（Boundary SCAN，MBIST，DC SCAN，AC SCAN ）。
verlog，system verilog & UVM
1、以下關於Venlog的描述，正確的是（無）
A.SystemVerilog是提供給驗證使用的，因此其不能被綜合。（可被綜合）
B.SystemVerilog中可以用logic代替Verilog中的wire和reg信號類型。（在部分條件下可以代替）
C.Verilog語言中的function語言不可被綜合。（可以綜合）
D.在Verilog中，定義成reg的信號會被綜合成觸發器。（在組合邏輯中不被綜合為觸發器）
E.Verilog中，如果case的條件不寫完整，將會導致綜合時出現鎖存器（Latch）。（在時序邏輯中不綜合成鎖存器）
2、一下關於驗證的描述，正確的是（B）
A．驗證平台使用checker檢測DUT的行為，只有知道DUT的輸入輸出信號變化之后，才能根據這些信號變化來判定DUT的行為是否正確
B．SystemVerilog區別於verilog的一個重要特征是其具有面向對象語言的特性：封裝、繼承和多態
C．UVM是Synopsys、Cadence、Mentor等EDA廠商聯合發布的驗證平台
D．Verilog，SystemVerilog，SystemC,，UVM都是驗證常用的硬件語言
解析：
選項A：驗證平台中實現監測DUT行為的組件是monitor。Checker是根據DUT的輸出來判斷DUT的行為是否與預期相符合，比對數據來源於RM（reference model）和o_agent的monitor。
選項C：VMM由Synopsys於2006年推出，OVM由Cadence和Mentor於2008年推出，UVM（Universal VerificationMethodology）由Accellera推出於2011年推出，得到Synopsys、Cadence、Mentor的支持。
選項D：UVM不是語言，是一個以SystemVerilog類庫為主體的驗證平台開發框架
UVM代碼題
1、下面是兩種情況下的UVM代碼：
第一種情況： task my_case0::main_phase(uvm_phase phase); for(int i = 0; i < 10; i++) begin #10; `uvm_info("case0", "phase is executed", UVM_LOW) end endtask task my_case0::run_phase(uvm_phase phase); phase.raise_objection(this); #100; phase.drop_objection(this); endtask 第二種情況： task my_case0::main_phase(uvm_phase phase); phase.raise_objection(this); #100; phase.drop_objection(this); endtask task my_case0::run_phase(uvm_phase phase); for(int i = 0; i < 10; i++) begin #10; `uvm_info("case0", "phase is executed", UVM_LOW) end endtask
請問上述兩段代碼"phase is executed"分別輸出了幾次？
第一種情況打印信息輸出0次，第二種情況打印信息輸出10次
解析：
UVM中通過objection機制來控制驗證平台的關閉。在進入到某一phase的時候，UVM會收集此phase提起的所有的objection（raise_objection），並且實時監測所有的objection是否已經撤銷了（drop_objection），當發現所有的objection都已經撤銷后，那么就會關閉此phase，開始進入下一個phase。當所有的phase都執行完畢后，就會調用$finish來把整個的驗證平台關掉。如果UVM發現此phase沒有提出任何objection，那么將會直接跳轉到下一個phase中。
在drop_objection語句之前必須先調用raise_objection語句，raise_objection和drop_objection總是成對出現。rasie_objection語句必須在phase中第一個消耗仿真時間的語句之前。
對於run_phase，與其他動態運行的phase是並行運行的，如果12個動態運行的phase有objection被提起，那么run_phase則不需要raise_objection就可以自動運行。
第一種情況中main_phase沒有提起任何objection，不理會操作，直接跳到post_main_phase,時刻還是為0。因此"phaseis executed"輸出0次
第二種情況中main_phase提起延時100ns的objection，run_phase則開始並行運行其for循環操作，因此"phase is executed"輸出10次