Vitis

Vitis 統合ソフトウェア プラットフォーム
Vitis 統合ソフトウェア プラットフォームがXDF 2019 で発表されたようです。

Vitis 2019.2 をインストールした
最初に、「Vitis コア開発キット - 2019.2 」の約30GB をダウンロードしてしまった。しかし、「Vivado Design Suite - HLx Edition - 2019.2 Full Product Installation」の「ザイリンクス統合インストーラ 2019.2」をダウンロードすれば、Vitis をインストールすることができた。

Vivado 2019.2 のプロジェクトを作り Vitis でソフトウェア開発1
Vivado 2019.2 が11月1日にリリースされたが、このバージョンからSDK が無くなった。それじゃ、どうやって、ZYNQ とかでソフトウェアを開発するのか?といったらVitis を使用することになる。そのVitis を使ってソフトウェア開発する手順を確認してみよう。
Vivado 2019.2 のプロジェクトを作り Vitis でソフトウェア開発2
前回は、Vivado 2019.2 が11月1日にリリースされたが、このバージョンからSDK が無くなった。それじゃ、どうやって、ZYNQ とかでソフトウェアを開発するのか?といったらVitis を使用することになる。そのVitis を使ってソフトウェア開発する手順を確認してみよう。ということで、ZYBO Z7-10 を使用したaxi_gpio を使用して4 LED を制御する簡単な回路をVivado 2019.2 で作成し、Vitis 2019.2 でプラットフォーム・プロジェクトを生成してビルドした。今回は、Vitis でHello World アプリケーション・プロジェクトを作成して動作を確認してみよう。
Vivado 2019.2 のプロジェクトを作り Vitis でソフトウェア開発3
前回は、Vitis でHello World アプリケーション・プロジェクトを作成して動作を確認できた。今回は、Vivado のブロックデザインで、LED にGPIO を付けたはずなので、LED の点滅させてみよう。
ブロック・デザインを間違えていてLEDは点滅しなかった。
Vivado 2019.2 のプロジェクトを作り Vitis でソフトウェア開発4
前回は、Vivado のブロックデザインで、LED にGPIO を付けたはずなので、LED の点滅させてみよう、ということで、LED_test アプリケーション・プロジェクトと作成し、動作させてみようとしたらVivado で作った回路のミスが発覚した。今回は、そのミスを修正して、もう一度、アプリケーションを動作させてみよう。
ZYBO Z7-10 でアプリケーションの動作テストを行ったところ、正常に動作した。LED も 2 進表示で点滅した。

Vitis 2019.2 の組み込みプロセッサ プラットフォームの開発をやってみる1(ハードウェア・コンポーネントの作成)
今回は、Vitis 2019.2 のマニュアルの”Vitis Application Acceleration Development Flow Documentation”の”Embedded Processor Platform Development”をやってみようと思う。ただし、チュートリアルはZCU102 用なので、Ultra96-V2 用に変換してみようと思う。具体的には、PetaLinux 部分は、”SDx 2019.1 のUltra96-V2 用プラットフォームを作る1(DSA ファイルを作成)”からのシリーズのブログ記事を参考にしようと思う。
Vitis 2019.2 の組み込みプロセッサ プラットフォームの開発をやってみる2(ソフトウェア・コンポーネントの作成1)
前回は、Vivado 2019.2 の組み込みプロセッサ プラットフォームを作ってみようということで、SDx 2019.1 用に作ったハードウェア・プラットフォーム用のVivado 2019.2 のプロジェクトをVivado 2019.2 にアップグレードして、XSA ファイルを生成した。今回は、”Vitis Unified Software Development Platform Documentation”の”
Embedded Processor Platform Development”の”Creating the Software Component”を参照しながら、Vitis 2019.2 のソフトウェア・コンポーネントを作成していこう。
Vitis 2019.2 の組み込みプロセッサ プラットフォームの開発をやってみる3(ソフトウェア・コンポーネントの作成2)
前回は、”Creating the Software Component”を参照しながら、PetaLinux 2019.2 を使用して、Vitis 2019.2 のソフトウェア・コンポーネントを作成していったが、petalinux-build までとなった。今回は sysroot を作成して、linux.bif を作成する。
Vitis 2019.2 の組み込みプロセッサ プラットフォームの開発をやってみる4(プラットフォームの作成)
前回はソフトウェア・コンポーネントの作成で sysroot を作成して、linux.bif を作成した。今回は、プラットフォームを作成してみよう。

Xilinx Runtime (XRT)

Vitis には、Xilinx Runtime (XRT) がある。
Xilinx Runtime (XRT) の資料は、Xilinx Runtime (XRT) Architecture に詳しく載っている。

「Vitis 2019.2 の組み込みプロセッサ プラットフォームの開発をやってみる」にXRTサポートを追加
”Xilinx Runtime (XRT)”にも書いたが、「Vitis 2019.2 の組み込みプロセッサ プラットフォームの開発をやってみる」シリーズにXRT サポート用のユーザーパッケージと zocl ドライバを追加した。

XRT をインストールした
”「Vitis 2019.2 の組み込みプロセッサ プラットフォームの開発をやってみる」にXRTサポートを追加”の続きで、XRT をインストールすることにした。なおパソコンのOS は18.04.3 LTS だった。

Vitis_Accel_Examples の hello_world サンプルをUltra96V2 のプラットフォームでやってみる
Xilinx/Vitis_Accel_Examples の hello_world サンプルを今まで作ってきたUltra96V2 のプラットフォームでやってみようと思う。
make を実行すると、作ってきたプラットフォームが non-accelerated platform と言われてしまった。。。ショック。。。
おかしい。。。アクセラレートできるようにプラットフォームを作ってきたはずなのだが。。。プラットフォーム違いなのか???
Vitis_Accel_Examples の hello_world サンプルをUltra96V2 のプラットフォームでやってみる2
Xilinx/Vitis_Accel_Examples の hello_world サンプルを今まで作ってきたUltra96V2 のプラットフォームでやって見たが、作ってきたプラットフォームが non-accelerated platform と言われてしまった。その原因としては、どこかで見たかわからないのだが、ハードウェアの xsa ファイル名とソフトウェアの spfm ファイル名が同じでなければならないというのがあったと思う。
そこで、xsa ファイル名からPetaLinux のプロジェクト名、Vitis でのプラットフォーム名をすべて ultra96v2_min で統一することにした。
Vitis_Accel_Examples の hello_world サンプルをUltra96V2 のプラットフォームでやってみる3
前回は、xsa ファイル名からPetaLinux のプロジェクト名、Vitis でのプラットフォーム名をすべて ultra96v2_min で統一したら、hello_world サンプルのビルドが進んだが、TARGET=hw でビルドした時に”ERROR: [CFGEN 83-2299] Clock ID 0 must exist. Please correct the targetted platform.”というエラーが出てしまった。今回は、そのエラーの解消を試みた。
Vivado のブロックデザインで clock のID が 0 のものが必要だった。
Vitis_Accel_Examples の hello_world サンプルをUltra96V2 のプラットフォームでやってみる4
前回は、TARGET=hw でビルドした時に”ERROR: [CFGEN 83-2299] Clock ID 0 must exist. Please correct the targetted platform.”というエラーが出てしまったので、そのエラーを解消したが、cp コマンドでエラーになってしまった。今回は、そのエラーの行を Makefile から削除して、make してみた。そして、sd_card ディレクトリを SDカードの第1パーティションに書いて、また、sysroot の aarch64-xilinx-linux ディレクトリを第2パーティションに書いた。SDカードをUltra96V2 に挿入して、PetaLinux を起動した。
init.sh 起動コマンドを動作させたところ、XILINX_XRT not set で liboclxdp.so が無いと言われた。
Vitis_Accel_Examples の hello_world サンプルをUltra96V2 のプラットフォームでやってみる5
前回は、Xilinx/Vitis_Accel_Examples の hello_world サンプルをビルドしてできたsd_card の内容をSDカードの第1パーティションに書き込み、sysroot の aarch64-xilinx-linux ディレクトリの内容をSDカードの第2パーティションに書き込んでできたSDカードをUltra96V2 に挿れたところLinux が起動した。しかし、hello_world サンプルは実行できなかった。今回は、その原因を追求し、、hello_world サンプルを動作させることができた。zocl ドライバをインストールしていなかったためだった。

Ultra96-V2 用 Vitis アクセラレーション・プラットフォームのサンプルを公開
今まで作ってきた Ultra96-V2 用 Vitis アクセラレーション・プラットフォームのサンプルを公開した。ダウンロードすることができる。

Vitis_Accel_Examples の hello_world サンプルをUltra96V2 のプラットフォームでやってみる6
前回は、hello_world サンプルは実行できなかった原因を追求し、hello_world サンプルを動作させることができた。今回は、hello_world サンプルで作成された Vivado HLS と Vivado のプロジェクトを見ていこう。

Vitis_Accel_Examples を Ultra96V2 のプラットフォームでやってみる1(array_partition)
Vitis_Accel_Examples の hello_world 以外のサンプルを Ultra96V2 のプラットフォームでやってみようと思う。
array_patition を Ultra96V2 のVitis アクセラレーション・プラットフォームでやってみよう。
TEST PASSEDでうまく行った。
Vitis_Accel_Examples を Ultra96V2 のプラットフォームでやってみる2(array_partition 2)
前回は、Vitis_Accel_Examples の hello_world 以外のサンプルを Ultra96V2 のプラットフォームでやってみようということで、ccp_kernels/array_patition を Ultra96V2 のVitis アクセラレーション・プラットフォームでやってみた。今回は、array_partition をVivado や Vivado HLS のプロジェクトを見ながら詳しく見ていこう。

ZYBO Z7-20 用のVitis アクセラレーション・プラットフォームを作成した
フィクスターズさんのブログでも紹介されているが、私もZYBO Z7-20 の Vitis アクセラレーション・プラットフォームを作成した。

Ultra96-V2 の Vitis アクセラレーション・プラットフォームの作り方1(ハードウェア・コンポーネント編)
Ubuntu 18.04 上で Ultra96-V2 の Vitis アクセラレーション・プラットフォームを 4 回に分けて作っていこう。
前回作った Ultra96-V2 の Vitis アクセラレーション・プラットフォームはデフォルトのクロック周波数が 100 MHz だったので、今回のデフォルトのクロック周波数は 200 MHz とする。
Ultra96-V2 の Vitis アクセラレーション・プラットフォームの作り方2(ソフトウェア・コンポーネント編)
Ultra96-V2 の Vitis アクセラレーション・プラットフォームのハードウェア・コンポーネント編の続きで、ソフトウェア・コンポーネント編をやっていこう。PetaLinux 2019.2 で実装して行く。
Ultra96-V2 の Vitis アクセラレーション・プラットフォームの作り方3(Vitis プラットフォーム作成)
ハードウェア・コンポーネント編、ソフトウェア・コンポーネント編で作成したファイルを元に、 Vitis 2019.2 を起動してプラットフォームを作成しよう。
Ultra96-V2 の Vitis アクセラレーション・プラットフォームの作り方4(Vitis アプリケーション・プロジェクトの作成)
Vitis のアクセラレーション・プラットフォームを作成できたので、それを使用してアプリケーション・プロジェクトを作成し、Ultra96-V2 で動作させてみよう。実機動作を確認した。

array_patition example をultra96v2_min2 プラットフォームでやってみよう
Vitis アクセラレーション・プラットフォームの ultra96v2_min2 ができたので、array_patition example をやってみよう。
array_patition example は”Vitis_Accel_Examples を Ultra96V2 のプラットフォームでやってみる1(array_partition)”でやっているので、結果が出ている。これは、動作クロックが 100 MHz だったが、今回の動作クロックは 200 MHz にしてあるので、どのくらい性能向上したか?を確かめてみよう。

Vitis 2019.2 のアプリケーション・プロジェクトの作り方1
Ultra96-V2 のVitis アクセラレーション・プラットフォームを作成したが、それを使用して自分のアプリケーション・プロジェクトを動作させてみよう。そのために、まだVitis 2019.2 でサンプル・プロジェクトしかやっていないので、自分でアプリケーション・プロジェクトを作り、自分でアクセラレーションする関数を指定してビルドしていないので、それを やってみようと思う。
Vitis 2019.2 のアプリケーション・プロジェクトの作り方2
自分でアプリケーション・プロジェクトを作り、自分でアクセラレーションする関数を指定してビ ルドしていないので、それをやってみようと思うということで、前回は、Xilinx 社のGitHub の Xilinx/Vitis-Tutorials の Mixing C++ and RTL Kernels のソースコードを使用してVitis 2019.2 のプロジェクトを作成し、ビルドする手順を行うことができた。今回は、ビルド後のSummary を見ていこう。
Vitis 2019.2 のアプリケーション・プロジェクトの作り方3
自分でアプリケーション・プロジェクトを作り、自分でアクセラレーションする関数を指定してビ ルドしていないので、それをやってみようと思うということで、前回は、ビルド後のSummary を観察した。
今回は、出来上がったSD_CARD イメージをMicroSD カードに書いて、実際にUltra96-V2 でテストしてみよう。実機動作を確認できた。

Vitis 2019.2 アプリケーション・プロジェクトのホスト・コード作成手順
Vitis 2019.2 アプリケーション・プロジェクトのホスト・コードの作成手順をまとめてみよう。

Vitis 2019.2 アプリケーション・プロジェクトの C/C++ カーネル・コード作成手順
前回は、”Vitis 2019.2 アプリケーション・プロジェクトのホスト・コード作成手順”でしたが、今回は、Vitis 2019.2 アプリケーション・プロジェクトの C/C++ カーネル・コード作成手順をまとめていきたいと思う。

Vitis 2019.2 アプリケーション・プロジェクト square その1
自分で作ったと言うか、Xilinx のサンプルを手直しした Viits 2019.2 アプリケーションプロジェクトの square を書いておく。
ホストアプリケーションは自分で作ったというのはおこがましいほど、Vitis- Tutorials/docs/mixing-c-rtl-kernels/reference-files/src/host /host_step1.cpp のコードを引用しまくりで恥ずかしいのだが、自分でリファクタリングも決まりきった手順なので難しいので、そのまま使わせてもらうことにする。
Vitis 2019.2 アプリケーション・プロジェクト square その2
Vitis-Tutorials/docs/mixing-c-rtl-kernels/reference-files/src/host/host_step1.cpp のコードを引用しまくりで、Vitis 2019.2 のアプリケーション・プロジェクトの square を作成して、ホストアプリケーションとカーネルアプリケーションのコードを貼った。
今回は、spuare のアクセラレーション・アプリケーション・プロジェクトを作成して、ビルドしていこう。
Vitis 2019.2 アプリケーション・プロジェクト square その3
前回は、Vitis 2019.2 のアクセラレーション用アプリケーション・プロジェクトの spuare_u96v2 を作成して、ビルドした。今回は、square_u96v2 に使用された Vivado HLS , Vivado のレポートなどを見て、Ultra96-V2 実機で動作を確認しよう。実機動作を確認できた。

Vitis 2019.2 アプリケーション・プロジェクト ラプラシアン・フィルタAXI Masterバージョン1
前回の square Vitis 2019.2 アプリケーション・プロジェクトで、自作(といってOpenCL シーケンス部分はほとんど引用だが)Vitis 2019.2 アプリケーション・プロジェクトを初めて作ったが、今回は、いつも題材にしているラプラシアン・フィルタをVitis 2019.2 アプリケーション・プロジェクトにして作成してみよう。
Vitis 2019.2 アプリケーション・プロジェクト ラプラシアン・フィルタAXI Masterバージョン2
前回は、ラプラシアン・フィルタをVitis 2019.2 アプリケーション・プロジェクトにして作成してみようということで、ソースコードを貼り付けた。今回は、Vitis 2019.2 のアプリケーション・プロジェクト laplacian_filter1 を作成し、ビルドしてUltra96-V2 の実機で確認してみよう。実機確認OKでした。

Vitis 2019.2 アプリケーション・プロジェクト ラプラシアン・フィルタAXI4-Streamバージョン1
Vitis 2019.2 アプリケーション・プロジェクト ラプラシアン・フィルタのAXI Master バージョンを作ったが、今回は、AXI4 Master DMA Read ー AXI4-Stream 入力, ラプラシアン・フィルタ処理, AXI4 Stream 出力 ー AXI4 Master DMA Write のラプラシアン・フィルタ処理のカーネルアプリケーションを作成する。
ソースコードを貼っておく。
Vitis 2019.2 アプリケーション・プロジェクト ラプラシアン・フィルタAXI4-Streamバージョン2
”Vitis 2019.2 アプリケーション・プロジェクト ラプラシアン・フィルタAXI4-Streamバージョン1”に、AXI4 Master DMA Read ー AXI4-Stream 入力, ラプラシアン・フィルタ処理, AXI4 Stream 出力 ー AXI4 Master DMA Write のラプラシアン・フィルタ処理のカーネルアプリケーションのソースコードを貼ったが、int の 64 ビット幅でバグでたので、int を int32_t に変更した。そして、ホストアプリケーションに getProfilingInfo()による時間計測を追加した。
今回はコードを貼っておく。
Vitis 2019.2 アプリケーション・プロジェクト ラプラシアン・フィルタAXI4-Streamバージョン3
前回は、バグを修正したソースコードを貼った。今回は、Vitis 2019.2 で lap_filter_axis_dma プロジェクトを作成してUltra96-V2 で動作を確認した。
Vitis 2019.2 アプリケーション・プロジェクト ラプラシアン・フィルタAXI4-Streamバージョン4
前回は、Vitis 2019.2 で lap_filter_axis_dma プロジェクトを作成してUltra96-V2 で動作を確認することができた。今回は、実行時のプロファイルを取得してみよう。

laplacian_filter1_host.cpp に時間計測コードを追加
最初にカーネルアプリケーションがAXI4 Master の laplacian_filter1_host.cpp をやってみて、次に、DMA Write - AXI4 Stream - DMA Readの lap_filter_axis_dma.cpp をやってみようとしている。この 2 つの実装をやってみることで、カーネルアプリケーションの書き方のバリエーションは示せるが、実機での性能差を示せていないのが、気がかりだった。そこで、時間計測コード を入れてみることにした。
最初にOpenCLで書いた時間計測コードを入れたがうまく行かなかったため、gettimeofday() を使用したコードで時間を計測した。
laplacian_filter1_host.cpp に時間計測コードを追加2
前回は、OpenCL の getProfilingInfo() を使用した時間計測を試みたがセグメンテーション・フォールトで出来なかった。そこで、 gettimeofday() を使用した時間計測コードを作成して時間計測した。ツィッターで @KSuzukiii さんに「enqueueTaskに event渡してないのが気になりました。」というコメントをいただいたので、調べてみるとたしかにそうだった。コードを修正して、やってみると成功したので、 OpenCL の getProfilingInfo() を使用した時間計測を行った。

Ultra96-V2 をUSB-LAN 変換アダプタでネットワークに接続
Ultra96-V2 のPetaLinux 2019.2 で無線LAN を使用して、ネットワークに接続するためにドライバとファームウェアをインストールしようとしていたが、うまく行かなかった。そこでUSB-LAN 変換アダプタを使用して、ネットワークに接続することにした。
USB-LAN 変換アダプタは前に使用していてパソコンのリプレースのために余っていたPLANEX のGU-1000T を使用する。このUSB-LAN 変換アダプタをUltra96-V2 のUSB-A コネクタに接続して、有線LAN で接続することができた。

ultra96v2_min2 プラットフォームのPeteLinux 2019.2 が動作するUltra96-V2 にSFTP できた
    ultra96v2_min2プラットフォームのPeteLinux 2019.2 が動作するUltra96-V2 にSFTP ができました。
ultra96v2_min2 プラットフォームのPeteLinux 2019.2 が動作するUltra96-V2 にSFTP できた2
”ultra96v2_min2プラットフォームのPeteLinux 2019.2 が動作するUltra96-V2 にSFTPできた”で、Ubuntu 18.04 の scp コマンドで、Ubuntu 18.04 の自分のパソコンから Ultra96-V2 のPetaLinux 2019.2 にファイルをアップロードすることができた。今回は、Ultra96-V2 のPetaLinux 2019.2 から Ubuntu 18.04 の自分のパソコンにファイルをダウンロードしてみよう。これは、ラプラシアン・フィルタ処理した画像ファイルを確認するのに使用する。

Vitis のRTL カーネル
今まで、Vitis のアクセラレーション・プラットフォームのC/C++ カーネルを実装してきたが、RTL カーネルもやってみようと思う。RTL カーネルの作成条件について見ていこう。
なお、C/C++ カーネルを作っていると、性能やクリティカルパスなどの情報が無いかもしくは、分かりにくい。そこで、Vivado HLS でC/C++ コードを合成して RTLカーネルを作成して、それをVitis で使っても良いのでは?と思っている。


テンプレートで書いた畳み込み ニューラルネットワークをRTLカーネルとしてVitisで実装する1(Vivado HLS 編 1)
以前テンプレートを使用して、パラメータを変更できる形に書いた畳み込みニューラルネットワー クをVivado HLS 2019.2 でIP にすることにした。Vitis のアクセラレーション・プラットフォームでやってみたいためだ。実はこのテンプレートを使用して、パラメータを変更できる形に書いた畳み込みニューラルネットワークを Vitis のアクセラレーション・プロジェクトとして作成したところ、ビルドが通らなかったので、Vivado HLS でIP 化した後で、Vitis のRTL カーネルとして使ってみたいということだ。
Vivado HLS でIP 化すると、チューニングもしやすいし、C/RTL 協調シミュレーションで波形も確認できるのでとても良い。そこで、IP 化したVerilog HDL コードをRTL カーネルとしてVitis で使いたいと考えたわけだ。。。
今回は、Vitis のRTL カーネルと実装するためのC++ のソースコードテストベンチを貼っておく。
テンプレートで書いた畳み込み ニューラルネットワークをRTLカーネルとしてVitisで実装する2(Vivado HLS 編 2)
前回は、Vitis のRTL カーネルとして実装するためのC++ のソースコードテストベンチを貼った。今回は、そのコードをVivado HLS 2019.2 でプロジェクトを作成して実装していこう。

ラプラシアン・フィルタを RTLカーネルとしてVitisで実装する1
テンプレートで書いた畳み込みニューラルネットワークをRTLカーネルとしてVitisで実装 しようとしていたが、ソースコードとやり方が全くやったこと無いのはやり方が間違っているかコードが間違っているのか分からないので、トラブった時に大変だと 考えた。そこで、”Vitis 2019.2 アプリケーション・プロジェクト ラプラシアン・フィルタAXI4-Streamバージョン2”で使用したラプラシアン・フィルタだったら、カーネル・アプリケーションはできているので、これを RTL カーネルとして実装することにした。
ラプラシアン・フィルタを RTLカーネルとしてVitisで実装する2
前回は、”Vitis 2019.2 アプリケーション・プロジェクト ラプラシアン・フィルタAXI4-Streamバージョン2”で使用したラプラシアン・フィルタを RTL カーネルとして実装することにした。Vivado HLS プロジェクトを作成し、C シミュレーション、C コードの合成、C/RTL 協調シミュレーション、Export RTL を行って、xo ファイルを作成した。
今回は、Vitis でアクセラレーション・アプリケーション・プロジェクトを作成し、ビルドした後で、Ultra96-V2 上で動作を確認した。
ラプラシアン・フィルタを RTLカーネルとしてVitisで実装する3
前回は、Vitis でアクセラレーション・アプリケーション・プロジェクトを作成し、ビルドした後で、Ultra96-V2 上で動作を確認することができた。今回は、lap_filter_aixs_dma のVitis アクセラレーション・アプリケーションを起動した時にできた profile_summary.csv を見てみよう。

テンプレートで書いた畳み込み ニューラルネットワークをRTLカーネルとしてVitisで実装する3(出力をグローバル・バッファからホストにコピーできない)
”テンプレートで書いた畳み込みニューラルネットワークをRTLカーネルとしてVitisで実 装する1(Vivado HLS 編 1)”のコードにはバグがあった。固定小数点を int32_t に変更しただけなので、小数点以下が切られてしまっている。これを現在は、256 倍してから int32_t に変更してある。
”テンプレートで書いた畳み込みニューラルネットワークをRTLカーネルとしてVitisで実装する2(Vivado HLS 編 2)”でエラーの表示を見ると、ハードウェアの出力値がほとんど 0 なのが分かると思う。このバグは 256 倍して出力して、出力側で 1/256 倍することで修正できた。しかし、Vitis アクセラレーション・プラットフォームで出力、つまり、左に曲がるか、直進するか、右に曲がるか(CNN の利用用途は白線走行です)の判定の output と左折、直進、右折の判定スコアの dot2[ ] の 2 個の出力値を出力しているが、それが 0 になってしまって反映されていない。

Vivado HLS の Vitis Bottom Up Flow を使用する1
”テンプレートで書いた畳み込みニューラルネットワークをRTLカーネルとしてVitisで実 装する3(出力をグローバル・バッファからホストにコピーできない)”で all_layers_dnn が 2 個の出力バッファを使用しているので、その場合は、ホスト・メモリにコピーできないのか?を確かめるために Vivado HLS プロジェクトの square_cubed プロジェクトを作成して確かめてみよう。ついでに、Vivado HLS の新規プロジェクトを作成する時に Vitis Bottom Up Flow というチェックボックスがあるのを覚えていたので、それを使用して、Vitis の RTL カーネルを生成してみようと思う。
Vivado HLS の Vitis Bottom Up Flow を使用する2
前回は、 2 個の出力バッファを使用している時に、ホスト・メモリにコピーできないのか?を確かめるために Vivado HLS プロジェクトの square_cubed プロジェクトを作成して確かめてみようということで、 Vivado HLS 2019.2 で square_cubed プロジェクトを作成した。(Vitis 2019.2 の RTL カーネルを作成するため)
今回は、Vitis 2019.2 のアクセラレーション・プロジェクト用のVivado HLS 2019.2 プロジェクトの square_cubed プロジェクトで xo ファイルを作成しよう。
Vivado HLS の Vitis Bottom Up Flow を使用する3
前回は、Vitis 2019.2 のアクセラレーション・プロジェクト用のVivado HLS 2019.2 プロジェクトの square_cubed プロジェクトで xo ファイルを作成した。今回は、Vitis 2019.2 で square_cubed アクセラレーション・アプリケーション・プロジェクトを作成して実機で動作を確認することができた。

Vitis の アクセラレーション・アプリケーションの動作には、BOOT.BIN の入れ替えが必要
”テンプレートで書いた畳み込みニューラルネットワークをRTLカーネルとしてVitisで実 装する3(出力をグローバル・バッファからホストにコピーできない)”で、Vitis アクセラレーション・プラットフォームで出力、つまり、左に曲がるか、直進するか、右に曲がるか(CNN の利用用途は白線走行です)の判定の output と左折、直進、右折の判定スコアの dot2[ ] の 2 個の出力値を出力しているが、それが 0 になってしまって反映されていないという問題があった。いろいろとやってみたところ、Vitis で生成した sd_card ディレクトリの BOOT.BIN を入れ替えてブートしないと値がおかしくなるようだ。

テンプレートで書いた畳み込み ニューラルネットワークをRTLカーネルとしてVitisで実装する3(Vivado HLS 編 3)
”テンプレートで書いた畳み込みニューラルネットワークをRTLカーネルとしてVitisで実 装する1(Vivado HLS 編 1)”に Vitis のRTL カーネルを作成するためにパラメータを変更できる形に書いた畳み込みニューラルネットワークをVivado HLS 2019.2 でIP にするためのソースコードとテストベンチコードを書いたが、任意精度固定データ型をそのまま int32_t にキャストしてしまったので、小数点以下の桁が無くなってしまった。それを修正するために、任意精度固定データ型の整数ビット長を 8 ビット延長して 256 倍することにした。
テンプレートで書いた畳み込み ニューラルネットワークをRTLカーネルとしてVitisで実装する4(Vivado HLS 編 4)
”テンプレートで書いた畳み込みニューラルネットワークをRTLカーネルとしてVitisで実 装する1(Vivado HLS 編 1)”に Vitis のRTL カーネルを作成するためにパラメータを変更できる形に書いた畳み込みニューラルネットワークをVivado HLS 2019.2 でIP にするためのソースコードとテストベンチコードを書いたが、任意精度固定データ型をそのまま int32_t にキャストしてしまったので、小数点以下の桁が無くなってしまった。それを修正するために、任意精度固定データ型の整数ビット長を 8 ビット延長して 256 倍することにした。ということで、前回は、ソースコードとテストベンチ・コードを貼った。今回は、ソースコードとテストベンチ・コードをVivado HLS で C シミュレーション、C コードの合成、Export RTL を行った。
テンプレートで書いた畳み込み ニューラルネットワークをRTLカーネルとしてVitisで実装する5(Vitis 編)
前回は、白線走行用畳み込みニューラルネットワークをVivado HLS 2019.2 で IP にした。今回は白線走行用畳み込みニューラルネットワークの xo ファイルを使用して Vitis 2019.2 でアプリケーション・プロジェクトを作成し、実機確認したところ、一応成功した。

Vitis のストリーミング接続について
今まで実装してきたAXI4 Master アクセスによるカーネルは基本的にメモリを介して他のカーネルと通信するので、メモリ帯域を消費する。1 個や 2 個のカーネルだったら良いかもしれないが、3 , 4 個と接続するとメモリ帯域が足りなくなってしまうだろう。そこで、カーネルをストリーミング接続するとメモリ帯域を消費しないで何個でもカーネルを接続できるはずだ。
Vitis のカーネル間のストリーミング接続について
現在まだ新横浜プリンスホテルに宿泊しているが、Vitis のカーネル間のストリーミング接続について、覚書を書いておく。

Vitis のカーネル間のストリーミング接続サンプル streaming_k2k_mm をやってみた1
Vitis でメモリベースのIP を並べているとメモリ帯域の逼迫が心配なので、どうしてもカーネル間をストリーミング接続したいということで、”Vitis のストリーミング接続について”で調べたが、その内の、”Streaming Data Transfers Between Kernels (K2K)”のサンプルの streaming_k2k_mm についてやってみよう。
Vitis のカーネル間のストリーミング接続サンプル streaming_k2k_mm をやってみた2
前回は、Vitis のサンプル・プロジェクトに入っている streaming_k2k_mm をビルドして、実機確認し、成功した。今回は、カーネル間のストーミング接続の設定ファイルを確認して、自分で新しいプロジェクトを作成して、やってみようと思う。
カーネル間のストーミング記述ファイルは、何も指定しないとVitis ビルド時に見つからなくてエラーになってしまった。
Vitis のカーネル間のストリーミング接続サンプル streaming_k2k_mm をやってみた3
前回は、カーネル間のストーミング接続の設定ファイルを確認して、自分で新しいプロジェクトを 作成して、やってみたが、カーネル間のストーミング接続ファイルがVitis に見つけられなくてエラーになってしまった。今回は、エラーの解消を図った。
ビルドが成功し、実機の動作も確認できた。

Vivado HLS 2019.2 で krnl_dma_read を作成する1(ソースコードの表示)
ストーミング接続用のhls::stream の定義は、hls::stream<ap_axiu<32,0,0,0> > にする必要がある。こうするとサイドチャネルの信号は last と keep , strb だけになる。この内の last を使用して、フレームの最後をマークしよう。
Vivado HLS 2019.2 で krnl_dma_read を作成する2(IP 化)
前回は、Vitis のカーネル間ストーミング接続をテストするために DMA Read カーネル ー ラプラシアン・フィルタ・カーネル ー DMA Write カーネルをストーミング接続してみようということで、最初にDMA Read を作ることにした。そして、ソースコードを貼った。今回は、それらのソースコードを使用して、Vivado HLS 2019.2 で C シミュレーション、C コードの合成、C/RTL 協調シミュレーション、Export RTL を行った。
Vivado HLS 2019.2 で krnl_dma_read を作成する3(DMA Read サイズを固定する)
”Vivado HLS 2019.2 で krnl_dma_write を作成する3”でDMA Write のサイズを固定したところ、劇的にリソース使用量が減少した。そうしたら、krnl_dma_read も同様ではないか?と思って、DMA Read サイズを固定したバージョンを作成してみることにした。

Vivado HLS 2019.2 で krnl_lap_filter を作成する1(ソースコードの表示)
Vitis のカーネル間ストーミング接続をテストするために DMA Read カーネル ー ラプラシアン・フィルタ・カーネル ー DMA Write カーネルをストーミング接続してみよう。
今回は、ラプラシアン・フィルタ・カーネル krnl_lap_filter を作成する。
Vivado HLS 2019.2 で krnl_lap_filter を作成する2(IP化)
前回は、ラプラシアン・フィルタ・カーネル krnl_lap_filter を作成するということで、ソースコードを貼った。今回は、Vivado HLS 2019.2 のプロジェクトを作成して、C シミュレーション、C コードの合成、C/RTL 協調シミュレーション、Export RTL を行っていこう。

Vivado HLS 2019.2 で krnl_dma_write を作成する1
Vitis のカーネル間ストーミング接続をテストするために DMA Read カーネル ー ラプラシアン・フィルタ・カーネル ー DMA Write カーネルをストーミング接続してみよう。
今回は、DMA Write カーネルを作成しよう。
Vivado HLS 2019.2 で krnl_dma_write を作成する2
Vitis のカーネル間ストーミング接続をテストするために DMA Read カーネル ー ラプラシアン・フィルタ・カーネル ー DMA Write カーネルをストーミング接続するために、前回は DMA Write カーネルを作成したのだが、リソースを消費すぎているのが分かった。今回は、リソース使用量を少なくするように努力してみよう。
Vivado HLS 2019.2 で krnl_dma_write を作成する3
Vitis のカーネル間ストーミング接続をテストするために DMA Read カーネル ー ラプラシアン・フィルタ・カーネル ー DMA Write カーネルをストーミング接続するためのDMA Write カーネルを作成したが、リソースを消費すぎていた。リソース消費を抑えようと for ループ内のPIPELINE 指示子を削除した。そうすると C コードの合成では、リソース使用量が減った様にレポートされたが、Export RTL したらリソース使用量が急激に増えてしまった。結局うまく行かなかった。その後の解析で、どうやら除算をしているようで、それがリソース使用量の大半を占めていることが分 かった。
考えてみれば、DMA 数を設定できるということは、バーストの数を数えて行く必要がある、ということで除算を使用しているのだと思う。(私ならば減算していくが。。。)そこで、予めDMA 数をコンパイラが数えられるように定数にすれば、コンパイラが静的に解析できるはずだ。今回は X_SIZE と Y_SIZE を定数として与えてみよう。

Vitis 2019.2 で自作カーネルを使用してストーミング接続を試す1
今まで作ってきた krnl_dma_read , krnl_lap_filter , krnl_dma_write をストーミング接続した Vitis 2019.2 プロジェクトを作成して、動作を確認することにした。プロジェクト名は streaming_lap_filter だ。
Vitis 2019.2 で streaming_lap_filter アプリケーション・プロジェクトを作成した。
Vitis 2019.2 で自作カーネルを使用してストーミング接続を試す2
前回は、今まで作ってきた krnl_dma_read , krnl_lap_filter , krnl_dma_write をストーミング接続した Vitis 2019.2 プロジェクトを作成して、動作を確認することにした、ということで、Vitis 2019.2 の streaming_lap_filter プロジェクトを作成した。今回は、ソースコードを入れていってプロジェクトを完成させた。ビルド成功した。
Vitis 2019.2 で自作カーネルを使用してストーミング接続を試す3
前回は、Vitis 2019.2 の streaming_lap_filter プロジェクトにソースコードを入れてプロジェクトを完成させたあとで、ビルドに成功した。今回は、Run Configuration を作成して、実機動作を行ったが、成功しなかった。
Vitis 2019.2 で自作カーネルを使用してストーミング接続を試す4(ChipScope で波形を確認する1)
前回は、Vitis 2019.2 の streaming_lap_filter プロジェクトの Run Configuration を作成して、実機動作を行ったが、成功しなかった。今回は、その原因を探るために、ChipScope を入れて波形を確認してみよう。
Vitis 2019.2 で自作カーネルを使用してストーミング接続を試す5(ChipScope で波形を確認する2)
前回は、Vitis 2019.2 の streaming_lap_filter プロジェクトの Run Configuration を作成して、実機動作を行ったが、成功しなかった原因を探るために、ChipScope を入れて波形を確認しようということで、--dk オプションを使用した ILA IP コアの挿入を行った。今回は引き続き、設定を行ってChipScope 波形を観察してみよう。
AXI4 Lite インターフェースを見てみると、dma_read と krnl_lap_filter は AXI4 Lite の Read トランザクションが見えるが、dma_write はRead トランザクションが見えない。
dma_write が起動していないんじゃないか?少なくともケアされていない疑惑が生じている。
なお、ひでみさんに起動できるカーネルは 2 個じゃないか?ということを聞いたので、カーネルを 2 個にして確かめてみよう。
Vitis 2019.2 で自作カーネルを使用してストーミング接続を試す6(AXI4 StreamにFIFOを追加)
前回は、設定を行ってChipScope 波形を観察した結果、dma_write カーネルが動作していないようだということが分かった。今回は、同時に動作できるカーネルが 2 個である場合は、途中に画像全部以上の FIFO があれば、最初の dma_read カーネルが終了し、dma_write カーネルが起動できて、つまり、全てのカーネルが動作するのではないか?という仮説に基づいて krnl_lap_filter カーネルに 4096 深度の FIFO を追加してみようということで追加してみたが動作しなかった。
Vitis 2019.2 で自作カーネルを使用してストーミング接続を試す7(krnl_lap_filter_dmaw.cpp)
前回は、同時に動作できるカーネルが 2 個である場合は、途中に画像全部以上の FIFO があれば、最初の dma_read カーネルが終了し、dma_write カーネルが起動できて、つまり、全てのカーネルが動作するのではないか?という仮説に基づいて krnl_lap_filter カーネルに 4096 深度の FIFO を追加したが、動作しなかった。今回は、カーネルを 2 個にするために krnl_lap_filter と dma_write カーネルを一緒にした krnl_lap_filter_dmaw を作成する。
Vitis 2019.2 で自作カーネルを使用してストーミング接続を試す8(streaming_lap_filter3 プロジェクト)
前回は、カーネルを 2 個にするために krnl_lap_filter と dma_write カーネルを一緒にした krnl_lap_filter_dmaw を作成し、Vivado HLS 2019.2 のプロジェクトを作成してC シミュレーション、C コードの合成、C/RTL 協調シミュレーションを行った。今回は、Vitis 2019.2 で krnl_filter_dmaw.cpp を使用した streaming_lap_filter3 プロジェクトを作成した。ホスト・アプリケーションソフトを作成して動作を確かめてみる。
Vitis 2019.2 で自作カーネルを使用してストーミング接続を試す9(streaming_lap_filter3 プロジェクト2)
前回は、Vitis 2019.2 で krnl_filter_dmaw.cpp を使用した streaming_lap_filter3 プロジェクトを作成した。ホスト・アプリケーションソフトの krnl_streaming_lap_filter_host3.cpp を貼った。今回は、カーネルのストリーミング接続の動作を確かめてみよう。
確かめてみたところ動作した。カーネルが 2 個だったら動作するようだ。
Vitis 2019.2 で自作カーネルを使用してストーミング接続を試す10(streaming_lap_filter3 のプロファイル)
前回は、カーネルのストリーミング接続の動作を実機で確かめたところ成功した。しかし、動作の レイテンシが遅かった。今回は、プロファイルを取得してみよう。なお、今回のプロファイルの設定は、Fixstars Tech Blog の”Zybo+VitisでSDSoC相当の高位合成やってみた”を参考にさせていただいている。

Vitis 2019.2 アプリケーション・プロジェクト ラプラシアン・フィルタAXI4-Streamバージョン5
”Vitis 2019.2 で自作カーネルを使用してストーミング接続を試す10(streaming_lap_filter3 のプロファイル)”で、カーネル間のストリーミング接続は、カーネルを起動するレイテンシがかかっていることが分かった。ここでは、2 個のカーネルを連続して起動していた。それでは、カーネルが 1 個の時はどうなのだろうか? 同じ、ラプラシアン・フィルタの実装で確かめてみよう。もうすでに、Vitis のプロジェクトは作ってあって、ブログも書いてある。
やはり、2 個のカーネルをカーネル間のストリーミング接続するよりも、ハードウェアで接続したほうが速い。

Vitis 2019.2 アプリケーション・プロジェクトでラプラシアン・フィルタAXI4-Streamバージョンのカーネルを複数インスタンス
今回は、Vitis 2019.2 アプリケーション・プロジェクトでラプラシアン・フィルタAXI4-Streamバージョンのカーネルを複数インスタンスしてみよう。


inserted by FC2 system