verilog代碼如何debug？
01-03
如題。最近學習fpga，寫了不少verilog，開始思考如何debug的問題！c語言是順序執行，而verilog是並行執行，想請教如何debug自己的verilog代碼，我以前一直都是對照著modelsim上的方針波形來看看哪裡有邏輯錯誤！
哈哈。你一定不知道debug的最高境界是什麼，是猜。對於總工程超過五十萬行，內部代碼上萬行的模塊，丟到FPGA上跑是不可能有波形看的，只能抓debug信號，通常要看的信號太多，debug介面太少會耗費大量時間進行迭代，邏輯分析儀的操作也很耗時，而且很多信號不在debug介面上，沒法看。有時候想用chipscope看，需要編多版bit，每編一版大半天就過去了。所以對於極難調試的問題，一般就靠猜，猜准了再抓。一般來講，拿FPGA跑，上來20秒內掛掉的都是比較明顯的bug，成因不會很複雜，容易解決，真正怕的是那種跑幾十分鐘或者幾小時沒事，然後掛掉的。我昨天剛經經歷這個過程。我們在用FPGA測SSD讀寫的heavy loading，開十個線程同時對flash進行讀寫，然後比較讀出來的結果和寫進去的結果，結果發現跑半個小時沒事，但是此後大約幾分鐘，傳到1KB對齊的末尾地址的時候，有可能會錯幾個byte，我當時由這個現象，根據對design的了解，開始有了某些懷疑方向，然後就開始想像，各個模塊訪問我的模塊之間是如何交互，在何種情況下可能出現這種錯誤，想了半天想到在某種極其巧合的情況下可能會存在訪問衝突，導致出錯，這種衝突只有幾個周期的時鐘窗口，必須周邊的模塊恰巧都在那時候按照一定的順序動作才會出現，於是讓firmware臨時修改了一個寄存器的配置，果然再跑就沒有問題了，接著開始修改design。前幾天還是調FPGA，測試power mode，每兩秒鐘就會進一次睡眠然後再恢復傳數據，跑二十多分鐘會出現進低功耗出不來，當時我用邏輯分析儀抓了幾個狀態機，看完之後大概明白了現象，然後就開始看 code，發現一個複位信號可能導致出錯，然後一跟蹤，發展這個複位居然有七八個源，而且每個源又有五六層邏輯。當時就根據code一點點推斷，由於沒有波形，所以很多信號是0是1就靠猜和推斷，最後我們鎖定了一個信號，這個信號沒有引出到debug介面，所以編了版bit，用chipscope抓，一看果然是它。hack了一下之後，跑了一晚上沒有出錯，而且還抓到了一個華碩主機板的bug。這種方法，說起來還是受到我們team leader的啟發，他負責的code有八萬行以上，因為design太大，所以沒有定位之前就抓基本無益，再加上這些design經過的驗證不少，相對簡單的bug早就修乾淨了，所以一出問題他就會先猜，好幾回都讓他直接命中。
Verilog 代碼如何Debug？
用眼睛看波形，用腦袋想原因，用手敲代碼首先你要知道錯誤是什麼，然後分析。systemverilog部分的錯誤，多是在testbench加print
rtl上的錯誤，要看波形
編譯錯誤，多看書吧在modelsim上用百分之1的時間可以解決百分之99的問題。
沒錯，剩下百分之1的問題，需要你在上板調試時用百分之99的時間來解決。Verilog代碼調試，個人看法：
1、設計代碼前，要根據要實現的功能，將設計方案反覆論證，方案設計的好，後面的設計就不會出現因為原理性問題而返工的現象；
2、模塊要根據功能進行劃分，只要是獨立的功能，就設計成單獨的模塊，越細越好。模塊劃分要合理，這部分也是需要反覆論證的，不要著急寫代碼；3、對每個功能模塊都要做模擬，邏輯模擬是必須的。如果系統頻率很高，那麼實現後的模擬也很重要！4、對於Xilinx FPGA，ChipScope是很好的模擬調試工具，必須掌握！使用ChipScope做模擬，由於FPGA資源限制，不可能將所有的信號都加入模擬，因此要找關鍵信號進行模擬！至於什麼是關鍵信號就要看具體的設計了。5、邏輯分析儀是必備的工具！板級調試時，如果出現問題，先順著自己的設計思路，分析一下產生問題的可能原因，然後去抓取信號分析。這裡需要自己對代碼的設計思路非常清晰，要做到這點其實就又回到了前面提到的系統方案設計，只有方案合理，實現起來才不會出現信號混亂的情況，出現問題也就容易分析。
小可經驗也不多，寫verilog也只有三年。簡單談一下看法吧。首先verilog分為兩大部分，一個是可綜合的部分，也就是用來描述電路結構的；另一部分是用來測試（比如編寫testbench）和建模的，這部分是不可綜合（成具體電路）的，這部分的verilog代碼和C語言比較類似。看題主的描述，應該問的是如何debug可綜合部分的verilog部分。首先這部分verilog是用來描述具體的硬體電路的，所以在編寫時的思路和軟體語言是很不相同的（甚至可以說完全不同）。具體的區別說起來就太多了，直接回答題主的問題吧。之前說了verilog的作用是描述電路，所以在編寫verilog之前，一定要先把電路結構想清楚，最好是把模塊圖畫出來。（即構建好micro-architecture然後再進行編碼，具體的可以上網查一下ASIC design flow，裡面詳細的硬體設計流程）如果是設計狀態機就先把狀態圖畫好。然後對著自己的電路圖一塊塊的編verilog，最後在頂層把它們全部例化連接起來。題主是做FPGA開發的，那麼應該會用到Quartus這個軟體，這個軟體有一個好處是可以看RTL級的電路模塊圖（在tools這個菜單下面），那麼每次編譯完之後都可以看一下生成的RTL級電路模塊圖和自己想的一不一樣，做一個初步的debug。當然這只是一個初學者初步debug的方法，正規的驗證還是要靠testbench。用testbench debug時，可以多運用$display這個命令，他類似於c裡面的printf可以把你想看的變數值，想打的話輸出在屏幕上，這樣可以方便的看一些變數在某個時刻的值，此外就是看波形了～verilog做驗證是一個專門得學科，技巧也非常多，寥寥數語肯定講不清楚，題主可以自己看一些驗證方面專門得教材。
看波形，對於數據可以把數據發出來進行分析
所以我們有了uvm，能夠用驗證解決的問題就不要拖到fpga測試上了，那樣效率很低
多加assertion。
模擬一定要求做到位，上板出現問題，首先是模擬按照同樣的場景去重現，一般上板重現不了的不是非同步處理不對就是工具問題，當然還有那種小概率可能只有上板跑很久才會出現問題的，上板抓波形那是下下策，在模擬之前把綜合，模擬，布線等告警全部看一遍，確保沒有低級錯誤
不要等代碼多了再debug。當你發現代碼太多時，就要考慮分模塊了。把一個功能拆成幾個到幾十個門電路、觸發器組成的模塊，每個模塊的功能要debug好，然後在wire每個模塊。實現每個模塊時要結合看看rtl級的電路
第一步，單元測試。對每一個或幾個高內聚低耦合的.v文件由設計人員進行自測試。原則是在有限時間內可遍歷，或對簡單合法的行為進行遍歷。第二步，CheckIn入開發庫，將代碼交付驗證人員進行模擬集成測試。在開發人員寫代碼和做單元測試的時間裡，驗證人員已經搭好了一個或簡潔或複雜的測試環境，他們運用一種叫做驗證方法學的魔法，將設計人員認為不可能遍歷的測試空間用一種很優雅的方式做了一種近似。在驗證人員手裡，他們將不再看到信號級別的測試空間，而是更關注一種叫transaction的行為。這種行為在驗證人員嘴裡更像一種玄學的表達而無清晰的定義。第二點五步，半實物模擬（Emulation）。可選，故不贅述。第三步，FPGA測試。由於模擬在時間維度上的不可展開，我們必須對設計進行長時間的壓力測試。FPGA自帶的一些debug工具就很好，但不一定夠用。在這裡推薦幾種增強型大殺器供君參考。S2C的DebugModule/ProtoBridge或Synopsys的ProtoLink。好處就是長時間的波形下載，可以像第二步進行模擬一樣進行代碼的debug。舉個例子，S2C的DebugModule可以存儲多大的波形呢？答案是128G-bit。以上。
推薦閱讀：
※Verilog 中定義信號為什麼要區分 wire 和 reg 兩種類型？
※如何評價英偉達發布的 Tesla V100 計算卡？
※片上網路NoC為何還沒有得到實際應用？
※集成電路的工作原理是什麼？
※人類歷史上第一個集成電路使用什麼儀器製作的？