ZYBO Z7-20 の PS の UART のビットレートを変更する（ベアメタル・アプリケーション）

ZYBO Z7-20 の PS の UART のビットレートは 115200 bps に設定されている。これではスピードが足りないので、もっと高いビットレートを設定することにした。

やり方は、ブロックデザインの ZYNQ Processing System7 をダブルクリックして開く。
PS-PL Configuration をクリックし、General を展開して、UART1 Baud Rate を 921600 に設定した。


論理合成、インプリメンテーション、ビットストリームの生成を行う。
Export Hardware を行って、 xsa ファイルを作成する。
Vitis を立ち上げて、 xsa ファイルでプラットフォームを作り、アプリケーション・プロジェクトを作成した。


ビルド後に、アプリケーション・ソフトウェアを起動すると、 921600 bps で Tera Term に表示することができた。

ZYBOでUbuntu を起動したらネットワークがつながらない

Zynq+Vivado HLS勉強会は 7 回から 8 回に変更になった。最後の回は、任意精度固定小数点データ型とVivado HLS のOpenCV対応を追加した。今日はZYBO でUbuntu 14.04 を立ち上げて、その上で、Vivado HLS で生成したAXI4 Lite Slave インターフェースのIP を使う方法をやる予定だ。
その下準備をしていたところ、ZYBO のボード・ファイルを使用して作成したブロック・デザインで、ネットワークが動作しなかった。いろいろとやってみたが、どうにも動作しない。もしかしてということで、ZYBO Z7-20のネットワークがつながらなかった例を思い出した。

まずは、VIvado 2017.3 で作成した multi_ex2 プロジェクトを示す。


multi_bd ブロック・デザインを開くと、MDIO_ETHERNT_0 が processing_system7_0 にあるのが分かる。これは EMIO にマップされているということだ。


processing_system7_0 をダブルクリックして開き、Page Navigatorで Peripheral I/O Pinsをクリックする。
Ethernet0 を展開すると、MDIO が EMIO にマップされている。


EMIO の脇の MDIO をクリックして選択する。

MDIO がハイライトされて、選択された。


OKボタンをクリックした。
すると、MDIO_ETHERNT_0 が無くなったのが分かる。これは、EMIO から MIO にマップが変更されたからだ。


これでブロック・デザインをセーブして、論理合成、インプリメント、ビットストリームの生成を行った。
ハードウェアをエクスポートして、SDK を立ち上げた。
FSBL を生成して、u-boot.elf を追加しながら、BOOT.bin を作成した。


これで、ZYBO 上でUbuntu 14.04 を起動したときにネットワークがつながるようになった。

ZYBO や ZYBO Z7 のボード・ファイルを早く直してほしいものだ。今のところ、ZYBO/B.3、ZYBO-Z7-10/A.0、ZYBO Z7-20/A.0 のボード・ファイルでは、今回の様に修正する必要があると思う。

”ZYBOのクロス開発環境の構築 (2017年10月時点)”をやってみました

”ZYBOのクロス開発環境の構築 (2017年10月時点)”が出ていたので、ZYBO のYocto を久しぶりにビルドしてみました。

ビルド方法はすべて、”ZYBOのクロス開発環境の構築 (2017年10月時点)”に書いてあるので省略。

ただ、ダウンロードが私の環境ではとっても遅いです。

bitbake core-image-minimal の結果を示します。


ビルドは成功です。

poky/build/tmp/deploy/images/zybo-zynq7 ディレクトリに u-boot, uEnv.txt, uImage ができていました。


u-boot と uImage を使ってZYBO をブートしてみようと思います。

やはり、Yoctoの u-boot を入れてSDK でBOOT.bin を作成して入れ替え、今までの uImage とYoctoの uImage を入れ替えたのではブートしませんでした。
今まで使っていた BOOT.bin に変えたところ、u-boot は起動しましたが、Linux Kernel が起動しませんでした（つまり uImage）。
やはり、BOOT.bin から何から一体でMicro SD カードに書かないとだめなようです。でもその時のFPGA のビットファイルはどうするんでしょうか？
後からコンフィグするのかな？

Vivado HLS で生成した AXI4 Master DMA IP を使用したカメラ画像表示システム6（アプリの変更と30fpsへ）

”Vivado HLS で生成した AXI4 Master DMA IP を使用したカメラ画像表示システム5（ILAコアの削除）”の続き。

前回は、Vivado HLS で生成した AXI4 Master DMA IP を使用したカメラ画像表示システムから 2 つの ILA コアを削除した。今回は、アプリケーションソフトを整備した後で、15 fps のカメラのフレームレートを 30 fps に変更する。

まずは、DMA_Read_addr IP の動作モードのDMA_WRITE_MODE はDMA_Write IP の書き込んでいる画像フレームの1つ前の画像フレームからDMA Read しているモードでこれは正常に動作している。問題は、FREE_RUM_MODE で、これは、3 つの画像フレームからフリーランで読んでるモードなのだが、15 fps でカメラがWrite していて、60 fps でビットマップ・ディスプレイ・コントローラがRead するので、画像フレームバッファが 3 つあると現在、過去が入り混じって画像がぶれてしまう。よって、FREE_RUM_MODE の場合は、画像フレームを 1 つにする必要があるようだ。そのように変更したところ、画像がぶれることは無くなった。


cam_disp_hls.c を貼っておく。

/* * cam_disp_hls.c * *  Created on: 2016/08/21 *      Author: Masaaki */


#include <stdio.h>
#include <stdlib.h>
#include "xil_io.h"
#include "xdma_read_addr.h"
#include "xdma_write.h"
#include "sleep.h"

#define NUMBER_OF_WRITE_FRAMES    3 // Note: If not at least 3 or more, the image is not displayed in succession.

#define HORIZONTAL_PIXELS    800
#define VERTICAL_LINES        600
#define PIXEL_NUM_OF_BYTES    4

#define FRAME_BUFFER_ADDRESS 0x10000000

#define DMA_WRITE_MODE
//#define FREE_RUN_MODE

void cam_i2c_init(volatile unsigned *mt9d111_i2c_axi_lites) {
    mt9d111_i2c_axi_lites[64] = 0x2; // reset tx fifo ,address is 0x100, i2c_control_reg
    mt9d111_i2c_axi_lites[64] = 0x1; // enable i2c
}

void cam_i2x_write_sync(void) {
    // unsigned c;

    // c = *cam_i2c_rx_fifo;
    // while ((c & 0x84) != 0x80)
        // c = *cam_i2c_rx_fifo; // No Bus Busy and TX_FIFO_Empty = 1
    usleep(1000);
}

void cam_i2c_write(volatile unsigned *mt9d111_i2c_axi_lites, unsigned int device_addr, unsigned int write_addr, unsigned int write_data){
    mt9d111_i2c_axi_lites[66] = 0x100 | (device_addr & 0xfe);   // Slave IIC Write Address, address is 0x108, i2c_tx_fifo
    mt9d111_i2c_axi_lites[66] = write_addr;
    mt9d111_i2c_axi_lites[66] = (write_data >> 8)|0xff;         // first data
    mt9d111_i2c_axi_lites[66] = 0x200 | (write_data & 0xff);        // second data
    cam_i2x_write_sync();
}

int main(){
    XDma_read_addr  dmar, *dmarp;
    XDma_write      dmaw, *dmawp;

    dmarp = &dmar;
    dmawp = &dmaw;

    // Initialization of DMA Read
    if (XDma_read_addr_Initialize(dmarp, 0) != XST_SUCCESS){
        fprintf(stderr,"DMA Read open error\n");
        exit(-1);
    }

    // Initialization of DMA Write
    if (XDma_write_Initialize(dmawp, 0) != XST_SUCCESS){
        fprintf(stderr,"DMA Write open error\n");
        exit(-1);
    }

    // frame buffer settings
#ifdef DMA_WRITE_MODE
    XDma_read_addr_Set_frame_buffer0(&dmar, FRAME_BUFFER_ADDRESS);
    XDma_read_addr_Set_frame_buffer1(&dmar, FRAME_BUFFER_ADDRESS+HORIZONTAL_PIXELS*VERTICAL_LINES*PIXEL_NUM_OF_BYTES);
    XDma_read_addr_Set_frame_buffer2(&dmar, FRAME_BUFFER_ADDRESS+2*HORIZONTAL_PIXELS*VERTICAL_LINES*PIXEL_NUM_OF_BYTES);

    XDma_write_Set_frame_buffer0(&dmaw, FRAME_BUFFER_ADDRESS);
    XDma_write_Set_frame_buffer1(&dmaw, FRAME_BUFFER_ADDRESS+HORIZONTAL_PIXELS*VERTICAL_LINES*PIXEL_NUM_OF_BYTES);
    XDma_write_Set_frame_buffer2(&dmaw, FRAME_BUFFER_ADDRESS+2*HORIZONTAL_PIXELS*VERTICAL_LINES*PIXEL_NUM_OF_BYTES);
#else // FREE_RUN_MODE
    XDma_read_addr_Set_frame_buffer0(&dmar, FRAME_BUFFER_ADDRESS);
    XDma_read_addr_Set_frame_buffer1(&dmar, FRAME_BUFFER_ADDRESS);
    XDma_read_addr_Set_frame_buffer2(&dmar, FRAME_BUFFER_ADDRESS);

    XDma_write_Set_frame_buffer0(&dmaw, FRAME_BUFFER_ADDRESS);
    XDma_write_Set_frame_buffer1(&dmaw, FRAME_BUFFER_ADDRESS);
    XDma_write_Set_frame_buffer2(&dmaw, FRAME_BUFFER_ADDRESS);
#endif

    // DMA_read_addr mode set
#ifdef DMA_WRITE_MODE
    XDma_read_addr_Set_mode_V(&dmar, 0); // DMA_WRITE_MODE
#else // FREE_RUN_MODE
    XDma_read_addr_Set_mode_V(&dmar, 1); // FREE_RUN_MODE
#endif

    // mt9d111_inf_axis_0, axi_iic_0, bitmap_disp_cont_axis_0
    volatile unsigned int *mt9d111_axiL;
    volatile unsigned int *cam_iic_axiL;
    volatile unsigned int *bmdc_axiL;

    mt9d111_axiL = (volatile unsigned int *)XPAR_MT9D111_INF_AXIS_0_BASEADDR;
    cam_iic_axiL = (volatile unsigned int *)XPAR_AXI_IIC_0_BASEADDR;
    bmdc_axiL = (volatile unsigned int *)XPAR_BITMAP_DISP_CONT_AXIS_0_BASEADDR;

    // bitmap_disp_cont_axis_0 is started
    bmdc_axiL[0] = (volatile unsigned int)FRAME_BUFFER_ADDRESS; // Camera Interface start (Address is dummy)

    // DMA Start
    XDma_read_addr_DisableAutoRestart(&dmar);
    while(!XDma_read_addr_IsIdle(&dmar)) ;
    XDma_read_addr_Start(&dmar);
    XDma_read_addr_EnableAutoRestart(&dmar);

    XDma_write_DisableAutoRestart(&dmaw);
    while(!XDma_write_IsIdle(&dmaw)) ;
    XDma_write_Start(&dmaw);
    XDma_write_EnableAutoRestart(&dmaw);

    // mt9d111_inf_axis_0 is started
    mt9d111_axiL[0] = (volatile unsigned int)FRAME_BUFFER_ADDRESS; // Camera Interface start (Address is dummy)

    // CMOS Camera initialize, MT9D111
    cam_i2c_init(cam_iic_axiL);

    cam_i2c_write(cam_iic_axiL, 0xba, 0xf0, 0x1);      // Changed regster map to IFP page 1
    cam_i2c_write(cam_iic_axiL, 0xba, 0x97, 0x20);     // RGB Mode, RGB565

    mt9d111_axiL[1] = 0; // One_shot_mode is disabled

    return(0);
}

これで、FREE_RUM_MODE も問題が無くなったので、次は、カメラのフレームレートを 15 fps から 30 fps に向上させることにした。
やり方は、”MT9D111のフレームレートを 15 fps から 30 fps にした”に書いておいた。
早い話が、カメラに供給するクロックを 36 MHz から倍の 72 MHz に変更するということだ。それに合わせて制約も変更する。
具体的には、PS からのクロックの FCLK_CLK2 の周波数設定を 36 MHz から 72 MHz に変更した。


もう一度、論理合成、インプリメント、ビットストリームの生成を行い、ハードウェアをエクスポートして、SDKを立ち上げた。
これで、画像のフレームレートが 15 fps から 30 fps に向上した。

このDMAWrite IPとDMA_Read_addr IP の組は使えそうだ。AXI VDMAの説明書を読まなくても簡単に使えるところが良いと思う。
願わくば、DMA_Read_addr IP を使うときのツールのバグが直ってほしいと思う。

Vivado HLS で生成した AXI4 Master DMA IP を使用したカメラ画像表示システム5（ILAコアの削除）

”Vivado HLS で生成した AXI4 Master DMA IP を使用したカメラ画像表示システム4（ILAコアの挿入2）”の続き。

前回、Vivado HLS で生成した AXI4 Master DMA IP を使用したカメラ画像表示システムが動作した。しかし、ブロックデザイン上で挿入したILA コアとネットリストの信号を観察するため入れたILA コアが残ってしまっている。それを削除した。

まずは、ブロックデザイン上で挿入したILA コアを削除しよう。

Debug にマーキングされた配線を複数選択して、右クリックし、右クリックメニューからClear Debug を選択する。


ILA コアの system_ila が削除された。


これで、ブロックデザイン上で挿入したILA コアが削除された。
次に、ネットリストの信号を観察するため入れたILA コアを削除する。

論理合成を行って、成功後に表示されるSynthesis Completed ダイアログで Open Synthesized Design を選択した。


Synthesized Design が表示された。Tools -> Set Up Debug... を選択した。


Set Up Debug ダイアログが表示された。Next ボタンをクリックした。


Existing Debug Nets で、Disconnect all net and remove debug cores を選択した。


Set Up Debug Summary が表示された。Finish ボタンクリックした。


ネットリストの信号を観察するため入れたILA コアが削除された。


確か、制約ファイルの ILA コア関連の制約は削除されたが、1つ ILA コアの制約が残っていたので、手動で削除した。

インプリメント、ビットストリームの生成を行った。結果を示す。


ILA コアが入る前と同等のリソース使用量になった。

ハードウェアをエクスポートして、SDK を立ち上げて、カメラ画像をディスプレイに表示してみたところ正常に表示された。

Vivado HLS で生成した AXI4 Master DMA IP を使用したカメラ画像表示システム4（ILAコアの挿入2）

”Vivado HLS で生成した AXI4 Master DMA IP を使用したカメラ画像表示システム3（ILAコアの挿入）”の続き。

DMA_Read_addr_0 の m_axi_in_r と outs は波形が出ていて動作しているようだった。よって今回は、AXI4-Stream 版のビットマップ・ディスプレイ・コントローラの内部信号をVivado Analyzer で確認してみよう。

Flow Navigator -> Synthesis -> Open Synthesized Design をクリックして、Synthesized Design を開く。

Tools -> Set Up Debug... を選択する。


Set Up Debug ダイアログが開いた。


Nets to Debug でFind Nets to Add... をクリックする。


Find Nets で、h_count を検索してみた。


Add Nets to Debug で信号を選択する。


観察する信号を示す。


次は、ILA Core Options を設定する。


Set Up Debug Summary が表示された。


Debug 画面が表示された。


cam_disp_axis.xdc の制約ファイルに挿入したu_ila_0 の制約が追加された。


インプリメント、ビットストリームの生成を行った。結果を示す。


SDK でXilinx Tools -> Program FPGA を選択して、ビットストリームをZynq にダウンロードした。
SDK で、Hello_World を起動して、PL にクロックを供給した。
Flow Navigator -> Program and Debug -> Open Hardware Manager -> Auto Connect を選択した。
Hardware Manager が起動した。
Dashboard Optionsを開いて、hw_ila_2, hw_ila_3 のすべてにチェックを入れた。


hw_ila_1 のトリガをかけた。AXI4 バス。


hw_ila_2 のトリガをかけた。ビットマップ・ディスプレイ・コントローラのclk_disp ドメイン。


hw_ila_3 のトリガをかけた。ビットマップ・ディスプレイ・コントローラの clk_axi ドメイン。


SDK で cam_disp_hls.elf をRun した。
hw_ila_3 の波形を示す。diap_mode_ena が 1 にならない。しかも init_done_d1 が上がったときに、u_ila_1_war_data_count_1[7:0] が 00 ではなかった。となると、ビットマップ・ディスプレイ・コントローラを活かすのが遅いことが考えられる。


cam_disp_hls.c のアプリケーションソフトで、DMA_read_addr の起動の後で、ビットマップ・ディスプレイ・コントローラを活かしていたのだが、これでは、ビットマップ・ディスプレイ・コントローラを活かすのが遅い。ビットマップ・ディスプレイ・コントローラを生かす記述（ピンクの四角）を DMA_read_addr の起動（青の四角）の前に持ってきた。


これでうまくDMA Read の波形が出力された。


画像も表示された。


DMA Read とDMA Write が両方表示されている波形を示す。

Vivado HLS で生成した AXI4 Master DMA IP を使用したカメラ画像表示システム3（ILAコアの挿入）

”Vivado HLS で生成した AXI4 Master DMA IP を使用したカメラ画像表示システム1（プロジェクト作成）”
”Vivado HLS で生成した AXI4 Master DMA IP を使用したカメラ画像表示システム2（SDK）”の続き。

前にやったのは半年くらい前だが、DMA Read IPが動作しないということで止まっていた。しかし、”「Vivado HLS で DMA Read IP を作る2（絶対アドレス指定版）」を使って合成後の機能シミュレーション3”で論理合成しても機能シミュレーションが問題なくなったということで、もう一度やってみようと思う。

cam_disp_axis_162 プロジェクトはVivado 2016.2 なので、”Vivado 2016.2 からVivado 2016.4 へアップグレード”を参照して、Vivado 2016.4 のcam_disp_axis プロジェクトを作成した。

当然、Target language はVHDL にしてある。
（2017/04/20 ： 追記）この時点ではアプリケーションソフトがバグっていてディスプレイに表示できませんが、アプリケーションソフトのバグフィックス後に、Target language を Verilog にしても動作しました。論理合成後の機能シミュレーションを行うときに強瀬された EDIF からVerilog に変換するツールがバグっているようです。

論理合成、インプリメント、ビットストリームの生成を行ったところ、成功した。
リソース使用量は以前と変化が無い。今回のProject Summary はキャプチャするのを忘れてしまったので、以前のVivado 2016.2 のときのProject Summary を貼っておく。


ハードウェアをエクスポートして、SDKを立ち上げた。
cam_disp_hls プロジェクトを作成し、cam_disp_hls.c をコピー＆ペーストした。
ビットストリームをZYBO にダウンロードして、cam_disp_hls.elf を起動したが、動作しなかった。


Vivado 2016.4 になって変わったVivado Analyzer を試してみようということで、ブロックデザインでDMA_Read_addr_0 のm_axi_in_r と outs とDMA_Write_0 の m_axi_out_r を選択して、右クリックし右クリックメニューからDebug を選択した。


選択したラインにデバックマークが付き、上に Run Connection Automation が出るので、クリックした。


Run Connection Automation が表示された。OK ボタンをクリックした。


system_ila が挿入された。ILA コアがブロックデザイン上に挿入されるようになった。


論理合成、インプリメント、ビットストリームの生成を行った。結果を示す。

全体的にリソース使用量が増えている。これはILA コアを入れたので、当然と言えば当然だ。

Vivado Analyzer はPL の回路にクロックが来ないと起動できない。ソフトウェアを起動しないと回路にクロックが供給されないので、Vivado Analyzer は起動しない。
と言う訳で、ZYBO にビットストリームをダウンロードしてから、cam_disp_hls.elf を起動した。


その後で、Flow Navigator -> Program and Debug -> Open Hardware Manager -> Auto Connect を選択した。


Hardware Manager が立ち上がった。


Status ペインで Run trigger immediate for this ILA core をクリックすると、すぐに波形がキャプチャされる。


Vivado 2016.4 では、AXI バスはステータスを表示してくれるようだ。トランザクションが全く見えなかった。


よくわからなかったので、DMA_Write_0 の ins も追加した。


論理合成、インプリメント、ビットストリームの生成を行った。成功した。
Project Summary を示す。


Hardware Manager で net_slot_3_axis_tvalid = R （DMA_Write_0 の ins）でトリガをかけて Run trigger for this ILA core をクリックした。


DMA_Write_0 の ins と m_axi_out_r は波形が出力されていることが分かった。


次に、net_slot_0_axi_arvalid = R （DMA_Read_addr_0 の m_axi_in_r）でトリガをかけたが掛からなかった。


これは、電源ON の少し間だけのみ DMA_Read_addr_0 の m_axi_in_r と outs が動作しているかもしれない。ということで、Hello_World プロジェクトを作成し、これを起動して、PL へクロックを供給してから cam_disp_hls.elf を起動することにした。

Hello_World プロジェクトを作成した。起動した。


Flow Navigator -> Program and Debug -> Open Hardware Manager -> Auto Connect を選択し、Hardware Manager を起動する。
net_slot_0_axi_arvalid = R （DMA_Read_addr_0 の m_axi_in_r）でトリガをかけた。


これで、SDK で、cam_disp_hls.elf を起動した。すると、トリガがかかってDMA_Read_addr_0 のm_axi_in_r と outs の波形が表示された。


これを見るときちんとDMA_Read_addr_0 の m_axi_in_r はAXI4 Master Read ができていて、AXI4-Stream の outs にもきちんと出力できているように見える。しかし、途中で tready が 1 から 0 になってしまっている。これは、AXI4-Stream 版のビットマップ・ディスプレイ・コントローラのピクセル用FIFO がフルになってしまっているからだと思われる。
AXI4-Stream 版のビットマップ・ディスプレイ・コントローラがおかしい可能性が出てきた。