極說?前端及驗證主題討論 （未刪減版）

來自專欄 IC CAD探索4 人贊了文章

關於我們 ：

IC 極客之家由IC 行業的幾位工程師發起，以公益，開源，分享為宗旨，致力於推廣IC 極客文化，組織大家深入交流IC 設計領域知識，經驗及方法學，打造IC 設計圈的思想國。

極刊，極說，極問文章請關注公眾號icgeeks. 極刊為獨立撰稿人關於IC 設計的技術分享，極說與極問基於討論交流信息整理，內容由技術委員會確認發布。

歡迎文末留言參與討論，入群，群內服務及合作請聯繫微信號sgsphoto

導讀

1. 漫談如何快速定位bug
2. 通信子系統log定位，譬如通信子系統前端輸入一幀數據到最後可能拆成很多物理層的幀 怎麼方便出現問題的時候追蹤，在上層插入錯誤怎麼表現到下層的
3. 多核SOC子系統驗證解決方案
4. 通信類模塊 scoreboard設計
5. 從拿到用戶需求開始到給出綜合網表，至少需要review幾次
6. IP 設計考慮靈活度時，可重構（配置寄存器）方案和可編程（編寫程序）方案的優劣和如何選擇
7. fpga驗證、動態模擬、formal、emulation、assertion、power驗證、security驗證、performence驗證等技術分別適用哪些場景？如果時間或金錢有限如何取捨？
8. 模擬驗證和fpga驗證的testcase復用
9. 數字設計的性能靠什麼保證？前端主要的checklist是什麼？
10. 晶元設計中的系統規劃：軟硬劃分、電源、時鐘、複位、埠、數模IP介面等的設計目標、風險、方法。
11. 如何在前端階段考慮可測性和DFT coverage
12. 關於coding style大家有什麼好的建議
13. 我們一般都談verilog的coding style，那Tcl、Perl等其他語言有沒有好的風格可以參照？
14. IP 設計，驗證環境，或者flow腳本如何做高可復用
15. 把驗證平台如何復用再細分，如怎麼驗證同類IP，驗證用例復用，批量生成適合用例
16. 大家公司項目的驗證環境有多少是基於uvm了?
17. 做soc與asic的比例？哪個更有前途或更利於職業發展？
18. 驗證計劃與管理是一個容易忽視的方面，或者說是小公司的薄弱的地方，有沒有現成的套路可用？
19. sdc 如何檢查？

20. SOC integration方面有哪些不錯的EDA 工具或自研解決方案，大家都是怎麼做的？
21. 工程師如何才能把前端流程（包括設計，綜合，STA，DFT，UPF，FPGA驗證等）做的比較深入，在沒有成熟的流程可參考的前提下
22. portable stimulus standard是不是有實際應用了？

1. 漫談如何快速定位bug

1# 主要依賴經驗，最近在看《刻意練習》，按照該書的觀點，能夠快速定位bug的高手，建立了一套有效的心理表徵，在分析問題時可以既見樹木又見森林，這種心理表徵是長時間訓練得來的

2# 熟悉晶元的規格，分塊歸納總結，形成條理,然後在debug之後不斷豐富總結的網路,最後能達到一看錯誤就能猜出大概是什麼原因

3# debug方法，熟悉晶元架構，熟悉testbench架構。快速查找報錯的位置，然後根據問題追根溯源。

4# debug，尤其是通信晶元的debug，可以有很多的方法。一個數據幀從進入到輸出，可以在通路上的關鍵節點處設置監測如各種計數器等，可通過VIO（xilinx）定時上報實時狀態。可以把VIO的各個信號線設置成類似於CPU匯流排的結構，監測計數器或者狀態寄存器編成相應的地址，輪詢讀取回PC，在PC上通過TCL或者其它語言捕獲數據。甚至可以將多個FPGA晶元都通過VIO進行調試，遠程操作，效率也可以大大提升。另外，也可以設置專門的測試幀，在裡面打各種不同大小的閉環，層層檢測，發現問題。

4.5# 這個VIO比chipscope有多大優勢?

4.5# 原理是一樣的，不同的就是可以方便操控，可以寫腳本抓取數據，還可以遠程操控。VIO有輸入也有輸出，可以實時的配置寄存器。如果這個不過癮，可以在opencores上隨便找個mini的CPU核，比如MSP430之類的，16條指令的那種，兼容TI的編譯器，編寫到FPGA裡面，這樣子就可以更方便了，上面寫C語言後可以下載到FPGA裡面，更加靈活。如果一個核不夠，可以弄成多個核，非常小的CPU，非常方便。還可以掛上協議棧，也可以跑比較小的freeRTOS等小的操作系統，一下子你的設計就變成了SOC。可以用來DEBUG，感覺方便的話可以留著甚至最後可以流片出來。缺點是速率比較慢，裡面的組合邏輯太多，只能跑25MHz

4.5# http://xilinx.eetrend.com/blog/11987，Vivado VIO （virtual input output）虛擬IO使用; https://opencores.org/projects

5# 採用二分法，和golden數據對比。對做golden數據的要求也提高了，能夠提供幾個關鍵節點的數據，不僅僅是最終的輸出結果。 採用排除法，看看各個模塊級的驗證是否通過。 採用特殊值，針對懷疑的對象，用特殊值來排除干擾，找到真兇。可以是特殊patten，也可以是force一些條件。 採用反例法，也是利用現象的特殊性來做試驗。

6# 讀了文章：雲風：斷點單步跟蹤是一種低效的調試方法.不論工具的好壞與否，作者還是提供了一定的思考方向，這裡有一些自己的想法：

1. debug 可以從兩個角度來看：主動的減少和被動的調試。
2. 如何主動減少：一方面是作者說的控制複雜度，我覺得更本質的是對設計的規則的制定，往大了說就是軟體 or 硬體的架構，往小了說就是如何劃分組織代碼，如何區分和處理一般情況和特殊情況。
3. 被動的調試：是驗證的主要工作，比如 code review，又比如我們寫 TB 然後測試。這裡就涉及到我昨天的問題——如何快速定位？
   這裡首先可以考慮 2 的影響，架構的耦合度、對設計的熟悉程度等都影響定位速度，例如如果架構結構清晰，就可以依據幾個關鍵點，快速縮小問題的根源；
   然後從工具來看，利用日誌或者調試工具，可以快速 check 關鍵點，逼近問題根源，之後就是腦力思考輔以調試工具的支持；
   最後從調試的階段來看，主要編碼完成時問題是最多也最 low 的，code review 是最佳選擇，尤其是對有修改的代碼的邊界情況；消除了最初級的 bug 之後，bug 還是比較明顯，這個時候可以多根據系統的狀態來定位問題，有些潛伏深的問題，或者驗證環境考慮不充分的問題，通過系統的狀態可以比較快的定位到；最後的階段，bug 很難找到，首先利用 coverage 確保覆蓋率，多從整個系統的設計機制和特殊、邊界情況的處理角度出發考慮。 以上只針對功能 bug。
   最近代碼寫了不少，也調了一些 bug。可能對大牛來說這些已經諳熟於心，不過還是忍不住寫寫，也希望大家多提提意見想法。

7# 同賣油翁的道理，熟能生巧。熟需要多練，巧需要總結。巧由熟生，是個人經驗累積的結果。別人的經驗始終是別人的，可以借鑒、引導，但不是捷徑。所以，我的辦法是：平時遇到問題多記錄，先對單個問題往深里鑽，然後對相似問題歸納總結，最後發散思維挖掘沒遇到而可能遇到的問題風險。有了漁，就有魚。

8# 關於bug定位，今天想到一個很有意思的比喻。比喻不好大家輕拍。bug定位就像醫生看感冒，需要用到三板斧：量體溫、看喉嚨、測血象。測體溫就是測電流、電壓，介面輸入等，從外部感官上找問題；看喉嚨就是看最基礎的介面，比如給晶元留給I2C或者UART，方便看看晶元有沒有發炎；測血象就是要看晶元內部信號，無論是通過JTAG 掃描輸出還是已經預留的debug介面。所以，這裡有兩個比較重要的廢話，1預留一些通用的介面，並且在各個模塊留出一些可讀信號；2在FPGA驗證階段用到的信號都需要送到debug介面上。晶元和人一樣，能不做FIB就不做，到了那一步就嚴重了。

9# 隨便說說體會：假設有結果bug、協議bug和coding bug，最後一種經常跑lint一般都能跑出來，有時候也最難發現，比如reg變成了latch。現在verilog2001用always *好了不少。結果bug有時候可能因為spec理解不一致，時序問題或控制問題，一般搞模型比對容易發現，溯源往上追。協議bug可能assertion之類的比較容易發現。

10# 微體系結構的設計一種方法是datapath+control，數據流設計好了，再調整數據流的控制信號就可以解決不少問題了。狀態機不是必須，即使有也只處理控制信號。很多軟體出身的一個狀態機解決全部功能，雖然可以work，但是其實不利於debug

2. 通信子系統log定位，譬如通信子系統前端輸入一幀數據到最後可能拆成很多物理層的幀 怎麼方便出現問題的時候追蹤，在上層插入錯誤怎麼表現到下層的

1# 一般會在主數據傳輸路徑的關鍵模塊添加包計數統計，無論是驗證還是樣片測試都可以通過讀這些統計計數寄存器比較快的定位到那個模塊丟包了

2# 由於通信系統很多是pipeline結構，所以在模擬驗證時可以在必要的地方監控數據，做比對。在板級驗證時，可以使用環回來驗證。入口環回，出口之前環回，中間環回

3. 多核SOC子系統驗證解決方案

4. 通信類模塊 scoreboard設計

1# 通信類的scoreboard設計 我覺可以分層次對比，比如： 底層的數據包、 中間層數據包、 頂層數據幀、 一幀圖像、 n幀的視頻(不太現實，數據量太大)、 某種統計數據或者checksum

5. 從拿到用戶需求開始到給出綜合網表，至少需要review幾次

1# 雖然拿到了客戶需求，但也要評估實現方案，跟客戶review直到規格確定。

• 研發階段，數字設計、模擬設計、可測性設計spec；
• 各階段模擬驗證；
• floorplan，sdc，netlist, 綜合的qor等都需要review；
• 在沒有uvm平台的情況下，是否應採用多種驗證方法相結合的方式滿足功能覆蓋率？

6. IP 設計考慮靈活度時，可重構（配置寄存器）方案和可編程（編寫程序）方案的優劣和如何選擇

1# 建議使用配置寄存器。兩個例外：1、處理器/協處理器IP；2、Spec無法完全確定的IP。可編程的方式雖然會靈活很多，但它與CPU的交互/高層代碼如何編譯/時序控制方面不容易做好。如果一個晶元里有四五個可編程的小IP，即使都是用非常簡單的小處理單元，編程方面也是個災難……

7. fpga驗證、動態模擬、formal、emulation、assertion、power驗證、security驗證、performence驗證等技術分別適用哪些場景？如果時間或金錢有限如何取捨？

1# 我覺得UVM驗證必須做，後端conformal必須做。看晶元用途，power/performance/security選做。沒錢可以不上emulator……

2# 問題7求教：power驗證、security驗證、performence驗證不是功能驗證的子集嗎？需要用到特別的方法、工具？

3# fpga驗證的應用場景。主要用於系統級驗證。常見的應用場景一個是驗證數據量大模擬時間長或者無法模擬的情況。比如一些外設介面，通信晶元與空口連接。一個是晶元回來前提前進行應用軟體開發。

4# fpga原型驗證的意義：主要目的其實不在於功能驗證和連接性驗證，而重要的是硬體系統跟軟體協同工作的早期開展，不需要等chip回來才能調試軟體，有助於縮短time-to-market時間。同時fpga可以進行一些application級別的測試和壓力測試，但是這些都不如軟硬體協同重要。如果過於倚重fpga進行功能驗證，說明驗證水平還有一定提升的空間。fpga驗證debug起來難度和敏捷度比similation差了很多數量級，因該也很難統計coverage。

8. 模擬驗證和fpga驗證的testcase復用

1# fpga驗證復用大部門模擬驗證case fpga驗證和模擬驗證側重點不一樣

2# fpga驗證著重應用場景，數據量比較大，耗時比較久的case，模擬驗證比較細但是只能跑小規模case

3# 由於很多儀錶只支持tcl控制，所以只有當模擬的testcase激勵產生和過程式控制制可以用tcl時，才能復用，復用時使用同名的api函數

4# 模擬驗證和fpga驗證test case復用。我們的項目c header可以共用，真正的case復用的挺少。前仿case的作用主要為軟體寫驅動提供個參考，或者調試平台的時候定位問題

5# 模擬和FPGA test case 重用，可以選C,在testbench支持C,在fpga系統應用層也是C，這樣有問題debug時，可以跑simulation,有助於快速定位哪個點出錯

9. 數字設計的性能靠什麼保證？前端主要的checklist是什麼？

10. 晶元設計中的系統規劃：軟硬劃分、電源、時鐘、複位、埠、數模IP介面等的設計目標、風險、方法。

1# 第十題挺挑戰,晶元規劃都是晶元核心架構師的工作，邏輯架構和物理架構在開發早期就基本確定了.性能和可實現性我感覺是這兩個架構設計非常關注的.晶元早期的paperfloorplan需要對各模塊資源有較為準確的評估，後續不要出現大的變動，IP的物理位置擺放需要從封裝和物理實現考慮，不僅僅是IP的限制，也需要考慮晶元的限制，不如高速IO的位置，電源平面的劃分和，打拍邏輯規劃等.

1# 這對 timing 和 area 的評估要求很高啊

1# 是的，不然返工迭代的坑很深

2# 性能要求不高的話，如何做對是入門者比較關心，或者擔心的。在規劃階段把後面的一些坑提前繞過，是需要經驗的，甚至教訓。如模式切換、時鐘、複位的設計不合理，會導致時序違反、毛刺，往往在後仿中發現。在做新項目時會特別留意。大家有類似教訓可以分享，以免重蹈覆轍.

11. 如何在前端考慮可測性和DFT coverage

1#不是dft專業人士，搞過幾天。提高測試覆蓋率對SOC來說不同應用不同要求吧，車載肯定大於通信，通信大於終端類。IP的覆蓋率一般由vendor保證，剩下的就是soc的邏輯和介面，這樣根據覆蓋率目標和測試成本來優化，好的編碼風格初步的scan覆蓋率不會差，根據前期的覆蓋率報告分析，這些都有工具幫助分析，可以針對比較差的點專門寫測試邏輯覆蓋，也不會太麻煩

12. 關於coding style大家有什麼好的建議

1# 請問如何才能養成好的編程風格，是不是需要對後端有很好的理解才能把前端代碼設計得面積小又沒有歧義？

2# 多研究研究spyglass 的規則～每家公司內部應該也都有編程規範的

3# 綜合工具的可綜合編程指導,dc有專門的文檔

4# 強烈建議前端工程師佔領dc，你看一下綜合器是怎麼理解你的code的，別再瞎寫了，這不是軟體

5# 限定代碼風格的目的主要有：可讀性、可綜合性、對後端流程的適應性等。具體建議可參考網上大公司的風格指導文檔，研究代碼檢查工具、綜合工具的規則、報告。

6# 關於coding style大家有什麼好的建議，在這個基礎上問一個更具體的問題：大家對於代碼中的宏是怎麼看待的，徹底不用，還是有限度使用？有沒有推薦的標準？

6# 有限度的使用。即個人代碼不允許定義宏，可以使用宏。項目中使用的通用宏集中放在一起

6# 個人意見:IP不建議用。soc可以有限用

6# 代碼中用宏有個潛在的隱患，如果綜合時 沒有設置好宏可能導致最終的網表和需求有差別。我們的建議是設計和驗證時使用。綜合都用確定的代碼。

6# 如果你們家是賣IP 的，那麼我同意在 handoff 之前就把宏去掉，只留唯一的branch

7# 追加一個例子，比如foreach全部的all_regs，先get name到一個list，再根據名字get cell，再gei attr，可能會比foreach_ all_regs 直接get attr要快。後者需要遍歷大量的內存數據，前者快也許是因為pt對於堆排序做了特殊的優化。可以實際試一下看看

8# 推薦一個:縮進使用4個空格

9# sdc pt 有個功能 constraint consistent，可以檢查sdc 的問題，之前叫GCA，目前我是用來檢查自己的sdc是否約束完整

10# eetop 有個文檔介紹前端關於dft 的 coding style

11# verilog coding建議是先畫電路圖 寫設計文檔 再coding。coding只是翻譯，正如verilog只是硬體描述語言，而不是硬體設計語言

12# 12 coding style. 最主要還是有經驗的人定義或者根據現有規則坐一些開關選擇(譬如HAL). 譬如CDC中第一集寄存器為什麼要有一些特殊定義如_syncff1,因為這樣在跑GLS時很容易挑出來，不check timing

13. 我們一般都談verilog的coding style，那tcl、perl有沒有好的風格可以參照？

1# 個人寫過幾個tcl perl，但要說風格，沒有。假如要確定風格，必須先確定腳本的質量評價標準，大概想到幾點：1）能跑 2）跑得快、佔用資源少 3）可讀性強、可維護性好。然後討論這些標準對風格的要求：第1條對風格沒要求；第2條一般靠腳本的設計演算法保證，如果不是做EDA軟體，而只是小用，應該沒太高要求；第3條嘛，多寫注釋，書寫美觀一點，複雜的話寫個說明文檔。

2# 關於perl和tcl風格就個人習慣說一下：命名直觀，分段清晰，縮進一致，多寫注釋。分段大致有這些：解釋參數，定義變數，讀取文件，主體處理，輸出，定義option和列印usage

3# 寫tcl最好多用list，尤其是基於pt dc這樣的eda 工具，比用object+get_attr效率要高很多。如果處理數據量小怎麼寫都好

更多精彩回答請關注下一篇極說文章，編程在IC 中的應用，這個問題你可以聽聽看IC 界編程最好的那些人怎麼說

14. IP 設計，驗證環境，或者flow腳本如何做高可復用

1# IP 設計，驗證環境，或者flow腳本如何做高可復用 說個flow腳本復用的簡單思路：將腳本按步驟階段拆分成多個子腳本；將可能變化的命令、參數用變數替換，並將變數定義放到統一的子腳本中。

2# ipcore復用及維護 參考 https://pypi.org/project/fusesoc/

3# Ip設計。可以在這個階段引入lint,cdc,synthesize的檢查。top scripts做到固定，用戶只需定義file list，最大限度做到可重用

15. 把驗證平台如何復用再細分，如怎麼驗證同類IP，驗證用例復用，批量生成適合用例

16. 大家公司項目的驗證環境有多少是基於uvm了?

1# 全部基於

2# 100%

3# 我們公司沒用啊

4# 我們公司只有幾個在用

5# 我們用uvm

6# soc應該是vip+c,IP應該是uvm

17. 做soc與asic的比例？哪個更有前途或更利於職業發展？

1# 做soc和asic。市場上工作機會要麼做大，要麼做小。大的往soc，新工藝，新工具，比如手機晶元這個規模，要進巨頭企業。小的往asic，數模混合，細分mcu，低功耗，拼成本，要跟對老闆。大晶元要很多錢，很多人，創業機會不多，做個螺絲釘，按部就班，工作生活平衡。小晶元短平快，風雨飄搖，有暴富機會但很少。技能上，一個求點上的深度，一個求面上的寬度。

2# FPGA 相對於模擬軟體，比較快，較之於真正的晶元，但是有些代碼不能重用，比如clock gating，upf，memory，模擬部分，但是對於邏輯區域，介面方面不錯，可以提高驗證速度，同時也可以調測介面軟體很准，但是頻率這塊需要折中

3# 除了fpga驗證之外還有硬體加速器驗證速度，環境搭建，軟硬體協同驗證也有一定的優勢.我們做規模較大的複雜晶元 會同時進行uvm驗證 fpga驗證 以及硬體加速器的驗證 驗證用例根據不同平台的特點互有補充

4# 每次寫完代碼不要滿足於vcs之類的編譯器不報錯 最好用DC綜合一下 這個檢查最嚴格 沒有DC的可以用symplify綜合看看 都是需要實戰的 光看spec 個人覺得意義不大

5# 首先要了解數字邏輯的結構,然後是什麼樣的語句對應什麼樣的結構,再之後要模擬和理解綜合工具的行為.但是現在綜合工具的優化能力很強，會自己做很多結構上的重新選擇和調整

6# soc 更具有通用性，換坑更方便，IP 更有意思。

7# 萌新一般建議從小的asic入手，做幾年邏輯設計，這是function階段。後期不光從function理解設計目標，還要從 power/area/timing上理解設計。同樣的需求是否有一些更好的實現電路， 這樣處理是不是面積更小，功耗更低，速度更快？如果需要涉及到某一方面優化， 可能需要根據評估反覆迭代，調整設計方案。例如一些公司在每個代碼版本會用工具 評估功耗，力爭做到極致。 還有就是在從協議到代碼的轉化中，處理一些不太複雜的sdc，cdc,upf等問題。 soc因為規模相對較大，模塊較多，設計上可能更多關注於匯流排，CPU核，各類IP， 效率的問題，相對於asic來說，處理的單元粒度大一些，問題更加複雜一些。 在某些大規模電路上，可能會使用更多的輔助工具和手段。對工具的要求更深入和多樣化了。

18. 驗證計劃與管理是一個容易忽視的方面，或者說是小公司的薄弱的地方，有沒有現成的套路可用？

1# 驗證計劃與管理 參考資料 https://verificationacademy.com/courses/verification-planning-and-management

2# http://www.testbench.in/

19. sdc 如何檢查

1# check timing命令不也是一種手段嗎？

2# 現在spyglass算s家的，c家有conformal cdc? 不過我感覺用起來review report里大堆的errors是個問題，比如大量的靜態寄存器報出非同步錯來，後續要專門review幾遍，腳本處理

3# SDC equivalence verification http://www.tauworkshop.com/2014/Slides/Subram_Equivalence_Checking.pdf

4# 另外關於 sdc quality, spyglass , ccd, 和善用 syn 可以結合使用。 但最根本是要約束 sdc 的寫法和 rule, 這個很重要

5# sdc的qa除了spyglass，之前記得conformal也有一個sdc的qa，Conformal Constraint Designer。PT應該也推出一個sdc檢查的配套工具。sdc的qa還可以通過review PT中unclocked reg，unconstrained path，timing arc break的warning（比如clock propagation被打斷，結果沒有傳到的reg上去，甚至reg有clock，但是沒有high frequency的clock）來驗證，雖然數量很多，但是這部分工作是有意義的。

6# 以前寫過一個腳本，在pre-cts的時候跑pre-STA，通過trace clock structure來預估cts的quality，並且給出一些建議供cts參考

7# excellion concert和 fishtail Confirm 都可以做sdc verification. 包括fp 和mcp的verification. 還有sdc generation 和 promotion demotion功能, mode merging, sdc equivelant check, PT也自帶mode merging 功能, 進而減少 signoff scenario 數量

20. SOC integration方面有哪些不錯的EDA 工具或自研解決方案，大家都是怎麼做的？

1# 不知道Chisel是不是一個合適的解決方案

21. 工程師如何才能把前端流程（包括設計，綜合，STA，DFT，UPF，FPGA驗證等）做的比較深入，在沒有成熟的流程可參考的前提下

1# 回答一個小公司驗證套路的問題吧。在流程完整的大公司干過，也在小公司搞過。剛開始在大公司做的時候，從來都覺得肯定還有bug沒抓完，一遍一遍的跑隨機case，一次又一次的review驗證點，找老員工開會review，即使到簽字畫押了依然覺得驗證完備性不夠。後來從大公司去小公司幹了，心態崩了……

我突然覺得自己以前的驗證做得何等好啊。再看看小公司的，幾乎沒有驗證流程。多數靠嘴，很少靠自動化check.後來一直強推標準驗證流程,第一步，熟悉規格，提取check點，然後找se和design 來review,這一步做仔細，功能驗證能效率提高,第二步，環境搭建可行性報告與策略，出來後找驗證老鳥review.並且結合一些實際難測的點，老鳥們給寫好的建議.

然後就是冒煙測試，case我習慣從直接到隨機，覆蓋點差不多的時候造大隨機case.第三步，反標case。驗證點和case一定要標，防止遺漏。功能覆蓋率也要補上來,除了功能，時序相關的要積極寫斷言assertion.最後，就查看各種覆蓋率吧，toggle覆蓋率容易忽略，會藏bug.另外，有一點，提驗證點的時候邊界點的提取，一定要加減三去提取,另外，我不打廣告，負責任的推薦本書。一本是UVM實戰.

其實，verilog的環境也是可以把sv寫的功能覆蓋率集成進去的,assertion你肯定要吧,覆蓋率只看行覆蓋和條件覆蓋太粗了

1.5# @Jocky.Yu 做大隨機會一個case隨機所有情況嗎？ 1.5# 我個人傾向慢慢放開約束的，不要一上來就搞大隨機. 這樣由於條件，分支選擇比較多，激勵的載入控制會比較複雜，很容易遺漏 有什麼經驗,比如，你有三個約束條件，你分別放開做一次，兩兩分開做一次，最後都放開做一次.雖然case多了，但其實debug會節省時間.還有一個人問題，快速bug的定位。這個說實話我覺得沒捷徑。最基本的就是熟練掌握模擬軟體，第二就是熟悉你所負責的模塊的功能。能吃透設計代碼最好 1.5# 一個關於隨機的技巧是 隨機的時候先隨機seed 然後就是run隨機的case時其實seed是固定的 這樣就可以隨時重現拉波形 不過如果隨機case報錯了，列印seed，下次跑的時候設定這個seed就復現了,這需要腳本把這些都處理好 1.5# 這需要腳本把這些都處理好,然後多寫white box assertion

2# 在題主假定的條件下，要做深入有點困難，但入門是比較容易的：做lab、看文檔而已。要想深入，感覺得刷牛叉項目、解決牛叉問題（若無的放矢，何來深入，恐怕深入到錯誤的方向去了，失去深入的意義，畢竟工程的目的是解決問題）。如果沒有成熟流程參考，一下做牛叉項目，風險很大，即使你自信滿滿，老闆也是不敢的。畢竟冰凍三尺非一日之寒，技術靠積累，不能急功近利。

3# 依靠自己，依靠團隊，依靠ic極客

4# 簡單分享一下自己的經驗吧，目前供職一家小公司分享一下自己的學習經驗，沒有到深入的程度 a. 我覺得是很重要的一點，就是要多交流，多請教大神，自己看文檔理解真的會有偏差 b.充分利用資源，看書，拿手上的項目做實驗。看書是個痛苦的過程，目前主要是user guide為主，s家的guide很不錯，有很多問題userguide 講的很好。 3.面試。可以偶爾參加一下面試，跟面試官多聊，這樣才能暴露自己的問題

5 挑個簡單的回答，很難。新手上手的話，基本上沒法深入，啥啥都不會心會很茫然; 做過case的熟手即使是面對之前沒做過的案子也會比照經驗一步一步去做，談到多深入或高屋見羚或許還談不上。沒辦法，這個行業只能靠熬，速成的人或方法恕還真沒見過。

22. portable stimulus standard是不是有實際應用了？

1# 我們公司還沒用。

2# 聽說CDNS的Perspec在某司用起來了？從宣傳資料看還是主要驗證soc內部的匯流排互聯以及cache性能，複雜IP的集成驗證還是做不了啊

23 大規模asic/soc設計時，fpga驗證存在單片fpga放置不下的問題，將設計分模塊實現在兩片或以上的fpga晶元中進行驗證時有可能需要增加一些交互用的特殊介面或將相同屬性的介面進行復用。這樣，被驗證的設計其實已經與原設計不同，那麼如何保證原設計驗證的有效性？還是說把調整後的設計當做最終設計？

1# 現在有多FPGA的系統和軟體分割邏輯，自動處理FPGA間介面時序.你說的特殊邏輯我們叫HSTDM高速時分復用，是工具插入的組合邏輯，不改變原有設計行為。當然做了TDM，FPGA性能肯定會降低很多

2# 硬體加速有，價格太貴1m吧，就算是硬體加速，據說代碼好像也不能完全重用，大公司多項目可以配一個復用.這個已經沒有實效性可言了，版級交互的頻率很低，再加上串並復用，大設計最後基本上就跑個3.5m赫茲.保證hold，降頻來做到setvp乾淨，功能上基本可以保證，我們這邊這樣弄過

3# 我之前做大規模的系統晶元會使用硬體加速器做模擬.雖然有不足 但是作為驗證和fpga的補充還是能發揮一些作用的.系統驗證速度比驗證模擬快 硬體相對於FPGA驗證平台簡單.在FPGA驗證平台搭建好之前 可以在這上面先把軟硬體系統調試起來 雖然用起來也是比較費勁 但是我們還是在這個平台上驗證出一些bug的 系統晶元,投入本來就大

| 加入IC 極客群

本群由IC 行業的幾位工程師發起，以公益，開源，分享為宗旨，致力於推廣 IC 極客文化，組織大家深入交流IC 設計領域知識，經驗及方法學，打造 IC 設計圈的思想國。

群也歡迎群友或 IC 極客玩家隨機發起不固定主題的討論。歡迎聯繫文末的微信號小主入群參與分享交流。

| 支持 （Donate）

本文經「原本」原創認證，作者Steve Bee，訪問http://yuanben.io查詢【1T8GEKLS】獲取授權