Xilinx的FPGA有多種配置接口,如SPI,BPI,SeletMAP,Serial,JTAG等;如果從時鐘發送者的角度分,還可以分為主動Master(即由FPGA自己發送配置時鐘信號CCLK)和被動Slave(即由外部器件提供配置所需要的時鐘信號);另外還可由板上穩定晶振提供時鐘信號,經由FPGA的EMCCLK接口,再從CCLK端口送出。
如此多的配置形式,一旦發生配置失敗怎么辦?大家都知道先要查看一下板子上FPGA的DONE管腳。但絕大多數情況下,DONE管腳此時會是低電平,只能證明配置確實失敗了。但是失敗的原因到底是什么呢?調試到底應該如何入手呢?
答案是:
第一步要做的,永遠都是拉出FPGA的狀態字寄存器Status Register看,它能直接告訴你或者極大地輔助判斷失敗的原因!不管FPGA的型號是哪個,不管用的下載工具是Vivado HW Manager還是ISE的iMPACT,不管軟件的版本如何,永遠都是這個。
Xilinx FPGA的狀態字,在賽靈思所有器件系列中都基本保持一致的定義(個別位由于系列特性不同可能有細微區別,這些不是最重要的,不在我們今天討論的范圍內)。
以UltraScale/UltraScale+系列為例,我們看看UG570上對狀態字的完整定義:
表格里面已經很清楚地解釋了每一個bit位代表的意義。下面學習如何讀出狀態字并從其具體值中判斷失敗原因。
我們先來讀一下一片未作配置的FPGA的狀態字看看。首先,用下載線連接好板子和電腦,板子上好電。打開Vivado硬件管理器,掃描板子上的JTAG鏈 (Open target -Auto Connect), 板子上的JTAG鏈中的器件會顯示在Hardware窗口中:
鼠標選中掃描出的FPGA器件,在下方的Hardware Device Properties窗口中,選擇Properties項,會出現該FPGA的一系列屬性。找到其中的REGISTER分類,展開,第二個寄存器CONFIG_STATUS, 即是我們要討論的狀態字了。
這里可以看到的是一個配置前的狀態字的標準狀態:
只有BIT02 PLL_LOCK, BIT03 DCI_MATCH, BIT11 INIT_B_INTERNAL, BIT12 INIT_B_PIN的值必須是1;
BIT08-10 MODE PINS,BIT21 SECURITY_STATUS, BIT25-26 BUS_WIDTH,BIT28 PUDC_B根據FPGA和板子具體的設定,可以為1或者0,其他都必須是0。
如果一上電,狀態字就表現出了非典型值,那么大概率硬件上就有錯誤或者不合理的地方了。比較典型的幾個例子:
1. 狀態字全0
REGISTER.CONFIG_STATUS 00000000000000000000000000000000
這種情況,說明FPGA被強行控制在全局復位狀態了。一般是硬件上PROGRAM_B管腳,或者INIT_B管腳被錯誤的拉到了地上,兩個管腳上的有效電平為0.
非常偶爾的情況下,當DONE管腳被錯誤拉為0電平時也能出現此種狀態字。
2. 狀態字全1,或者一串1后面跟著一個到數個0(一般不超過4個)
REGISTER.CONFIG_STATUS 11111111111111111111111111111111
REGISTER.CONFIG_STATUS 11111111111111111111111111111110
REGISTER.CONFIG_STATUS 11111111111111111111111111111100
這種一般是板子上設計的JTAG鏈里面不只一個FPGA器件,比如是Xilinx的FPGA和一個第三方的CPLD串聯等。
由于Vivado里面并沒有第三方器件的BSDL文件,那么在掃描整個JTAG鏈時,它無法識別鏈中各器件的型號以及數目,所以往往從TDO管腳中移位出一串1來。如果Xilinx的FPGA位于鏈的末端(接近TDO的位置),那么有時可以識別出正確的FPGA型號。但是這種情況仍然無法正確進行將要進行的配置操作。另外很多例子中則是FPGA的型號也被識別錯誤了。
解決方案如下:
https://www.xilinx.com/support/answers/61312.html
3. Unknown Device/Many Unknow Devices
此時,不要說狀態字無法檢測了,整個JTAG已經無法正確掃描,Vivado里面無法識別出任何器件。這一般是板子上的JTAG接口的TDO或者鏈中最后一個器件的輸出管腳TDO,被短接到了地平面上。
除了上述典型情況,當然還有很多一上電就無法繼續配置的情況,原因不勝枚舉。這種情況下請詳細描述你的JTAG鏈構成,讀出當前的狀體字(如何還能夠讀的話),在論壇上發貼問問Xilinx的專家吧:
https://forums.xilinx.com/t5/%E8%B5%9B%E7%81%B5%E6%80%9D%E4%B8%AD%E6%96%...
如果狀態字正常,可以接下來進行配置操作。或者是在你的配置失敗后,保留失敗現場再連接好板子和電腦繼續讀出狀態字。
如果你的板子已經重新上下電了,那么當時失敗的場景也就消失了。這也就是我們一再強調失敗后要保留現場,板子上要保留JTAG接口的原因。當然在設計成熟后,或者實驗室調試工作結束后,可以去掉JTAG接口以期得到產品更高的安全性。
配置完成后,得到的狀態字如下:
REGISTER.CONFIG_STATUS 00010010100100000111110111111100
注意其中的:
BIT02 PLL_LOCK, BIT03 DCI_MATCH, 絕大多數情況已經變為1;
BIT04 EOS,BIT05 GTS, BIT06 GWE, BIT07 GHITH,以及BIT11 INIT_BINTERNAL, BIT12 INIT_B_PIN,BIT13 DONE_INTERNAL, BIT14 DONE_PIN必然是1;
BIT18-20 STARTUP_STATTE應該是100;
BIT25-26 BUS_WIDTH應該是檢測出了正確的配置位寬,或者在serial的情況下,保持默認的01值;
其他BIT01 DECRYPTOR, BIT09-10 MODE_PINS, BIT21-23 SECURITY_STATUS, BIT28 PUDC_B, BIT30CFGBVS_PIN, 根據你的使用,有可能是其他的0或者1組合。
RESERVED的不用管。
如果不是這種結果,那么就要看看出什么問題了。
在一些相對簡單,典型的情況下,只看某一位就可以直接得到想要的答案。
1) BIT00, CRC error為1
在不是狀態字全1的情況下CRC error位為1,說明配置出現了CRC錯誤。這是一種很常見,但比較難修復的錯誤,因為CRC錯誤的原因一般是因為板子上的信號質量(SI, Signal Integrity)不行,傳輸數據的過程中0/1電平判決錯誤,導致配置數據寫入失敗。
如何確定真的是SI問題呢?看失敗概率。CRC錯誤一般是隨機出錯的,并不一定100%失敗(除非板子的信號差得沒法用了,這個一般不會)。那么配置文件中01翻轉的次數越少,出錯的概率越小。你可以生成一個只點亮板上一盞LED的小測試設計,此時bit文件中有效數據(1)非常少,試著下載該bit看看,是不是配置失敗率降低了?如果是,那么基本可以確定了。
一旦出現這種情況,可以嘗試的辦法有:
1. 降低CCLK頻率
2. 在CCLK的輸入端(以及輸出端),加入合適的端接電路
3. 換用更高質量的配置時鐘(比如使用質量較好的晶振通過EMCCLK提供時鐘)
4. 改善數據鏈路的信號質量,如果對待CCLK,同樣在數據通路上加入合適的端接匹配電路。
總而言之,要做的就是改善板上的信號質量。如果板子SI實在太差,那只有改板,或者嘗試下其他配置方式了。
2) 其他位都正常,BIT13 DONE_INTERNAL也為1了,但是BIT14 DONE_PIN為0,FPGA不工作!
這種情況,其實配置數據已經完整、正確的送入FPGA并且被接收了,但是FPGA的DONE管腳連接不正確,導致DONE沒有或者沒有在規定時間內上拉到要求的電平,從而導致FPGA最終的啟動失敗。
Xilinx的FPGA,一般要求DONE管腳上外加一個上拉電阻(330 ohm, 4.7K ohm等,不同系列要求不同,請參照對應的Configuration User Guide)。如果這個上拉電阻沒有加,或者加的阻值過大或過小,那么DONE管腳無法在規定的時間里面達到高電平,此時內部配置控制器會認為配置失敗了,典型情況就是DONE internal為高(內部數據接收完畢,內部釋放了),但是DONE外部管腳為低。
此時需要做的,就是檢查PCB上DONE部分的設計,看看是不是有和其他管腳相連的情況,被其他管腳強行拉低了。或者是設計的DONE點亮LED燈電路不合理, LED通電后把DONE管腳的電平降為低電平。
如果你不清楚如何設計這部分電路,從 www.xilinx.com 上,找到一款和你使用的FPGA型號相同或者同系列的開發板,參考它的原理圖設計。
3) BIT29 BAD PACKET error
Bit29為1,大概率也是CRC錯誤。這不過這個CRC錯誤比較特殊,出錯位跑到了配置文件里面的命令上,導致配置命令變成了一個無效無意義的指令。此時狀態字會報出bad packet error。
和CRC錯誤的隨機性一樣,多次重復加載過程,大概率出錯的數據位下次落到其他的數據上。由于配置數據的數量遠遠大于配置命令,那么很有可能下次出錯看到的是BIT00 CRC ERROR為1.
如果每次都是BAD PACKET error,更要懷疑使用的配置文件已經損壞。比如進行了非法改寫。Xilinx的任何配置文件,都是禁止手工修改的。
4) BIT15 IDCODE Error為1.
配置文件下載時,都要先經過FPGA的IDCODE校驗。如果這一步通不過,那么后續的配置不會進行。這種情況下,看看配置文件的bit/bin/mcs是不是給錯了。或者FPGA器件有silicon revision的變化。舉個例子,有的系列ES芯片和Production芯片的配置文件是不能兼容的。這種錯誤情況,如果是用JTAG通過Vivado下載,那么log里面也會有相應的提示。
5) BIT13 DONE_INTERNAL+ BIT14 DONE_PIN均為0
這也是一種較常見的錯誤。此時要重點檢查一下BIT07 GHIGH位,看看它是不是1。如果是,那么大概率是,你的CCLK時鐘給的不夠多。FPGA在接收完所有的配置數據后,還需要一定數量的CCLK時鐘去完成內部的初始化。如果發送端,此時常常是一個CPU用Slave模式加載,認為有效數據結束,強行停止了進一步的時鐘發送,那么有時可以觀測到此種狀況。此時去檢查BIT18-20 STARTUP_STATE,根據具體的情況,也有一定概率看到不是預期的100.
標準的做法是,在默認設置下持續發送CCLK時鐘,直至檢測到DONE管腳已經拉高,然后再多發送至少64個時鐘信號。如果修改了配置默認設置,比如選擇了wait for PLL to lock,那么需要更多的時鐘信號。
6) 狀態字看起來和沒有發出配置數據,即和剛上電的表現一樣。
這種情況,說明所有發出的配置數據都被FPGA忽略掉了,因為它不認為你發送過來的是有效配置數據。
FPGA的配置文件里面,有一個數據同步頭,一般是AA 99 55 66。如果由于某種原因,這個同步頭FPGA都沒有認出來,那么后續的數據會被它全部忽略。
一般的原因是:
1. 在非serial配置模式中,沒有正確的做Byte Swap;
2. 配置文件生成時,BPI數據線寬設置不對(x8, x16, x32選錯了)
3. SPI的x1, x2, x4選擇錯誤;
4. 嚴重的板級SI問題導致的CRC錯誤;
以上列舉了常見的一些配置錯誤和其狀態字的相應表現。需要注意的是,狀態字寄存器有32位,其組合可以說是相當多的。除了上述情況,配置失敗定位還可能需要結合狀態字,加載過程中log文件,硬件設計原理圖和工具版本信息,以及通過其他一些配置接口在不同條件下去對比測試才能逐步定位。
編輯:hfy
-
FPGA
+關注
關注
1629文章
21729瀏覽量
603041 -
寄存器
+關注
關注
31文章
5336瀏覽量
120249 -
Xilinx
+關注
關注
71文章
2167瀏覽量
121318 -
時鐘信號
+關注
關注
4文章
448瀏覽量
28542
發布評論請先 登錄
相關推薦
評論