microblaze之Video Processing Subsystem調(diào)試誤區(qū)

內(nèi)容：總結(jié)video processing subsystem調(diào)試中遇到的問題，以及在解決問題中的思路方法論，引為前車之鑒。

1，我的目的是希望采用vps中的scaler模塊對圖像進行拉伸縮小。IP的配置如下：

2，整個系統(tǒng)的框架圖如下，僅比上期的內(nèi)容增加了scaler模塊，如下：

3，查手冊，可以知道這個scaler only組件分成了hscale,vscale和GPIO，其中GPIO是控制上下游stream流控設(shè)備復(fù)位用，暫時忽略。hscale和vscale的寄存器空間如下，主要關(guān)注圖像的大小，以及縮放比率：

4，vivado中的工程綜合完畢之后，進入SDK之中，可以看到xv_hscale.h和xv_vscale.h，文件內(nèi)部包含了控制這個scale模塊的函數(shù)。雖然使用的是scaler only模式，但是系統(tǒng)自動生成了所有的IP文件，例如deinterlace,csc等，因為這里指需要使用scale，因此直接操控xv_hscale和xv_vscale或許更簡單。

5，在SDK內(nèi)部編寫控制代碼，下載之后輸出沒有圖像，添加打印之后發(fā)現(xiàn)hscale初始化失敗，而vscale初始化成功，對比了hscale和vscale的驅(qū)動代碼后，發(fā)現(xiàn)是完全一致的，于是沒有明白原因何在，如下：

6，在SDK中采用debug單步調(diào)試，于是發(fā)現(xiàn)了問題所在，原來hscale傳遞的基地址參數(shù)為0x00，這是一個非法的地址。但是想一想就知道這是系統(tǒng)自動生成的驅(qū)動文件，不應(yīng)該出現(xiàn)這種低級的錯誤才對。于是去查看系統(tǒng)設(shè)備描述文件xparameters.h，發(fā)現(xiàn)hscale的地址確實是0x000000,vscale的地址是0x20000，而vps的基地是0x44A40000。

7，后面懷疑過自己的工程創(chuàng)建是否有誤，以及創(chuàng)建IP過程中可否允許編輯起始地址，但結(jié)果根本無法編輯，工程也確認無誤。后來想到應(yīng)該是hscale和vscale的基地址僅僅是整個IP的偏移地址而已，在初始化的時候應(yīng)該加上IP的首地址，于是做如下更改，并設(shè)置好圖像的寬高，但是line rate和pixel rate卻不知道填寫多少，寫一個45和74吧，因為我的圖像是720P60，水平同比是45Khz,像素時鐘是74.25，結(jié)果當(dāng)然還是沒有圖像輸出，原因是這個兩個值是錯誤的。同時把寄存器讀出來之后可以知道所有的數(shù)據(jù)是配置了的，那么原因就是某些數(shù)據(jù)是錯誤的。

8，想到上次調(diào)試TPG模塊的時候，圖像的寬度需要除以2，進而也嘗試之后仍然不對。于是去xilinx論壇社區(qū)找一下有無相同的問題。搜索vpss scaler后瀏覽，發(fā)現(xiàn)有人在gitup里面上傳有scale的代碼，于是點擊后大致瀏覽一遍，發(fā)現(xiàn)了line rate和pixel rate 的計算公式：

9,有這個發(fā)現(xiàn)之后，因為我的輸入和輸出的寬度和高度是一樣的，因此line rate 和pixel rate應(yīng)該設(shè)置為65536。現(xiàn)在終于知道了這兩個參數(shù)指的意思分別是縱向和橫向的縮放比率。

10，原本以為可以出圖了，實際上還是沒有出圖，讓人沒想到的是程序只要執(zhí)行scaler_set_HwReg的任何函數(shù)，程序立馬就跑飛了。然后重新燒錄bit文件，重新運行elf文件，還是一樣的結(jié)果。這個時候我把Block design中的debug信號全部去掉，同時把AXI系統(tǒng)時鐘由150M改為100M，最終的結(jié)果還是會跑飛。這時候我想軟件上面沒有改動的余地了，于是想知道VPS這個IP的AXI總線是處于什么狀態(tài)，當(dāng)我執(zhí)行這些函數(shù)的時候。于是僅把AXI總線信號加入debug模塊，觸發(fā)運行后得到如下的結(jié)果，情況是VPS沒有應(yīng)答，因此CPU直接掛掉了。

11，這個時候差點快絕望了，于是放棄直接控制h_scale和v_scale的方式，改用控制最上層的vps，誰知道xilinx需要做什么騷操作。首先看一下xvprocss.h文件信息，里面定義各種操作的函數(shù)，初始化函數(shù)中依據(jù)所定義的子IP，SetSubsystemConfig函數(shù)有選擇性的進行配置。

12，然后仔細的看了一遍函數(shù)中的數(shù)據(jù)結(jié)構(gòu)定義，于是重新編寫了控制程序，這時候想應(yīng)該有圖輸出了吧，然而還是沒有圖輸出。并且把里面的寄存器讀出來之后，發(fā)現(xiàn)除了最開始0x00寄存器空間之外，其他數(shù)據(jù)全部是0，確實很意外。

13，到了這個時候，確實沒有招了，于是來回的改來改去，無意中多注釋了兩行代碼，結(jié)果出圖了，同時監(jiān)控AXI總線上的數(shù)據(jù)，也有應(yīng)答了。原來是我在配置完成之后，又把這個IP軟復(fù)位了。因此其余的數(shù)據(jù)全部變成了0。印證了陸游的那句話，山窮水復(fù)疑無路，柳暗花明又一村。

總結(jié)：

1，通過調(diào)試這個IP，對于軟件編程有了更進一步的了解；

2，其實直接控制h_scale和v_scale應(yīng)該可以達到同樣的功能，只不過這個IP需要有特殊的配置順序，以及各種復(fù)位邏輯，任何的差池都會導(dǎo)致沒有圖像輸出；

3，目前還沒有深入了解這個IP的控制流程，還需要深入底層去看實現(xiàn)的細節(jié)部分，比如實現(xiàn)deinterlace等其他功能。

審核編輯：湯梓紅