昨日、PYNQボードが手に入りました。

前回はMicroSD カードに書くイメージをダウンロードした。今回はイメージをMicroSD カードに書いて、PYNQボードでLinux を起動してみよう。

前回はLinux を起動して、起動メッセージや、Webページ、Samba の様子を確認した。今回は、PYNQボードで起動しているWebアプリケーションのJupyter Notebook をやってみた。

前回は、PYNQボードのJupyter Notebook を試してみた。今回は、PYNQボードのLinux を確認して、OpenCVをインストールしてみた。

Vivado のブロックデザインでPS の設定はどうやるのか？というのが疑問だったので、調べてみた。

Vivado のIP インテグレータでのPS の設定をすることができたので、今度はデバイス・ツリーが分かればLinux でVivado のプロジェクトに追加したIP をLinux でUIO として使うことができる。
今回は、PYNQボードのデバイス・ツリーを探ってみた。

前回はちょっとミスったが、PYNQのプロジェクトを生成することができた。今回はそのタイミ ングエラーを解析してみよう。

前回はタイミング・レポートを100個まで表示した。今回は、Report CDC を確認してみた。

前回は、Report CDC で異なるクロック・ドメイン間のデータのやり取りの状況を解析した。今回はその問題となるパスを確認して解決してみよう。

このところ実装しているVivado HLS のFASTX コーナー検出IP をPYNQ ボードにも実装してカメラ画像からリアルタイムにFASTX コーナー検出を行った。

前回、ブロックデザインが完成したので、今回は、ビットストリームまで生成して、SDKを立ち 上げてアプリケーションソフトを作り、PYNQボードでカメラ画像をリアルタイムにFASTX コーナー検出してみよう。

PYNQボードには、”PYNQボードでカメラ画像をリアルタイムにFASTX コーナー検出1”、”PYNQボードでカメラ画像をリアルタイムにFASTX コーナー検出2”で、PYNQボードに付けたカメラの画像にFASTX コーナー検出をリアルタイムで行うことができた。
でも、そろそろPYNQ祭りに向けて、もう少しPYNQボードに芸をさせたい。そこで、いつものラプラシアンフィルタIPと最近、assert() の例としてやってみたアンシャープ・マスクキング・フィルタを追加することにした。

前回は、アンシャープ・マスクキング・フィルタIP を生成した。今回はラプラシアンフィルタIP を生成する。

前回は、PYNQボード用の AXI4-Stream版のラプラシアンフィルタIP を作成した。今回は、AXI4-Stream版アンシャープ・マスクキング・フィルタIP と AXI4-Stream版のラプラシアンフィルタIP をPYNQボードのFASTX コーナー検出のVivado 2016.4 プロジェクトに追加する。

前回は、Vivado 2016.4 のブロックデザイン上で、FASTXコーナー検出IP にラプラシアンフィルタIP とアンシャープ・マスクキング・フィルタIP を追加した。今回はアプリケーションソフトを作成して、動作させてみよう。

前回は、SDK のベアメタル・アプリケーションソフトでPYNQボード用のFASTX コーナー検出とラプラシアンフィルタ、アンシャープ・マスクキング・フィルタをテストできた。今回は、Jupyter Notebook を使用してPython で開発している。

いろいろとJupyter Notebook でやってはいるが、まだカメラ画像が表示されない。ちなみに今使っているPYNQボードのMicro SDカードのイメージは 2017/02/10 以前のものだ。

昨日は、「FPGAエクストリーム・コンピューティング 番外編：PYNQ祭り」に参加して発表してきました。

XilinxのBNN-PYNQをやって見たいということで、やってみました。BNN- PYNQはBinarized Neural Network (BNN) on PYNQ だそうです。

前回は、BNN-PYNQをインストールした。今回は、jupyter notebook の bnn/Cifar10.ipynb をやってみた。

”Ubuntu16.04にVivado 2016.4をインストール”でVirtualBoxに新しいVirtualマシンを作って、Ubuntu 16.04 をインストールして、Vivado 2016.4 をインストールできたので、やっとBNN-PYNQのHardware design rebuilt がやれる環境が整った。それで、BNN-PYNQのHardware design rebuilt をやってみることにした。今回はcnv-pynq をやってみた。

前回は、BNN-PYNQの cnv-pynq をHardware design rebuilt したので、今回はもう1つの lfc-pynq をHardware design rebuilt してみよう。

BNN-PYNQが頻繁に変更されているので、PYNQボードのBNN-PYNQをアップグ レードした。

ikwzm さんの”FPGA+SoC+Linux+Device Tree Overlay+FPGA Manager(PYNQ-Z1対応)”を試してみようと思う。

前回は、FPGA-SoC-Linux をクローンした。今回は、Micro SDカードをフォーマットして、パーティションを切った。

前回は、Micro SDカードの準備を行った。今回は、そのMicro SDカードにファイルを書き込んで、PYNQに挿入してテストしてみよう。

前回は、Micro SDカードのパーティションに必要なファイルをコピーして、PYNQに挿入してDebian をブートした。そして、Linux ヘッダ/イメージパッケージとデバイスドライバ パッケージのインストールを行った。今回は、そのPYNQのDebian 環境を整備しよう。

ikwzm さんのFPGA Manager と デバイスツリー・オーバーレイを確かめてみるために、簡単な例としてPYNQボードのLED表示プロジェクトを作ることにした。

前回は、ikwzm さんのFPGA Manager と デバイスツリー・オーバーレイを確かめてみるために、簡単な例としてPYNQボードのLED表示プロジェクトを作ることにして、ブロックデザインを作って、論理合成を始め るところまでだった。今回は、論理合成、インプリメント、ビットストリームの生成を行って、SDKでアプリケーションソフトを作って、PYNQで確かめた。

前回は、ikwzm さんの配布しているDebian の環境整備を行った。今回は、 デバイスツリー・オーバーレイを確かめてみよう。

前回は、デバイスツリー・オーバーレイを試して、成功した。今回は、FPGAをコンフィギュ レーションする FPGA Manager を試してみた。

前回は、FPGA Manager を試して、ikwzm さんのおかげでビットファイルをダウンロードして、アプリケーションソフトを動作させることができた。今回は、デバイスツリー・オーバーレイとFPGA Manager を shell スクリプトにしてみようと思う。

前回は、デバイスツリー・オーバーレイとFPGA Manager を使いやすいようにShell スクリプトを作成した。今回は、2つのFPGA回路とデバイスツリーをLinux 起動しながら入れ替えてみようと思う。

前回は、新たなFPGA回路として、以前作ったFASTX コーナー検出、ラプラシアンフィルタ、アンシャープ・マスクキング・フィルタの回路をコンフィギュレーションし、デバイスツリー・オーバーレイを行った。今回は、その動作 をチェック（動作しなかったのだが）し、その後で、PYNQのLinux を起動しながら、GPIO でLED をテストする回路をコンフィギュレーションし、デバイスツリー・オーバーレイを行って、動作を確認する。

昨日のFASTX コーナー検出、ラプラシアンフィルタ、アンシャープ・マスクキング・フィルタの回路が動かないと書いたが、ikwzm さんがクロックはどうなっているかと聞いてくれて、それでハッと気が付いた。Zynq のクロックはPSから供給されていて、ビットファイルは関係ない。。。
ikzwm さんから、”Linux でユーザー空間から Zynq の PLクロック信号を制御するデバイスドライバ”を教えて頂いた。いつもありがとうございます。しかし、何でも作ってありますね。。。

「”FPGA+SoC+Linux+Device Tree Overlay+FPGA Manager(PYNQ-Z1対応)”を試してみる9（入れ替え2）」では、FASTX コーナー検出、ラプラシアンフィルタ、アンシャープ・マスクキング・フィルタの回路を使用して、カメラ画像を表示することができなかった。これは、PS から出力される fclk の出力周波数が設定されていないのが原因ではないか？というご指摘を ikwzm さんから頂いた。
そこで、「ikwzm さんの構築したPYNQ ボード用DebianでのPS出力クロックfclkの設定方法」で、デバイスツリー・オーバーレイを使用した。fclk の設定のやり方を学習したので、実際にFASTX コーナー検出、ラプラシアンフィルタ、アンシャープ・マスクキング・フィルタの回路に適用して試してみよう。

”Pmod Shield: Adapter Board for Uno R3 Standard to Pmod”が来ました。これは、PYNQやArty-Z7、Arty のArduino拡張コネクタに刺さって、Pmodコネクタを増設するボードです。

”TensorFlow + Kerasを使ってみた22（Linux版とWindows版のVivado HLSでの違い）”までで作ってきたMNISTのCNNをVivado に組み込んで実機で動作させてみようと思う。とりあえずは、従来のフレームワークに入れて、HLSストリーム版のCNN が実際にうまく行くかを確認したい。

”Kerasを使用したMNIST CNNで手書き文字認識1（以前のVivado プロジェクトをVivado 2017.4に変換）”のCNN IP を削除して、”DMA付きテンプレートを使用したMNISTのCNN4（Cコードの合成、Export RTL）”で作成したIP をAdd IP したのだが、Add IPのリストに出てこなかった。そこで、Windows版のVivado HLS 2018.2 で再度IP化して、Vivado 2018.2 のVivado プロジェクトにAdd IP した。

前回は、”Kerasを使用したMNIST CNNで手書き文字認識1（以前のVivado プロジェクトをVivado 2017.4に変換）”のCNN IP を削除して、Windows版のVivado HLS 2018.2 で mnist_conv_nn3_hlss_ko_dma プロジェクトの all_layers IP を再度作成してAdd IP した。今回は PYNQ_MNIST_CNN3_182 フォルダVivado 2018.2 プロジェクトの論理合成、インプリメンテーション、ビットストリームの生成を行い、SDK でアプリケーションソフトの mnist_conv_soft_test.c を今回のプロジェクトに合うように変更した。

前回は、 PYNQ_MNIST_CNN3_182 フォルダVivado 2018.2 プロジェクトの論理合成、インプリメンテーション、ビットストリームの生成を行い、SDK でアプリケーションソフトの mnist_conv_soft_test.c を今回のプロジェクトに合うように変更した。今回は、SDK でPYNQボードをコンフィギュレーションし、アプリケーションソフトの mnist_conv_soft_test.elf を起動してPYNQボードで動作を確認する。

前回は、SDK でPYNQボードをコンフィギュレーションし、アプリケーションソフトの mnist_conv_soft_test.elf を起動してPYNQボードで動作を確認した。今回はアプリケーションソフトを動作させて、自分で書いた手書き数字を認識させてみよう。

前回は、アプリケーションソフトを動作させて、自分で書いた手書き数字を認識させたが、1, 4, 6, 7 が誤認識してしまった。以前の 10 個の特徴マップのCNN では、正常に認識しているので、量子化の精度、および飽和演算に問題があるのか？はたまた過学習になっているのかを検証することになった。今回は、考えられる 2 つの原因の内の量子化の精度、および飽和演算について検証を行った。

前回は、考えられる 2 つの原因の内の量子化の精度、および飽和演算について検証を行ったが、浮動小数点数による特徴マップが3個のMNISTのCNN の演算でも手書き数字を誤認識していたので、量子化の精度、および飽和演算の問題ではないという結論になった。今回は、過学習が手書き数字の誤認識に影響しているのか？を 確かめるために、Epoch 数を変更して再学習を行った。

前回は、過学習が手書き数字の誤認識に影響しているのか？を確かめるために、Epoch 数を変更して再学習を行って、PYNQボードに実装して手書き数字の認識を確認した。今回は、その過程でVivado HLS で行った、精度の確認を書けなかったので、それを書いておく。

前回は、MNIST のCNN の特徴マップが３個の時に過学習が手書き数字の誤認識に影響しているのか？を確かめるために、Epoch 数を変更して再学習を行った時の重みやバイアスをVivado HLS のC ヘッダ・ファイルとして代入した時の結果を示した。今回は、特徴マップが3個の時には、あまり精度の向上が見られなかったため、MNIST のCNN の特徴マップが10個の場合を再学習してVivado HLS で精度を確認してみようと思う。

前回は、MNIST のCNN の特徴マップが10個の場合を再学習してVivado HLS で精度を確認した。今回は、Vivado HLSで精度を確認できたので、Vivado HLS 2018.2 で mnist_conv_nn10_hlss_ko_dma プロジェクトを作成して、IP 化を行い、PYNQ_MNIST_CNN10_182 フォルダのVivado 2018.2 プロジェクトを作成し、論理合成、インプリメンテーション、ビットストリームの生成を行った。

前回は、Vivado HLS 2018.2 で mnist_conv_nn10_hlss_ko_dma プロジェクトを作成して、IP 化を行い、PYNQ_MNIST_CNN10_182 フォルダのVivado 2018.2 プロジェクトを作成し、論理合成、インプリメンテーション、ビットストリームの生成を行った。今回は、SDK を起動して、PYNQボードをコンフィギュレーションし、アプリケーションソフトを起動して、手書き数字の認識を行った。

Kria-PYNQ をやってみようと思う。

前回は、KV260 用 Ubuntu 20.04 LTS イメージをダウンロードして、MicroSD カードに書き込んだ。今回は、KV260 に MicroSD カードを挿入して、Ubuntu 20.04 LTS をブートして、設定を行った。

前回は、KV260 に MicroSD カードを挿入して、Ubuntu 20.04 LTS をブートして、設定を行い、X アプリケーションをホスト・パソコンに表示することができた。今回は、Kria-PYNQ を git clone してインストールしようとしたがライブラリの依存関係のエラーがでてしまった。そこで、もう一度 KV260 の MicroSD カードを作り直して、再度挑戦したら Kria-PYNQ をインストールすることができた。Jupyter Notebook を表示した。

前回は、Kria-PYNQ を git clone してインストールしようとしたがライブラリの依存関係のエラーがでてしまった。そこで、もう一度 KV260 の MicroSD カードを作り直して、再度挑戦したら Kria-PYNQ をインストールすることができた。Jupyter Notebook を表示した。今回は、Jupyter Notebook の kv260/video ディレクトリの display_port_introduction.ipynb と mipi_to_displayport.ipynb をやってみよう。

Jupyter Notebook の kv260/video ディレクトリの display_port_introduction.ipynb と mipi_to_displayport.ipynb をやってみたのだが、Pcam5C カメラの画像はキャプチャできたが、DisplayPort に出力できなかった。今回は、前回失敗した時の解像度は 1280 x 720 ピクセルだったが、640 x 480 ピクセルに設定してやり直してみたところ DisplayPort に出力することができた。

前回やったのは、Jupyter Notebook の kv260/video ディレクトリの display_port_introduction.ipynb と mipi_to_displayport.ipynb をやった時に、失敗した時の解像度は 1280 x 720 ピクセルだったが、640 x 480 ピクセルに設定してやり直してみたところ DisplayPort に出力することができた。今回は、opencv_face_detect_webcam.ipynb と opencv_filters_webcam.ipynb をやってみよう。

前回は、opencv_face_detect_webcam.ipynb と opencv_filters_webcam.ipynb をやってみた。今回は、opencv_filters_webcam.ipynb をちょっと改造して、ジュピター・ノートブックに元画像を表示した。ラプラシアン・フィルタの画像を追加した。ソーベル・フィルタを追加した。

Kria-PYNQ の pynq-hellowrld に resizer_pl.ipynb ファイルがある。
これは、KV260 の PL に実装した Resize IP を PYNQ の Python から制御するソフトウェアだ。
Resize IP の代わりに Sobel IP などの自分で作成した IP を実装して PYNQ で動作させてみたい。

Sobel IP などの自分で作成した IP を実装して Kria-PYNQ で動作させてみたいということで、前回は、PYNQ で使用される Vivado の生成ファイルを調べた。今回は、制御用 Python コードの書き方を調べてみた。

”PYNQ を使って Python で手軽に FPGA を活用 (5)”をやってみるために、AXI4-Stream インターフェースの 2 乗する IP 、DMA_pow2_axis を作成しよう。

”PYNQ を使って Python で手軽に FPGA を活用 (5)”を KV260 でやってみるということで、前回は、AXI4-Stream 版の 2 乗 IP の DMA_pow2_axis を Vitis HLS で作成した。今回は、DMA_pow2_axis IP を使用して、Vivado 2021.2 の DMA_pow2_axis_i プロジェクトを作成した。

”PYNQ を使って Python で手軽に FPGA を活用 (5)”を KV260 でやってみるということで、前回は、DMA_pow2_axis IP を使用して、Vivado 2021.2 の DMA_pow2_axis_i プロジェクトを作成し、論理合成、インプリメンテーション、ビットストリームの生成を行って、成功した。今回は、できあがったビットファイルと hwh ファイルを KV260 のアップロードし、Jupyter Notebook のコードを用意して KV260 で実行した。結果は実行することができなかった。

”PYNQ を使って Python で手軽に FPGA を活用 (5)”を KV260 でやってみるということで、前回は、できあがったビットファイルと hwh ファイルを KV260 のアップロードし、Jupyter Notebook のコードを用意して KV260 で実行した。結果は実行することができなかった。今回は、その原因を探るためにブロック・デザインに System ILA を入れて、波形を見てみよう。

前回、”PYNQ を使って Python で手軽に FPGA を活用 (5)”をやってみるために、AXI4-Stream インターフェースの 2 乗する IP 、DMA_pow2_axis を作成したが、””PYNQ を使って Python で手軽に FPGA を活用 (5)”をやってみる3（System ILA を使用したデバック）”に示すように、AXI4-Stream インターフェース出力で tlast を出力する必要があることが分かったので、ソースコードに tlast を追加しようと思う。

前回は、その原因を探るためにブロック・デザインに System ILA を入れて、波形を観察したところ、S2MM の AXI4-Stream の最後のデータ送出時に TLAST が 1 になっていなかった。そこで、”Vitis HLS 2021.2 で KV260 用の DMA_pow2_axis IP を作成する2”で、TLAST と TUSER を処理した DMA2_pow2 IP を作成した。今回は、この DMA_pow2 IP を使用して、再度 Jupyter Notebook で DMA pow2 を動作させてみたところ、まだ DMA が終了しなかった。

前回は、DMA_pow2 IP を使用して、再度 Jupyter Notebook で DMA pow2 を動作させてみたところ、まだ S2MM の DMA Write が終了しなかった。具体的には、10 個のデータを DMA Write するはずが、バースト長が 32 個になっていた。今回は、DMA の個数を S2MM の AXI4 Master Write のデータ転送の最後に WLAST が 1 にアサートするまで、データの個数を増やしてみた。33 個のデータで WLAST が 1 になったが、Jupyter Notebook のコード実行はやはり終了しなかった。

今までは、”PYNQ を使って Python で手軽に FPGA を活用 (5)”の”PL から PS に接続されたメモリを読み書きする”の stream_double.v を Vitis HLS 2021.2 で作った DMA_pow2_axis に置き換えて KV260 の PYNQ で実行して失敗していた。今回は、”PYNQ を使って Python で手軽に FPGA を活用 (5)”の”PL から PS に接続されたメモリを読み書きする”をそのままやってみる。つまり、DMA_pow2_axis の代わりに stream_double.v を使って、やってみよう。

””PYNQ を使って Python で手軽に FPGA を活用 (5)”を手順通りにやってみる”で、Vitis HLS 2021.2 で作成した DMA_pow2_axis IP を元々の stream_double.v に変更したら、Jupyter Notebook で動作した。今回は、Xilinx 社の AXI DMA IP を使用せずに、Vitis HLS で作成した AXI4 Master インターフェースの DMA_pow2 IP だとJupyter Notebook で動作するのか？を確認する。今回は、Vitis HLS 2021.2 で DMA_pow2 IP を作成する。

前回は、Vitis HLS 2021.2 で DMA_pow2 IP を作成した。今回は、 Vivado 2021.2 で DMA_pow2_test32 プロジェクトを作成する。 DMA_pow2 IP を使用して DMA_pow2_test32 ブロック・デザインを作成し、論理合成、インプリメンテーション、ビットストリームの生成を行って、ビットファイルと hwh ファイルを生成する。

前回は、Vivado 2021.2 で DMA_pow2_test32 プロジェクトを作成する。 DMA_pow2 IP を使用して DMA_pow2_test32 ブロック・デザインを作成し、論理合成、インプリメンテーション、ビットストリームの生成を行って、ビットファイルと hwh ファイルを生成した。今回は、Jupyter Notebook にビットファイルと hwh ファイルをアップロードして、動作確認を行って成功した。また、System ILA を使って、波形を観察した。

今まで、TKEEP と TSTRB は”Vivado Design Suite AXI リファレンス ガイド UG1037 (v3.0) 2015 年 6 月 24 日”の 148 ページの”AXI4‐Stream 信号のま とめ”の”表 A-7”によるとオプションで Vitis HLS で IP コアを作成する時も C コードに処理を書かなかったのですが、特に DMA に入力する AXI4-Stream の TKEEP の処理については、入力をそのまま出力に返すか、オール 1 にしないと問題が起こる様だ。

”AXI4-Stream におけるサイド・チャネル信号 TKEEP と TSTRB の扱いについて”を踏まえて、もう一度 AXI4-Stream 信号についてまとめておきたい。前回 AXI4-Stream について、まとめた資料は”AXI4-Stream のお勉強”

TKEEP と TSTRB は、入力された信号を出力するか、オール 1 にする必要がありそうだということで、それを踏まえて、再度 axi_dma と DMA_pow2_axis を Kria-PYNQ で動作させてみようと思う。

TKEEP と TSTRB は、入力された信号を出力するか、オール 1 にする必要がありそうだということで、それを踏まえて、再度 axi_dma と DMA_pow2_axis を Kria-PYNQ で動作させてみようとうことで、前回は、TKEEP, TSTRB の処理を追加して、DMA_pow2_axis IP を再合成し、IP にした。今回は、その再合成された DMA_pow2_axis IP を使用して、Vivado 2021.2 の DMA_pow2_axis_i プロジェクトを再度、論理合成、インプリメンテーション、ビットストリームの生成を行って、ビットファイルと hwh ファイルを生成する。

TKEEP と TSTRB は、入力された信号を出力するか、オール 1 にする必要がありそうだ。それを踏まえて、再度 axi_dma と DMA_pow2_axis を Kria-PYNQ で動作させてみようということで、前回は、DMA_pow2_axis IP を使用して、Vivado 2021.2 の DMA_pow2_axis_i プロジェクトを再度、論理合成、インプリメンテーション、ビットストリームの生成を行って、ビットファイルと hwh ファイルを生成した。今回は、Jupyter Notebook で動作を確認し、ILA ダッシュボードで波形を確認する。
動作を確認できた。

”自作した Vivado プロジェクトの DMA_pow2_test を PYNQ で実行する2（制御用 Python コードの書き方を調べる）”で引用した pynq-helloworld/resizer_pl.ipynb ファイルだが、このフレーム・ワークを自分で使用しようとした時に 32 ビット・フィールドの内の R, G, B の割当が分からない？ので、Vitis HLS 2021.2 を使って、確かめてみることにした。

前回は、PYNQ で使用するためのソーベル・フィルタを Vitis HLS 2021.2 で作成するためのコードを貼って、sobel_axis_RGB24 プロジェクトを作成した。今回は、C シミュレーション、C コードの合成、C/RTL 協調シミュレーション、Export RTL 、Implementation を行った。

”RGB 24 ビット・データ入出力対応のソーベル・フィルタを Vitis HLS 2021.1 で作成する1”
”RGB 24 ビット・データ入出力対応のソーベル・フィルタを Vitis HLS 2021.1 で作成する2”
で作成した RGB 24 ビット・データ入出力対応のソーベル・フィルタ IP を使用して、Vivado 2021.2 で img_filtプロジェクトを作成し、img_filt ブロック・デザインを作成した。そして、論理合成、インプリメンテーション、ビットストリームの生成を行って、ビットファイルと hwh ファイルを作成した。

前回は、RGB 24 ビット・データ入出力対応のソーベル・フィルタ IP を使用して、Vivado 2021.2 で img_filtプロジェクトを作成し、img_filt ブロック・デザインを作成した。そして、論理合成、インプリメンテーション、ビットストリームの生成を行って、ビットファイルと hwh ファイルを作成した。今回は、ビットファイルと hwh ファイルを KV260 の Jupyter Notebook にアップロードし、sobel.ipynb を作成して、動作を確認したが、DMA buffer サイズが足りないというエラーになった。

前回は、ビットファイルと hwh ファイルを KV260 の Jupyter Notebook にアップロードし、sobel.ipynb を作成して、動作を確認したが、DMA buffer サイズが足りないというエラーになった。今回は、axi_dma_0 の Width of Buffer Length Register が 14 ビットで足りないのじゃないか？という ikwzm さんのツィートでのご指摘があったので、26 ビットに変更して、Vivado プロジェクトで論理合成、インプリメンテーション、ビットストリームの生成を行って、Jupyter Notebook にアップロードして確かめたが、今度は、DMA が終了しなかった。更に、sobel_axis_RGB24 IP の TKEEP, TSTRB をオール 1 にしていないバグも修正したが、やはり、DMA が終了しなかった。

前回は、axi_dma_0 の Width of Buffer Length Register が 14 ビットで足りないのじゃないか？という ikwzm さんのツィートでのご指摘があったので、26 ビットに変更して、Vivado プロジェクトで論理合成、インプリメンテーション、ビットストリームの生成を行って、Jupyter Notebook にアップロードして確かめたが、今度は、DMA が終了しなかった。更に、sobel_axis_RGB24 IP の TKEEP, TSTRB をオール 1 にしていないバグも修正したが、やはり、DMA が終了しなかった。今回は、Vivado のブロック・デザインに System_ILA を実装して、ILA ダッシュボードで波形を確認してみよう。
ここまでやってみて、気がついたことがある。
ソーベル・フィルタ IP は、AXI VDMA の仕様で作ってあって、AXI DMA の仕様じゃなかった。。。
ソーベル・フィルタ IP は、AXI DMA の仕様にする必要があると思う。
TUSER は使わないでスタートして、データの一番最後だけ TLAST を 1 にする必要があるんじゃないだろうか？

Xilinx 社の axi vdma などの画像用仕様では、画像フレームの最初のデータで AXI4-Stream の tuser を 1 にして、その後は 0 にする。画像の行の最後のデータで tlast を 1 にするという規則がある。

”KV260 の PYNQ で自作のソーベル・フィルタを動作させる4”で sobel_axis_RGB24 IP が動作しなかったので、見直した所、”Xilinx の axi_dma IP を画像用に使用するための方法”に示すように、axi_vdma 用と axi_dma 用に動作を分けることにした。改めて、ソースコードとテストベンチを示す。

前回は、axi_vdma 用と axi_dma 用に動作を分けた sobel_axis_RGB24 のソースコードとテストベンチを貼った。今回は、sobel_axis_RGB24 の C シミュレーション、C コードの合成、C/RTL 協調シミュレーション、Export RTL、Implementation を行った。

”RGB 24 ビット・データ入出力対応のソーベル・フィルタを Vitis HLS 2021.1 で作成する4”で、Vitis HLS 2021.2 で sobel_axis_RGB24 の C シミュレーション、C コードの合成、C/RTL 協調シミュレーション、Export RTL、Implementation を行った。今回は、”KV260 の PYNQ で自作のソーベル・フィルタを動作させる1”で作成した img_filt ブロック・デザインの sobel_axis_RGB24 IP を入れ替えて、論理合成、インプリメンテーション、ビットストリームの生成を行って、ビット・ファイルと hwh ファイルを生成した。それらのファイルを Jupyter Notebook にアップロードして、確かめた所、ソーベル・フィルタが動作した。完成だ。

前回は、”KV260 の PYNQ で自作のソーベル・フィルタを動作させる1”で作成した img_filt ブロック・デザインの sobel_axis_RGB24 IP を入れ替えて、論理合成、インプリメンテーション、ビットストリームの生成を行って、ビット・ファイルと hwh ファイルを生成した。それらのファイルを Jupyter Notebook にアップロードして、確かめた所、ソーベル・フィルタが動作した。今回は、ソーベル・フィルタは動作したが、せっかく System ILA を入れてあるので、波形を確認してみよう。

今まで、ソーベル・フィルタを KV260 の PYNQ で動作させてきたが、メディアン・フィルタも KV260 の PYNQ で動作させてみよう。とりあえず、RGB 24 ビット・データ入出力対応のメディアン・フィルタを Vitis HLS 2021.2 で作成することにした。今回は、RGB 24 ビット・データ入出力対応のメディアン・フィルタ median_axis_RGB24 のソースコードとテストベンチ・コードを貼って、Vitis HLS 2021.2 で作成した median_axis_RGB24 プロジェクトを示す。

前回は、RGB 24 ビット・データ入出力対応のメディアン・フィルタ median_axis_RGB24 のソースコードとテストベンチ・コードを貼って、Vitis HLS 2021.2 で作成した median_axis_RGB24 プロジェクトを示した。今回は、RGB 24 ビット・データ入出力対応のメディアン・フィルタ median_axis_RGB24 の C シミュレーション、C コードの合成、C/RTL 協調シミュレーション、Export RTL、Implementation を行った。

”KV260 の PYNQ で自作のソーベル・フィルタを動作させる5”のブロック・デザインに”RGB 24 ビット・データ入出力対応のメディアン・フィルタを Vitis HLS 2021.2 で作成する2”で作成した median_axis_RGB24 IP を追加して、論理合成、インプリメンテーション、ビットストリームの生成を行った。

前回は、”KV260 の PYNQ で自作のソーベル・フィルタを動作させる5”のブロック・デザインに”RGB 24 ビット・データ入出力対応のメディアン・フィルタを Vitis HLS 2021.2 で作成する2”で作成した median_axis_RGB24 IP を追加して、論理合成、インプリメンテーション、ビットストリームの生成を行った。今回は、生成されたビット・ファイルと hwh ファイルを KV260 上の Jupyter Notebook にアップロードし、img_filt.ipynb ファイルを作成して、動作を確認したところ動作した。

ZYBO Z7 用の PYNQ を見つけたのでやってみようと思う。

ZYBO Z7 用の PYNQ が”Pynq 2.7 for Zybo-Z7”にあったということで、前回は、Zybo-Z7-2.7.0.img を MicroSD カードに書き込んだ。今回は、その MicroSD カードを ZYBO Z7-20 に挿入して、PYNQ Linux を起動し、環境を整備する。更に Jupyter Notebook を起動する。

前回は、PYNQ イメージを書き込んだ MicroSD カードを ZYBO Z7-20 に挿入して、PYNQ Linux を起動し、環境を整備する。更に Jupyter Notebook を起動することができた。今回は、 Jupyter Notebook が動作するかどうか？ base/GPIOs_test.ipynb を動作させてみよう。

”ZYBO Z7-20 で PYNQ を使用する3”の続き。そして、”RGB 24 ビット・データ入出力対応のソーベル・フィルタを Vitis HLS 2022.1 で作成する2”で作成した sobel_axis_RGB24 IP を使用する。
今回は、Vivado 2022.1 で ZYBO Z7-20 用の img_filt プロジェクトを作成し、前回作成した sobel_axis_RGB24 IP を使用して、ブロック・デザインを作成して、論理合成、インプリメンテーション、ビットストリームの生成を行った。

前回は、Vivado 2022.1 で ZYBO Z7-20 用の img_filt プロジェクトを作成し、前回作成した sobel_axis_RGB24 IP を使用して、ブロック・デザインを作成して、論理合成、インプリメンテーション、ビットストリームの生成を行って成功した。今回は、前回作成された bit ファイルと hwh ファイル、そして画像ファイルを ZYBO Z7-20 の PYNQ Linux にアップロードする。そして、Jupyter Notebook で sobel.ipynb を作成して実行した。結果としてソーベル・フィルタを動作させることができた。

今まで作ってきた IP を使用して、Vivado 2022.1 を使用して ZYBO Z7-20 用のカメラ画像表示システムを作ろうと思う。
今まで作ってきた IP と Digilent/vivado-library の rgb2dvi IP を使用して、Vivado 2022.1 で cam_disp プロジェクトを作成する。

今まで作ってきた IP を使用して、Vivado 2022.1 を使用して ZYBO Z7-20 用のカメラ画像表示システムを作ろうと思うということで、前回は、Vivado 2022.1 で cam_disp プロジェクトを作成し、論理合成、インプリメンテーション、ビットストリームの生成を行って成功した。今回は、ハードウェアをエクスポートして、Vitis 2022.1 でプラットフォームとアプリケーション・プロジェクトの生成を行った。

前回は、ハードウェアをエクスポートして、Vitis 2022.1 でプラットフォームとアプリケーション・プロジェクトの生成を行った。今回は、アプリケーション・ソフトウェアを作成し、ビルドしたら elf ファイルができた。ZYBO Z7-20 で実機確認した見たところ、カメラ画像が表示されなかった。

前回は、アプリケーション・ソフトウェアを作成し、ビルドしたら elf ファイルができた。ZYBO Z7-20 で実機確認した見たところ、カメラ画像が表示されなかった。今回は、以前動作していたはずの Vivado プロジェクトを 2022.1 上で再現することにした。Vivado 2021.1 のプロジェクトを DFX の変更をもとに戻して Vivado 2022.1 に変換し、論理合成、インプリメンテーション、ビットストリームの生成を行って成功した。

前回は、以前動作していたはずの Vivado プロジェクトを 2022.1 上で再現することにした。Vivado 2021.1 のプロジェクトを DFX の変更をもとに戻して Vivado 2022.1 に変換し、論理合成、インプリメンテーション、ビットストリームの生成を行って成功した。今回は、ハードウェアをエクスポートし、Vitis 2022.1 を起動して、アプリケーション・ソフトウェアをビルドして ZYBO Z7-20 で実機確認したところ、カメラ画像の表示に成功した。

前回は、ハードウェアをエクスポートし、Vitis 2022.1 を起動して、アプリケーション・ソフトウェアをビルドして ZYBO Z7-20 で実機確認したところ、カメラ画像の表示に成功した。今回は、以前のプロジェクトでカメラ画像の表示に成功するということは、今回作った IP のいずれかがおかしいのだろう？ということで、cam_disp プロジェクトで IP を交換してみた所、bitmap_disp_cont_axis IP を交換したらカメラ画像が表示された。

前回は、以前のプロジェクトでカメラ画像の表示に成功するということは、今回作った IP のいずれかがおかしいのだろう？ということで、cam_disp プロジェクトで IP を交換してみた所、bitmap_disp_cont_axis IP を交換したらカメラ画像が表示された。しかし、フレームバッファをシングル・バッファにすれば正常に表示できたが、トリプル・バッファにすると画像が乱れた。今回は、トリ プル・バッファにした時も正常に画像を表示できるようにバグをフィックスした。

”ZYBO Z7-20 用カメラ画像表示システムの作成7”で完成したビットストリームを PYNQ で動作させてみよう。

”ZYBO Z7-20 用カメラ画像表示システムの作成7”で完成したビットストリームを PYNQ で動作させてみようということで、前回は、ZYBO Z7-20 の PYNQ を起動して、ノートブックを新規作成し、Python コードを書いて実行してみたが、途中で Linux カーネルが落ちてしまった。今回は、原因を探るため、System ILA を入れて、まずは、動作時の動作を見るため、ZYBO Z7-20 を JTAG モードで起動して、ベアメタル・アプリケーションを使用して、カメラ画像表示時の波形を見ておこう。

前回は、途中で Linux カーネルが落ちた原因を探るため、System ILA を入れて、まずは、動作時の動作を見るため、ZYBO Z7-20 を JTAG モードで起動して、ベアメタル・アプリケーションを使用して、カメラ画像表示時の波形を見た。今回は、そのデバッグを行って、vflip_dma_write IP の設定がおかしいことに気付いた。vflip_dma_write IP の設定を修正したら、カメラ画像が表示できた。

”ZYBO Z7-20 用カメラ画像表示システムを PYNQ で動作させる3”で ZYBO Z7-20 の PYNQ 上でカメラ画像を表示することができた。今度は、その回路にソーベル・フィルタを追加して、エッジをリアルタイムに表示させてみよう。

ZYBO Z7-20 の PYNQ 上でカメラ画像を表示することができたので、ソーベル・フィルタを追加して、エッジをリアルタイムに表示させてみようということで、前回は、ソーベル・フィルタ IP をブロック・デザインに追加し、論理合成、インプリメンテーション、ビットストリームの生成を行って、成功した。今回は、ハードウェアをエクスポートし、Vitis でアプリケーション・ソフトウェアを修正して、ベアメタル・アプリケーションとして、ソーベル・フィルタを動作させた。

前回は、ハードウェアをエクスポートし、Vitis でアプリケーション・ソフトウェアを修正して、ベアメタル・アプリケーションとして、ソーベル・フィルタを動作させた。今回は、ソーベル・フィルタを PYNQ 上で動作させることができた。

”axis2DMA IP の作成1”と”axis2DMA IP の作成2”で作成した axis2DMA IP を”PYNQ で動作する ZYBO Z7-20 用カメラ画像表示システムにソーベル・フィルタを追加する1”のブロック・デザインに追加して、Jupyter Notebook にカメラ画像を表示しよう。

ZYBO Z7-20 の PYNQ 2.7 に OpenCV 3.4.16 をインストールしてみよう。
make を行ったが、まる 1 日経っても 80 % から進んでいない。。。これはどれだけ日にちを掛けてもダメなようだ。

ZYBO Z7-20 の PYNQ 2.7 に OpenCV 3.4.16 をインストールしてみようということで、前回は、make の 80 % まで make できたがそれ以上は難しいようだった。今回は、cmake のオプションを変更して、ビルドの負荷を軽くして make して見たところ成功した。

Jupyter Notebook にカメラ画像を表示しようということで、前回は、cam_disp_bd ブロック・デザインに axis2DMA IP を追加した。今回は、前回作成したビットストリームと hwh ファイルを ZYBO Z7-20 の PYNQ LInux 上にアップロードして、Jupyter Notebook を起動して動作を確認したところ、Jupyter Notebook に表示されたカメラ画像が真っ黒だった。axis2DMA IP に AXI4-Stream データが渡っていないのだろうか？

前回は、ビットストリームと hwh ファイルを ZYBO Z7-20 の PYNQ LInux 上にアップロードして、Jupyter Notebook を起動して動作を確認したところ、Jupyter Notebook に表示されたカメラ画像が真っ黒だった。今回は、原因を追求するために System ILA を入れて、波形を確認したが、axis2DMA IP の DMA Write が出ていなかった。

前回は、Jupyter Notebook に表示されたカメラ画像が真っ黒だった原因を追求するために System ILA を入れて、波形を確認したが、axis2DMA IP の DMA Write が出ていなかった。今回は、メモリ帯域の負荷が増えるけど、DMA2axis_3buf IP と sobel_axis_RGB24 IP をもう 1 個ずつ実装した。

前回は、メモリ帯域の負荷が増えるけど、DMA2axis_3buf IP と sobel_axis_RGB24 IP をもう 1 個ずつ実装して、論理合成、インプリメンテーション、ビットストリームの生成を行った。今回は、Jupyter Notebook で動作の確認を行ったが、結局動作しなかった。ブロック・デザインを再検討した結果、AXI4-Stream Data Width Converter の AXI4-Stream 入出力に TUSER が無かったことに気がついた。これが原因だと思う。

前回は、Jupyter Notebook で動作の確認を行ったが、結局動作しなかった。ブロック・デザインを再検討した結果、AXI4-Stream Data Width Converter の AXI4-Stream 入出力に TUSER が無かったことに気がついた。今回は、axis2DMA4dwc IP を作成したので、axis2DMA IP を axis2DMA4dwc IP に交換した。Jupyter Notebook で実行してみたが途中で PYNQ が落ちてしまったようだ。

前回は、axis2DMA4dwc IP を作成したので、axis2DMA IP を axis2DMA4dwc IP に交換した。Jupyter Notebook で実行してみたが途中で PYNQ が落ちてしまったようだ。今回は、デバッグをしたところ、axis2DMA4dwc IP のアドレスが 64 ビットアドレスだったため、AXI4 Master のアドレスの上 32 ビットだけアドレスを書き込んでいたので、DMA でアドレスが 0 番地になっていたのがバグの原因だった。

前回は、デバッグをしたところ、axis2DMA4dwc IP のアドレスが 64 ビットアドレスだったため、AXI4 Master のアドレスの上 32 ビットだけアドレスを書き込んでいたので、DMA でアドレスが 0 番地になっていたのがバグの原因だった。今回は、axis2DMA4dwc IP のアドレスを 32 ビット・アドレスに変更し、Vivado で論理合成、インプリメンテーション、ビットストリームの生成を行った。その後 Jupyter Notebook で動作を確認したところ、Jupyter Notebook に画像を表示できたが、色が違っていた。

前回は、axis2DMA4dwc IP のアドレスを 32 ビット・アドレスに変更し、Vivado で論理合成、インプリメンテーション、ビットストリームの生成を行った。その後 Jupyter Notebook で動作を確認したところ、Jupyter Notebook に画像を表示できたが、色が違っていた。今回は、色の違いを修正するために、Red と Blue を入れ替えたところ、正常な色になった。

前回は、色の違いを修正するために、Red と Blue を入れ替えたところ、正常な色になった。今回は、1 つやるのを忘れていたことがあった。それは、カメラ画像をファイルにすることだ。結論を言うとカメラ画像を JPEG ファイルにすることができた。

PYNQ での割り込みを学習するために、Adam Taylor さんの”MicroZed Chronicles: Memory Scrubbing”を ZYBO Z7-20 の PYNQ でやってみることにした。今回は、Vivado 2022.1 で pynq_int プロジェクトを作成してブロック・デザインを作成し、論理合成、インプリメンテーション、ビットストリームの生成を行った。

PYNQ での割り込みを学習するために、Adam Taylor さんの”MicroZed Chronicles: Memory Scrubbing”を ZYBO Z7-20 の PYNQ でやってみることにしたということで、前回は、Vivado 2022.1 で pynq_int プロジェクトを作成してブロック・デザインを作成し、論理合成、インプリメンテーション、ビットストリームの生成を行った。今回は、ZYBO Z7-20 上の PYNQ Linux にビットストリームと hwh ファイルをアップロードし、pynq_int.ipynb ファイルを生成して、割り込み動作を確認した。

自分で作った IP を使用して画像を表示しているが、それを Xilinx 社の IP を使用して画像を表示してみたい。

具体的には bitmap_disp_cont_axis IP を AXI4-Stream to Video Out(v_axi4s_vid_out) IP と Video TIming Controller (v_tc) IP で置き換えたい。

自分で作った IP を使用して画像を表示しているが、それを Xilinx 社の IP を使用して画像を表示してみたいということで、前回は bitmap_disp_cont_axis IP を AXI4-Stream to Video Out(v_axi4s_vid_out) IP と Video TIming Controller (v_tc) IP で置き換えた。今回は、実際に v_axi4s_vid_out と v_tc を配線して、論理合成、インプリメンテーション、ビットストリームの生成を行った。

前回は、実際に v_axi4s_vid_out と v_tc を配線して、論理合成、インプリメンテーション、ビットストリームの生成を行った。今回は、Jupyter Notebook の cam_disp2.ipynb を作成して実行したが、ディスプレイに表示される色が間違っていた。たぶん RGB のところ RBG になっていると思われる。

前回は、Jupyter Notebook の cam_disp2.ipynb を作成して実行したが、ディスプレイに表示される色が間違っていた。たぶん RGB のところ RBG になっていると思われる。今回は、ディスプレイに表示するソーベル・フィルタの後に AXI4-Stream Subset Converter を挿入して RGB を RBG に変換したところ、色が正常になった。

PYNQ v3.0 (Belfast) がリリースされた。
PYNQ-Z1 に PYNQ v3.0 を書いた MicroSD カードを挿入して、起動してみた。

Kria-PYNQ を KV260 で使って見るために新しい Ubuntu 22.04 を KV260 で使ってみよう。

最初に”設計開始 Kria KV260 ビジョン AI スターター キットを使用”の”手順 1. SD カード イメージを設定する (Ubuntu)”で” Kria Ubuntu デスクトップ 22.04 LTS イメージ”をダウンロードすることにした。

前回は、Ubuntu 22.04 のイメージをダウンロードした。MicroSD カードに書いて、KV260 に挿入し、Ubuntu 22.04 をブートすることができた。今回は、その Ubuntu 22.04 の設定を行った。

前回は、Ubuntu 22.04 の設定を行って、GUI のファイルマネージャーやテキスト・エディタを起動することができた。今回は、その KV260 の Ubuntu 22.04 に Kria-PYNQ をインストールしてみたところ失敗した。

”再度 KR260 で Ubuntu 22.04 LTS を起動した”で安定的に KR260 で Ubuntu 22.04 が動作したので、Kria-PYNQ をやってみよう。
今回は、Kria-PYNQ のインストールを行った。

KR260 で Kria-PYNQ をやってみようということで、前回は、Kria-PYNQ のインストールを行った。今回は、resizer_ps.ipynb をやってみよう。

KR260 で Kria-PYNQ をやってみようということで、前回は、resizer_ps.ipynb をやってみて成功した。今回は、PL を使用した resizer_pl.ipynb をやってみよう。

KR260 で Kria-PYNQ をやってみようということで、前回は、PL を使用した resizer_pl.ipynb をやって成功した。今回は、pynq-dpu ディレクトリの中の dpu_mnist_classifier.ipynb をやってみよう

pynq.io には ZUBoard 1CG 用の PYNQ v3.0.1 があるので、やってみようと思う。

pynq.io には ZUBoard 1CG 用の PYNQ v3.0.1 があるので、やってみようと思うということで、前回は、PYNQ の Development Boards から ZUBoard 1CG 用の PYNQ v3.0.1 のイメージをダウンロードし、MicroSD カードに書いて、Ubuntu 22.04 を ZUBoard 1CG で起動した。今回は、ZUBoard 1CG の PYNQ の Jupyter Notebook を使ってみた。

ZUBoard 1CG で PYNQ v3.0.1 を動作させたが、そこにDPU-PYNQ をインストールした。

前回は、ZUBoard 1CG で PYNQ v3.0.1 を動作させたが、そこにDPU-PYNQ をインストールした。そして、ノートブックの内の dpu_mnist_classifier.ipynb をやってみたところ、成功した。今回は、dpu_resnet50.ipynb と dpu_resnet50_pybind11.ipynb をやってみた。

ZUBoard 1CG の PYNQ v3.0.1 上に DPU-PYNQ をインストールして、ノートブックを実行している。前回は、dpu_resnet50.ipynb と dpu_resnet50_pybind11.ipynb をやってみた。今回は、dpu_tf_inceptionv1.ipynb と dpu_yolov3.ipynb をやってみた。

前回は、生成した IP を使用してテスト・パターン・ジェネレーターのブロック・デザインを作成した。次に、Video Test Pattern Generator と AXI Video Direct Memory Access を Add IP して、自動配線を行った。今回は、Color Convert (2ppc) IP と Pixel Pack (2 ppc) IP、 AXI Interrupt Controller IP を追加して、自動配線を行った。Validate Desgin を行ったところ、成功した。よって、ブロック・デザインが完成した。

前回は、Color Convert (2ppc) IP と Pixel Pack (2 ppc) IP、 AXI Interrupt Controller IP を追加して、自動配線を行った。Validate Desgin を行ったところ、成功した。よって、ブロック・デザインが完成した。今回は、ブロック・デザインの HDL Wrapper ファイルを作成し、論理合成、インプリメンテーション、ビットストリームの生成を行って成功した。bit ファイルと hwh ファイルが生成された。

前回は、ブロック・デザインの HDL Wrapper ファイルを作成し、論理合成、インプリメンテーション、ビットストリームの生成を行って成功した。bit ファイルと hwh ファイルが生成された。今回は、前回生成した bit ファイルと hwh ファイルを ZUBoard 1CG の PYNQ v3.0.1 に転送し、”Getting Started with PYNQ and the ZUBoard”の Python3 のソフトウェアを動作せたところ、成功した。

ソーベル・フィルタを ZUBoard 1CG の PYNQ v3.0.1 で使用するために Vitis HLS 2023.1 で RGB 24 ビットの AXI4-Stream データ入出力対応のソーベル・フィルタを Vitis HLS 2023.1 で作成した。

”RGB 24 ビットの AXI4-Stream データ入出力対応のソーベル・フィルタを Vitis HLS 2023.1 で作成する”で Vitis HLS 2023.1 を使用して、ソーベル・フィルタ IP の sobel_axis_RGB24 を作成した。今回は、Vivado 2023.1 の sobel_pynq プロジェクトを作成し、sobel_axis_RGB24 を使用して、sobel ブロック・デザインを作成した。論理合成、インプリメンテーション、ビットストリームの生成を行って、成功した。hwh ファイルと bit ファイルが生成された。

前回は、Vivado 2023.1 の sobel_pynq プロジェクトを作成し、sobel_axis_RGB24 を使用して、sobel ブロック・デザインを作成した。論理合成、インプリメンテーション、ビットストリームの生成を行って、成功した。hwh ファイルと bit ファイルが生成された。今回は、hwh ファイルと bit ファイル、画像ファイルを ZUBoard 1CG に転送し、Jupyter Notebook を作成し、ソーベル・フィルタの動作を確認した。

メディアン・フィルタを ZUBoard 1CG の PYNQ v3.0.1 で使用するために Vitis HLS 2023.1 で RGB 24 ビットの AXI4-Stream データ入出力対応のメディアン・フィルタを Vitis HLS 2023.1 で作成した。

メディアン・フィルタを ZUBoard 1CG の PYNQ v3.0.1 で使用するために Vitis HLS 2023.1 で RGB 24 ビットの AXI4-Stream データ入出力対応のメディアン・フィルタを Vitis HLS 2023.1 で作成するということで、前回は、Vitis HLS 2023.1 で median_axis_RGB24 プロジェクトを作成し、C シミュレーションを行った。今回は、C コードの合成、C/RTL 協調シミュレーション、Export RTL、Implementation を行った。

”RGB 24 ビットの AXI4-Stream データ入出力対応のメディアン・フィルタを Vitis HLS 2023.1 で作成する2”でメディアン・フィルタが作成できた。その medain_axis_RGB24 IP を”ZUBoard 1CG の PYNQ v3.0.1 で自作のソーベル・フィルタを動作させる1”で作成したブロック・デザインに追加した。

”RGB 24 ビットの AXI4-Stream データ入出力対応のメディアン・フィルタを Vitis HLS 2023.1 で作成する2”で作成したメディアン・フィルタを使ってみようということで、前回は、medain_axis_RGB24 IP を”ZUBoard 1CG の PYNQ v3.0.1 で自作のソーベル・フィルタを動作させる1”で作成したブロック・デザインに追加した。今回は、作成したブロック・デザインの HDL Wrapper ファイルを作成し、論理合成、インプリメンテーション、ビットストリームの生成を行って、成功した。hwh ファイルと bit ファイルが生成された。

前回は、作成したブロック・デザインの HDL Wrapper ファイルを作成し、論理合成、インプリメンテーション、ビットストリームの生成を行って、成功した。hwh ファイルと bit ファイルが生成された。今回は、生成されたビット・ファイルと hwh ファイルを ZUBoard 1CG 上の Jupyter Notebook にアップロードし、median_sobel.ipynb ファイルを作成して、メディアン・フィルタとソーベル・フィルタの動作を確認したところ動作した。

RGB 24 ビットの AXI4-Stream データ入出力対応のソーベル・フィルタを Vitis HLS 2023.1 で作成した。

RGB 24 ビットの AXI4-Stream データ入出力対応のソーベル・フィルタを Vitis HLS 2023.1 で作成するということで、前回は、ソースコードとテストベンチコードを貼って、Vitis HLS 2023.1 で gaussian_axis_RGB24 プロジェクトを作成した。今回は、gaussian_axis_RGB24 プロジェクトで、C シミュレーション、C コードの合成、C/RTL 協調シミュレーション、Export RTL、Implementation を行った。

”RGB 24 ビットの AXI4-Stream データ入出力対応のガウシアン・フィルタを Vitis HLS 2023.1 で作成する2”でガウシアン・フィルタ IP が生成できた。その gaussian_axis_RGB24 IP を”ZUBoard 1CG の PYNQ v3.0.1 で自作のメディアン・フィルタとソーベル・フィルタを動作させる1”のソーベル・フィルタとメディアン・フィルタの回路に追加した。

前回は、”RGB 24 ビットの AXI4-Stream データ入出力対応のガウシアン・フィルタを Vitis HLS 2023.1 で作成する2”でガウシアン・フィルタ IP が生成できた。その gaussian_axis_RGB24 IP を”ZUBoard 1CG の PYNQ v3.0.1 で自作のメディアン・フィルタとソーベル・フィルタを動作させる1”のソーベル・フィルタとメディアン・フィルタの回路に追加した。今回は、i3filters ブロック・デザインの axis_dwidth_converter_0 と axis_dwidth_converter_1 に System ILA を追加して、論理合成、インプリメンテーション、ビットストリームの生成を行って成功した。hwh ファイルと bit ファイルが生成された。

前回は、i3filters ブロック・デザインの axis_dwidth_converter_0 と axis_dwidth_converter_1 に System ILA を追加して、論理合成、インプリメンテーション、ビットストリームの生成を行って成功した。hwh ファイルと bit ファイルが生成された。今回は、生成されたビット・ファイルと hwh ファイルを ZUBoard 1CG 上の Jupyter Notebook にアップロードし、i3filters.ipynb ファイルを作成して、メディアン・フィルタとソーベル・フィルタの動作を確認したところ動作した。

前回は、生成されたビット・ファイルと hwh ファイルを ZUBoard 1CG 上の Jupyter Notebook にアップロードし、i3filters.ipynb ファイルを作成して、メディアン・フィルタとソーベル・フィルタの動作を確認したところ動作した。

しかし、”AXI4-Stream Data Width Converter のバイト・レーン変換を確認する4”で、3 バイト幅の AXI4-Stream インターフェースの色のフィールドが MSB から BGR であることがわかった。今までは RGB のつもりで各フィルタの IP を作成していた。今回は、色のフィールドの修正のため AXI4-Stream Subset Converter を 2 個、i3filters ブロック・デザインに追加して、バイト・レーンの変換を行った。その後、論理合成、インプリメンテーション、ビットストリームの生成を行って、ZUBoard 1CG の PYNQ Linux にアップロードして、動作を確認したところ問題なく動作した。

”ZUBoard 1CG の PYNQ v3.0.1 で自作のガウシアン・フィルタ、メディアン・フィルタとソーベル・フィルタを動作させる3”でガウシアン・フィルタの動作を確認できたが、ファイルをロードした 4 バイトのデータは AXI4-Stream Data Width Converter で 4 バイトを 3 バイトに変換してガウシアン・フィルタに入力されている。
このバイト変換は”PYNQ の画像ファイル・フォーマットを調査するために choose_RGB IP を Vitis HLS 2021.2 で作成する8”で解析して、4 バイトのデータが OpenCV の MAT 形式であることは確認してある。（MAT 形式のフォーマットについては、”Vitis Vision Library の AXI4 Master インターフェース版 medianblur をZYBO Z7-20 で使ってみる1（準備編）”を参照）
しかし、”PYNQ の画像ファイル・フォーマットを調査するために choose_RGB IP を Vitis HLS 2021.2 で作成する8”では、4 バイトを 3 バイトに変換した後についての検証が足りなかったので、もう一度、”ZUBoard 1CG の PYNQ v3.0.1 で自作のガウシアン・フィルタ、メディアン・フィルタとソーベル・フィルタを動作させる3”のハードウェアで検証してみよう。

Pythonの画像処理ライブラリPillow(PIL)の Image.open でオープンした画像ファイルのフォーマットを確認するということで、前回は、blue.png、 green.png、 red.png の画像ファイルを作成した。今回は、PNG の画像ファイルを ZUBoard 1CG の PYNQ Linux にアップロードし、Jupter Notebook を書き換えて実行したところ、PNG の画像ファイルは 4 チャネルでエラーが出てしまった。

Pythonの画像処理ライブラリPillow(PIL)の Image.open でオープンした画像ファイルのフォーマットを確認するということで、前回は、PNG の画像ファイルを ZUBoard 1CG の PYNQ Linux にアップロードし、Jupter Notebook を書き換えて実行したところ、PNG の画像ファイルは 4 チャネルでエラーが出てしまった。今回は、blue.bmp、 green.bmp、 red.bmp を用意して、ZUBoard 1CG の PYNQ Linux にアップロードし、Jupter Notebook を書き換えて実行したところ、AXI4-Stream Data Width Converter で変換された 3 バイトの AXI4-Stream は上のバイトから RGB でなく BGR であることがわかった。

Pythonの画像処理ライブラリPillow(PIL)の Image.open でオープンした画像ファイルのフォーマットを確認するということで、前回は、blue.bmp、 green.bmp、 red.bmp を用意して、ZUBoard 1CG の PYNQ Linux にアップロードし、Jupter Notebook を書き換えて実行したところ、AXI4-Stream Data Width Converter で変換された 3 バイトの AXI4-Stream は上のバイトから RGB でなく BGR であることがわかった。前回の作業は、AXI4-Stream Data Width Converter は 2 個搭載されているが、その内の 3 バイト幅の AXI4-Stream から 4 バイト幅に変換する AXI4-Stream Data Width Converter の動作を見た。今回は、4 バイト幅の AXI4-Stream から 3 バイト幅に変換する AXI4-Stream Data Width Converter の動作を見た。

”Vitis HLS 2023.1 で RGB の各色を n 倍する color_converter_RGB24 IP を作成する2”で作成した color_converter_RGB24 IP を”ZUBoard 1CG の PYNQ v3.0.1 で自作のガウシアン・フィルタ、メディアン・フィルタとソーベル・フィルタを動作させる4”の回路に追加してみよう。

”Vitis HLS 2023.1 で RGB の各色を n 倍する color_converter_RGB24 IP を作成する2”で作成した color_converter_RGB24 IP を”ZUBoard 1CG の PYNQ v3.0.1 で自作のガウシアン・フィルタ、メディアン・フィルタとソーベル・フィルタを動作させる4”の回路に追加してみようということで、前回は、最初に Vivado 2023.1 の i4filters プロジェクトを新規作成した。また、i3filters プロジェクトでエクスポートしたブロック・デザイン作成 tcl ファイルを元に i4filters ブロック・デザインを作成し、color_converter_RGB24 IP を挿入した。今回は、i4flilters ブロック・デザインのラッパーファイルを生成し、論理合成、インプリメンテーション、ビットストリームの生成を行って成功した。PYNQ で使用する hwh ファイルと、bit ファイルが生成された。

”Vitis HLS 2023.1 で RGB の各色を n 倍する color_converter_RGB24 IP を作成する2”で作成した color_converter_RGB24 IP を”ZUBoard 1CG の PYNQ v3.0.1 で自作のガウシアン・フィルタ、メディアン・フィルタとソーベル・フィルタを動作させる4”の回路に追加してみよう。

”Vitis HLS 2023.1 で RGB の各色を n 倍する color_converter_RGB24 IP を作成する2”で作成した color_converter_RGB24 IP を”ZUBoard 1CG の PYNQ v3.0.1 で自作のガウシアン・フィルタ、メディアン・フィルタとソーベル・フィルタを動作させる4”の回路に追加してみようということで、前回は、最初に Vivado 2023.1 の i4filters プロジェクトを新規作成した。また、i3filters プロジェクトでエクスポートしたブロック・デザイン作成 tcl ファイルを元に i4filters ブロック・デザインを作成し、color_converter_RGB24 IP を挿入した。今回は、i4flilters ブロック・デザインのラッパーファイルを生成し、論理合成、インプリメンテーション、ビットストリームの生成を行って成功した。PYNQ で使用する hwh ファイルと、bit ファイルが生成された。

”Vitis HLS 2023.1 で RGB の各色を n 倍する color_converter_RGB24 IP を作成する2”で作成した color_converter_RGB24 IP を”ZUBoard 1CG の PYNQ v3.0.1 で自作のガウシアン・フィルタ、メディアン・フィルタとソーベル・フィルタを動作させる4”の回路に追加してみようということで、前回は、i4flilters ブロック・デザインのラッパーファイルを生成し、論理合成、インプリメンテーション、ビットストリームの生成を行って成功した。PYNQ で使用する hwh ファイルと、bit ファイルが生成された。今回は、”メディアン・フィルタとガウシアン・フィルタが RBG 出力でバグっていた”で、median_axis_RGB24 IP と gaussian_axis_RGB24 IP がバグっているのがわかった。Vitis HLS 2023.1 を起動して、median_axis_RGB24 IP と gaussian_axis_RGB24 IP をバグを修正してから、C シミュレーション、C コードの合成、Export RTL を行った。できた IP を Vivado 2023.1 の i4filters プロジェクトの median_axis_RGB24 IP と gaussian_axis_RGB24 IP と入れ替えて、論理合成、インプリメンテーション、ビットストリームの生成を行って成功した。

前回は、”メディアン・フィルタとガウシアン・フィルタが RBG 出力でバグっていた”で、median_axis_RGB24 IP と gaussian_axis_RGB24 IP がバグっているのがわかった。Vitis HLS 2023.1 を起動して、median_axis_RGB24 IP と gaussian_axis_RGB24 IP をバグを修正してから、C シミュレーション、C コードの合成、Export RTL を行った。できた IP を Vivado 2023.1 の i4filters プロジェクトの median_axis_RGB24 IP と gaussian_axis_RGB24 IP と入れ替えて、論理合成、インプリメンテーション、ビットストリームの生成を行って成功した。今回は、hwh ファイルと bit ファイルを ZUBoard 1CG の PYNQ Linux にアップロードし、i4filters.ipynb を作成した。i4filters.ipynb を実行したところ、無事に”Vitis HLS 2023.1 で RGB の各色を n 倍する color_converter_RGB24 IP を作成する2”で作成した color_converter_RGB24 IP を動作させることができた。

今週の水曜日（2023/10/25）に”実践的！FPGA開発セミナー vol.27”で発表します。
タイトルは”PYNQ上で画像用自作ハードウェアを動作させる”です。

今日、”実践的！FPGA開発セミナー vol.27”が開催されて、そこで、お話させていただきます。
事前に発表用スライドの”PYNQ上で画像用自作ハードウェアを動作させる”を公開します。

ZUBoard 1CG の PYNQ v3.0.1 で自作の 4 個のフィルタは動作させることができているので、次は RGB24toHSV - HSVConverter - HSVtoRGB24 の各 IP を加えた 5 個のフィルタを動作させたい。今回は、Vivado 2023.2 で i5filters プロジェクトを作成し、i4filters プロジェクトでブロック・デザインを出力した i4filters.tcl を i5filters.tcl に改名し、少々手直したあとで、i5filters プロジェクトで動作させてブロック・デザインを作成した。

RGB24toHSV - HSVConverter - HSVtoRGB24 の各 IP を加えた 5 個のフィルタを動作させたいということで、前回は、Vivado 2023.2 で i5filters プロジェクトを作成し、i4filters プロジェクトでブロック・デザインを出力した i4filters.tcl を i5filters.tcl に改名し、少々手直したあとで、i5filters プロジェクトで動作させてブロック・デザインを作成した。今回は、RGB24toHSV - HSVConverter - HSVtoRGB24 の各 IP を加えたところ、HSVtoRGB24 IP に col_size の入力ポートが付いていたが、これはバグだ。正しくは、AXI4-Liteインターフェースのレジスタになるはずだった。そこで、Vitis HLS 2023.1 を起動して、バグを修正し、もう一度、HSVtoRGB24 IP をブロック・デザインに追加した。論理合成、インプリメンテーション、ビットストリームの生成を行って、成功した。

前回は、RGB24toHSV - HSVConverter - HSVtoRGB24 の各 IP を加えたところ、HSVtoRGB24 IP に col_size の入力ポートが付いていたが、これはバグだ。正しくは、AXI4-Liteインターフェースのレジスタになるはずだった。そこで、Vitis HLS 2023.1 を起動して、バグを修正し、もう一度、HSVtoRGB24 IP をブロック・デザインに追加した。論理合成、インプリメンテーション、ビットストリームの生成を行って、成功した。今回は、ZUBoard 1CG の PYNQ を立ち上げて、upyter Notebook 上で i5filters フォルダを作成し、Jupyter Notebook で前回作成したビット・ファイルと hwh ファイルをアップグレードした。画像ファイルを用意して、i5filters.ipynb ファイルを作成し、実行したところ、真っ黒な画像が得られた。デバッグの必要がある。

前回は、ZUBoard 1CG の PYNQ を立ち上げて、upyter Notebook 上で i5filters フォルダを作成し、Jupyter Notebook で前回作成したビット・ファイルと hwh ファイルをアップグレードした。画像ファイルを用意して、i5filters.ipynb ファイルを作成し、実行したところ、真っ黒な画像が得られた。デバッグの必要がある。今回は、System ILA を追加して、論理合成、インプリメンテーション、ビットストリームの生成を行って、再度、bit ファイルと hwh ファイルを ZUBoard 1CG の PYNQ にアップロードして、ILA ダッシュボードを起動して、波形を確認したところ、問題ないことがわかった。画像も正常に表示されていた。結局、昨日の 1 回のみバグっただけで、今日は何回やっても画像が表示された。なんだったんだろうか？

前回は、System ILA を追加して、論理合成、インプリメンテーション、ビットストリームの生成を行って、再度、bit ファイルと hwh ファイルを ZUBoard 1CG の PYNQ にアップロードして、ILA ダッシュボードを起動して、波形を確認したところ、問題ないことがわかった。画像も正常に表示されていた。結局、昨日の 1 回のみバグっただけで、今日は何回やっても画像が表示された。今回は、バグが無かったので、正常に HSVConverter を PYNQ 上で試したところ、うまく行った。

ZUBoard 1CG の PYNQ v3.0.1 で自作の今まで作成してきた 10 個のフィルタを動作させよう。

今まで Vitis HLS で作成したすべてのフィルタを実装したいということで、前回は、Vivado 2023.2 で i10filters プロジェクトを作成し、i5filters プロジェクトでブロック・デザインを出力した i5filters.tcl を i10filters.tcl に改名し、少々手直したあとで、i10filters プロジェクトで動作させてブロック・デザインを作成した。今回は、average_axis_RGB24, edge_enhancement_axis_RGB24, laplacian_axis_RGB24, min_max_axis_RGB24, unsharp_masking_axis_RGB24 ディレクトリを作成し、average_axis_RGB24, edge_enhancement_axis_RGB24, laplacian_axis_RGB24, min_max_axis_RGB24, unsharp_masking_axis_RGB24 の各 IP をブロック・デザインに追加してブロック・デザインを完成し、論理合成、インプリメンテーション、ビットストリームの生成を行って成功した。

前回は、average_axis_RGB24, edge_enhancement_axis_RGB24, laplacian_axis_RGB24, min_max_axis_RGB24, unsharp_masking_axis_RGB24 ディレクトリを作成し、average_axis_RGB24, edge_enhancement_axis_RGB24, laplacian_axis_RGB24, min_max_axis_RGB24, unsharp_masking_axis_RGB24 の各 IP をブロック・デザインに追加してブロック・デザインを完成し、論理合成、インプリメンテーション、ビットストリームの生成を行って成功した。今回は、ZUBoard 1CG の Pynq Linux を起動して、Jupyter Notebook の i5filters ディレクトリのファイルを Jupyter Notebook 経由でコピーしようとしたら、 エラーになったので、ターミナルのコマンドでコピーを行った。次に i10filters_wrapper.bit と i10filters.hwh ファイルをアップロードし、i10filters_wrapper.bit は i10filters.bit に名前を変更した。

前回は、ZUBoard 1CG の Pynq Linux を起動して、Jupyter Notebook の i5filters ディレクトリのファイルを Jupyter Notebook 経由でコピーしようとしたら、 エラーになったので、ターミナルのコマンドでコピーを行った。次に i10filters_wrapper.bit と i10filters.hwh ファイルをアップロードし、i10filters_wrapper.bit は i10filters.bit に名前を変更した。今回は、Jupyter Notebook のファイル i10filters.ipynb を編集して、average_axis_RGB24, edge_enhancement_axis_RGB24, laplacian_axis_RGB24, min_max_axis_RGB24, unsharp_masking_axis_RGB24 ディレクトリを作成し、average_axis_RGB24, edge_enhancement_axis_RGB24, laplacian_axis_RGB24, min_max_axis_RGB24, unsharp_masking_axis_RGB24 の各 IP の Python コードを追加した。平均化フィルタ（average_axis_RGB24）のみをアクティブにした。

前回は、Jupyter Notebook のファイル i10filters.ipynb を編集して、average_axis_RGB24, edge_enhancement_axis_RGB24, laplacian_axis_RGB24, min_max_axis_RGB24, unsharp_masking_axis_RGB24 ディレクトリを作成し、average_axis_RGB24, edge_enhancement_axis_RGB24, laplacian_axis_RGB24, min_max_axis_RGB24, unsharp_masking_axis_RGB24 の各 IP の Python コードを追加した。平均化フィルタ（average_axis_RGB24）のみをアクティブにした。今回は、平均化フィルタを掛けた画像にラプラシアン・フィルタを掛け た。また、原画像、メディアン・フィルタ、最小値フィルタのラプラシアン・フィルタ処理結果を示した。

前回は、平均化フィルタを掛けた画像にラプラシアン・フィルタを掛けた。また、原画像、メディ アン・フィルタ、最小値フィルタのラプラシアン・フィルタ処理結果を示した。今回は、アンシャープ・マスキング・フィルタとエッジ強調フィルタを使用した。

Bambu で高位合成した median_hlsst_RGB24 を ZUBoard 1CG の PYNQ で試してみたい。
Vivado 2023.2 で ZUBoard 1CG 用の bambu_median プロジェクトを作成し、Bambu で高位合成した median_hlsst_RGB24 を使った bambu_median ブロック・デザインを作成し、論理合成、インプリメンテーション、ビットストリームの生成を行ってビット・ファイルを作成する。
今回は、 Vivado 2023.2 で ZUBoard 1CG 用の bambu_median プロジェクトを作成し、ブロック・デザインを作成する前の準備を行って、bambu_median ブロック・デザインを作成し、median_hlsst_RGB24.v をブロック・デザインに追加した。

Bambu で高位合成した median_hlsst_RGB24 を ZUBoard 1CG の PYNQ で試してみたいということで、前回は、Vivado 2023.2 で ZUBoard 1CG 用の bambu_median プロジェクトを作成し、ブロック・デザインを作成する前の準備を行って、bambu_median ブロック・デザインを作成し、median_hlsst_RGB24.v をブロック・デザインに追加した。今回は、bambu_median ブロック・デザインを完成させた。

前回は、bambu_median ブロック・デザインを完成させた。今回は、HDL ラッパー・ファイルを生成し、論理合成、インプリメンテーション、ビットストリームの生成を行って、bit ファイルと hwh ファイルを生成した。

前回は、HDL ラッパー・ファイルを生成し、論理合成、インプリメンテーション、ビットストリームの生成を行って、bit ファイルと hwh ファイルを生成した。今回は、System ILA を追加するのを忘れていたので、System ILA を追加して、もう一度、論理合成、インプリメンテーション、ビットストリームの生成を行って、bit ファイルと hwh ファイルを生成した。

前回は、System ILA を追加するのを忘れていたので、System ILA を追加して、もう一度、論理合成、インプリメンテーション、ビットストリームの生成を行って、bit ファイルと hwh ファイルを生成した。今回は、前回作成した bit ファイルと hwh ファイルを ZUBoard 1CG の PYNQ Linux の Jupyter Notebook 上にアップロードして動作を確認したが、dma.recvchannel.wait() でエラーになった。

前回は、bit ファイルと hwh ファイルを ZUBoard 1CG の PYNQ Linux の Jupyter Notebook 上にアップロードして動作を確認したが、dma.recvchannel.wait() でエラーになった。今回は、ILA ダッシュボードで波形を観測したところ、問題なく各モジュールが動作していたので、そ～ベル・フィルタの出力画像を確認したところ、問題なく画像が表示された。多分、 Bambu で作成したメディアン・フィルタ IP からTLAST が出力されないのが問題のようだ？

”Bambu で高位合成した median_hlsst_RGB24 を ZUBoard 1CG の PYNQ で試してみる6”で AXI DMA を正常に動作させるためには AXI4-Stream インターフェースの tlast が必要ということが分かった。よって、”Bambu で hls stream インターフェースのメディアン・フィルタを高位合成する1”で実装した median_hlsst_RGB24 に tlast を追加する。

median_hlsst_RGB24 に tlast を追加するということで、前回は、median_hlsst_RGB24.cpp を変更し、outs 出力ストリームのデータ・ビット幅を 1 ビット増やして、そこに tlast の機能を割り当てた。そして、g++ コンパイラでコンパイルし動作を確認した。今回は、median_hlsst_RGB24.cpp を Bambu で高位合成して、median_hlsst_RGB24.v を生成した。

前回は、median_hlsst_RGB24.cpp を Bambu で高位合成して、median_hlsst_RGB24.v を生成した。今回は、Cocotb でシミュレーションを行って、tlast が正常に出力できているのが確認できた。

前回は、Cocotb でシミュレーションを行って、tlast が正常に出力できているのが確認できた。今回は、Bambu で生成された median_hlsst_RGB24.v を Vivado 2023.2 の bambu_median プロジェクトの median_hlsst_RGB24.v と入れ替えて、tdata と tlast を出力できるように Slice を追加した。その後、論理合成、インプリメンテーション、ビットストリームの生成を行って、成功した。

前回は、Bambu で生成された median_hlsst_RGB24.v を Vivado 2023.2 の bambu_median プロジェクトの median_hlsst_RGB24.v と入れ替えて、tdata と tlast を出力できるように Slice を追加した。その後、論理合成、インプリメンテーション、ビットストリームの生成を行って、成功した。今回は、前回作成した bit ファイルと hwh ファイルを ZUBoard 1CG の PYNQ Linux の Jupyter Notebook 上にアップロードして動作を確認したところ、問題なく動作した。