賽靈思的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，不管軟件的版本如何，永遠都是這個。

賽靈思 FPGA 的狀態字，在賽靈思所有器件系列中都基本保持一致的定義（個別位由于系列特性不同可能有細微區別，這些不是最重要的，不在我們今天討論的范圍內）。

以UltraScale/UltraScale+系列為例，我們看看UG570（官網查詢UG570）上對狀態字的完整定義：

表格里面已經很清楚地解釋了每一個bit位代表的意義。下面學習如何讀出狀態字并從其具體值中判斷失敗原因。

我們先來讀一下一片未作配置的FPGA的狀態字看看。首先，用下載線連接好板子和電腦，板子上好電。打開Vivado硬件管理器，掃描板子上的JTAG鏈 （Open target -Auto Connect）, 板子上的JTAG鏈中的器件會顯示在Hardware窗口中：

鼠標選中掃描出的FPGA器件，在下方的Hardware Device Properties窗口中，選擇Properties項，會出現該FPGA的一系列屬性。找到其中的REGISTER分類，展開，第二個寄存器CONFIG_STATUS, 即是我們要討論的狀態字了。

注意FPGA此時的狀態是Not Programmed, 那么對應的狀態字展開如下：

這里可以看到的是一個配置前的狀態字的標準狀態：

只有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鏈構成，讀出當前的狀體字（如何還能夠讀的話），在論壇上發貼問問賽靈思的專家吧：

如果狀態字正常，可以接下來進行配置操作。或者是在你的配置失敗后，保留失敗現場再連接好板子和電腦繼續讀出狀態字。

如果你的板子已經重新上下電了，那么當時失敗的場景也就消失了。這也就是我們一再強調失敗后要保留現場，板子上要保留JTAG接口的原因。當然在設計成熟后，或者實驗室調試工作結束后，可以去掉JTAG接口以期得到產品更高的安全性。

配置完成后，得到的狀態字如下：

REGISTER.CONFIG_STATUS00010010100100000111110111111100

注意其中的：

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最終的啟動失敗。

賽靈思的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文件，硬件設計原理圖和工具版本信息，以及通過其他一些配置接口在不同條件下去對比測試才能逐步定位。

???審核編輯：湯梓紅