FPGAの部屋

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

FPGAの部屋の有用と思われるコンテンツのまとめサイトを作りました。ご利用ください。 http://marsee101.web.fc2.com/index.html

2014年03月

AXI VDMAを使ったカメラ画像回路の作製2(Xilinxアンサーを検索)”の続き。

AR# 53281の推奨事項を知ったので、カメラ・インターフェースAXI_Stream IP (mt9d111_inf_axi_stream) に、AXI Stream の TUSER と TKEEPの処理を追加した。

最初にISEのプロジェクトを示す。
e81b6de3.png


XPSプロジェクトを示す。
f0875dce.png


XPSプロジェクトのPortsタブを下に示す。
f1f2bd57.png


s_axis_s2mm_tkeep と s_axis_s2mm_tuser の信号を追加した。

s_axis_s2mm_tkeep と s_axis_s2mm_tuser の信号のVHDLコードを下に示す。

m_axis_tuser(0) <= s2mm_fsync_node;


tuser は、Start Of Frame を示す。

m_axis_tkeep <= (others => '1') when pfifo_empty='0' else (others => '0');


tkeep は、tdataがストリームに有効なデータとして扱われるかどうかを示す。

上記の様に修正して、インプリメントして、SDKでFPGA をコンフィグして、デバックしようとしたら、デバック画面で main()関数の先頭行に行かずに止まってしまう。
7589d942.png


FPGAをコンフィグせずに、FPGAがコンフィグされていないというワーニングを無視して、デバックを行うと、ちゃんとデバック画面で main()関数の先頭行に行った。
916c130f.png


やはり、PL部の回路に何らかの不具合があるかもしれない?もう一度、プロジェクトを作りなおしてみることにする。

(2014/04/02:追記)
やはり、プロジェクトを作り直しても、同様でした。ChipScopeを入れなければ、SDKのデバックに問題が無いので、ChipScopeとSDKのJTAGの共有あたりの問題だと思います。

親父が背骨の圧迫骨折で現在入院していて、もう約三ヶ月になります。そろそろ退院ということですが、もう80歳を超えているので、思うように歩けないということで住宅改修をすることになりました。
家の中の玄関の手すりやトイレの手すりは専門業者に付けてもらいましたが、通り道の段差のステップや、外のコンクリート製の階段の手すりは自分でつけることにしました。
下の写真が通り道の段差用のステップです。段差が高いので、2段のステップになりました。
a4da3789.jpg


2x4材を3本をベースにして、それに90度クロスするように、下の段は8枚、上の段は4枚の 1x4材をコーススレッドで打ってあります。

外のコンクリート製の階段の手すりです。ブロックで作ってあるので、ブロックを挟み込んで 2x4材を立てられる金具がホームジョイ本田に売っていたので、買ってきて使いました。
9c14969d.jpg


どうですか?斬新な形でしょう?斜めよりも手すりも階段状になっていたほうが、使いやすいし作りやすいと思います。
右手は杖で、左手で掴みます。掴む方の手すりは登りよりも下りのほうが50mm高くしてあります。この方が使いやすいです。

AXI VDMAを使ったカメラ画像回路の作製1(プロジェクトの作製)”の続き。

AXI VDMAを双方向でまともに動かしたことが1度もないので、動かしてみたいということで、Xilinx社のアンサーを検索してみた。
そうしたところ、”AR# 56623 LogiCORE IP AXI Video Direct Memory Access v6.0 - IPI デザインで S2MM_TREADY がディアサートされたままになる”が見つかった。
このアンサーは、VivadoのIP Integrator 用だが、 s_axis_s2mm_tkeep のデフォルト接続は現在 0 で、すべてのバイトをヌルバイトとして処理して、データをメモリに転送できなくなって、内部バッファーがFULLになると、treadyがディアサートされるというアンサーだ。
今回のAXI VDMAはVer.5.04で、Project Navigatorを使用しているが、一応、tkeep信号を 1 に駆動しておこうと思う。

次に、”AR# 53281 LogiCORE IP AXI Video Direct Memory Access - FSYNC 処理の推奨事項”が見つかった。
それによると、fsync を使ったインターフェースから、SOF(Start Of Frame) on TUSER を使ったインターフェースに移行しているそうだ。積極的に tuser を使ったほうが良いそうだ。

AR# 53281の推奨事項を以下に引用する。

・入力で Video Timing Controller コアを検出モードで使用する。

・Video In to AXI4 Stream コアを使用して入力ビデオ タイミング情報から SOF 信号を生成する。

・AXI VDMA などの該当するコアの SOF on TUSER モードをイネーブルにし、fsync 信号ではなくこれを使用してフレーム同期を行う。コアによって、SOF が自動的にシステム全体に伝搬されます。

・デザインに AXI VDMA が含まれている場合 :
   ・S2MM 側を外部フレーム同期モードに設定し、SOF on TUSER をイネーブルにする。 S2MM_DMACR レジスタの FsyncSrcSelect ビットを 2'b10 に設定してフレーム同期ソースとして TUSER を選択してください。

   ・MM2S 側をフリー ランニング モードに設定する。

   ・fsync 信号を接続する (XPS では接続しなくてもよい)。

・出力で Video Timing Controller コアを生成モードで使用し、ビデオ タイミング情報を再生成する。

・AXI4 Stream to Video Out コアを使用して出力ビデオ データを同期する。


そうか、MM2S側はフリー・ランさせて、VTCでタイミングを再生成させるのか?その場合、AXI VDMAは、fsync を出したら途切れなくデータを供給してくれないと、ビデオ信号が破綻してしまいそうだ。今の自作 custom_vtc IP には、生成モードは無いので、作る必要がある。

詳細は、『AXI4-Stream Video IP およびシステム デザイン ガイド』 (UG934)を参照して欲しいそうだ。

自分の AXI_VDMA 回路を見なおしてみよう。

FPGAの部屋のまとめサイトを更新しました。

ZYBOAXI4バスの演習資料を追加して、その他の記事のまとめをアップロードしました。

ZynqのAXI_ACPポートとAXI_HPポートの性能の違い1(AXI_ACPポート)”の続き。

前回は、AXI_ACPポートを使って、ビットマップ・ディスプレイ・コントローラIPを使用して、AXI_ACPポートからピクセル・データをReadするのをChipScope Proで観察するという方法で性能を見た。今回は、AXI_HP0 ポートを使用して同様に性能を見ようと思う。

最初にAXI_HPポートの Project Navigator のプロジェクトを示す。
2ca7db9e.png


XPSプロジェクトを下に示す。Processing_System_7_0 の S_AXI_HP0 ポートに bitmap_disp_cntrler_axi_master_0 の M_AXIポートが接続されているのがわかる。
b6eaee2b.png


Project Navigator で、論理合成、インプリメント、ビットストリームの生成を行い成功した。
ハードウェア構成をエクスポートして、SDKを立ちあげた。
5d89a4cc.png


FPGAにビットストリームをダウンロードして、ソフトウェアを起動したところ、キャラクタが表示されたが、AXI_ACPポートと違って、AXI_HPポートは、ARMプロセッサでキャッシュをフラシュする命令を実行していないため、表示キャラクタがボロボロになっている。これは、フレームバッファ領域もデータ・キャッシュがONされていることで起こる。
1b4bbe73.jpg


ChipScope Pro を立ちあげて、ARVALIDでトリガしたAXI_HP0 ポートの Read Transaction の波形を下に示す。
b2db1297.png


RVALIDは、データ・チャネルの転送の間はずっと1でReadデータが供給できているのがわかる。

最初のトランザクションを引き伸ばした。
e957e968.png


トランザクション全体の経過時間は 85クロックだった。85クロック x 10nsec(100MHz) = 850 nsec となった。

次に、ARVALIDが 1 になった後で、最初に RVALID が 1 になった時間を計測してみた。これは、アドレスが入ってからデータが出てくるまでのレイテンシに相当する。これは、21クロックだった。つまり、210 nsec となった。
b8617e7e.png


トランザクション全体の経過時間から、データが出るまでのレイテンシを引くとデータ・トランザクション時間になる。これは、640 nsec となった。
次に、データ転送帯域の使用率を計算する。64バーストのデータをフルスピードで転送すると、640 nsec のはずなので、640 nsec / 640 nsec x 100 = 100 % になる。つまりデータ転送帯域幅の 100 % のスループットとなった。

AXI_HP0 ポートのデータ転送帯域使用率は、100 % という結果になった。ChipScope Pro で見えたトランザクションはすべて、RVALIDがデータ・チャネルの転送中はずっと 1、つまり、データ転送帯域使用率は、100 % だった。

ここで、AXI_ACPポートとAXI_HP0ポートのデータをまとめる。

・データ転送帯域使用率
AXI_ACPポート:35 % ~ 71 %      AXI_HP0ポート:100 %

・データが出てくるまでのレイテンシ
AXI_ACPポート:10クロック(100 nsec)  AXI_HP0ポート:21クロック(210 nsec)


上記の様な結果になった。

AXI_ACPポートはキャッシュのコヒーレンシを維持した状態で転送が出来るが、連続バーストするとキャッシュに入っているかいないかを検査する必要がある。キャッシュにない場合には、SDRAMから読んでくる必要があるので、遅くなる可能性がある。これは、画像のピクセル・データをReadするポートとしては向いていない。AXI_HPポートを使うべきである。
一方、AXI_ACPポートは、データが出てくるまでのレイテンシは短いので、メールボックスなど、プロセッサと専用ハードウェアの情報のやりとりに向いていると思う。

(追記)
ちょっと誤解を招く表現だったかもしれないので、追記する。

今回は、画像を表示するため、ピクセル・データをDMAするという状況でのテストだった。つまり、キャラクタを書くスピードは人間の認識できるスピードだった。AXI_HPポートを使用する場合は、ARMプロセッサが書いてからキャッシュをフラシュするするのが正常な手順だ。そうしないと、上の写真に示したように、キャッシュが書き戻された領域と、書き戻されていない領域に別れて、正常に表示されない。キャッシュのフラッシュはソフトウェアで明示的に行う。現在はそのキャッシュのフラッシュのコストを見積もっていない。前述したように、このピクセル・データのDMA用途では、ReadのDMAが殆どを占めて、Writeの方は殆ど専有時間は無い。つまり、キャシュのフラッシュ時間は人間が目に見える時間に行えば良いということになる。キャッシュのフラッシュのコストが問題にならない用途だと言える。(ピクセル・データがL2キャッシュにも入らないので、AXI_HPポートを使うのが適当だとは思う)
次に、MPI通信などのコンピュータ同士の通信用途を考えてみよう。今度は、ARMプロセッサから書かれたデータは1度で必ずRDMAされなければならない。その場合には、FPGA側にDMAコントローラがある場合は、ARMプロセッサのキャッシュをフラッシュしたら、フラッシュ命令の完了を待って、FPGA側のDMAコントローラを起動する必要がある。よって、キャッシュをフラッシュするコストは隠蔽されずに見えてくることになる。その時に、キャッシュをフラッシュする必要があるAXI_HPポートのRDMAが有利か、それともキャッシュをフラッシュしなくても済むAXI_ACPポートの方が有利かは検証していないので、まだわからない?ということになる。(DMA領域をDキャッシュONにしているという条件付き。キャッシュの容量も関係してきます)

つまり、まだ限定された条件での比較ですよ、ということを言いたい訳です。。。

↑このページのトップヘ