FC2カウンター FPGAの部屋 SDSoC

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

FPGAの部屋

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

SDx 2016.3 のプラグマによるハードウェアと性能の違い5

SDx 2016.3 のプラグマによるハードウェアと性能の違い4”の続き。

SDSoC 勉強会SDSoC勉強会_170128_スライド「SDx 2016.3のプラグマによるハードウェアと性能」の18ページの性能比較表で「プラグマ無し」と「SEQUENTIAL」のハードウェア実行時間がばらつくのは、メモリ領域を malloc() で取っているからではないか?という指摘を頂いた。malloc() でとるとページ(4kバイト)ごとに不連続なメモリを使用している可能性がある。ページごとに、スワップアウトしているかどうか?を確かめてスワップアウトされていたらスワップインする必要がある。つまり、ページごとに余計な処理をする必要がある。それで、遅くもなっているし、時間の変動も起こるのではないか?という指摘だった。
それならば、sds_alloc() でCMA 領域に連続メモリ領域を確保すれば大丈夫なはずだ。なお、ソフトウェアはMMU を通っているので、MMUで論理アドレスー物理アドレス変換が自動的に行われるので、CPUから論理アドレスに書けばページが違っていても問題ない。(論点が微妙に違うのはご容赦ください)

さて、前回のSDSoC の lap_filter2 プロジェクトは memcpy() を使った実装を上書きしてしまったので、新たに lap_filter1 プロジェクトを作成した。
SDx_2016_3_2_1_170130.png

今回は、最初から hw_rd_bmp と hw_lapd にメモリ領域を確保する際に、sds_alloc() を使用した。
SDx_2016_3_2_2_170130.png

これで、プラグマ無しにしてRelesase でビルドを行った。
SDx_2016_3_2_3_170130.png

MicroSD カードに sd_card フォルダの内容を書いて、ZYBO の電源ONした。
Linux が立ち上がった。cd /mnt し、 ./lap_filter1.elf を起動した。結果を示す。
SDx_2016_3_2_4_170130.png

ソフトウェア実行時間がたま~にばらつくときがあるのだが、ハードウェア実行時間は安定した。やはり、malloc() で取るとハードウェア実行時間は安定しないようだ。
明らかにソフトウェア実行時間がおかしい値を除いたハードウェア実行時間の5回の平均は、1047 us だった。明らかにおかしい値を除いたソフトウェア実行時間の5回の平均は、854 us だった。

次に、

#pragma SDS data access_pattern(cam_fb:SEQUENTIAL, lap_fb:SEQUENTIAL)

プラグマを使用した場合について、やってみよう。今回もハードウェアに関するメモリ領域は引き続き、sds_alloc() を使用している。
SDx_2016_3_2_5_170130.png

Relesase でビルドを行った。
MicroSD カードに sd_card フォルダの内容を書いて、ZYBO の電源ONした。
Linux が立ち上がった。cd /mnt し、 ./lap_filter1.elf を起動した。結果を示す。
SDx_2016_3_2_6_170130.png

こちらも、ソフトウェア実行時間がたま~にばらつくときがあるのだが、ハードウェア実行時間は安定した。やはり、malloc() で取るとハードウェア実行時間は安定しないようだ。
明らかにソフトウェア実行時間がおかしい値を除いたハードウェア実行時間の5回の平均は、969 us だった。プラグマ無しよりもこちらのほうがハードウェア実行時間が短い。明らかにおかしい値を除いたソフトウェア実行時間の5回の平均は、843 us だった。

ソフトウェアのメモリ領域の確保も sds_alloc() にしてみよう。これでどうなるだろうか?
SDx_2016_3_2_7_170130.png

Relesase でビルドを行った。
MicroSD カードに sd_card フォルダの内容を書いて、ZYBO の電源ONした。
Linux が立ち上がった。cd /mnt し、 ./lap_filter1.elf を起動した。結果を示す。
SDx_2016_3_2_8_170130.png

ソフトウェア実行時間もばらつく頻度が多くなった気がする。ハードウェア実行時間もたまにばらついている。

プラグマ無しで、ソフトウェアのメモリ領域の確保も sds_alloc() にしてみた。
SDx_2016_3_2_9_170130.png

Relesase でビルドを行った。
MicroSD カードに sd_card フォルダの内容を書いて、ZYBO の電源ONした。
Linux が立ち上がった。cd /mnt し、 ./lap_filter1.elf を起動した。結果を示す。
SDx_2016_3_2_10_170130.png

やはり、ソフトウェア実行時間もばらつく頻度が多くなった気がする。
  1. 2017年01月31日 05:00 |
  2. SDSoC
  3. | トラックバック:0
  4. | コメント:0

SDSoC 勉強会

今日は、SDSoC 勉強会に行ってきました。
猛者ばかりなので、プレゼンするのに戦々恐々としていましたが、割とうまくできたかな?
資料はSlideShareにアップしました。タイトルは、「SDx 2016.3のプラグマによるハードウェアと性能」です。
疑問の点も指摘して頂いて、納得しました。後で検証してみたいと思います。

他の方のプレゼンも、とっても濃い話ばかりで、楽しめました。
懇親会でも楽しく過ごすことができました。
幹事さん、参加された皆さん、楽しかったです。ありがとうございました。
  1. 2017年01月28日 22:58 |
  2. SDSoC
  3. | トラックバック:0
  4. | コメント:0

SDSoCのチュートリアルをやってみた4(ハードウェア/ソフトウェア イベントのトレース)

SDSoCのチュートリアルをやってみた3(タスクのパイプライン処理最適化)”の続き。

SDSoC 環境ユーザー ガイド SDSoC 環境の概要 UG1028 (v2016.2) 2016 年 7 月 13 日”の66ページの”第7章  チュートリアル : ハードウェア/ソフトウェアイベントのトレース”をやってみよう。
SDSoC Environment Tutorial: Introduction UG1028 (v2016.3) November 30, 2016”では、43ページの”Lab 7: Hardware Debug”だった。

さて、zc702 のスタンドアロン・プロジェクト zc702_test をMatrix Multiplication テンプレートで作成した。
SDx_v2016_3_tut_39_170119.png

ZYBO の空のスタンドアロン・プロジェクト mmult_trace を作成した。
zc702_test のソースファイルを mmult_trace にコピー&ペーストした。
mmult_accel 関数をハードウェア関数に登録した。
SDx_v2016_3_tut_40_170119.png

mmult_accel.h の #define N 32 を #define N 16 に変更した。(ZYBO ではリソースが足りないため)
SDx_v2016_3_tut_41_170119.png

mmult.cpp の #define NUM_TESTS 1024 を 10 に変更した。これはトレースるのにあまり大きな数だとトレースしきれないからだろう?
SDx_v2016_3_tut_42_170119.png

Enable event tracing にチェックを入れてからビルド・ボタンをクリックしてビルドした。
SDx_v2016_3_tut_43_170119.png

ビルドが終了した。成功だ。
SDx_v2016_3_tut_44_170119.png

トレースするので、mmult_trace を右クリックし、右クリックメニューからRun As -> 4 Trace Applicatin (SDSoC Debugger) を選択した。
SDx_v2016_3_tut_45_170119.png

すると、ZYBO がコンフィグレーションされて、ソフトウェアが走ったようだ。この前までにZYBO をJTAG モードにして電源ON して多く必要がある。
トレース結果が表示された。
SDx_v2016_3_tut_46_170119.png

現在の画面で右下のアクティブなウインドウをダブルクリックして最大化した。
SDx_v2016_3_tut_47_170119.png

チュートリアルよりも大分まばらだが、トレース・イベントがグラフィカルに表示されている。
オレンジ色がソフトウェア・イベント、緑色がアクセラレータ・イベント、青色がデータ転送・イベントだそうだ。
しかしなぜこんなに間が空いてしまっているのだろうか?無駄な気がするが?その他のソフトウェア処理が重いのだろうか?これではあまり性能が上がらないと思う。

左のProject Explorer をよく見ると、mmult_trace_Traces フォルダができていた。その中のTrace[1] にSDSoC_AXI_Trace_1-19_15-18 が出来ていた。その下のAXI Event Analysis -> AXI Status View が上の図だ。Tmf Statistics Analysis -> Statistics をダブルクリックして開けてみた。
SDx_v2016_3_tut_49_170119.png

統計情報のようだ。

AXI Status View をイベント・テキストの下に持ってきた。これでチュートリアルの図と同じになった。
SDx_v2016_3_tut_50_170119.png

最後にVivado プロジェクトの結果のレポートを示す。
SDx_v2016_3_tut_51_170120.png

リソースがかなり消費されている。

ブロックデザインを示す。
SDx_v2016_3_tut_52_170120.png

トレース用のIP が多い。
  1. 2017年01月20日 04:46 |
  2. SDSoC
  3. | トラックバック:0
  4. | コメント:0

SDSoCのチュートリアルをやってみた3(タスクのパイプライン処理最適化)

SDSoCのチュートリアルをやってみた2(システム パフォーマンスの見積もり)”の続き。

SDSoC Environment Tutorial: Introduction UG1028 (v2016.3) November 30, 2016”の33ページ”Chapter 5 Accelerator Optimization”をやってみよう。
なお、”SDSoC 環境ユーザー ガイド SDSoC 環境の概要 UG1028 (v2016.2) 2016 年 7 月 13 日”では、63 ページの”第6章 チュートリアル : タスクのパイプライン処
理最適化”となる。

最初にZYBO 用のファイルは無いのだが、zc702 のファイルを加工してみよう。
ZYBO 用の空の async_wait_zybo プロジェクトを作成した。system configuration は Linuxとした。

C:\HDL\Xilinx\SDx\2016.3\samples\mmult_pipelined から mmult.cpp, mmult_accel.cpp, mmult_accel.h を async_wait_zybo プロジェクトの src フォルダにコピー&ペーストした。
SDx_v2016_3_tut_25_170119.png

Active build configuration を Release に設定し、HW function に mmult_accel を指定して、ビルド・ボタンをクリックした。
SDx_v2016_3_tut_26_170119.png

エラーが出た。やはり、Zynq-7010 ではリソースが足りないようだ。
SDx_v2016_3_tut_27_170119.png

mmult_accel.h を開いて #define N 32 を #define N 16 に書き換えた。
SDx_v2016_3_tut_28_170119.png

もう一度、ビルド・ボタンをクリックしてビルドを行ったら成功した。
SDx_v2016_3_tut_29_170119.png

このチュートリアルでは、Figure 2 に示すように通常はシーケンシャルにうハードウェアのアクセラレーションを行う。
SDx_v2016_3_tut_30_170119.png
SDSoC Environment Tutorial: Introduction UG1028 (v2016.3) November 30, 2016”の35ページのFigure 2: Sequential Execution of Matrix Multiply Calls を引用

パイプラインされたアクセレーターの実行のために、async(id), と wait(id) プラグマを使用してコードを書き直す必要があるそうだ。
その記述を示す。
SDx_v2016_3_tut_31_170119.png

pipeline_depth がパイプラインの数を示していて、最初にパイプライン数のmmult_accel() を発行して、その後は1つのパイプラインが終わったら、次のmmult_accel() を発行する。発行が終了したら、SDS wait(1) でパイプライン数だけの完了を待つ。そのようなプログラムになっているようだ。
その概念図は、Figure 3 に示されている。
SDx_v2016_3_tut_32_170119.png
SDSoC Environment Tutorial: Introduction UG1028 (v2016.3) November 30, 2016”の36ページのFigure 3: Pipelined Execution of Matrix Multiply Calls を引用

パイプライン実行のためには、引数の配列をコピーするためのマルチバッファが必要とのことだ。これは、mmult_accel.cpp の float _A[N][N], _B[N][N] のことだろうと思っている。
SDx_v2016_3_tut_33_170119.png

ビルドした SDカードのイメージをZYBO にSFTP して起動した。
./async_wait_zybo 1 を実行した。これは順次実行だ。
SDx_v2016_3_tut_34_170119.png

値が安定しない。SW/HW が 1.05 倍から2.73 倍でばらついている。

./async_wait_zybo 2 を実行した。これは2つのパイプラインによるパイプライン実行だ。
SDx_v2016_3_tut_35_170119.png

やはり、こちらも値が安定しない。

残念な結果になってしまったが、Vivado のレポートを示す。
SDx_v2016_3_tut_36_170119.png

Vivado のブロックデザインを示す。
SDx_v2016_3_tut_37_170119.png

Vivado HLSを示す。
SDx_v2016_3_tut_38_170119.png
  1. 2017年01月19日 12:32 |
  2. SDSoC
  3. | トラックバック:0
  4. | コメント:0

SDSoCのチュートリアルをやってみた2(システム パフォーマンスの見積もり)

SDSoCのチュートリアルをやってみた1(システムのデバック)”の続き。

前回は、ソフトウェアとハードウェア両方を含んだスタンドアロンのシステムをSDSoCのデバックモードでデバックすることができた。今回は、”SDSoC 環境ユーザー ガイド SDSoC 環境の概要 UG1028 (v2016.2) 2016 年 7 月 13 日”の54 ページの”チュートリアル : システム パフォーマンスの見積もり”をやってみよう。

これもZynq のボードを使用するので、ZYBOをパソコンにUSBケーブルで接続し、ZYBO の電源をON しておく。

SDxプロジェクトは前回の debug_test_bm を使用する。

debug_test_bm プロジェクトを展開して project.sdx をダブルクリックして開く。
Estimate performance にチェックを入れて、トンカチ ボタンをクリックしてデバックでビルドする。
SDx_v2016_3_tut_19_170115.png

Performance and resource estimation report for the 'debug_test_bm' project が表示された。
SDx_v2016_3_tut_20_170115.png

Click Here をクリックした。
Run application to get its performance ダイアログが表示された。
SDx_v2016_3_tut_21_170115.png

ZYBO がコンフィギュレーションされて、ソフトウェアだけのバージョンが実行されるそうだ。ハードウェアの見積もりと比較されて表示される。
SDx_v2016_3_tut_22_170115.png

main の性能差は2.25 倍ハードウェア・アクセラレーションした場合が速い。
main 関数の中の madd 関数は、ハードウェア・アクセラレーションした場合が、79.32 倍速いという結果になった。

上の図で、Summary の最初のPeformance estimates for 'main' function になっているが、これをmain 以外にすることもできるそうだ。これは、project.sdx の Root function を書き換えると変更できるそうだ。その場合は、Clean project を行ってから、ビルドするそうだ。(”SDSoC Environment Tutorial Introduction UG1028 (v2016.3) November 30, 2016”の 20 ページの”Changing Scope of Overall Speedup Comparison”を参照した)
SDx_v2016_3_tut_23_170115.png

今のビルドはデバックで行っているが、リリースでビルドした場合の性能差を示す。
SDx_v2016_3_tut_24_170115.png

main の性能差は1.78 倍ハードウェア・アクセラレーションした場合が速い。
main 関数の中の madd 関数は、ハードウェア・アクセラレーションした場合が、15.09 倍速いという結果になった。

やはり、デバックよりもリリースの方がハードウェアとソフトウェアの性能差が縮まっている。
  1. 2017年01月17日 05:06 |
  2. SDSoC
  3. | トラックバック:0
  4. | コメント:0

SDSoCのチュートリアルをやってみた1(システムのデバック)

SDSoCのデバック方法やパフォーマンス測定のただし方法などを知らなかったので、SDSoCのチュートリアルをやってみることにした。引用するのは、”SDSoC 環境ユーザー ガイド SDSoC 環境の概要 UG1028 (v2016.2) 2016 年 7 月 13 日”で、”SDSoC Environment Tutorial Introduction UG1028 (v2016.3) November 30, 2016”も参考にしながら進めていこう。
UG1028 の日本語訳は意味不明のところがあったので、英語版も大いに参考にさせて頂いた。

それでは、SDSoCのデバック方法からやってみよう。
日本語版UG1028 の 46 ページの”チュートリアル : システムのデバッグ”をやってSDSoCのデバック方法を体験した。
SDx 2016.3 を使用して、プロジェクトはスタンドアロン・プロジェクトを使用し、ZYBO 実機を使用してデバックする。

Micro USB コードでパソコンと接続した。

JTAG 起動モードとし、ZYBO を電源ON した。

SDSoCで File メニューからNew → Xilinx SDx Project を選択した。

Create a New SDxProject ダイアログで、Project name に debug_test_bm と入力した。
SDx_v2016_3_tut_1_170115.png

Choose Hardware Platform で、zybo を選択した。(私のChoose Hardware Platform には、カスタム・プラットフォームを入れているので、他の人よりも数が多い)
SDx_v2016_3_tut_2_170115.png

Choose Software Platform and Target CPU で System configuration を Standalone OS(Zynq 7000) に設定した。
SDx_v2016_3_tut_3_170115.png

Templates で、Matrix Multiplication and Addition (area reduced) を選択した。Finish ボタンをクリックした。
SDx_v2016_3_tut_4_170115.png

debug_test_bm プロジェクトが生成された。すでにハードウェアにオフロードする関数も設定されている。この環境でデバックすることができるようだ。
SDx_v2016_3_tut_5_170115.png

debug_test_bm プロジェクトを右クリックして、右クリックメニューから Build Project を選択した。
SDx_v2016_3_tut_6_170115.png

ビルドが成功した。ビルド後の debug_test_bm プロジェクトのDebug フォルダの debug_test_bm.elf を右クリックし、右クリックメニューからDebug As -> Launch on Hardware (SDSoC Debugger) を選択した。
SDx_v2016_3_tut_7_170115.png

パースペクティブをデバックに変更するというおなじみのダイアログが出た。Yes ボタンをクリックした。
SDx_v2016_3_tut_8_170115.png

SDx がデバックモードになって、main 関数の最初の行で止まっていた。
なお、この時点で、ZYBO はコンフィギュレーションされて、DONE のLEDが点灯している。
SDx_v2016_3_tut_9_170115.png

結果を表示するためのターミナルをSDx で起動する。
Window メニューからShow View -> Others... を選択した。
SDx_v2016_3_tut_10_170115.png

Show View ダイアログで、Terminal の下のTerminal を選択した。
SDx_v2016_3_tut_11_170115.png

右下にTerminal ウインドウが追加された。
SDx_v2016_3_tut_12_170115.png

Connect アイコンをクリックして、Terminal Settings を表示させる。
Connection Type を Serial に、Port をCOM4 (これはそれぞれの環境によって異なる)に、Baud Rate を 115200 に設定した。
SDx_v2016_3_tut_13_170115.png

Tera Term を起動していたので、すでに使われていると出てしまっているが、Tera Term を落としたら接続できた。
SDx_v2016_3_tut_14_170115.png

Step Over アイコンをクリックした。
SDx_v2016_3_tut_15_170115.png

SDx_v2016_3_tut_16_170115.png

main.cpp の行が1行進んで、右の上の Variables ウインドウでも test_passed 変数が更新されて、黄色に変わっている。
SDx_v2016_3_tut_17_170115.png

Resume アイコンをクリックすると、ソフトウェアが終了して、結果が右下のTerminal ウインドウに表示された。
SDx_v2016_3_tut_18_170115.png

これでSDx 2016.3 でのデバック方法が分かった。ハードウェアとソフトウェアが協調して動作する環境でデバックすることができた。
  1. 2017年01月16日 05:35 |
  2. SDSoC
  3. | トラックバック:0
  4. | コメント:0

Vivado HLS のソースコードをSDx で試す4(AXI4-Stream向きのコード)

Vivado HLS のソースコードをSDx で試す3(AXI4-Stream向きのコード)”の続き。

前回は、Vivado HLS で使用していたAXI4-Stream のソースコードをSDSoC 用のサイドチャネル付きAXI4-Stream に対応するソースコードにうまく変換できなかったため、配列渡しとして書き換えた上でAXI4-Stream として実装するプラグマを与えたら、理論上の限界値に近い実行性能が出た。今回は、同じソースコードで、SDSoCのプラグマを変更して実行性能を見ていこう。最初にSDS data zero_copy を与えてみた。

lap_filter4.c にSDS data zero_copy を追加した。
SDx_v2016_3_134_170111.png

Relesase でビルドを行った。
成功したので、Vivado のレポートを見た。
SDx_v2016_3_135_170111.png

前回よりもリソース使用量が少ない。前回のレポートを示す。
SDx_v2016_3_127_170111.png

ブロックデザインを示す。
SDx_v2016_3_136_170111.png

lap_filter_axim はAXI4 Master となった。シンプルな構成になっている。

Vivado HLS のSynthesis Report を示す。
SDx_v2016_3_137_170111.png

次に、実際にZYBO で確かめてみよう。
workspace\lap_filter2\SDRelease\sd_card の内容をMicro SD カードにコピーした。
ZYBO に挿入して電源ONした。
Linux が立ち上がった。
cd /mnt./lap_filter4.elf を実行した。
SDx_v2016_3_138_170111.png

ソフトウェアの実行時間の下5回の平均は、約 47.7 ms だった。
ハードウエアの実行時間の下5回の平均は、約 6.04 ms だった。
ハードウェアの実行時間/ソフトウェアの実行時間 ≒ 0.127倍、つまり、ハードウェアの性能はソフトウェアの約 7.90 倍ということになった。前回の約 8.61 倍ほどではないが、リソース使用量が少ないのに、相当な高性能だ。
こうなると、Vivado HLS で生成したAXI4 Master の回路はDMAのRead とWrite が重なり合っているとしか考えられないのだが、本当だろうか?一度、このコードのままVivado HLS 2016.3 でコードを合成してみよう。
  1. 2017年01月12日 05:33 |
  2. SDSoC
  3. | トラックバック:0
  4. | コメント:0
»