使用FPGA測試的一些有效方法

【摘要】
對于芯片前端設(shè)計而言，在流片前的測試是保證芯片正常工作的重要環(huán)節(jié)。本文針對FPGA驗證方法中遇到的一些棘手問題，提出了自己的解決方案并在實際工程中加以使用，取得了良好的效果。

【關(guān)鍵詞】
FPGA 測試 時序 代碼一致性

引言

隨著芯片設(shè)計技術(shù)越來越成熟，越來越多的產(chǎn)品選擇使用SoC（System on Chip）的技術(shù)實現(xiàn)。然而，每一次流片不一定都能達到預期的效果。根據(jù)Synopsys公司統(tǒng)計，有超過60％的公司需要重新流片（respin）。在這個過程中浪費了大量的金錢，一次修正平均的花費就超過100萬美元。如果一旦錯過了商品推出的最佳時機，那么錯過市場機會的代價則以數(shù)千萬美元計，甚至更高。據(jù)統(tǒng)計，在需要respin的芯片中有43％是在前端的設(shè)計和實現(xiàn)的時候產(chǎn)生的邏輯功能錯誤。如何避免或減小如此高的風險是每一個設(shè)計單位思考的問題。

現(xiàn)在行業(yè)內(nèi)有兩種解決此問題的方案，第一種方案是利用越來越先進的EDA仿真工具仿真測試。業(yè)界產(chǎn)品的兩大巨頭Synopsys和Cadance都推出了自己的解決方案。然而，EDA工具非常昂貴，卻不一定能滿足每一個項目的要求。另外，EDA工具的仿真時間很長。用一套無線通信系統(tǒng)舉例，初始化的過程就需要半天的時間，每收發(fā)一幀都需要3－4個小時，因此在有限的時間內(nèi)不可能完成比較全面的測試（測試時采取的都是并行運算的方式，工作站都是Sun Blade2000的配置）。最后，仿真軟件再完善也不是實際的硬件操作，因此某些只可能在硬件上發(fā)生的問題，無法通過仿真來獲得。比如某些時序問題和功耗問題。另外，硬件的“脾氣”比較古怪，經(jīng)常會出現(xiàn)一些意想不到的狀態(tài)，這些都是仿真軟件無法模擬出來的。第二種解決方案是采用FPGA進行真實的硬件測試。比如Xilinx公司的EasyPath解決方案。然而使用這種方案也面臨著一些需要解決的問題，比如如何使設(shè)計的產(chǎn)品可以既在ASIC上工作，又在FPGA上正常工作，如何保證FPGA與ASIC的一致性。針對這些問題的解決方法是本文重點討論的內(nèi)容。

本文的測試實例和測試方法均來源于北京市嵌入式重點實驗室的無線局域網(wǎng)芯片項目，本項目的產(chǎn)品目前已經(jīng)成功流片。這些測試方法的應(yīng)用對項目的順利進展起到了關(guān)鍵性的作用，起到了良好的效果。
 
時序問題的解決

我們知道FPGA可以接受的時鐘和所允許的時序遠遠低于ASIC。但作為ASIC產(chǎn)品而言，我們在設(shè)計的時候又往往采取較高的時鐘速率。由于ASIC時鐘樹與布線相對自由，故對于高速率設(shè)計解決起來相對容易。對于Xilinx FPGA而言，盡管采用了90nm工藝的Virtex-4可以支持的性能高達500M[1]，但是其時鐘樹和布線資源相對固定，因此一旦在編譯和布局布線的時候處理不當，就會產(chǎn)生時序沖突（timing violation）。產(chǎn)生時序沖突的結(jié)果，輕則使設(shè)計的邏輯與實際布局布線后的網(wǎng)表不一致，重則導致布局布線根本無法通過，從而致使驗證無法進行。

我們在解決時序問題的時候采取了五種不同的方法。其中一種方法是應(yīng)在設(shè)計中就加以注意，兩種在綜合的時候進行，還有兩種在布局布線時采用。

設(shè)計過程中注意時序問題

若希望設(shè)計的產(chǎn)品能夠在FPGA驗證平臺上順利的完成驗證，在設(shè)計過程中就需要注意盡量多的使用FPGA的內(nèi)部資源，如DSP48，乘法器，RAM，DCM等。

在我們的設(shè)計中有不少濾波器，這些濾波器正好可以使用DSP48[2]這個模塊。該模塊如圖－1所示，為乘加結(jié)構(gòu)。濾波器若不使用這種模塊，則需進行大量的乘、加運算。這樣不但浪費資源，而且很容易導致時序無法滿足要求。而如果使用這樣的模塊，則基本上所有的濾波器都不再處于“最差路徑”上。

 
 
圖 1 DSP48示意圖

對于乘法器，如果使用slice搭建不僅浪費資源，而且性能差，位寬一旦比較寬就會導致時序出現(xiàn)問題。Xilinx的ISE中配有Core Generator這個工具。通過該工具可以生成需要的乘法器。使用這些乘法器來代替普通的乘法器，可以達到滿意的效果。除了乘法器，還可以使用該工具產(chǎn)生RAM和DCM等，在此不再贅述。
 
綜合過程解決時序問題

我們使用Synplicity公司的Synplify工具進行綜合，這是業(yè)界通常使用的綜合工具之一。選擇該工具最主要的原因在于它與Xilinx的FPGA配合的很好。我們做過實驗，通過該工具綜合產(chǎn)生結(jié)果報表，再通過ISE產(chǎn)生真實布局布線后的報表。對這兩個報表的時序估計部分進行對比，我們發(fā)現(xiàn)兩者之間驚人的相似，最差路徑之間的差別不超過1ns。

我們知道，綜合的時候需要設(shè)置約束，最重要的是時鐘約束。這個約束限制了系統(tǒng)工作的頻率。為了降低系統(tǒng)對于時鐘抖動的敏感性，我們采取的第一個方法是在設(shè)置時鐘約束的時候?qū)⒋思s束值設(shè)的略高于實際的時鐘頻率。這樣做有一個前提，那就是在綜合后不得有負的時鐘余度（time slack）出現(xiàn)。當沒有負的時鐘余度出現(xiàn)的時候，提高時鐘約束可以有效避免因時鐘抖動而引入的時序問題，但是如果因為提高了約束中時鐘頻率，而導致負的時鐘余度的出現(xiàn)，那么有可能導致在布局布線過程中產(chǎn)生時序沖突而無法正常布局布線。在這種情形下，就不宜提高約束中的時鐘頻率。

在綜合中采取的第二個方法是使用綜合工具提供的pipeline和retiming功能[3]。這些功能可以調(diào)整寄存器的位置，使之在不改變邏輯的前提下，將寄存器的位置調(diào)整的更加合理，如圖－2所示。這個功能主要用于組合邏輯過長且不合理的情況下。當然，如果某些乘法器位數(shù)過寬而結(jié)果沒有寄存的時候也會導致組合邏輯時序緊張。當發(fā)生這種情況而retiming功能又無法糾正時，就需要設(shè)計者在做設(shè)計的時候?qū)Τ朔ㄆ鞯妮敵鼋Y(jié)果做一拍寄存，同時其余的控制邏輯也要做相應(yīng)的調(diào)整。

 
 
圖 2 retiming 示意圖

布局布線階段解決時序問題

當綜合工作完成，進入布局布線的階段后，仍然有兩種方法可以改善邏輯時序問題。

第一種是手動增加并調(diào)整BUFG（Global Clock Buffer）。BUFG是Xilinx的全局時鐘資源，所有時鐘樹的起點都是BUFG，位于FPGA的北極和南極。當布線后仍有負的slack時，有可能是某些當作時鐘使用的信號沒有被放上時鐘樹，此時就要手動將這些信號放上BUFG。若遇到門控時鐘，還應(yīng)該使用BUFGMUX資源。另外，在Virtex-4中，北邊的BUFG主要負責北部的時鐘，南部的BUFG負責南部的時鐘。在我們的項目中，共有十余個時鐘，因此，BUFG位置的選擇也很關(guān)鍵。有些時候，工具不能解決一切問題，只有手動調(diào)整BUFG的位置，或?qū)UFG的位置信息寫入用戶約束文件才可以取得較滿意的效果。

在Virtex-4中共有16個BUFG，若都被使用且經(jīng)手動優(yōu)化后仍不滿足要求 ，那么還可以使用ISE提供的Floorplanner工具，對設(shè)計的各個模塊手動進行位置擺放，使各個模塊盡量靠近自己所使用的時鐘樹。

代碼一致性

對于經(jīng)過FPGA驗證的代碼而言，最擔心的是經(jīng)過驗證的代碼和進行流片的代碼不一致。導致這個現(xiàn)象產(chǎn)生的原因是多種的，其中版本控制和由于FPGA、ASIC專用器件不一致而引起的問題是最常見的兩個問題。前者不在本文的討論范圍，故在此略過。

對于經(jīng)過FPGA驗證的代碼，為了能夠使被測代碼可以順利的在FPGA進行驗證，根據(jù)2.1節(jié)所述，一般都采取了FPGA專用的器件。這些FPGA專用器件在ASIC中是不存在的。為了解決這個問題，我們通常采取“假代碼”（Fake Code）解決。

顧名思義，“假代碼”就是在代碼中保留FPGA專用器件的名稱和接口，但是在FPGA和ASIC中使用不同的器件內(nèi)核。該器件若在FPGA下使用則使用FPGA專用器件，若在ASIC下使用，則使用自己編寫的代碼。盡管這種做法仍然無法保證代碼的完全一致，但是卻最大限度的避免了代碼的差別。

結(jié)論

究竟使用EDA 仿真工具還是使用FPGA進行流片前的功能驗證一直是業(yè)內(nèi)討論的熱點話題，不同的設(shè)計、測試人員也有自己的觀點。本文針對使用FPGA進行驗證測試所遇到的一些問題提出了相應(yīng)的解決方法，對于使用FPGA進行驗證測試的工程師有一定的參考意義。

【參考文獻】
1 《Virtex-4 User Guide》 Xilinx Corp.
2 《XtremeDSP for Virtex-4 FPGAs User Guide》 Xilinx Corp.
3 《Synplify Pro User Guide》 Synplicity, Inc.