摘 要： 現場可編程邏輯門陣列（FPGA）應用于圖像處理時，需要對數據中的圖像信息進行準確的提取。設計中，FPGA中解壓縮功能需要對壓縮數據中的圖像信息進行提取。根據壓縮格式，設計了一種基于狀態機的圖像信息提取模塊，并且在XST（Xilinx官方綜合工具）以及Synplify pro兩個綜合環境下進行了仿真驗證。通過對比仿真結果的差異，嘗試分析設計的寄存器傳輸級視圖（RTL視圖），并找出了影響狀態機工作的關鍵要素。強調了代碼風格對FPGA設計的重要性。
?

0 引言

　　狀態機是數字系統設計中的重要組成部分，是FPGA實現高效率高可靠性邏輯控制的重要途徑。在實際工程應用中，狀態機工作是否正常決定著系統能否穩定工作。本文設計了一個基于狀態機的圖像信息提取模塊，通過對該設計的仿真，分析了狀態機設計中的狀態競爭、鎖存器的引入以及綜合工具誤判等常見情況。強調了代碼規范對于FPGA設計的重要性。

1 設計背景及思路

　　基于相機的實時圖像目標仿真系統可以產生實時的虛擬目標圖像流，因而被用于光電經緯儀等圖像跟蹤系統的開發調試。目標仿真系統中虛擬目標是經過DSP以一定的壓縮格式壓縮后儲存于DDR中的，FPGA通過SRIO與DSP通信，讀取壓縮后的目標圖形數據，經過FPGA內部解壓縮與現實背景疊加輸出。該系統中使用灰度圖像作為圖像源。其簡化結構圖如圖1所示。

目標圖像示意圖如圖2所示，虛擬目標圖形以水平方向的線段形式壓縮，整個壓縮后的目標圖形由n條線段組成，每條線段包含該線段的起始行列號、像素點數以及各像素點的像素值。其中每一幀的第一條線段還包含這幀圖像壓縮后的大小，壓縮大小為32 bit。行列號、像素數以及各像素點的像素值均以16 bit表示。

FPGA對虛擬目標圖像進行復原時，最主要的是對壓縮數據中的目標圖形的各類信息進行提取，行列號代表著目標圖形的位置信息，壓縮大小以及像素數表示目標圖形的大小信息，像素值則代表各點的灰度信息。本文以有限狀態機為基礎設計了基于狀態機的壓縮圖像信息提取模塊。

首先需要確定狀態機的狀態數。壓縮圖像信息提取模塊的目的在于將壓縮圖像的信息進行分別提取，因此根據壓縮的數據格式須將數據分為5塊進行提取，分別為一幀壓縮圖像大小（frame_size，32 bit）、每條線段的起始行號（row_no，16 bit）、起始列號（column_no，16 bit）、每條線段的像素數（row_size，16 bit）以及分別的像素值（pic_element，16 bit）。考慮到16 bit的位寬，須將一幀壓縮圖像大小（frame_size）進行兩次提取，由于空閑狀態的存在，共設置7個狀態，分別為：wait_state（S0）、frame_s_state1（S1）、frame_s_state2（S2）、row_no_state（S3）、column_no_state（S4）、row_s_state（S5）、pic_element_state（S6）。

需要注意的是壓縮數據中frame_size只存在于第一條線段，因此frame_size的提取在一幀數據中只進行一次。根據數據大小以及每行像素數，可以設置相應的狀態轉移條件，相應的信號如表1所示。

壓縮數據在幀聲明信號到來之后開始傳輸，當幀聲明信號到來時，狀態機進入等待狀態（S0），隨后便開始依次提取第一條線段中的信息，包括幀大小的前16 bit，幀大小的后16位，行號、列號、像素數（即依次進入S1、S2、S3、S4、S5狀態），接著將r_done信號拉高，并且開始提取像素值數據（即進入S6狀態）直至下一線段到來，第二條線段到來時r_done信號拉低，提取第二條線段的行號（即從S6跳轉到S3狀態），其余步驟與第一條線段相同，直至一幀信號傳輸完成（即f_done拉高），狀態機跳轉置等待狀態（S0）。根據上述分析，狀態轉移圖如圖3所示。

2 綜合仿真

　　總結前面的分析，可以使用VHDL硬件描述語言對狀態機進行描述。在VHDL設計中分3個進程來設計狀態機：（1）主控時鐘進程，負責下一狀態與當前狀態的切換，以及相應狀態條件的邏輯部分；（2）狀態轉移組合邏輯進程，根據當前狀態及狀態條件進行狀態轉移判斷并輸出下一狀態；（3）同步時序狀態輸出，用同步時序邏輯寄存狀態輸出，避免組合邏輯的毛刺與不穩定[1]。

首先在Modelsim中對設計的代碼進行了功能邏輯仿真。仿真結果與預期結果一致。仿真結果如圖4所示。

隨后對設計在XST和Synplify pro兩個綜合環境下進行了編譯下載，并使用ChipScope進行了板級仿真。使用的FPGA是Xilinx生產的Virtex5系列FPGA，型號為XC5VLX110T。圖5是XST綜合后的結果，圖6是Synplify pro綜合的結果。

同一個設計在不同綜合環境下出現了差異，XST綜合后的時序波形與預期不符，出現了錯誤，而Synplify pro綜合后的波形則滿足了設計要求。這說明所設計代碼存在著問題。下面將嘗試著分析這些問題。

3 錯誤分析

　　通過對代碼的分析，發現代碼存在很明顯的狀態競爭，以下面的代碼為例：
　　when S0=>
　　if r_done=′0′ and f_done=′0′ then
　　Next_S<=S1；
　　end if；

上面的代碼中if條件語句不完備，導致在!（r_done=‘0’and f_done=‘0’）時無法判斷下一狀態，可能導致綜合工具產生誤判，并且可能引入鎖存器（Latch）來鎖存下一狀態[2]。而事實上，XST和Synplify pro的確都在設計中引入了鎖存器來保證狀態的正常切換和保持。這一點從綜合報告中可以看得出來。

在兩者都生成鎖存器的情況下，認為兩個綜合工具結果的差異，很有可能是因為綜合工具的誤判。為了證實這一結論，本文嘗試著分析了XST和Synplify pro的綜合RTL視圖（寄存器傳輸級）[3-4]，找出了兩者出現明顯差異的RTL視圖部分，如圖7、圖8所示。

圖7、圖8分別是XST和Synplify pro對下面這段代碼的綜合。
　　when S6=>
　　if r_done=′0′ and f_done=′0′ then
　　Next_S <=S3；
　　elsif r_done=′0′ and f_done=′1′ then
　　Next_S<=S0；
　　end if；

可以發現前者的判斷邏輯為：!r_done&!f_done 為真時，狀態S6跳轉到S3；為假時，狀態S6跳轉到S0。也就是說，在r_done=‘1’時狀態沒有保持S6，而是跳轉到S0，導致結果錯誤。而后者的判斷邏輯為：!r_done&!f_done為真時，狀態S6跳轉到S3，否則保持S6；f_done=‘1’時，狀態S6跳轉到S0，否則保持S6。這個組合邏輯保證了在正常情況下，狀態機運轉正常，因而得到了所希望的狀態輸出。

根據上面的分析，找出了兩個潛在的問題，鎖存器的引入以及綜合工具的誤判。顯然真正導致結果差異的是綜合工具對組合邏輯的誤判。但是在同步設計中鎖存器也常是一個潛在的問題。鎖存器不同于寄存器，鎖存器沒有時鐘驅動，對毛刺敏感，上電后處于不確定狀態。它會導致同步設計的時序分析復雜化，甚至出現時序以及穩定性上的問題，通常這些問題都是不可復現的。另外FPGA的基本單元是由查找表和觸發器組成的，生成鎖存器反而需要更多的資源[5]。因此在同步設計中最好不要使用鎖存器[6]。

4 完善設計

　　根據先前的仿真與分析，對代碼中的狀態轉移條件判斷進行了改進和完備。解決的方式很簡單，就是完備if條件判斷語句，不至于讓綜合工具去猜測缺省的部分，從而避免綜合工具的誤判，同時也避免了鎖存器的引入。例如：
　　when S0=>
　　if r_done=′0′ and f_done=′0′ then
　　Next_S<=S1；
　　else
　　Next_S<=S0；
　　end if；

將修改后的代碼再次綜合，分別查看RTL視圖，發現XST和Synplify pro的RTL視圖中分別生成了XST和Synplify pro中表示有限狀態機的標準模塊[3-4]，說明本文設計的狀態機是符合兩者要求的。對完善后的設計進行了板級仿真，仿真結果與預期一致。

對比了修改前后Synplify pro綜合結果的時鐘性能和資源使用的情況，如表2所示。

5 結論

　　本文提出了一種基于狀態機的圖像信息提取模塊的設計，并進行了仿真分析。從上面的仿真分析可以看出代碼的設計風格對于綜合結果的影響，綜合器作為設計工具，它的綜合優化結果是依賴于代碼的。同一個邏輯，不同的代碼在綜合工具中可能產生不同的綜合結果，有的如同上面分析的Synplify pro，結果一致，但是性能差距很大；或者有些在結果上都不一致，如同上面分析XST一樣。因此對于一個FPGA設計，初始設計思路是實現設計的關鍵，同樣實現設計的代碼語言風格也對設計的結果有著重要的影響[7]。