FC2カウンター FPGAの部屋 2020年02月11日
FC2ブログ

FPGAやCPLDの話題やFPGA用のツールの話題などです。 マニアックです。 日記も書きます。

FPGAの部屋

FPGAの部屋の有用と思われるコンテンツのまとめサイトを作りました。Xilinx ISEの初心者の方には、FPGAリテラシーおよびチュートリアルのページをお勧めいたします。

Vitis 2019.2 で自作カーネルを使用してストーミング接続を試す9(streaming_lap_filter3 プロジェクト2)

Vitis 2019.2 で自作カーネルを使用してストーミング接続を試す8(streaming_lap_filter3 プロジェクト)”の続き。

前回は、Vitis 2019.2 で krnl_filter_dmaw.cpp を使用した streaming_lap_filter3 プロジェクトを作成した。ホスト・アプリケーションソフトの krnl_streaming_lap_filter_host3.cpp を貼った。今回は、カーネルのストリーミング接続の動作を確かめてみよう。

最初に、動作を確かめた時には、2 つのカーネルが完走したが、つまりホスト・アプリケーションソフトが終了するようになったが、DMA Write のトランザクションが全く出ていなかった。そこで、 krnl_filter_dmaw.cpp の volatile をすべて消して、やってみたらうまく行った。これは、volatile が良くないのか?と思ったが、他のパソコンで volatile 付きで動作がうまく行ったのと、もう一度、同じパソコンで volatile 付きでやってみたら動作したので、単に最初のビルドが正常でなかったようだ。

さて、動作を確認してみよう。
Vitis で生成されたBOOT.BIN をUltra96-V2 の MicroSD カードの第 1 パーティションに転送する。
/home/masaaki/Vitis_Work/2019.2/streaming_lap_filter3/Hardware/sd_card ディレクトリに移動し、 sudo su で root になって scp コマンドで SFTP する。
scp BOOT.BIN 192.168.3.23:/run/media/mmcblk0p1
streaming_lap_filter_51_200210.png

Ultra96-V2 のPetaLinux をリブートする。
PetaLinux が起動したら、 Ultra96-V2 のPetaLinux 上で zocl ドライバを起動した。
insmod /lib/modules/4.19.0-xilinx-v2019.2/extra/zocl.ko
streaming_lap_filter_52_200210.png

Vitis の Assistant ウインドウの streaming_lap_filter3_system の streaming_lap_filter3 -> Hardware を右クリックし、右クリックメニューから Run -> Run Configurations... を選択して、 streaming_lap_filter3 の Run Configuration を作成した。
streaming_lap_filter_53_200210.png

Run Configuration ダイアログで Run ボタンをクリックすると動作を確認することができた。
streaming_lap_filter_54_200210.png

実行時間は 1.651 ms だった。
後、 2 回ほど実行してみた。
streaming_lap_filter_58_200210.png

streaming_lap_filter_59_200210.png

それぞれ実行時間は 1.772 ms と 1.525 ms だった。これら 3 つの実行時間を平均すると、1.649 ms となった。
ラプラシアンフィルタを 1 つのカーネルとして実装した例はすでにやってある。”Vitis 2019.2 アプリケーション・プロジェクト ラプラシアン・フィルタAXI4-Streamバージョン3”がそうだ。そこに出てきた数値の 560 us と 430 us を平均すると 495 us となる。今回のカーネル間のストリーミング接続による方法の方が、約3.33 倍遅いという結果が出た。やはり、今回のChipScope の結果をみても、dma_read をスタートしてから、krnl_lap_filter_dmaw をスタートするまでが長いのではないだろうか?

ChipScope の波形を示す。krnl_lap_filter_dmaw の DMA Write の AWVALID でトリガをかけている。
streaming_lap_filter_55_200210.png
streaming_lap_filter_57_200210.png

生成された temp_lap.bmp ファイルをパソコンに SFTP して確かめてみた。
streaming_lap_filter_61_200210.png

temp_lap.bmp ファイルを表示すると、エッジが表示されているのが分かる。
streaming_lap_filter_62_200210.png

ラプラシアンフィルタを 1 つのカーネルとして実装した例よりも、2 つのカーネルに分けてストリーミング接続をした方が 3.33 倍遅いという結果が出たが、それは、たぶん、2 つ目のカーネルの起動が遅いのだと思う。ChipScope 画面を見るとスループットは十分取れていると言える。
計算してみよう。
dma_read のRead スピードを計算してみると、ChipScope 波形のクロックを数えると、64 クロックのRead トランザクションについて、次のトランザクションとの間隔は 204 クロックだった。よって、スループットは
64 クロック / 204 クロック * 200 MHz ≒ 62.7 MWord / sec (Word = 32 ビット)
62.7451 MWord / sec * 4 バイト ≒ 251 MB / sec
3072 ピクセル / 62.7 MWord / sec = 49.0 us

ChipScope のスループットだと 3072 ピクセルのラプラシアンフィルタ処理を 49.0 us で終了できるはずなので、設定側が相当遅いということが考えられる。ということは、ピクセル数が多くなるほど、相対的に性能が向上する可能性があるはずだ。
今は 1 つのカーネルでのラプラシアンフィルタ処理に比べて、 2 つのカーネルのストリーミング接続の方が 3.33 倍遅いが、ピクセル数が多くなると、双方の性能差が縮んでくることが予想される。
  1. 2020年02月11日 04:14 |
  2. Vitis
  3. | トラックバック:0
  4. | コメント:0