最初の記事は、”
AXI VDMAのお勉強”
前の記事は、”
AXI VDMAのお勉強３（Scatter Gather Mode）”
AXI VDMA General Operations（93ページ）AXI VDMA Frame Boundary・フレーム境界はモードによって様々。
・external fsync mode の場合は、チャネルの同期入力、mm2s_fsync と s2mm_fsync でフレーム境界が決まる。
・AXI VDMAが同期出力の mm2s_fsync_out か s2mm_fsync_out をアサートした後で、フレームの画像データ転送が始まる
・同期入力から同期出力までは、パイプラインの遅延があるそうだ。
・free run mode (C_USE_FSYNC = 0) では、内部で同期信号を生成している。
・フレーム境界で、同期出力の mm2s_fsync_out か s2mm_fsync_out をアサートする。
・S2MMチャネルの場合は、予定のデータを受信した時にハングアップするのを避けるため s_axis_s2mm_tready をアサートし続ける。これは、C_USE_FSYNC=1,3 and C_FLUSH_ON_FSYNC=1,3の場合だ。
・それは、適切なエラービットをセットするそうだ。エラービットのテーブルは、Table 3‐12: MM2S Errors、Table 3‐13: S2MM Errors（112ページ）を参照。
・画像のパラメータをアップデートしたときは、同期出力の mm2s_fsync_out か s2mm_fsync_outと一緒に、mm2s_prmtr_updateまたはs2mm_prmtr_updateをアサートする。
推奨：S2MMのデットロックのシナリオは、TUSER(0)をSOFとして使用していた時、ストリーミング・マスタが、s2mm_prmtr_updateがアサートするのを待って、s_axis_s2mm_tvalidをドライブする時だ。AXI VDMA は、TUSER(0)がアサートされ、s2mm_prmtr_updateをドライブするのを想定しているからだ。ストリーミング・マスタは、データ転送する際に s2mm_prmtr_update に依存しないようにする。
AXI VDMA Video Transfer・データはシステムメモリからストリームまたは現在操作対象のフレームと垂直サイズ、水平サイズ、ストライドの開始アドレスで定義されているシステムメモリにストリームで転送される。
・下の図に、システムメモリに記憶された一般的なビデオ画像を示す。画像メモリの一部分を表示している。
・Horizontal Sizeのバイト数分のVertical Sizeのラインが、システムメモリのビデオ・フレームのスタート・アドレスの番地から転送される。
Free Run Mode (C_USE_FSYNC = 0)・free run mode (C_USE_FSYNC = 0)では、ビデオデータは可能な限り速く転送される。
・フレームの境界を示すのが、mm2s_fsync_outとs2mm_fsync_out。
・スタートアップ時に、各チャネルのDMACR.RSを１にし、ビデオのパラメータを設定した後で、最初の同期信号（mm2s_fsync_out か s2mm_fsync_out）をアサートする。（AXI VDMAが）
・最初の同期信号（mm2s_fsync_out か s2mm_fsync_out）をアサートすると最初のフレームが始まる。
・MM2Sチャネルでは、mm2s_fsync_outをアサート後に、ビデオデータがDMA転送される。
・S2MMチャネルでは、s2mm_fsync_outの後で、フレームのビデオデータをAXI VDMAにDMA転送する。
Frame Sync Mode (C_USE_FSYNC = 1,2,3)続きます。
- 2013年05月20日 05:14 |
- IP
-
| トラックバック:0
-
| コメント:0
今日は下の娘と、
クレヨンしんちゃん、B級グルメ、サバイバル（映画）を見て来ました。とっても面白かったです。笑いました。クレヨンしんちゃんシリーズはとっても面白いです。好きです。
- 2013年05月19日 17:59 |
- 日記
-
| トラックバック:0
-
| コメント:0
最初の記事は、”
AXI VDMAのお勉強”
前の記事は、”
AXI VDMAのお勉強２（Register Direct Mode）”
Scatter Gather Mode (C_INCLUDE_SG = 1) （92ページ）Scatter Gather Modeとは、AXI VDMA操作が実行されるDMA操作のリストを保持するメモリ常駐のデータ構造を必要とする。DMA命令のリストは、ディスクリプタのチェーンと呼ばれるもので構成されている。各ディスクリプタは、処理すべき次の記述子へのポインタを持っていて、最後のディスクリプタはチェーンの最初のディスクリプタへのポインタを持っている。つまりチェーンをグルっと回ってDMA転送しているわけね。
VDMAを行う前に、descriptor pointer registers と DMA control registers をセットアップする。下に最低限の手順を示す。
１．チャネルの CURDESC_PNTRレジスタに有効なポインタを書く (Offset 0x08 for MM2S and 0x38 for S2MM)。
２．チャネルの DMACRレジスタにコントロール情報を書く (Offset 0x00 for MM2S and 0x30 for S2MM) 。いろいろな設定があるが、DMACR.RS=1でDMAが開始される。DMAのステータス・レジスタのHalt解除（DMASR.Halted = 0）にはタイムラグがあるそうだ。
３．チャネルの TAILDESC_PNTRレジスタに有効なポインタを書く (Offset 0x10 for MM2S and 0x40 for S2MM)。ディスクリプタをフェッチし、そして処理してチャネルをスタートする。
４．DMA scatter gather処理は、TAILDESC_PNTRが処理されるまで続く。終了すると DMASR.Idle = 1となる。
・C_NUM_FSTORESの値だけ、ディスクリプタのチェーンがある。
・Scatter Gatherエンジンは、ディスクリプタを読んで、内部レジスタをアップデートする。
・画像のタイミング情報 (vsize, hsize, stride, and frame delay)は、最初のディスクリプタから読まれて、その後のディスクリプタの画像情報は無視される。
・スタート・アドレスは、C_NUM_FSTORESの数のスタート・アドレス・レジスタに書き込まれる。
・ディスクリプタのポインタが、TAILDESCなった次の frame sync（C_USE_FSYNC = 0だと内部同期信号で、 C_USE_FSYNC = 1,2,3だと外部同期信号）でIDLE状態になるそうです。
・次の frame syncで、DMAコントローラは、新たに更新された値で動作するように内部レジスタセットを変更する。（あまり意味がよくわからない？)
・途中、言っている意味がよくわからないので飛ばします。
・DMAコントローラは、SGエンジンは、末尾ポインタに到達して一時停止した場合でも、映像データを転送し続ける。これは、中断のないビデオ·データ転送を可能にする。
Updating Video Transfer Information（93ページ）・ビデオ転送情報を更新するには、CPUが新しいスタート・アドレス、vsize, hsize, stride や frame delay情報をTAILDESC で示されたメモリアドレスの後に書く。
・その後で新しいTAILDESC を指定すると、自動的に Scatter Gather DMAするようです。
・チャネルに新しいパラメータで動作した時、mm2s_fsync と s2mm_fsync に同期して、mm2s_prmtr_update とs2mm_prmtr_update が出力される。
（重要） On the S2MM channel, new video line size and number of video lines need to change following the assertion of s2mm_prmtr_update or undefined results occur.
そのまま引用。S2MMチャネルでは、画像のラインサイズやライン数を変更した後に、s2mm_prmtr_update がアサートされるか、定義されていない結果が起こると言っているのだろうか？（英語に自信が無いので、すみません）
・ AXI VDMA Scatter Gatherエンジンは、MM2SとS2MMチャンネルに独立のディスクリプタキューと内部レジスタセットを持っていて、独立に動作する。
Additional Design Information（101ページ）Scatter Gather Descriptorディスクリプタ・チェーンは、MM2S_FRMSTORE and S2MM_FRMSTORE ディスクリプタから構成されて、1つのディスクリプタは32ビット7個で構成されるそうです。
ディスクリプタの構成が102ページから105ページまでに書いてあります。
- 2013年05月19日 05:15 |
- IP
-
| トラックバック:0
-
| コメント:0
最初の記事は、”
AXI VDMAのお勉強”
前の記事も、”
AXI VDMAのお勉強”
”LogiCORE IP AXI Video Direct Memory Access v5.04a Product Guide PG020 December 18, 2012”を参考にしながら、勉強したことを書いておこうと思う。
AXI VDMAはマニュアルが152ページもあって、どうやって使うか覚えるのが大変だが、90ページの Programming Sequence を読みながら、覚書を書いていこうと思う。
まず、レジスタについては、30ページからの Register Space を参照のこと。MM2S用、S2MM用のレジスタが並んでいる。印象的なのは、それぞれのスタート・アドレス・レジスタが16個ずつあることだ。
Register Direct Mode (C_INCLUDE_SG = 0) （90ページ）
・register direct modeは、ビデオのパラメータとスタート・アドレス・レジスタに開始アドレスをセットして、DMA Control Register をセットする。
１． DMACR register (Offset 0x00 for MM2S and 0x30 for S2MM)に値をセットする。下に、Figure 2‐3: MM2S DMACR Register を引用する。
いろいろな設定があるが、DMACR.RS=1でDMAが開始される。DMAのステータス・レジスタのHalt解除（DMASR.Halted = 0）にはタイムラグがあるそうだ。
DMACR = 0x00000003 ( Circular Mode, Run)
２．ビデオのフレームバッファのアドレスを1からN個まで書く。Nはどこで決まっているかというと、C_NUM_FSTORES で決まるディフォルトは3個。0x5Cから0x98までの16個がMM2S用で、0xACから0xE8までの16個がS2MM用。
３．Frame DelayとストライドをFRMDLY_STRIDEレジスタに設定する (Offset 0x58 for MM2S and 0xA8 for S2MM)。
ビットマップ・ディスプレイ・コントローラで、1ピクセルRGB合計4バイトで表される。
ストライドは、SVGAの横ピクセル800ピクセル X 4バイト = 3,200を設定する。（94ページのAXI VDMA Video Transfer、Figure 3‐1: Example Video Image Transfer を参照）描画領域は1面しか用意しないため。図1参照。
図1 画像データの描画領域
４．有効な水平サイズをHSIZEレジスタに設定する。 (Offset 0x54 for MM2S and 0xA4 for S2MM)
５．有効な垂直サイズをVSIZEレジスタに設定する。 (Offset 0x50 for MM2S and 0xA0 for S2MM)
画像データを転送するチャネルがスタートする。
（重要） On the S2MM channel, new video line size and number of video lines need to change following the assertion of s2mm_prmtr_update or undefined results occur.
そのまま引用。S2MMチャネルでは、画像のラインサイズやライン数を変更した後に、s2mm_prmtr_update がアサートされるか、定義されていない結果が起こると言っているのだろうか？（英語に自信が無いので、すみません）
Updating Video Transfer Information （91ページ） Register Direct Mode (C_INCLUDE_SG = 0)で、描画している最中に、画像のパラメータやスタート・アドレスをいじることができる。垂直サイズ・レジスタに書くと、フレーム境界で反映される。
変更された画像パラメータをAXI VDMAが使うと、各チャネルの pmrtr_update 出力 ( mm2s_prmtr_update and s2mm_prmtr_update ) がアサートされる。
AXI VDMAが動作中に画像パラメータを変更するときは、初期化の時と同様に設定する。
１．変更したいチャネルに、任意の順序で Frame Delay, Stride, and Horizontal Size を書く。
２．最後に、Vertical Size を書く。Vertical Size をレジスタに書いた時には、すぐに動作中のパラメータに入れされずに、フレーム境界で変更される。（当たり前ですよね。画像が乱れちゃう。内部レジスタに書かれてから、フレーム境界でコピーされるようです）
C_ENABLE_VIDPRMTR_READS = 0 にすると、Register Direct Mode で画像パラメータ用のレジスタ (VSIZE, HSIZE, FRMDLY_STRIDE, and START ADDRESS/ES) をディスエーブルして、FPGAのリソースを削減できるそうです。最初に決めたパラメータから変更できないということでしょうかね？
次の記事は、”
AXI VDMAのお勉強３（Scatter Gather Mode）”
- 2013年05月17日 05:51 |
- IP
-
| トラックバック:0
-
| コメント:0
昨日、
アルテラSoCシンポジウムに行って来ました。
Zynq同様にデュアルコア ARM® Cortex™-A9のHPS（アルテラではPSでなくHPS）とFPGAがチップに入っています。Cyclone V SoCのデュアルコア ARM® Cortex™-A9は800MHz動作といってました。スピードグレードで変更するかも？といってましたが、基本的には 800MHz なんですね？（ZedBoard の Zynq の ARMコアの動作周波数は 667MHz ですが、スピードグレードによって違います）
Zynqとの大きな違いは、Zynq で言うとAXI ACPポートは最大64ビット幅なのですが、SoC FPGAだと最大128ビット幅だそうです。スループットが同じ動作周波数だったら2倍になりそうです。AXI HPポートに類するポートはなかったですが、HPSのDDRコントローラにアクセスするAXIポートが6個あるそうです。ツールでそのポートを設定する時にプルダウンメニューを見ていましたが、256ビット幅までありました。そんなにビット幅があるんでしょうか？かなりスループットがでるのかも？です。そうそう、この辺のAXIポートを設定するツールのデモを見ていたらAXI3と書いてあった気が？します。Xilinxと同じですね。この辺りはARMのIPコアの制限なんでしょうかね？
FPGA側にDDRコントローラのハードコアを載せているのも、大きな違いです。これがあると、FPGA側で画像のフレームバッファを組むことができます。帯域も計算しやすいですね。
後は、FPGAだけでもROMからコンフィギュレーションできるそうです。
Qsysも使いやすそうでしたが、やはり接続が1次元です。見やすさは、2次元で回路図のようにIPを接続できるXilinxのVivado IP Integrator の方が見やすそうでした。使ったことがなくてビデオで見ただけですし、あくまで見やすいという観点だけです。（参考、動画です。
Targeting Zynq Using Vivado IP Integrator）
そうそうARM Development Studio 5 (DS-5) Altera Edition ツールキットとSignalTap II が協調して検証できるのは素晴らしいですね。こういう検証環境を使ってみたいです。Web EditonではDS-5のリモートデバックのみで、USBブラスタは使えないとのことでした。実質、Linuxのみデバックできるということでしょうかね？
評価ボードですが、4種類紹介がありました。
１．
Cyclone V SoC 開発キット値段は、$1,595なので高価ですが、DS-5がUSBブラスタで使えるライセンスが付いているそうです。このボードはHPS部とFPGA部にDDR3が付いているそうです。
２．
Helio(ヘリオ) ボード ～Cyclone V SoC ベーシックボード～25,800円（税別）だそうです。このボードは、FPGA部にDDR3は載っていませんが欲しいです。1.のアルテラ純正ボードとBSP(Board Support Package)互換だそうです。同じSDカードでLinux起動していました。
３．
Arrow's SoCKIT値段はわかりませんが、スイッチなどが付いていて、DE0の雰囲気のボードです。このボードもHPS部とFPGA部にDDR3が付いているそうです。
４．
EBV SoCrates Evaluation Board円盤状の変わったボードです。値段はわかりません？
最後に、SoC FPGAのコニュニティサイトが立ち上がっているそうです。
RocketBoards.orgです。ボードの情報もあります。
追加です。現在のAltera の OpenCLは、プロセッサがx86（古いですか？Intel のPC用のプロセッサ）対応だそうですが、SoC FPGA用のOpenCLも対応中だそうです。
もう一度追加。
富士ソフトが
SoC FPGA にAndroid をポーティングしていました。記憶に間違いがなければ、オープンソースとして出す？そうです（間違っていたらごめんなさい）。グラフィックエンジン（1部かな？）はハードウェアにオフロードしてあるそうです。GPUじゃないとのことです。Android に必要な機能だけを抜き出してFPGAに実装してあるとのことでした。このIPも評価版としてバイナリだけども出すそうです。バイナリと言うのは、SOFファイルなんでしょうか？バイナリなので、ネットリストではないと思います。デモを見て来ましたが、当然ながら描画機能をFPGAにオフロードしてあるほうが速かったです。
＃セミナの資料は、全くもらっていないので、記憶に頼っているため不正確な場合があります。ご了承下さい。また、間違っていたら、コメントでご指摘下さい。よろしくお願い致します。
- 2013年05月16日 05:34 |
- その他のFPGAの話題
-
| トラックバック:0
-
| コメント:0
自作IPでのトリプルバッファリングが完成した。
今度は、トリプルバッファリングを行うことができる
AXI VDMAを使って、現在、ZedBoardでカメラ画像を表示ているシステムを構成してみようと思う。
今までの、AXI VDMAのことを書いたのブログ記事は、”
AXI VDMAのお勉強”がある。
AXI VDMAは、CMOSカメラからの画像をAXI4-Stream で受けて、AXI3 Master WriteでDDR3 SDRAMへWriteしながら、DDR3 SDRAMにバッファされたCMOSカメラからの画像データをAXI3 Master Read で読んできて、AXI4-Stream でビットマップ・ディスプレイ・コントローラへ画像データを転送する。下にそのブロック図を示す。
これから、カメラ・インターフェイスIPとビットマップ・ディスプレイ・コントローラIPをAXI4-Streamに対応するように修正していく予定だ。
AXI4-Stream の解説をしたブログ記事は、”
AXI4-Stream のお勉強”がある。
- 2013年05月14日 05:35 |
- ZedBoard
-
| トラックバック:0
-
| コメント:0
”
Triple Frame Buffer Controller の追加４（IPの追加）”で、トリプルバッファリングのIPをXPSプロジェクトに追加した。
今回は、インプリメントを行なって実機で試してみた。
・PlanAheadでのインプリメントは無事に終了した。
・その後、SDKにハードウェアをエクスポートして、リコンパイルを行った。
・ZedBoardにビットストリームをダウンロードして、ソフトウェアをRunさせた。
カメラの画像は表示されなかった。バグだ。
ChipScope を入れて、いろいろとやってみたが、原因はわからなかった。camera_fb_start_addrも、bitmapd_fb_start_addrも正常のようだ。
原因を突き止めたのは、カメラ・インターフェイスIPとビットマップ・ディスプレイ・コントローラIPのアドレス処理回路にChipScope のプローブを付けた時だった。下に示す。
上の図で、addr_count がビットマップ・ディスプレイ・コントローラIPのアドレス、paddr_reg がカメラ・インターフェイスIPのアドレスを示している。paddr_reg は、正しいアドレスだが、addr_count はアドレスが若すぎる。（addr_count のビットは、[31:3]なので、左に3ビットシフトする。つまり、1F040 は F8200 ）
これはおかしいということで調査したところ、ビットマップ・ディスプレイ・コントローラIPの下位モジュールで、フレームバッファのアドレスを渡すのを忘れていた。下位モジュールのインスタンスの所で、フレームバッファアドレスを下位モジュールに接続する記述を忘れていた。
これで、PlanAheadでインプリメント時に、エラーもワーニングも出ていなかったのだが、これは困る。エラーかワーニングを出してほしい。
ともかく、この行を追加して、もう一度、インプリメントを行った。今度は、ビットマップ・ディスプレイ・コントローラIPのアドレスも正常になった。
見えているビットマップ・ディスプレイ・コントローラIPのアドレスは、0344B240 なので、左に3ビットシフトしたら、1A259200 だった。
ディスプレイに表示してみると、正常に表示された。手を画面上で動かしても横筋は見えない。
SDKでBOOT.bin を作製してSDカードに書いたら正常に動作した。PS-RSTボタンを押さなくても画面が正常に表示されている。どうやら、以前のバージョンで作成したビットストリームをISE14.5のSDKでRun させたり、ブート用のvbinファイルを作成すると調子が悪いようだ。
最後に、カメラのクロックをオシロスコープで測定してみた。カメラに与えているクロックは、PS部のクロックを使用していて、35.714283MHzの設定だった。
実際にカメラに与えているXCLKを下に示す。周波数の実測値は 35.715MHz だった。
カメラから出力されるPCLK は、17.857MHz だった。入力の約半分の周波数だ。これだとフレームレートは 15fps になる。
- 2013年05月13日 05:08 |
- ZedBoard
-
| トラックバック:0
-
| コメント:0
