FPGA驗證技術

第一編  驗證的重要性

    驗證，顧名思義就是通過模擬、時序分析、上板調試等手段檢驗設計正確性的過程，在FPGA/IC開發流程中，驗證主要包括功能驗證和時序驗證兩個部分。為了了解驗證的重要性，我們先來回顧一下FPGA開發的整個流程。FPGA開發流程和IC的開發流程相似，主要分為以下幾個部分：
1）設計輸入，利用HDL輸入工具、原理圖輸入工具或狀態機輸入工具等把所要設計的電路描述出來；
2）功能驗證，也就是前模擬，利用Modelsim、VCS等模擬工具對設計進行模擬，檢驗設計的功能是否正確；常用的模擬工具有Model Tech公司的ModelSim，Synopsys公司的VCS，Cadence公司的NC-Verilog和NC-VHDL，Aldec公司的 Active HDL VHDL/Verilog HDL等。模擬過程能及時發現設計中的錯誤，加快了設計進度，提高了設計的可*性。
3）綜合，綜合優化是把HDL語言翻譯成最基本的與或非門的連接關係（網表），並根據要求（約束條件）優化所生成的門級邏輯連接，輸出edf和edn等文件，導給CPLD/FPGA廠家的軟體進行實現和布局布線。常用的專業綜合優化工具有Synplicity公司的Synplify/Synplify Pro、Amplify等綜合工具，Synopsys公司的FPGA Compiler II綜合工具（Synopsys公司將停止發展FPGA Express軟體，而轉到FPGA Compiler II平台），Exemplar Logic公司出品的LeonardoSpectrum等綜合工具。另外FPGA/CPLD廠商的集成開發環境也帶有一些綜合工具，如Xilinx ISE中的XST等。
4）布局布線，綜合的結果只是通用的門級網表，只是一些門與或非的邏輯關係，與晶元實際的配置情況還有差距。此時應該使用FPGA/CPLD廠商提供的實現與布局布線工具，根據所選晶元的型號，進行晶元內部功能單元的實際連接與映射。這種實現與布局布線工具一般要選用所選器件的生產商開發的工具，因為只有生產者最了解器件內部的結構，如在ISE的集成環境中完成實現與布局布線的工具是Flow Engine。
5）時序驗證，其目的是保證設計滿足時序要求，即setup/hold time符合要求，以便數據能被正確的採樣。時序驗證的主要方法包括STA（Static Timing Analysis）和后模擬。在後模擬中將布局布線的時延反標到設計中去，使模擬既包含門延時，又包含線延時信息。這種后模擬是最準確的模擬，能較好地反映晶元的實際工作情況。模擬工具與綜合前模擬工具相同。
6）生成並下載BIT或PROM文件，進行板級調試。
在以上幾個主要開發步驟當中，屬於驗證的有功能模擬和時序驗證兩個步驟，由於前模擬和后模擬涉及驗證環境的建立，需要耗費大量的時間，而在STA中對時序報告進行分析也是一個非常複雜的事情，因此驗證在整個設計流程中佔用了大量的時間，在複雜的FPGA/IC設計中，驗證所佔的時間估計在60％～70％之間。相比較而言， FPGA設計流程的其他環節由於需要人為干預的東西比較少，例如綜合、布局布線等流程，基本所有的工作都由工具完成，設置好工具的參數之後，結果很快就可以出來，因此所花的時間精力要比驗證少的多。
    一般而言，在驗證的幾個內容中功能驗證最受重視，研究討論得最多，特別是現在FPGA/IC設計都朝向SOC（System On Chip，片上系統）的方向發展，設計的複雜都大大提高，如何保證這些複雜系統的功能是正確的成了至關重要的問題。功能驗證對所有功能進行充分的驗證，儘早地暴露問題，保證所有功能完全正確，滿足設計的需要。任何潛在的問題都會給後續工作作帶來難以極大的困難，而且由於問題發現得越遲，付出的代價也越大，這個代價是幾何級數增長的。這裡將以功能驗證為主說明驗證方法、工具、驗證環境的建立、
做功能驗證時，需要建立驗證環境，以便對設計（DUT/DUV，Design Under Test/Verification）施加特定的輸入，然後對DUT的輸出進行檢查，確實其是否正確。在實際驗證工作中，一般採用由TESTBENCH 和DUT(design under test)組成的Verification體系，如下圖所示。

圖1  驗證體系
   這是驗證系統普遍適用的模型，Testbench為DUT提供輸入，然後監視輸出，從而判斷DUT工作是否正確。注意到這是一個封閉的系統，沒有輸入也沒有輸出。驗證工作的難度在於確定應該輸入何種激勵，相應的正確的輸出應該是怎樣的。
下一篇我們看個具體的例子，一起寫代碼和模擬。

第二篇  分析一個testbench
     很多FPGA/IC開發工具都提供設計例子，方便使用者學習和練習，例如，Xilinx ISE提供了很多設計實例，放在ISE5.X的安裝目錄下的ISEexamples目錄下，例如CDMA匹配濾波器、Johnson計數器、PN碼發生器、頻率計等，這些例子是經驗豐富的工程師寫的，我們可以學到編程思想、代碼風格等方面的知識和經驗，這些東西可能從學校老師或一般書籍都學習不到。如果你用的不是Xilinx的FPGA，也就是說不使用ISE，那也沒關係，HDL代碼和testbench的設計思想和方法是一樣的，你照樣可以從中學到很多東西。下面以其中一個例子??同步FIFO為例，分析一下我們的第一個testbench，設計的源代碼可以在ISEexamples目錄下找到， Xilinx還提供了Application Note詳細介紹了該FIFO的細節，下載的網址是http://www.xilinx.com/xapp/xapp131.pdf

1．511x8同步FIFO功能簡介
為了對這個511x8同步FIFO進行功能驗證，首先要清楚它的功能，只有這樣才能知道需要驗證什麼功能，以及如何進行驗證，圖1為該同步FIFO的原理框圖。

與非同步FIFO相比，同步FIFO的讀、寫時鐘是同一個時鐘，簡化了FIFO的設計，Empty和Full標誌的產生也比較容易，同步 FIFO內部使用二進位計數器記錄讀地址和寫地址。在非同步FIFO中，由於讀寫使用不同的時鐘，也就是說設計存在兩個時鐘域，為了減少出現亞穩態時產生的錯誤，記錄讀寫地址的計數器要使用格雷碼，Empty和Full標誌的產生也比較複雜。511x8同步FIFO（以下簡稱FIFO）的工作時序如圖2所示。

讀FIFO數據時，首先read_allow信號置高，時鐘上升沿到來時read_addr地址處的數據將出現在read_data處，同時read_addr加1。讓read_allow信號持續為高可以完成burst read操作。如果讀出的數據是FIFO的最後一個數據，那麼讀操作完成後Empty信號變高。Empty信號為高時讀出來的數據是無效的。

寫FIFO數據時，首先write_allow信號置高，同時準備好輸入數據write_data，時鐘上升沿到來時，數據將寫入 write_addr所指向的地址中，同時write_addr加1。讓write_allow信號持續為高可以完成burst write操作。如果某一個時鐘上升沿時寫入第511個數，那麼下一個時鐘沿到來的時候Full信號變高，表示FIFO已經寫滿。

我們再詳細分析FIFO的工作時序圖。在圖2中，開始時FIFO的讀寫指針均為0，Empty為高表示FIFO處於空的狀態，然後 write_allow置高，時鐘上升沿到來時寫入第一個數據，Empty變低；一個CLK之後，read_allow置高，時鐘上升沿到來時，讀出數據，由於是最後一個數據，所以Empty信號又變為有效（高電平）。在時序圖的右半部分，寫入509個數據之後，再寫入兩個數據，Full信號變為有效，表示FIFO為滿。

這個FIFO還有一個名為fifo_count_out的輸出，從4’b0000~4’b1111，分別表示FIFO滿的程度從不足1/16到15/16，為某些應用提供方便。

2．驗證
清楚FIFO的功能之後，我們就可以開始驗證工作了。驗證工作的第一步是整理出FIFO需要驗證的功能點，這些功能點一般直接來源於FIFO應該具有的功能，或者來源於它的使用方法。FIFO需要驗證的功能點包括：
1）FIFO複位后，read_addr和write_addr為0，Full為0，Empty為1。
2）讀FIFO數據時，read_allow信號必須置高，時鐘上升沿到來時read_addr地址處的數據將出現在read_data處，同時read_addr加1。
3）讀出FIFO的最後一個數據后，Empty信號變高。
4）寫FIFO數據時，write_allow信號必須置高，時鐘上升沿到來時，輸入數據write_data將寫入write_addr所指向的地址中，同時write_addr加1。
5）如果某一個時鐘上升沿時寫入第511個數，那麼下一個時鐘沿到來的時候Full信號變高，表示FIFO已經寫滿。
6）fifo_count_out端能正確的指示FIFO滿的程度。

分析Xilinx提供的testbench可以為我們編寫自己的testbench提供很好的參考。FIFO的RTL代碼和 testbench代碼放在ISEexamples\fifo_ver_131和fifo_vhd_131下。以verilog代碼為例， fifo_ver_131中包括了兩個testbench文件，一個是功能模擬testbench文件fifoctlr_cc_tb.tf，另一個是時序模擬（后模擬）testbench文件fifoctlr_cc_tb_timing.tf，這裡我們主要分析功能模擬文件，為了方便大家理解，以下（下一帖）為註釋過的功能模擬testbench。大家看testbench的代碼時，對照FIFO需要驗證的功能點，檢查是不是所有功能點都經過了驗證。

FIFO的testbench主要包括初始化、驗證initial塊、讀寫task等內容，初始化部分主要完成複位信號、CLK信號等的初始化工作，讀寫task把讀寫、delay等操作模塊化，方便使用。這裡主要介紹一下驗證initial塊，也可以說是驗證的主程序，如下所示。

initial begin
  delay;           //保證驗證環境正確複位
  writeburst128;   //寫入512個數，Full信號應該在寫入511個數后變高
  writeburst128;
  writeburst128;
  writeburst128;
  read_enable = 1; //讀出一個數，Full信號應該變低
  writeburst128;   //同時讀寫，檢查FIFO操作是否正確
  read_enable = 0; //讀操作結束
  endwriteburst;   //寫操作結束
  delay;         
  readburst128;    //連續讀512次，Empty信號應在讀出511個數后變高
  readburst128;
  readburst128;
  readburst128;
  endreadburst;
end

這段程序首先延遲5個時鐘周期，等初始化完成之後再開始驗證工作。驗證時，首先寫入512個數，使用波形觀察器可以檢查寫入的過程是否正確，以及Full信號在寫入511個數后是否變高；然後read_enable = 1，讀出一個數，Full信號應該變低，這樣寫操作和Full信號的驗證就基本完成了；程序接著也啟動了寫操作，由於此時read_enable仍然為高，即讀寫同時進行，這是對實際情況的模擬，可以對FIFO的功能進行更嚴格的驗證；最後，連續讀FIFO 512次，用波形觀察器檢查讀操作是否正確，Empty信號是否在讀出511個數后變高，如果這些操作都是正確的，那麼FIFO的功能就基本正確了。

需要注意的一點是，以上的程序是不可綜合的，因為不是RTL級描述，而是行為級描述（Behavioral Description）。行為級描述的特點是直接描述對象的功能，具有比較高的抽象層次，開發、運行速度都比RTL代碼要會，因此testbench都是用行為級描述寫的。關於行為級描述的特點、寫法以後將有專門的章節論述。

這個testbench的特點是，輸入激勵由testbench產生，輸出響應的檢查人工完成，這樣的testbench編寫相對容易，可以加快開發速度，作為開發人員自己驗證是非常好的選擇。有些testbench能完成輸入激勵和輸出檢查，不用觀察波形也能完成驗證工作，這樣的 testbench具有更高的自動化程度，使用方便，可重複性好，當設計比較複雜而且團隊中有專門的驗證工程師時，一般會有驗證工程師建立一套這樣的 testbench，用於驗證開發工程師的RTL級代碼，如果發現問題，開發工程師修改後在testbench再運行一次所花的時間非常少，開發複雜項目時這樣做可以比用波形觀察器節省很多時間。

3．總結
驗證一般要通過寫testbench實現，從《FPGA驗證》第一篇我們知道，testbench要完成向DUT施加激勵和檢查DUT相應是否正確的功能，這就要求我們非常清楚待驗證模塊（DUT）的功能，這樣才知道需要驗證什麼、如何施加激勵和如何檢查響應是否正確。寫 testbench時， 首先要列出需要驗證的功能，讓后再編寫testbench，這樣可以做到有的放矢，避免遺漏。

思考：
1．Testbench中有“write_enable = #2  1”一行代碼，為什麼要2ns的延遲？

第三篇  驗證工具介紹

    我們做FPGA/IC開發會用到很多工具，包括代碼輸入、模擬、綜合、布局布線、時序分析等各種各樣工具，熟悉這些工具是成功完成設計的關鍵，因為我們的設計思想需要通過這些工具來實現，只有清楚的知道工具的用法、如何設置參數、如果檢查工具的輸出結果，才能使設計者的想法變為顯示，對驗證來說也是如此。

驗證的工具很多，有些是驗證必不可少的，例如模擬器，有些工具可以代替人完成最繁瑣的工作，並能提高功能驗證的可信度，例如linting和代碼覆蓋率工具。這裡我們介紹常用驗證工具的特點和用途，以便為工具的使用提供參考。

1）代碼檢查工具
常用的代碼檢查工具有nlint等，nlint根據設計的RTL描述代碼結構做靜態分析，推斷描述代碼存在的邏輯錯誤，但無法決定描述代碼是否能夠現實設計要求的功能。代碼檢查工具可用於強制代碼遵從編寫規範，由於代碼檢查工具工具是靜態驗證工具，因此運行速度快，可以節省時間。由於Verilog不是強類型語言，使用代碼檢查工具非常必要，可以檢測race conditions 及數據寬度不匹配，可保證Verilog正確描述數據處理過程，避免造成數據的棄位及增位現象，這種錯誤通過模擬並不一定發現。因為verilog 語言的特點， 對Verilog描述的設計，Linting tool是一種有益的驗證工具。因為VHDL 語言的特點，對VHDL使用Linting tool的作用不如對Verilog語言那麼明顯，但Linting tool還是能發現一些潛在的問題。

2）模擬器
模擬器是常用的驗證工具，它通過忽略及簡化設計的物理特性，對設計的實現進行模擬。模擬器通過執行RTL級的設計描述，模擬設計的物理實現，它無法確定設計真實的物理實現與設計描述之間的區別。模擬的結果取決於設計描述是否準確反映了設計的物理實現。模擬器不是一個靜態工具，需要編寫激勵和檢查輸出響應。激勵由模擬設計工作環境的testbench 產生，響應為模擬的輸出，由設計者確定輸出的有效性。

模擬器的類型分為3種類型，Event-driven Simulator（事件驅動模擬器）、Cycle-Based Simulator（基於周期的模擬器）、Co-Simulator（聯合模擬器），分別介紹如下：

1．Event-driven Simulator
事件驅動模擬器是最常用的模擬器，例如modelsim/VCS等都是事件驅動模擬器，它將信號的變化定義為一個事件，該事件驅動模擬執行，事件驅動模擬器能準確地模擬設計的時序特徵，可模擬非同步設計。

2．Cycle-based simulator
Cycle-based simulator模擬器的特點是忽略設計的時序，假定所有flip_flop的setup和hold時間都滿足要求，在一個時鐘周期，信號僅更新一次，從而信號必須與時鐘同步。模擬速度比事件驅動模擬器高。基於周期的模擬器的工作過程步驟是，首先編譯電路，將組合邏輯壓縮成單獨的表達式，根據該表達式可確定flop的輸入，然後執行模擬，遇到時鐘的有效沿， flip_flop 的值被更新。基於周期的模擬器的缺點是不能模擬非同步電路，不能進行驗證設計的時序。

3．Co-Simulators
聯合模擬器對同一設計各個部分，分別用不同的模擬器模擬，如即含有同步設計又含有非同步設計的電路，可用Event-driven Simulator對非同步設計模擬，用Cycle-based Simulator對非同步設計模擬。聯合模擬器中各個Simulator 的操作是locked-step的，類似於電路的pipeline 操作。其缺點是由於不同模擬器之間需要同步和相互通訊，Co-Simulators的模擬速度受到最慢Simulator的限制，因而影響模擬器的性能，而且在各模擬器傳送的信息會產生多義性。

4．Hardware modeler
硬體模擬器創建一個物理晶元的邏輯模型，向模擬器提供該晶元的行為信息，晶元和模擬器的通信過是首先將物理晶元插入硬體模擬器，然後格式化來自模擬器的數據，作為該晶元的輸入，最後將該晶元輸出的數據，包含時序信息，送往模擬器。硬體模擬器可以提供很高的模擬速度，但是設備價格高昂。需要注意的是，硬體模擬器做的仍然是功能模擬，而不是時序模擬，因為晶元是降頻運行的。

3）波形觀察器
模擬調試的過程中波形觀察器是必不可少的工具，它能提供信號狀態和變化的詳細信息，但是波形觀察器不能用來判斷一個設計是否通過驗證，因為波形是不可重複的且無法用於遞歸模擬。

波形觀察器的優點是可以觀察模擬的整個過程，有利於設計及testbench 的診斷，缺點是由於要輸出波形，影響了模擬的速度，因此應儘可能限制在波形圖中顯示的信號數量及時間長度。波形觀察器的另一個作用是波形比較，主要用於 redesign，保證設計具有cycle-accurate的後向兼容性。在波形比較中，不能僅看錶象，需仔細分析，確認波形之間存在的差別是有意義的。例如，有時我們僅關心波形transitions之間的相對位置，而不關心它的絕對位置。

以上是比較常用的驗證工具，另外可能用到的驗證工具有：形式驗證工具、靜態時序分析工具以及Vera、SpecmanE、SystemC等高級語言驗證工具，這些工具在複雜的IC/FPGA設計中用得比較多。