應用EDA仿真技術解決FPGA設計開發(fā)中故障的方法

　　本文針對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ā)在上板調試過程中，有時候出現(xiàn)的bug是很極端的情況或很少出現(xiàn)的情況，而現(xiàn)在通常的做法是：在故障出現(xiàn)的時候通過SignalTap 把信號抓出來查找其問題的所在、修改程序；在改完版本后，先要對整個工程進行重新編譯，然后再上板跑版本進行驗證，看看故障是否解決。

　　這樣就會出現(xiàn)三個問題：

　?、儆袝r候故障很難定位，只知道哪個模塊出錯，很難定位到具體的信號上，給抓信號帶來麻煩。如果故障定位不準確，漏抓了關鍵信號，則需要重新在 SignalTap里添加信號、編譯版本并再次上板定位故障，浪費時間。

　　②故障定位后，修改代碼還需要再編譯一次產生新版本的下載文件，修改后若還有問題則要重復這一過程，這樣從故障定位到修改完成需要很多次編譯。

　?、凵习逯匦逻M行驗證時，如果這個bug的出現(xiàn)的幾率很小，短時間內不再復現(xiàn)，并不能說明在極端情況下的故障真的被解決了。

　　舉例說明：

　　例如在一個基帶系統(tǒng)的FPGA邏輯版本中，輸出模塊調用了一個異步FIFO，某一時刻FIFO已空的情況下多讀了一個數(shù)據(jù)，產生了bug，如圖1所示。

　　圖1 SignalTap抓出的bug出現(xiàn)時的數(shù)據(jù)

　　該輸出模塊的功能是判斷FIFO中是否有大于4個數(shù)據(jù)可讀出，若大于則連續(xù)輸出4個數(shù)據(jù)作為一組。系統(tǒng)中采用異步FIFO的內部讀數(shù)據(jù)指針來做判斷，而異步FIFO讀寫數(shù)據(jù)需要跨時鐘域，需要至少2個時鐘周期的握手時間，導致數(shù)據(jù)指針不準確。在判斷的時鐘沿，雖然顯示有超過4個的數(shù)據(jù)可讀，但是因為握手時間的延遲實際上FIFO中可能只有3個數(shù)據(jù)。

　　圖1中rdreq為FIFO的讀使能信號，在4個時鐘周期內有效，但是只讀出了3個數(shù)（數(shù)據(jù)0D2086C9F被讀了兩次），因為FIFO在第 4個時鐘周期已經(jīng)讀空。這里應該改成同步FIFO，由于同步FIFO數(shù)據(jù)的讀寫只在一個時鐘域內進行，就沒有這個握手時間延遲的問題了。

　　定位這個故障的時候我們可以很容易知道是哪個模塊出了問題，但是具體是其內部的哪個信號還需要下些功夫，如果出錯信號隱藏的很深，很難一次就抓到需要的信號；而且即使我們抓到了正確的信號，如果故障在改完之后沒有解決，則還需要重新修改、再進行編譯，耗費時間；即使改過之后故障不再復現(xiàn)，也有可能是因為bug出現(xiàn)的條件苛刻，無法證明故障真的解決了。