FPGA設(shè)計驗證關(guān)鍵要點

1、FPGA設(shè)計驗證關(guān)鍵要點不同于ASIC設(shè)計，F(xiàn)PGA設(shè)計中的標(biāo)準(zhǔn)元件或客制化實作，一般欠缺大量的資源及準(zhǔn)備措施可用于設(shè)計驗證。由于可以重新程式化元件，更多時候驗證只是事后的想法。本文將探討在FPGA設(shè)計驗證周期過程中使用的工具及技術(shù)，并逐一審視各項優(yōu)缺點。有效驗證降低設(shè)計風(fēng)險FPGA設(shè)計驗證的規(guī)畫和預(yù)算安排的失敗，可能瓦解整個產(chǎn)品開發(fā)計畫；時程的延誤會和光罩技術(shù)的再修正（respin）一樣嚴(yán)重。由于失誤可重新程式化加 以修正，驗證的風(fēng)險不高，因此并未把追蹤及校正錯誤所需的成本納入考量。尤其在復(fù)雜、多重時脈FPGA設(shè)計中，若將元件、系統(tǒng)及軟件開發(fā)的交互影響考慮進(jìn) 來，這個后果更可能會加大數(shù)倍。一

2、個良好驗證技術(shù)和工具，在FPGA開發(fā)過程中可用來大量減少使用元件的風(fēng)險。在此架構(gòu)中，初始驗證傾向于高階中執(zhí)行以發(fā)現(xiàn)總體功能上的錯誤，但當(dāng)驗證程 序進(jìn)行到設(shè)計以全速操作所有功能的最終目標(biāo)時，設(shè)計上的問題逐漸困難到令人難以理解。通常問題和資料及時序相關(guān)，有些問題很少碰到甚至要以全速執(zhí)行驗證數(shù) 小時甚至數(shù)天，才能偵測到它們發(fā)生一次；有些問題顯然和一些模糊不清的事件有高度相關(guān)，當(dāng)真的碰到時，必須先準(zhǔn)備好測試環(huán)境以捕捉該問題并提供資料才能作 分析。  多數(shù)模擬提供之驗證并非完整 模擬將設(shè)計編譯成一種以邏輯向量作為驅(qū)動的形式，該向量代表輸入驅(qū)動信號.。設(shè)計中的行為模式可看成一種波形，設(shè)計者使用邏

3、輯模擬器來修正設(shè)計中的錯誤。 模擬運(yùn)作在RTL層次，因此能提供設(shè)計者一個熟悉的設(shè)計視野，它提供一個設(shè)計最完整且最能掌控的視野，設(shè)計中任何電路節(jié)點都可被檢視及強(qiáng)制設(shè)定到一邏輯準(zhǔn)位。然而，相對于實際元件運(yùn)作的速度，模擬一個具有眾多向量的大設(shè)計是非常慢的。  大部份的模擬使用一個測試向量（test bench），該測試向量一般包含設(shè)計本身及驅(qū)動設(shè)計的所有輸入；包含系統(tǒng)中操作該設(shè)計的資料、時脈、重置及控制的邏輯信號，而輸入的資料樣式及時序便是 由這些邏輯信號決定的。若設(shè)計中包含復(fù)雜的模組，像是和外界溝通的Ethernet、PCI埠，或是外部存儲器控制器，那么測試向量可能也包含了外部元件 的模

4、擬行為模組，該模組塑模了系統(tǒng)運(yùn)作時FPGA和外部元件的互動模式。  模擬模組可由設(shè)計FPGA邏輯的設(shè)計者同一人建立，因為他們了解這些介面是如何運(yùn)作，而介面運(yùn)作是由元件的規(guī)格表（datasheet）中的時序圖所推斷出來。 當(dāng)有其他廠商的IP產(chǎn)品用于設(shè)計時，該IP通常都包含一個用來驗證它自己的介面模型，該模型可以整合進(jìn)設(shè)計的測試向量以驅(qū)動IP介面。  測試向量模擬采用固定的信號時序設(shè)定及FPGA外部元件的邏輯模型當(dāng)作模擬引信（stimulus），模擬結(jié)果顯示于波形檢視器，設(shè)計者以波形和設(shè)想的行為模式比對并反覆修正設(shè)計原始碼來作邏輯除錯。  然而，RTL模擬只能顯示邏輯

5、行為，如果信號的時脈或是模型效能和實際的元件行為不同，那么模擬結(jié)果和元件實際下載到系統(tǒng)板上的結(jié)果將不相符；盡管 將設(shè)計實作后之目標(biāo)元件時序回貼（back-annotate）是可行的，如此模擬的行為可以反應(yīng)實際實作后的時序，但這并不能校正任何測試向量和實際運(yùn) 作環(huán)境時序上的差異。 時鐘（clocks）在多重時脈系統(tǒng)中是另一個特別要注意的信號來源，在此系統(tǒng)中并無一個實用的方法可以建構(gòu)這些在測試向量中的相位及頻率的關(guān)系，而這些時序關(guān)系可以明確決定該設(shè)計是否在系統(tǒng)能正常運(yùn)作。  當(dāng)模擬設(shè)計時，驗證層級是測試向量和實際運(yùn)作環(huán)境相似精確度的函數(shù)，以精確地反應(yīng)母板環(huán)境的向量來模擬設(shè)計去偵測到最多的

6、錯誤。然而，建構(gòu)這類的環(huán)境并不容易，而且大多數(shù)向量僅提供實際引信的近似值，大多數(shù)情況下，模擬提供的驗證不完整。  硬件驗證 僅管模擬提供了設(shè)計一個重要的層級，但它對設(shè)計效能在整體系統(tǒng)中的表現(xiàn)，沒有提供足夠的瞭解。因為引信（stimulus）最多只是實際環(huán)境的近似值，硬件驗證提供了唯一方法，可以瞭解當(dāng)FPGA于系統(tǒng)中以時脈速度運(yùn)作時，內(nèi)部究竟發(fā)生了什么事。  FPGA硬件驗證可分為用邏輯分析儀的外部驗證及用硬件除錯器的內(nèi)部驗證。  使用邏輯分析儀之外部驗證邏輯分析儀原本用于電路板層級的除錯。透過I/O接腳連接到FPGA內(nèi)部訊號用來監(jiān)控FPGA內(nèi)部信號。邏輯分析儀提供

7、從板子以及從FPGA內(nèi)部同時捕捉資料的好處，這能力足以分析整個系統(tǒng)。  將PCB板上接腳連上FPGA沒使用到的腳位就可用邏輯分析儀連接或是探測FPGA。板上接腳另外連上邏輯分析儀接頭，將FPGA接腳設(shè)計成連進(jìn)設(shè) 計內(nèi)部成為連接埠（ports），深入設(shè)計內(nèi)的線路節(jié)點。接著，設(shè)計以可程式化的邏輯工具繞線，就可以捕捉到信號值并顯示在邏輯分析儀。  當(dāng)邏輯分析儀捕捉到元件內(nèi)部節(jié)點的資料時，以上方式提供了視窗以透視元件在系統(tǒng)中運(yùn)作的情形，不過會有些缺點：首先，設(shè)計者必須手動更改設(shè)計，在階 層中一路向上穿透，將內(nèi)部節(jié)點連到元件接腳，該接腳再連接至外部板上接腳。而這過程在每一次反覆修正中

8、都要重覆一次，不屬于設(shè)計中元件層級的節(jié)點都必須繞 線到最上層，不僅容易出錯而且耗費時間。  再來，探測能力受到元件上可自由運(yùn)用接腳及板上接腳的數(shù)目限制。第三，信號名稱必須輸入邏輯分析儀之檢視器以追蹤設(shè)計中哪個節(jié)點顯示在哪一行，而每次探測點一移掉，名稱就得重新輸入。最后，除了設(shè)計原訂目的，設(shè)計中節(jié)點繞線到其他的接腳，可能會干擾到元件運(yùn)作或時序。  目前有工具可減少自設(shè)計中展開網(wǎng)目（net-list）節(jié)點的連接數(shù)目，將深藏在設(shè)計階層中的節(jié)點以訊號線導(dǎo)引至最上層，該技術(shù)可減輕這樣的負(fù)擔(dān)。缺點是由于使用網(wǎng)目，在設(shè)計從RTL到網(wǎng)目過程中，其名稱及功能會改變，卻沒有警訊并會提錯誤資訊。

9、  邏輯分析儀具備復(fù)雜的觸發(fā)機(jī)制選項，但觸發(fā)點不是設(shè)計來捕捉FPGA內(nèi)部事件，它只能操作在連接到外部接腳的那些節(jié)點上，使用邏輯分析儀對FPGA內(nèi)部設(shè)計除錯是相當(dāng)費時、不方便和受限的。  硬件除錯器 沒有模擬的人為操作及邏輯分析儀的使用不便，硬件除錯器代表系統(tǒng)驗證工具的最終手段。不像模擬器，除錯器顯示了元件實際的邏輯資料，讓設(shè)計者看到當(dāng)元件在系統(tǒng)中以全速運(yùn)作時，其內(nèi)部邏輯的實際運(yùn)算結(jié)果。以元件硬件資源來換取資料和命令，讓除錯器不再需要元件的接腳。  在眾多的除錯器中，可發(fā)現(xiàn)有不同運(yùn)算的特色及方法的除錯器，除錯器可大致分為二大類：設(shè)計網(wǎng)目型以及原始代碼型（source

10、 code）。除錯器同時也提供不同的觸發(fā)機(jī)制及功能。 網(wǎng)目除錯器網(wǎng)目除錯器定義為：在合成（synthesis）而展開后的網(wǎng)目設(shè)計上運(yùn)作，探測（Probes）及觸發(fā)點直接加到網(wǎng)目，資料則會顯示在波形圖上。  RTL除錯器RTL除錯器可顯示在設(shè)計層級，而探測及觸發(fā)點直接加于原始代碼上，其結(jié)果可貼回（annotated）到原始代碼，在時間軸上前進(jìn)或退后以顯示每個時脈來觀察，也可以用波型圖看到結(jié)果。  除錯器需求驗證設(shè)計時，要使工具好用，一些需求是基本的，每個需求視所需要的程度而定，而工具提供這些能力的程度，決定這個驗證工具可應(yīng)用在多大的范圍。明顯地，資料必須精確地反應(yīng)R

11、TL功能，而設(shè)計者必須要能將資料和原來設(shè)計關(guān)連起來，除錯器必須提供檢視和解釋結(jié)果的方法。  所有的除錯器都在探測設(shè)計的節(jié)點并圖形化顯示結(jié)果。然而，為了效率最佳化，除錯器必須在RTL層級上探測和顯示結(jié)果，因為那是一般熟悉的設(shè)計版本，而且那里的邏輯必須運(yùn)作地和預(yù)設(shè)的一樣。  當(dāng)使用硬件除錯器時，很重要的一點是，它要能精確地補(bǔ)捉發(fā)現(xiàn)錯誤和驗證系統(tǒng)行為所需的資料。工具不僅必須定位某一事件附近的邏輯轉(zhuǎn)換位置，而且要能追蹤甚少發(fā)生事件的錯誤，并保證可以捕捉到這些事件以作進(jìn)一歩檢查。  除錯器必須提供觸發(fā)機(jī)制，能捕捉任何時刻、任何頻率的任何邏輯事件，并把相關(guān)的資料收集起來。觸發(fā)

12、必須要有夠強(qiáng)大的功能，能一路追查一系列的事件到 觸發(fā)的根源。最后，除錯器必須要能偵測跨不同時域的事件，如：電子不穩(wěn)態(tài)（metastability） 在某段時間內(nèi)造成的信號轉(zhuǎn)換。這些需求在下面的章節(jié)中會再討論，并對照比較操作在RTL及網(wǎng)目層級的工具差異。  加入探測及觸發(fā)點除錯器應(yīng)該要能支援快速且容易地加入探測點及觸發(fā)器，允許資料能輕易地對照到原設(shè)計。最重要的是，它要保證資料在任 何時刻的完整性，能提供選擇個別節(jié)點、整條或各組（field）匯流排的能力，以供探測及觸發(fā)點之用。網(wǎng)目除錯器顯示設(shè)計中所有節(jié)點的清單供探測個別節(jié)點 或用來當(dāng)作觸發(fā)點，這清單可以透過篩選器刪減以顯示其中某部份，節(jié)

13、點可以被選定作為探測或觸發(fā)點。  節(jié)點的名稱可能令人陌生，因為它們是經(jīng)過編譯產(chǎn)生的，其功能在編譯過程中可能已經(jīng)改變了。RTL除錯器則直接在原始代碼中加入探測和觸發(fā)點，在下面 圖一中，顯示了一個經(jīng)Synplicity的Identify RTL Debugger編譯過的設(shè)計，其中所有可能被探測的節(jié)點都以小圖示標(biāo)記起來，點選其中一個節(jié)點會開啟一份選單讓人設(shè)定該節(jié)點是一個探測點、觸發(fā)點、或者 二者皆是，因為有維持住設(shè)計層級，很直覺就可以瀏覽設(shè)計以定位探測點。 <圖一> Synplicity's Identify Instrumentor 除了探測個別節(jié)

14、點，除錯器應(yīng)該還要能從匯流排上捕捉并顯示資料，匯流排及匯流排組也應(yīng)該要能當(dāng)作觸發(fā)點，就如同個別節(jié)點一樣，匯流排組（fields）應(yīng) 該要能被程式化以針對特定或某范圍的值檢查。匯流排在網(wǎng)目中會被展開，但可在網(wǎng)目除錯器中藉由選擇匯流排中每一個位元來重組成一匯流排，在這樣的一個匯流 排中無法探測或觸發(fā)其中某部份，因為在設(shè)計展開后的版本中，匯流排的觀念是無意義的。  Identify RTL Debugger可提供個別節(jié)點、匯流排以及部份匯流排的信號量測。部份匯流排區(qū)段的定義以下面圖二的選單來定義，其中指定了要取樣或是作為觸發(fā)點的匯流排組。       <

15、圖二>Identify Instrumentor，匯流排觸發(fā)選單 每個部份匯流排區(qū)段都可以上圖二中的匯流排觸發(fā)選單來量測，指定匯流排組后，其它的選項用來探測（取樣）該匯流排組，從數(shù)個樣式中觸發(fā)一至二個。  移動探測點在除錯期間，很難預(yù)期設(shè)計中所有可能發(fā)生錯誤的節(jié)點都可被依序探測到。大部份情形是，在驗證過程中會不斷反覆探測不同的次 數(shù)及位置，最差的情形是，這些改變需完整重新編譯，包含整體設(shè)計合成及布局繞線，理想上每次探測不須耗費使用者太多力氣，不用重新編譯。Identify RTL Debugger和某些網(wǎng)目除錯器都提供加速編譯（incremental compilat

16、ion），藉由呼叫FPGA編輯器來修改現(xiàn)有繞線，讓探測或觸發(fā)點從其中一點移到另一點。  跨時域觸發(fā)多重時脈在FPGA元件中經(jīng)常被使用，多個專用的時脈緩沖器是其特徵。在多重時脈系統(tǒng)中常碰到有關(guān)不同時域間資料的時序問 題。這類問題包括電子不穩(wěn)態(tài)（metastability）,setup及hold time無法達(dá)成，以及資料流失的問題。偵測這種細(xì)微的問題一般來說是很困難的，這種問題可能根本不會在邏輯模擬中出現(xiàn)，也無法僅用單一時域內(nèi)過度取樣， 或是在某時域內(nèi)觸發(fā)而在另一時域內(nèi)取樣的除錯方式偵測到。硬件除錯器應(yīng)該提供方法偵測這類由跨時域間資料傳遞所引發(fā)的問題。網(wǎng)目除錯器沒有提供任何偵測跨 時域

17、時序問題的機(jī)制。  Identify RTLDebugger提供一個交互觸發(fā)的功能，如下圖三所示，可允許觸發(fā)某時域內(nèi)邏輯，去驅(qū)動和致能另一時域內(nèi)的觸發(fā)器。交互觸發(fā)可用來檢視跨時域事件的時序，藉由另一個更快時脈過度取樣某時段，它亦可用來觀看該時段內(nèi)發(fā)生的事件。 <圖三>交互觸發(fā)例子 取樣和觸發(fā)模式當(dāng)觸發(fā)條件成熟時，取樣模式控制資料被加入緩沖器的方式，這些模式允許使用者依據(jù)不同模式排列資料流入順序，僅藉由排序相關(guān)資料，即可增加緩沖器的使用效率，例子包括填充整個緩沖器、儲存單一取樣信號線或中斷前才進(jìn)行儲存。  觸發(fā)模式描述對應(yīng)觸發(fā)條件的資料儲存時序

18、，例子包括觸發(fā)周期的數(shù)目、週期寬度及某週期之后的延遲時間。  網(wǎng)目除錯器僅提供非常陽春的緩沖器控制，只有每個觸發(fā)取樣的數(shù)量或是緩沖器的設(shè)定，但沒有實際資料排序的能力。Identify RTL Debugger有四個取樣模式及四個觸發(fā)模式，取樣模式控制緩沖器如何補(bǔ)捉資料，觸發(fā)模式則控制資料捕捉時序。  狀態(tài)機(jī)觸發(fā)偵測獨特條件最精確最強(qiáng)而有力的方法就是使用狀態(tài)機(jī)作為觸發(fā)方式。當(dāng)追蹤一連串事件時，狀態(tài)機(jī)可追查任何條件之間的狀態(tài)， 狀態(tài)機(jī)建立一連串元件運(yùn)作時，必須要完成的歩驟及條件，以達(dá)到一個以上的觸發(fā)條件。觸發(fā)條件可以和任何狀態(tài)聯(lián)結(jié)在一起，以使?fàn)顟B(tài)機(jī)收集模煳不清事件的資 料。 &

19、#160;網(wǎng)目除錯器沒有內(nèi)建狀態(tài)機(jī)觸發(fā)點，但允許手動實作狀態(tài)機(jī)或計數(shù)器以觸發(fā)某一事件，藉由編輯原始代碼可將狀態(tài)機(jī)加入設(shè)計中。手動解決方案需要人為調(diào)整邏輯，也需要手動為每個觸發(fā)作調(diào)整，再指定新的觸發(fā)節(jié)點，最后予以重新合成。除錯器中的觸發(fā)點會附在狀態(tài)機(jī)的節(jié)點上。  網(wǎng)目除錯器的確包含一簡易串列狀態(tài)條件的形式，這是在進(jìn)行到最后之儲存資料條件前，必須滿足的一連串觸發(fā)條件。并不提供路徑，或是發(fā)生單一狀態(tài)次數(shù)的計算，以及停留在某一狀態(tài)內(nèi)時間的其他選擇。  Identify RTL Debugger提供了狀態(tài)機(jī)編輯器，藉由提供包含巨集觸發(fā)功能的選單式編輯器以自動觸發(fā)狀態(tài)機(jī).。例如；是否觸

20、發(fā)某個狀態(tài)，或是在某條件下觸發(fā)，以及如 何使用計數(shù)器觸發(fā)等.都可在除錯器內(nèi)作調(diào)整，也可以在除錯過程中動態(tài)改變設(shè)定，并不會直接影響設(shè)計。  如下圖四所示，該編輯器可使用任何觸發(fā)/條件模式，或一至二個類似狀態(tài)機(jī)的取樣模式的巨集。巨集編輯器包含一些欄位設(shè)定，可決定某狀態(tài)會使用的條件以及事件數(shù)量，或是計算出來的取樣數(shù)，每個狀態(tài)都有轉(zhuǎn)移到其他狀態(tài)的條件。 <圖四>Identify RTL Debugger狀態(tài)轉(zhuǎn)換編輯器將觸發(fā)狀態(tài)機(jī)自動化 斷點（Break Point）觸發(fā)在RTL分支敘述（如WHEN或IF敘述）上觸發(fā)，允許設(shè)計者直接從原始代碼本身而非邏輯值上表明

21、觸發(fā)，好處是可以更接近原始代碼的方式參照設(shè)計的除錯資料。本質(zhì)上，網(wǎng)目型產(chǎn)品并不能提供斷點觸發(fā)，因為觸發(fā)點僅在網(wǎng)目編譯后才加入設(shè)計中，此時這類的結(jié)構(gòu)已不存在。  Identify RTL Debugger確實提供了斷點觸發(fā)，斷點可緊鄰置于分支敘述旁，而且可在一個除錯週期中動態(tài)及個別啟動這些斷點。  資源需求在資源受限的設(shè)計中，實現(xiàn)探測點及觸發(fā)點所需的資源是很重要的，在這種情況下，設(shè)計者想知道他們所加的探測資源是否會使設(shè)計變得太大，以致無法實現(xiàn)于元件中。  網(wǎng)目除錯器的探測點是八進(jìn)制累加，因為那就是探測核心所用的大小，跨過八進(jìn)制的邊界需要對整個八位元核心作加法。資源需求是加到觸發(fā)口（trigger port）上比對單位數(shù)以及比對型態(tài)復(fù)雜度的函數(shù)。  當(dāng)使用網(wǎng)目工具時，除非經(jīng)人為計算，無法得知有那些資源真正用來探測設(shè)計，因為FPGA編譯軟件不提供此資訊。雖然可經(jīng)由使用者手冊中的規(guī)格表計算出來，但僅能用于表格中使用的最簡單配置。  使用Identify RTL Debubber時，資源是以單一位元為基準(zhǔn)加上去的，所以只有所需的資源才會用到，使用到的資源會動態(tài)地顯示并且