本文針對FPGA實際開發(fā)過程中，出現(xiàn)故障后定位困難,、反復修改代碼編譯時間過長,、上板后故障解決無法確認的問題，提出了一種采用仿真的方法來定位,、解決故障并驗證故障解決方案,。可以大大的節(jié)約開發(fā)時間,，提高開發(fā)效率,。
FPGA近年來在越來越多的領域中應用，很多大通信系統(tǒng)（如通信基站等）都用其做核心數(shù)據(jù)的處理,。但是過長的編譯時間,，在研發(fā)過程中使得解決故障的環(huán)節(jié)非常令人頭痛。本文介紹的就是一種用仿真方法解決故障從而減少研發(fā)過程中的編譯次數(shù)，最終達到準確定位故障,、縮短解決故障時間的目的,。文例所用到的軟件開發(fā)平臺為Altera公司的Quartus II，仿真工具為ModelSim,。
問題的提出
系統(tǒng)開發(fā)在上板調(diào)試過程中,，有時候出現(xiàn)的bug是很極端的情況或很少出現(xiàn)的情況，而現(xiàn)在通常的做法是：在故障出現(xiàn)的時候通過SignalTap把信號抓出來查找其問題的所在,、修改程序,；在改完版本后，先要對整個工程進行重新編譯,，然后再上板跑版本進行驗證,，看看故障是否解決。
這樣就會出現(xiàn)三個問題：
?、儆袝r候故障很難定位,，只知道哪個模塊出錯，很難定位到具體的信號上,，給抓信號帶來麻煩,。如果故障定位不準確，漏抓了關(guān)鍵信號,，則需要重新在SignalTap里添加信號,、編譯版本并再次上板定位故障，浪費時間,。
?、诠收隙ㄎ缓螅薷拇a還需要再編譯一次產(chǎn)生新版本的下載文件,，修改后若還有問題則要重復這一過程,，這樣從故障定位到修改完成需要很多次編譯。
?、凵习逯匦逻M行驗證時，如果這個bug的出現(xiàn)的幾率很小,，短時間內(nèi)不再復現(xiàn),，并不能說明在極端情況下的故障真的被解決了。
舉例說明：
圖1 SignalTap抓出的bug出現(xiàn)時的數(shù)據(jù)
圖2 SignalTap抓信號界面
例如在一個基帶系統(tǒng)的FPGA邏輯版本中,，輸出模塊調(diào)用了一個異步FIFO,，某一時刻FIFO已空的情況下多讀了一個數(shù)據(jù)，產(chǎn)生了bug,，如圖1所示,。
該輸出模塊的功能是判斷FIFO中是否有大于4個數(shù)據(jù)可讀出，若大于則連續(xù)輸出4個數(shù)據(jù)作為一組。系統(tǒng)中采用異步FIFO的內(nèi)部讀數(shù)據(jù)指針來做判斷,，而異步FIFO讀寫數(shù)據(jù)需要跨時鐘域,，需要至少2個時鐘周期的握手時間，導致數(shù)據(jù)指針不準確,。在判斷的時鐘沿,，雖然顯示有超過4個的數(shù)據(jù)可讀，但是因為握手時間的延遲實際上FIFO中可能只有3個數(shù)據(jù),。
圖1中rdreq為FIFO的讀使能信號,，在4個時鐘周期內(nèi)有效，但是只讀出了3個數(shù)（數(shù)據(jù)0D2086C9F被讀了兩次）,，因為FIFO在第4個時鐘周期已經(jīng)讀空,。這里應該改成同步FIFO，由于同步FIFO數(shù)據(jù)的讀寫只在一個時鐘域內(nèi)進行,，就沒有這個握手時間延遲的問題了,。
定位這個故障的時候我們可以很容易知道是哪個模塊出了問題，但是具體是其內(nèi)部的哪個信號還需要下些功夫,，如果出錯信號隱藏的很深,，很難一次就抓到需要的信號；而且即使我們抓到了正確的信號,，如果故障在改完之后沒有解決,，則還需要重新修改、再進行編譯,，耗費時間,；即使改過之后故障不再復現(xiàn)，也有可能是因為bug出現(xiàn)的條件苛刻,，無法證明故障真的解決了,。
針對這三個問題，筆者提出如下想法：
雖然定位具體的出錯信號很困難,，但是定位是哪個模塊出錯很容易,，在bug出現(xiàn)的時候我們可以抓出這個模塊的全部輸入信號，考慮是否可以利用這些信號在仿真環(huán)境下重建bug出現(xiàn)的條件,，利用仿真環(huán)境具體定位錯誤信號的位置,。
定位好錯誤信號的具體位置后，修改代碼,，再用相同的條件進行仿真,。這樣可以通過對修改前后輸出數(shù)據(jù)的對比，很直觀的驗證修改是否成功,，從而在修改成功后只需編譯一次即可,，節(jié)省時間,。
上板后bug不復現(xiàn)也可以排除是由于極端情況很難滿足造成的，去除了后顧之憂,，徹底解決了故障,。
仿真解決故障的方法
通過對這個異步FIFO問題的解決，可以證明這種通過所抓信號建立bug存在條件,，定位,、清除bug的方法是可行的。步驟如下：
圖3 SignalTap II List File界面
?、賹ug出現(xiàn)時SignalTap抓的信號保存成文檔文件
Quartus II 平臺用SignalTap抓到信號的界面如圖2所示,。
在信號名稱上單擊右鍵，選擇圖2所示Create SignalTap II List File選項,，生成如圖3格式界面,。
圖3中界面上半部分顯示的是list對信號個數(shù)及信號名的描述，下半部分是采樣點所對應的信號值,，帶h的表示是十六進制數(shù)值,。
將list file另存為文本格式文件即可，如圖4所示,。
圖4 “另存為”選項界面
此后可以把這個文本文件中無用的描述刪掉,，只留SignalTap抓出來的數(shù)據(jù)（空格、h等符號也要刪掉）,，另存為.dat文件供仿真使用,。
有了故障出現(xiàn)時的輸入數(shù)據(jù)，我們就可以在仿真環(huán)境下構(gòu)建故障出現(xiàn)的條件,。
?、诶?dat文件建立bug出現(xiàn)的條件
用verilog語言編寫仿真文件（testbench），使用語句$readmemh或$readmemb將.dat文件中的數(shù)據(jù)存儲到一個設定的ram中,，如：$readmemh(“s.dat”,ram),。
注意$readmemh讀取是按照十六進制數(shù)據(jù)進行（認為.dat文件中的數(shù)據(jù)都是十六進制數(shù)），會自動將其轉(zhuǎn)換為4位二進制數(shù)存入ram中,，所以設定的ram位寬要是.dat文件中數(shù)據(jù)位寬的4倍,；使用$readmemb時，存儲SignalTap所抓信號時,，信號都要先設定為binary類型,，ram位寬就是.dat文件數(shù)據(jù)的位寬。ram的深度為.dat文件中數(shù)據(jù)的個數(shù),。
然后在程序里把ram中數(shù)據(jù)按照所對應時鐘沿輸出到一個寄存器變量中，ram地址累加即可,。
always@(posedgeclk)
begin
data<=ram[addr];
addr<=addr+1'b1;
end
復現(xiàn)bug存在條件時,，需將模塊的輸入信號與ram中的數(shù)據(jù)位相對應,，仿真文件調(diào)用模塊時，將寄存器data對應位作為輸入接入即可,。
在仿真環(huán)境中復現(xiàn)bug波形如圖5所示,。
把圖5和圖1進行比較，可見通過這種方法我們在仿真環(huán)境下建立了bug出錯時的環(huán)境,，得到相同的輸出出錯數(shù)據(jù),。
③修改程序后在仿真環(huán)境驗證修改是否成功
修改程序后,，我們只要使用同樣的環(huán)境進行仿真,，并且有針對性的觀察bug是否解決。本例中出現(xiàn)bug的原因是使用了異步FIFO,，改成同步FIFO后,，問題應該就會解決，我們可以通過仿真驗證,。修改程序后仿真的波形如圖6所示,。
由圖6可見，修改后相同的條件FIFO讀出4個數(shù),，說明沒有讀空,，符合要求，bug解決,。圖7為版本編譯后上板使用SignalTap抓取的信號波形,，以作比較。
圖5 modelsim環(huán)境下復現(xiàn)的出錯數(shù)據(jù)
圖6 修改程序后相同條件下的輸出數(shù)據(jù)
圖7 修改程序后SignalTap抓的信號
比較后易見,，波形完全相同,，說明方法可行。
總結(jié)
文中描述的方法可針對各種的故障的解決,。在故障出現(xiàn)時,，只需定位出錯的模塊，這些模塊內(nèi)嵌一些子模塊也無妨,；抓信號時將故障模塊的輸入輸出信號抓出即可,；利用輸入信號重建故障環(huán)境，若仿真輸出信號和所抓輸出信號相同,，說明故障環(huán)境建立正確,；用這個仿真平臺就可以具體定位是哪個子模塊、哪個信號出錯,，而不需要在SignalTap中把這些信號抓出來,；并且在修改代碼后可以驗證是否修改成功，節(jié)省時間,，很明確的證明故障真的被解決了,，事半功倍,。