”
ZYBOにHDLで書いたラプラシアンフィルタを実装する5（IP化） ”の続き。
前回は、HDLで書いたラプラシアンフィルタIP をIP化することができたので、今回は、”
IPをVivadoのIPIに追加して、BOOT.binとデバイスツリーを作り、ZYBO のLinuxでアプリケーションを作る作り方 ”のVivado 2015.3 のプロジェクトのブロックデザインに追加する。（V_ZYBO_CAMDfL144_tu_2 をコピーしてVivado 2015.3 のプロジェクトとした）
・現在のフォルダ名を V_ZYBO_CAMDfL153_tu_HDL に変更した。
・Flow Navigator -> Project Manager -> IP Catalog をクリックして、IP Catalog を表示した。
・右のウインドウにIP Catalog が出るので、どこでも良いから右クリックして、右クリックメニューから IP Setting... を選択した。
・Project Settings ダイアログが立ち上がった。IP が指定されていた。
・Repository Manager タブをクリックすると、IP Repositories に自分で追加したIP が入っていた。
・＋ボタンをクリックして、IP Repositories にHDL で書いたラプラシアンフィルタIP を追加する。
・lap_fil_HDL_axim フォルダを選択した。
・Add Repository ダイアログが表示された。
・lap_fil_HDL_axim IP が IP Repositories に追加された。
・IP Catalog に lap_fil_HDL_axim IP が追加された。
・V_ZYBO_CAMDｆL ブロックデザインを開いた。
・Add IP ボタンをクリックして lap_fil_hdl_axim_V1_0 を追加する。
・lap_fil_hdl_axim_V1_0 が追加された。
・右上のRun Connection Automation をクリックして、lap_fil_hdl_axim_V1_0 の配線を自動接続する。
・Run Connection Automation が表示された。
・All Automation にチェックを入れた。
・M_AXI を選択して、Slave を /processing_system7_0/S_AXI_HP2 を選択した。
・s_axi_lite を選択して、/processing_system7_0/M_AXI_GP0 が選択されているのを確認した。
・AXI_Interconnect のポートが自動的に増えて、lap_fil_hdl_axim_V1_0 が自動的に接続された。
・Regenerate Layout ボタンをクリックして、レイアウトを再生成した。
・Address Editor を示す。
lap_fil_hdl_axim_V1_0 は、Axi Lite Slave として、0x43C30000 番地にマップされた。
・ブロックデザインをセーブした。
・ウインドウをドックした時の、プロジェクトを示す。（Vivado 2015.3 を使用）
2015年10月31日 04:30 |
ZYBO
| トラックバック:0
| コメント:0
”
ZYBOにHDLで書いたラプラシアンフィルタを実装する5（IP化） ”でHDL で書いたラプラシアンフィルタをIP にすることができた。
これからVivado プロジェクトのIP Integrator のブロックデザインにHDL で書いたラプラシアンフィルタIP を追加して、論理合成、インプリメントを行い、SDKにハードウェアをエクスポートして、FSBLとビットストリームとU-boot でBOOT.bin を生成する。
また、Linux で zynq-zybo.dts にHDL で書いたラプラシアンフィルタIPのエントリを追加して、コンパイルしてdevicetree.dtb を生成する。
BOOT.bin とdevicetree.dtb をUbuntu 14.04 のRoot file system が入ったSDカードのMS DOSパーティションに入れて、ZYBOに入れてUbuntu 14.04 をブートする。
ZYBO のUbuntu 上で、アプリケーションをVivado HLS で生成されたドライバを使用して作製する。
このような手順で作製していくのだが、この手順を忘れてしまった。
そこで、もう一度おさらいしようと思う。
まずは、Vivado HLS 2014.4 で生成したラプラシアンフィルタIP をカメラ・コントローラIP やビットマップ・ディスプレイ・コントローラIP が接続れたブロックデザインに入れて、ZYBO のUbuntu 上でアプリケーションを作った時のFPGAの部屋の記事をまとめる。
Vivado HLS 2014.4でラプラシアン・フィルタ関数をaxi masterモジュールにする3（IP Catalog にVivado HLSのIPを追加） Vivado HLS 2014.4でラプラシアン・フィルタ関数をaxi masterモジュールにする4（ブロックデザインにVivado HLSのIPを追加、インプリメント） Vivado HLS 2014.4でラプラシアン・フィルタ関数をaxi masterモジュールにする5（BOOT.bin, devicetree.dtb の生成） Vivado HLS 2014.4でラプラシアン・フィルタ関数をaxi masterモジュールにする6（/sys, /devディレクトリ） Vivado 2014.4のCドライバーファイル１ Vivado 2014.4のCドライバーファイル2 ZYBO Linux (Ubuntu 14.04 LTS) 上でMakefile を作ってラプラシアンフィルタIPの制御ソフトをコンパイル ZYBO Linux (Ubuntu 14.04 LTS) 上でMakefile を作ってラプラシアンフィルタIPの制御ソフトをコンパイル2 これで、ラプラシアンフィルタIP をVivado のブロックデザインに入れて、Linux上で動作される方法は終了なのだが、現状の最新プロジェクトはどうなのかというと、おるさんのコードを元に、tu1987さんが書いてくれたC++ソースコードをVivado HLS 2014.4 で高位合成し、IP化したプロジェクトが最新となっている。
Vivado HLS 2014.4 で合成したラプラシアンフィルタIPの高速化16（性能が最大になる設定を探る8、追加2） このプロジェクトでは、ラプラシアンフィルタのみの処理時間は 15.3 ms となった。
但し、タイミングエラーが出ているので、インプリメント時のStrategy を変更してインプリメントを行う方法で複数のインプリメントを実行して、一番良い物を使う方法でインプリメントを行った。
Vivado 2014.4 でインプリメント時にStrategy を変更してインプリメント結果を改善する ブログにログが残っていると本当に助かる。。。自分でも。
ログ残っていなかったら、やり方を再度検索する必要がある。ブログは自分にとって、欠かせない補助記憶だ。。。
V_ZYBO_CAMDｆL_tu_2フォルダのプロジェクトをVivado 2015.3 のプロジェクトに変換してインプリメントを行った結果を下に示す。
やはり、通常にインプリメントしたのでは、タイミングエラーが発生している。
2015年10月30日 04:50 |
Linux
| トラックバック:0
| コメント:0
昨日、
Adafruit の2.8インチのタッチ付き液晶ディスプレイ が届いた。
Arduino のコネクタに嵌合するヘッダが付いているタッチ付き液晶ディスプレイだ。
これは、Rocketboards.org の
OpenCL Mandelbrot Demo on Atlas-SoC をやるために購入した。
Adafruit に2015年の10月15日に注文して、2015年の10月28日に届いた。13日で届いたの優秀だと思うが、トラッキングが酷かった。
Shipping は USPS (United States Postal Service) でお願いしたのだが、トラッキングはジャマイカに届いたということになっているので、とっても心配した。
Adafruit にメールしたのだが、USPSのトラッキングは当てにならないということだった。ドキドキだったが届いて良かった。
価格はタッチ付き液晶ディスプレイが $34.95 、Shipping が $12.85 で合計 $47.80 だった。Paypal で支払いをしたが、日本円で 5,908 円だった。
これで、DE0-Nano-SoC でマンデルブローが試せる。OpenCLのライセンスが無いので、コンパイルは出来ないのが残念だが。。。
2015年10月29日 04:50 |
DE0-Nano-SoC
| トラックバック:0
| コメント:4
”
ZYBOにHDLで書いたラプラシアンフィルタを実装する4（シミュレーション） ”の続き。
前回、シミュレーションで動作を確認できたので、今回はIP化を行う。使用するVivado のバージョンは 2015.3 だ。
Tools メニューから Create and Package IP... を選択する。
Create and Package IP.ダイアログが開いた。
Create Peripheral, Package IP or Package a Block Design
Package Your Curent Project
New Creation
Package IP ウインドウの Identification が開いた。
Compatibility
File Groups
Customization Prameters
Ports and Interfaces
Addressing and Memory は warning が出ていた。
Addressing and Memory の Range Dependency を ”pow(2,12)”に変更したら、warning は無くなった。
Customization GUI
Review and Package で、Package IP ボタンをクリックした。
Package IP ダイアログが出て、成功したそうだ。
IP化できた。
2015年10月28日 04:38 |
ZYBO
| トラックバック:0
| コメント:0
”
ZYBOにHDLで書いたラプラシアンフィルタを実装する3（FIFO の生成3） ”の続き。
前回で、FIFO IPの生成は終了した。今回は、シミュレーションを行う。
最初に、自作した Verilog HDLソースコードを示す。Verilog HDLソースコードは以前と同じだが、トップの名前を lap_filter_axim.v から lap_fil_hdl_axim.v に変更した。モジュール名も lap_fil_hdl_axim に変更した。
Verilog HDL ソースコードは、以下の記事のあるので、参考にされたい。
AXI4 Master アクセスのラプラシアン・フィルタ IP5(lap_filter_axim.v のHDLソース) AXI4 Master アクセスのラプラシアン・フィルタ IP6(lap_filter_axim_LiteS_if.v のHDLソース) AXI4 Master アクセスのラプラシアン・フィルタ IP6(line_read_and_y.v と Dual_Port_Memory.v) AXI4 Master Interfaceモジュールの作製4(axi4_master_inf.v のHDLソース) テストベンチ用の axi_slave_BFM はこちら。
AXI4 Slave Bus Functional Model のVerilog HDL版２ シミュレーション用 同期FIFO IP テストベンチはすでに作ってあるので、Vivado 2015.3 でシミュレーションを行った。
AXI4 Master の波形を示す。
最初に2ラインをAXI4 Master Read して、3ライン目をAXI4 Master Read しながら、ラプラシアンフィルタ演算処理をリアルタイムで行っているので、Read が終了したら、すぐにAXI4 Master Write が始まる。完全にパイプラインされていて無駄はない。
更に、3ライン目の3番目のピクセルデータが来たところからラプラシアンフィルタ処理が始まっているので、すぐにWrite を初められる。つまり、メモリ帯域に空きがあるのが前提だが、更に処理時間を縮める事が可能だ。
1フレームの最後までシミュレーションを行った。約、9.9 ms 程度でラプラシアンフィルタ処理が終了した。
テストベンチの lap_fil_hdl_axim_tb.v を貼っておく。
`default_nettype none
2015年10月27日 05:00 |
ZYBO
| トラックバック:0
| コメント:0
”
ZYBOにHDLで書いたラプラシアンフィルタを実装する2（FIFO の生成2） ”の続き。
前回まででは、Write用のFIFO を生成したので、今回はRead用のFIFO を生成する。
最初に、read_adfifo を生成する。
Coregen を立ち上げて read_adfifo の設定を見た。
Vivado 2015.3 の read_adfifo の FIFO Generator の画面を示す。
Native Ports タブ
Status Flags タブ
Data Counts タブ
Summary タブ
OK ボタンをクリックすると、Generate Output Products ダイアログが表示された。
Generate ボタンをクリックした。
ダイアログが表示されたので、OKボタンをクリックした。
これで、read_adfifo の生成が終了した。
次は、read_adfifo_outs を生成する。
Coregen を立ち上げて read_adfifo_outs の設定を見た。
Vivado 2015.3 の read_adfifo_outs の FIFO Generator の画面を示す。
Native Ports タブ
Status Flags タブ
Data Counts タブ
Summary タブ
OK ボタンをクリックすると、Generate Output Products ダイアログが表示された。
Generate ボタンをクリックした。
ダイアログが表示されたので、OKボタンをクリックした。
これで、read_adfifo_outs の生成が終了した。
最後は、read_fifo を生成する。
Coregen を立ち上げて read_fifo の設定を見た。
Vivado 2015.3 の read_fifo の FIFO Generator の画面を示す。
Native Ports タブ
Status Flags タブ
Data Counts タブ
Summary タブ
OK ボタンをクリックすると、Generate Output Products ダイアログが表示された。
Generate ボタンをクリックした。
ダイアログが表示されたので、OKボタンをクリックした。
read_fifo の生成が終了した。
これで、すべてのFIFOが生成された。Vivado 2015.3 のプロジェクトを示す。
試しに合成してみたが、成功した。
合成結果は削除した。
すべてのFIFO の設定表を示す。
2015年10月26日 04:01 |
ZYBO
| トラックバック:0
| コメント:0
”
ZYBOにHDLで書いたラプラシアンフィルタを実装する1（FIFO の生成1） ”の続き。
前回は、write_adfifo の生成を行ったが、今回はその続きで、Write関連のFIFOの生成を行う。
最初に write_adfifo_outs の生成を行う。
Coregen を立ち上げて write_adfifo_outs の設定を見た。
Vivado 2015.3 の write_adfifo_outs の FIFO Generator の画面を示す。
Native Ports タブ
Status Flags タブ
Data Counts タブ
Summary タブ
OK ボタンをクリックすると、Generate Output Products ダイアログが表示された。
Generate ボタンをクリックした。
ダイアログが表示されたので、OKボタンをクリックした。
これで、write_adfifo_outs の生成が終了した。
次に、write_fifo の生成を行う。
Coregen を立ち上げて write_fifo の設定を見た。
Vivado 2015.3 の write_fifo の FIFO Generator の画面を示す。
Native Ports タブ
Status Flags タブ
Data Counts タブ
Summary タブ
OK ボタンをクリックすると、Generate Output Products ダイアログが表示された。
Generate ボタンをクリックした。
ダイアログが表示されたので、OKボタンをクリックした。
これで、write_fifo の生成が終了した。
Write関連のFIFOの生成は終了した。
2015年10月25日 09:01 |
ZYBO
| トラックバック:0
| コメント:0
Atlas-SoC のÅngström Distribution にOpenCV をインストールした。
最初に参考させて頂いたサイトを紹介する。”
Intel Edison + OpenCVで顔認識 ”だ。
そのサイトに従って、opencv をインストールした。
最初は、update と upgrade を行った。
opkg update
次に opkg で opencv をインストールした。
opkg install opencv
次に python-opencv をインストールした。
opkg install python-opencv
python-opencv のインストールが終了した。
haarcascade_frontalface_alt.xml のダウンロードだが、”
Intel Edison + OpenCVで顔認識 ”に書いてあるサイトから wget しても無いと言われてしまう。
そこで、VNCを立ちあげて、Atlas-SoC に接続して、そこの Midori ブラウザからダウンロードすることにした。URLを示す。
http://sourceforge.net/projects/roboticscode/files/Face%20Tracker/haarcascade_frontalface_alt.xml/download?use_mirror=jaist&r=http%3A%2F%2Fosdn.jp%2Fprojects%2Fsfnet_roboticscode%2Fdownloads%2FFace%2520Tracker%2Fhaarcascade_frontalface_alt.xml%2F&use_mirror=jaist
Save As ボタンをクリックして、/home/root/ にセーブした。
次は、サンプルのレナ像をダウンロードする。下のURLからレナ像をダウンロードさせて頂いた。
http://www.eml.ele.cst.nihon-u.ac.jp/~momma/wiki/wiki.cgi/RSJ2011.html
レナ像の所で、右クリックメニューから、Save Image As を選択した。
ダイアログが出てくるので、Save As ボタンをクリックした。
/home/root/ に lena.jpg という名前でセーブした。
確かにセーブ出来ている。
次に、顔検出をするソフトウェアを用意する必要がある。これは、”
python+OpenCVで顔認識をやってみる ”の recognize.py を使わせて頂いた。
Midori で”
python+OpenCVで顔認識をやってみる ”を表示して、gedit を立ちあげて、Python コードをコピー・アンド・ペーストした。
更に、cascade_path を変更した。日本語がトーフになっているが気にしない。。。
recognize.py をセーブした。
VNC 上で Terminal を立ちあげて、
python recognize.py
を実行した。
すると、detected.jpg が生成された。
detected.jpga を表示すると、レナ像の顔が検出されていた。
GIMPが入っているので、GIMPで画像を表示しているが、起動が重い。。。
2015年10月24日 07:36 |
DE0-Nano-SoC
| トラックバック:0
| コメント:2
以前、ZedBoard 用にHDLで書いたラプラシアンフィルタのIP があった。（”
AXI4 Master アクセスのラプラシアン・フィルタ IP９（できた。完成） ”）
これをZYBO用にVivado 2015.3 で再度実装してみたいと思う。
ZYBO 用のVivado のプロジェクトにしたのだが、Coregen でつくってあるFIFOは読み込めない。
そこでFIFO Generator で作り直すことにした。
FIFO は汎用AXI Master IP の所に使われているので、
”AXI4 Master Interfaceモジュールの作製２（シミュレーション） ”のISE プロジェクトを立ちあげてFIFO の設定を真似て、Vivado の FIFO Generator で設定を入れることにした。
ISEを立ち上げるのは久しぶりだ。懐かしい。。。
Coregen を立ち上げて write_adfifo の設定を見た。
Vivado 2015.3 の write_adfifo の FIFO Generator の画面を示す。
Native Ports タブ
Status Flags タブ
Data Counts タブ
Summary タブ
OK ボタンをクリックすると、Generate Output Products ダイアログが表示された。
Generate ボタンをクリックした。
ダイアログが表示されたので、OKボタンをクリックした。
これで、write_adfifo の生成が終了した。
2015年10月23日 05:08 |
ZYBO
| トラックバック:0
| コメント:0
”
”Atlas-SoC素晴らしいんじゃないの”をやってみる2 ”の続き。
Atlas-SoC のイメージを Micro SD カードのWrite して、DE0-Nano-SoC ボードに挿入した。USBをLAN接続するドライバをインストールし、Web ページを表示している。
今回は、Try -> Developing on the Atlas-SoC Board (via SSH or VNC) の VNC をインストールしてみた。
そのページのVNC の Download ボタンをクリックしてTightVNC をダウンロードした。
TightVNC のWindows 64 ビット版をダウンロードして、インストールした。
TightVNC Viewer を立ちあげて、Remote Host に 192.168.7.1 を指定して Connect した。
すると、DE0-Nano-SoC ボードで起動しているLinux のディスクトップが見えた。
Web ブラウザ（Midori）も起動できるし、File Manager も起動することができた。
但し、Midori は日本語フォントが入っていなかった。
これで、大体、”
Atlas-SoC素晴らしいんじゃないの ”の内容は終了だ。
2015年10月21日 04:26 |
DE0-Nano-SoC
| トラックバック:0
| コメント:0
”
Atlas-SoC のMicro SD カードでLinux をブートした時のブートメッセージ ”を見ると、Atlas-SoC のMicro SD カードのLinux Distribution は
Ångström Distribution の様だ。
YOCTO PROJECT COMPATIBLE, 1.7 THIS TIME ということなので、Yocto コンパチのLinux のようだ。
”
BeagleBoard-xMでAngstrom Linuxを動かす ”によると、Angstromのオンラインビルダー・ページがあって、Webページ上で設定していくことによってLinux のシステムイメージをビルドできるということだが、今はWebページが無くなっているようだ。
opkg update
をやってみた。（VNC の環境がすでに走っている）
真ん中のターミナルで opkg upgrade を実行中だ。
終了したらVNC Viewer が落ちてしまった。
シリアルから reboot して、もう一度、VNC Viewer を立ちあげて、DE0-Nano-SoC ボードに接続した。
”
BeagleBoard-xMでAngstrom Linuxを動かす ”を参考に
タイムゾーンを UTC から JST に変更した 。
（2015/10/23：追記 JSTに変更するとVNC Viewer で接続した時にネットに繋がらない気がするので、UTCのままの方が良さそうだ） cd /etc
2015年10月21日 04:05 |
DE0-Nano-SoC
| トラックバック:0
| コメント:0
Atlas-SoC のMicro SD カードでLinux をブートした時のブートメッセージが取得できたので、貼っておく。
0
アスキーアートが潰れているので、下に貼っておく。
2015年10月21日 03:37 |
DE0-Nano-SoC
| トラックバック:0
| コメント:0
”
”Atlas-SoC素晴らしいんじゃないの”をやってみる1 ”の続き。
前回、Atlas-SoC のイメージを Micro SD カードのWrite して、USBをLAN接続するドライバをインストールし、Web ページを表示するところまでできた。
今回は、”
Atlas-SoC素晴らしいんじゃないの ”を参考に、そのWeb ページを堪能してみたい。
この画面はPlay をクリックしたところだ。Blink The LEDs をクリックした。
Blink The LEDs が表示された。
All On をクリックすると、8個あるLED のうちの一番左のLEDだけが点灯し、順番に右に点灯していく。見ているフラッシャーのようだ。
All Off は一番右のLED が消灯して、順次左のLED が消灯していく。
Blink は一番右のLED が最初について、左のLED が点灯していき、全部のLED が点灯したら、右のLED から消灯していく。フラッシャーのように見える。
Accelerometer はどうやるのか、よくわからなかった。
Fast Fourier Transform をやってみた。
FFTはSine Wave でやってみた。
Data Source in HPS と Data Source in FPGA の2つの方法でFFT をテストしているようだ。それぞれ、FFT の大きさごとに評価している。Data Source in HPS では、256 データでは、CPU の方が速いがそれ以外はFPGA でやったほうが速いという結果だ。
その下に、Data Source in HPS と Data Source in FPGA のブロック図がある。
最初にData Source in HPS を下に示す。
CPU Procesing は925MHzのDual Core CPUで SDRAM 上のRAM Disk 上からソースデータをCPU が読んできて、NEON コプロセッサを使った計算ライブラリを使ってFFT して、またRAM Disk に書き込むそうだ。
FPGA Processing は100MHz動作のFFT コアを使用しているそうだ。
FPGAを使ったFFT では、RAM Disk の内容をFFT 上のDMA がACP ポートを使用してRead し、FPGA上のFFT エンジンがFFT を行って、やはりACP ポートを使って、RAM Disk に書き込むそうだ。
次は、Data Source in FPGA を下に示す。
CPU Procesing は925MHzのDual Core CPUを使用している。
FPGA 上のDMA コアがACP ポートを経由してRAM Buffer のデータをCPU に送り、CPUがFFT を行う。たぶん、NEON コプロセッサを使っているんだろう？
FPGA Processing は同様に100MHz動作のFFT コアを使用しているそうだ。
FPGA 上のRAM Buffer のデータをDMA がFFT エンジンに送って、FFT を行い、別のDMA がACP ポートを通して、SDRAM に書き込むそうだ。
ブロック図まで付いていて、構造がわかりやすい。面白い。
2015年10月20日 04:17 |
DE0-Nano-SoC
| トラックバック:0
| コメント:2
”
Atlas-SoC素晴らしいんじゃないの ”をやってみたいということでやってみた。
まずは、手元にあるのは、DE0-Nano-SoC で Atlas-SoC じゃないので、Atlas-SoC のSDカード・イメージをダウンロードした。
RocketBoard.org に
Atlas-SoC Development Platform があるが、その
Getting Latest SD Card Image から atlas_sdcard_v1.1.img.tgz をダウンロードした。
この atlas_sdcard_v1.1.img.tgz を Lhaplus で解凍するときちんと解凍できなかったので、Cygwin を起動して、
tar zxvf atlas_sdcard_v1.1.img.tgz で解凍することをお勧めする。（Windows 7 です）
そうすると atlas_sdcard_v1.1.img が解凍できた。
新品の Class 10 の 8 GB Micro SD カード（4GBでも Class 4 でも良さそう）を SD Card Reader/Writer に入れて、パソコンに接続した。
まずは、
SDFormatter でフォーマットしないと Win32 Disk Imager でイメージを書くことが出来なかった。
SDFormatter でフォーマットした。
次に、
Win32 Disk Imager を立ちあげて、atlas_sdcard_v1.1.img を選択した。
Write ボタンをクリックして、イメージをMicro SD カードにWrite した。その際に、書き込むMicro SD カードかどうか必ずチェックすること。
イメージのWrite が始まった。
イメージのWrite が終了すると、Windows に Micro SDカードのドライブが認識された。
VirtualBox 上のUbuntu 14.04 にMicro SDカードをマウントすると、2つのドライブが見えた。やはり、Root File System がある。
UART と USB OTG のUSBケーブルをパソコンに接続した。
FPGA Configuration Mode Switch (MSEL[4:0]） = 01010 (ON OFF ON OFF ON OFF）と設定した。
Micro SDカードを、DE0-Nano-SoC に入れて、電源ONした。
シリアルポートに Tera Term で接続すると、Linux が起動しているのが見えた。
USB OTG の方は、パソコンがドライバを検索していたが、2つほど入らなかった。
ドライバは2 つ入らなかったが、ドライブがマウントされた。
フォルダを見ると、start.htm があるので、ダブルクリックした。
すると start.htm が立ち上がった。
ドライバをインストールしろと書いてあった。
G:\Drivers\Windows の下にある ATLAS_D64.exe をダブルクリックしてインストールした。（Windows 7 64 ビット版）
デバイス・ドライバのインストールが始まった。
途中で、Linux Developer Community ネットワーク アダプターをインストールするか聞いてくるので、インストールボタンをクリックする。
デバイス・ドライバのインストールが終了した。
192.168.7.1 を見ると、ATLAS-SoC のページが表示されていた。
2015年10月19日 04:58 |
DE0-Nano-SoC
| トラックバック:0
| コメント:0
Terasic の SoC FPGA（Xilinx で言えば Zynq）ボードの
DE0-Nano-SoC が手に入ったので、やってみることにした。
電源用のACアダプタは 5V - 2A だった。
Micro SDカードが既に入っているので、FPGA Configuration Mode Switch (MSEL[4:0]） = 01010 (ON OFF ON OFF ON OFF）にして、UARTのUSB-mini BコネクタにUSBケーブルを接続してパソコンに接続した。
電源のACアダプタのプラグをDE0-Nano-SoC に接続した。（結構、基板が熱くなる。SoC FPGAを触ってみたがそんなに熱くないので、電源かな？かなり小さな基板なので放熱が厳しいのかもしれない？）
しばらく、パソコンで、UARTのドライバをインストールしていましたが、自動的にネットからドライバを取得できた。
UARTのドライバがインストールされたら、Tera Term を シリアル、115200bps, 8bit, 1 Stopbit に設定するとLinux が動作しているのが確認できた。
Linux はYocto だった。
ls コマンドで、ファイルが見えたが、bt_test というファイルがあった。
ifconfig で見た。まだ LAN ケーブルは接続していない。LAN ケーブルを接続してもinet addr が表示されなかった。DHCPに対応させていないのか？
dmeg を実行した結果を示す。起動時のメッセージだ。
root@socfpga:~# dmesg at 0
DE0-Nano-SoCに添付されていたMicro SDカードの中身です。Ramdiskではなく、Root File System がセカンダリー・ドライブに入っていました。
2015年10月18日 06:01 |
DE0-Nano-SoC
| トラックバック:0
| コメント:0
”
Vivado HLS 2015.3 でアンシャープマスキング・フィルタのC/RTL コシミュレーション ”が成功したので、IP化を行った。
int 型で予め左シフトして小数を整数にして演算するプロジェクトを最初にIP化する。
IP化するにあたって、現在はインクルード・ヘッダで、”A”の画像に合わせたサイズを unsharp_mask_axis.h に設定してるので、それを 720p に変更した。unsharp_mask_axis.h を示す。
// unsharp_mask_axis.h
次に、ブロックレベルのプロトコルが ap_ctrl_hs になっているので、それを ap_ctrl_none に戻した。
これで、もう一度、C から HDL への合成を行った。
BRAM_18K は 8 個、DSE48E は 18 個、FF は 1522 個、LUT は 1629 個使用している。
IP 化を行った。
次は、固定小数点型だ。
同様に、 unsharp_mask_axis.h の画像の大きさを 720p に変更した。unsharp_mask_axis.h を示す。
// unsharp_mask_axis.h k_fixed_td;
次に、ブロックレベルのプロトコルが ap_ctrl_hs になっているので、それを ap_ctrl_none に戻した。
これで、もう一度、C から HDL への合成を行った。
BRAM_18K は 8 個、DSE48E は 18 個、FF は 2152 個、LUT は 1825 個使用している。やはり、int 型で予め左シフトして小数を整数にして演算するのよりも多くのリソースを使用している。
IP 化を行った。
2015年10月17日 05:11 |
Vivado HLS
| トラックバック:0
| コメント:0
Vivado HLS 2015.3 でアンシャープマスキング・フィルタのC/RTL コシミュレーションをやってみる。
Vivado HLS 2015.3 では、Open Wave Viewer ... ボタンが追加されていて、このボタンをクリックするとVivado が立ち上がり、C/RTL コシミュレーションの波形を表示してくれる。
まずは、固定小数点型からシミュレーションを行う。
最初にブロックレベルのインターフェースが ap_ctrl_none ではC/RTL コシミュレーションできないので、ap_ctrl_hs に変更した。
#pragma HLS INTERFACE ap_ctrl_hs port=return
これで、C から HDL への合成をやり直してから、Run C/RTL Cosimulation ボタンをクリックしてC/RTL コシミュレーションを行った。
Co-simulation Dialog の Dump Trace の選択項目に port が増えていたので、port に変更した。多分、ポートの波形をDump するのだと思う。
C/RTL コシミュレーションが行われて結果が表示された。
Latency も Interval も 3114 クロックだった。平均2乗誤差もCシミュレーションと同じだ。
Open Wave Viewer ... ボタンをクリックすると、Vivado 2015.3 が立ち上がって、波形が表示された。
波形ウインドウをフロートして、詳しく波形を観察した。
上の波形で ins_TVALID, ins_TREADY と out_TVALID, out_TREADY はアンシャープマスキング・フィルタ処理をしている間は 1 に固定されて、１クロックごとにフィルタ処理を行っているのが分かった。これで問題ないはずだ。
次に、int 型で予め左シフトして小数を整数にして演算するプロジェクトへ変更した。
ここでもブロックレベルのインターフェースを ap_ctrl_none から ap_ctrl_hs に変更した。
これで、C から HDL への合成をやり直してから、Run C/RTL Cosimulation ボタンをクリックしてC/RTL コシミュレーションを行った。
Co-simulation Dialog の Dump Trace の選択項目に port が増えていたので、port に変更した。
C/RTL コシミュレーションが行われて結果が表示された。
Latency も Interval も 3109 クロックだった。こちらのほうがクロック数が少ない。平均2乗誤差もCシミュレーションと同じだ。
mse_b = 0.0108696
Open Wave Viewer ... ボタンをクリックし、Vivado 2015.3 を立ちあげて波形を表示した。
波形ウインドウをフロートして、詳しく波形を観察した。
固定小数点型の場合と同様に、上の波形で ins_TVALID, ins_TREADY と out_TVALID, out_TREADY はアンシャープマスキング・フィルタ処理をしている間は 1 に固定されて、１クロックごとにフィルタ処理を行っているのが分かった。こちらも問題ない。
2015年10月16日 04:25 |
Vivado HLS
| トラックバック:0
| コメント:0
アンシャープマスキング・フィルタのC++ソースコードによって、Vivado HLS 2014.4 とVivado HLS 2015.3 を比較してみた。
まずは、int 型で予め左シフトして小数を整数にして演算するコードで比較する。同じC++ソースコードを使用する。
最初にVivado HLS 2014.4 のC から HDL への合成結果から示す。
クロック周期のTarget が 10 ns のところ Estimated は 8.22 ns だった。
BRAM_18K が 4 個、DSP48E が 18 個、FF が 1462 個、LUT が 1849 個だった。
Analysis を見るとステート数は32 ステートだった。
次に、Vivado HLS 2015.3 のC から HDL への合成結果を示す。
クロック周期のTarget が 10 ns のところ Estimated は 10.08 ns で、エラーになっている。
BRAM_18K が 2 個、DSP48E が 18 個、FF が 1331 個、LUT が 1575 個だった。Vivado HLS 2014.4 よりも使用リソースは少ない。BRAM も 2 個使用になった。2 ラインしか確保していないので、2 個使用は順当なところだと思う。
Analysis のステート数は 31 ステートだった。
Vivado HLS 2015.3 はステート数も少ないので、もう少しクロック周期の制約を小さな値にしてみる。クロック周期を 8 ns にしてみた。
Estimated は 6.88 ns となった。
BRAM_18K が 2 個、DSP48E が 18 個、FF が 1492 個、LUT が 1575 個だった。FF のみが増えいている。これでもFF、LUT 共にVivado HLS 2014.4 よりも少ない。
Analysis のステート数は 33 ステートだった。
次は、固定小数点型の比較を行う。同じC++ソースコードで比較する。
まずは、Vivado HLS 2014.4 のC から HDL への合成結果から示す。
クロック周期のTarget が 10 ns のところ Estimated は 8.71 ns だった。
BRAM_18K が 4 個、DSP48E が 18 個、FF が 1957 個、LUT が 1993 個だった。
Analysis を見るとステート数は37 ステートだった。
次に、Vivado HLS 2015.3 のC から HDL への合成結果を示す。
クロック周期のTarget が 10 ns のところ Estimated は 10.08 ns で、エラーになっている。
BRAM_18K が 2 個、DSP48E が 18 個、FF が 1603 個、LUT が 1725 個だった。Vivado HLS 2014.4 よりも使用リソースは少ない。やはり、BRAM も 2 個使用になった。
Analysis のステート数は 35 ステートだった。
同様に、Vivado HLS 2015.3 はステート数も少ないので、もう少しクロック周期の制約を小さな値にしてみる。クロック周期を 8 ns にしてみた。
Estimated は 6.65 ns となった。
BRAM_18K が 2 個、DSP48E が 18 個、FF が 2117 個、LUT が 1771 個だった。FF と LUT が増えているが、特に FF の増加が大きい。FF は Vivado HLS 2014.4 よりも多くなった。
Analysis のステート数は 38 ステートだった。
”Vivado HLS 2014.4 vs Vivado HLS 2015.1 vs Vivado HLS 2015.3（AXI4-Stream版ラプラシアンフィルタ IPの比較） ”では、Vivado HLS 2015.3 が良かったが、今回は微妙な結果になった。
迷うところではあるが、Vivado HLS 2015.3 を使ってみようかな？と思う。
2015年10月15日 04:52 |
Vivado HLS
| トラックバック:0
| コメント:0
間に関連の記事は入っているが、一応、”
Vivado HLS によるアンシャープマスクキング・フィルタの作製9（C++ の任意精度固定小数点型3） ”の続き。
”
Vivado HLS によるアンシャープマスクキング・フィルタの作製8（C++ の任意精度固定小数点型2） ”で、int 型で予め左シフトして小数を整数にして演算するコードを書いた。
今回は、ap_int 型で桁を制限してリソース使用量の低減を図ろうと思う。使用しているVivado HLS のバージョンは、2014.4。
ZYBOのプロジェクトを作って、unsharp_mask_axis.cpp と unsharp_mask_axis.h を ap_int 型に修正した。
unsharp_masking() と unsharp_mask_axis.h を示す。
まずは、unsharp_masking() から。
#define PRECISION 6 // 小数点以下の桁数、精度（1以上） int unsharp_masking(int pix_mat[3 ][3 ], int k, int num_adec_k)3 ][3 ];int result=0 ;int z;9 <<(PRECISION+num_adec_k))/k + (8 <<PRECISION);for (int i=0 ; i<=16 ; i += 8 ){for (int j=0 ; j<3 ; j++){for (int k=0 ; k<3 ; k++){0xf f; 0 ][0 ]<<PRECISION) -(xy[0 ][1 ]<<PRECISION) -(xy[0 ][2 ]<<PRECISION)1 ][0 ]<<PRECISION) +(x1y1*xy[1 ][1 ]) -(xy[1 ][2 ]<<PRECISION)2 ][0 ]<<PRECISION) -(xy[2 ][1 ]<<PRECISION) -(xy[2 ][2 ]<<PRECISION);9 ) >> num_adec_k; 1 <<(PRECISION-1 )); if (z<0 ) 0 ;else if (z>255 )255 ;return (result);
unsharp_mask_axis.h を示す。
#ifndef __UNSHARP_MASK_AXIS_H_ #define __UNSHARP_MASK_AXIS_H_ #define HORIZONTAL_PIXEL_WIDTH 64 #define VERTICAL_PIXEL_WIDTH 48 #define ALL_PIXEL_VALUE (HORIZONTAL_PIXEL_WIDTH*VERTICAL_PIXEL_WIDTH) #define PRECISION 6 // 小数点以下の桁数、精度(0 以上の数を指定する） #define K_BITLEN 4 // k のビット長 #define NUM_ADC_K 2 // k の小数点の位置 typedef ap_int<6 +PRECISION+NUM_ADC_K+8 +3 > y_td;#endif
これで、C シミュレーションを行った。
平均2乗誤差も int 型で予め左シフトして小数を整数にして演算した時と同じだ。
次に、C++ から HDL へ合成を行った。結果を示す。
BRAM_18K は 4 個、DSP48E は 24 個、FF は 1489 個、LUT は 1812 個のリソースを消費した。
”
Vivado HLS によるアンシャープマスクキング・フィルタの作製8（C++ の任意精度固定小数点型2） ”で、int 型で予め左シフトして小数を整数にして演算した時のリソース使用量は、
BRAM_18K は 4 個、DSP48E は 18 個、FF は 1462 個、LUT は 1849 個だったので、
LUT は37 個減ったが、FF が 27 個、DSP48E は 6 個増えてしまった。
う～ん。これでは int 型を使ったほうが良さそうだ。
2015年10月14日 03:57 |
Vivado HLS
| トラックバック:0
| コメント:0
Vivado HLS 2014.4 で int 型で予め左シフトして小数を整数にして演算したり、固定小数点型を使って小数点を含んだ演算をしてきた。今までフィーリングでこれで大丈夫かな？と判定してきたが、流石になにか判定基準が欲しい。
そこで、平均2乗誤差を導入することにした。平均2乗誤差 MSE (mean squared error) を次に式で求めることにする。（「
二乗誤差とPSNR 」を参照させて頂いた）
Σ（（浮動小数点数のアンシャープマスキング・フィルタ処理値） - （固定小数点のアンシャープマスキング・フィルタ処理値））の2乗） / （総画素数 - 2行分の画素）
分母だが、最上位の2行は元の画素値なので、それを含めない画素数とした。
これを計算して見ると、固定小数点型を使用した場合の
ap_ufixed<8, 8, AP_RND, AP_SAT> z;
と定義した時の平均2乗誤差を示す。（C シミュレーション結果）
mse_b = 0.00679348
となった。
なお、mse_b が青の平均2乗誤差、mse_g が緑の平均2乗誤差、mse_r が赤の平均2乗誤差、mse がその3色の平均2乗誤差となる。
次に、
ap_ufixed<8, 8, AP_TRN, AP_SAT> z;
と定義した時の平均2乗誤差は、
mse_b = 0.0108696
となって、AP_RND よりも大きくなった。（C シミュレーション結果）
次に、 int 型で予め左シフトして小数を整数にして演算した時の平均2乗誤差を示す。（C シミュレーション結果）
mse_b = 0.0108696
固定小数点型で量子化モードが AP_TRN の時の平均2乗誤差と同じになった。
ちなみに、 int 型で予め左シフトして小数を整数にして演算した時で、PRECISION を 8 にした時の平均2乗誤差を示す。（今までは 6。
C++ソースコード参照 ）
mse_b = 0.00611413
どの辺りの平均2乗誤差を目指そうか？迷うが、PRECISION = 8 のアンシャープマスキング・フィルタ画像と PRECISION = 6 のアンシャープマスキング・フィルタ画像がほとんど変わらないので、 PRECISION = 6 の時の平均2乗誤差を目標としよう。
つまり、固定小数点での量子化モードはAP_TRN にする事になる。
PRECISION = 8 のアンシャープマスキング・フィルタ画像を示す。（K = 2.5）
PRECISION = 6 のアンシャープマスキング・フィルタ画像を示す。（K = 2.5）
平均2乗誤差を取る付近の unsharp_mask_axis_tb.cpp のコードを下に示す。
"outs" << endl;double mse = 0 ; double mse_r = 0 ; double mse_g = 0 ; double mse_b = 0 ; for (int j=0 ; j < bmpihr.biHeight; j++){for (i=0 ; i < bmpihr.biWidth; i++){32 > val = vals.data;32 > val_soft = vals_soft.data;int )val;if (val != val_soft){"ERROR HW and SW results mismatch i = %ld, j = %ld, HW = %d, SW = %d\n" , i, j, (int )val, (int )val_soft);if (vals.last)"AXI-Stream is end" << endl;0xf f) - (val & 0xf f)), 2.0 );8 )&0xf f) - ((val>>8 )&0xf f)), 2.0 );16 )&0xf f) - ((val>>16 )&0xf f)), 2.0 );2 )); 2 )); 2 )); 3 ;"mse_b = " << mse_b << endl;"mse_g = " << mse_g << endl;"mse_r = " << mse_r << endl;"mse = " << mse << endl;
2015年10月13日 16:02 |
Vivado HLS
| トラックバック:0
| コメント:0
今日は下の娘と奥さんと
バクマン（映画） を見てきました。コミックとストーリーが少し違っていましたが、なかなか面白かったです。主題歌も良かったですよ。
2015年10月12日 22:08 |
日記
| トラックバック:0
| コメント:0
Vivado HLS 2015.3 の半精度浮動小数点数でアンシャープマスキング・フィルタを作った。
”
Vivado HLS によるアンシャープマスクキング・フィルタの作製2（floatで実装してみた） ”で使った浮動小数点数をVivado 2015.3 から実装された半精度浮動小数点数に変更してやってみた。
半精度浮動小数点数 half はhls_half.h をインクルードすると使用することができる。
Cシミュレーションの結果を示す。K = 2.5 の場合だ。
テストベンチのアンシャープマスキング・フィルタの演算は float なので、half との間の誤差は出ている。
次に、C から HDL への合成結果を示す。
DSP48E が 141 % 、FF が 103 %、LUT が 313 % でいずれもZYBO の Zynq-7010 のFPGAのリソースをオーバーしている。
float で実装した時と比べると、リソース使用量は減っているが、やはりリソース使用量は多いといえる。Zynq-7010 には入らない。
float で実装した時のリソース使用量を下に示す。
半精度浮動小数点数を使っても、ZYBO にアンシャープマスキング・フィルタが入らないということが分かった。残念。。。
下に使用したC++ソースコードを示す。
最初に、unsharp_mask_axis.h を示す。
#ifndef __UNSHARP_MASK_AXIS_H_ #define __UNSHARP_MASK_AXIS_H_ #define HORIZONTAL_PIXEL_WIDTH 64 #define VERTICAL_PIXEL_WIDTH 48 #define ALL_PIXEL_VALUE (HORIZONTAL_PIXEL_WIDTH*VERTICAL_PIXEL_WIDTH) #define K_BITLEN 4 // k のビット長 #define NUM_ADC_K 2 // k の小数点の位置 #endif
次に、unsharp_mask_axis_halffp.cpp を示す。
#include <stdio.h> #include <string.h> #include <ap_int.h> #include <hls_stream.h> #include <ap_axi_sdata.h> #include <hls_half.h> #include "unsharp_mask_axis.h" int unsharp_masking(int pix_mat[3 ][3 ], ap_uint<K_BITLEN> k);int unsharp_mask_axis(ap_uint<1 > usm_fil_enable, ap_uint<K_BITLEN> usm_fil_k, hls::stream<ap_axis<32 ,1 ,1 ,1 > >& ins, hls::stream<ap_axis<32 ,1 ,1 ,1 > >& outs){#pragma HLS INTERFACE ap_none port=usm_fil_enable #pragma HLS INTERFACE ap_none port=usm_fil_k #pragma HLS INTERFACE axis port=ins #pragma HLS INTERFACE axis port=outs #pragma HLS INTERFACE ap_ctrl_none port=return 32 ,1 ,1 ,1 > pix;32 ,1 ,1 ,1 > usm;int line_buf[2 ][HORIZONTAL_PIXEL_WIDTH];#pragma HLS array_partition variable=line_buf block factor=2 dim=1 #pragma HLS resource variable=line_buf core=RAM_2P int pix_mat[3 ][3 ];#pragma HLS array_partition variable=pix_mat complete int usm_fil_val;do { while (pix.user == 0 );for (int y=0 ; y<VERTICAL_PIXEL_WIDTH; y++){for (int x=0 ; x<HORIZONTAL_PIXEL_WIDTH; x++){#pragma HLS PIPELINE if (!(x==0 && y==0 )) for (int i=0 ; i<3 ; i++){for (int j=0 ; j<2 ; j++){#pragma HLS UNROLL 1 ];0 ][2 ] = line_buf[0 ][x];1 ][2 ] = line_buf[1 ][x];2 ][2 ] = pix.data;0 ][x] = line_buf[1 ][x]; 1 ][x] = pix.data;if (x<2 || y<2 ) if (x==0 && y==0 ) 1 ;else 0 ;if (x == (HORIZONTAL_PIXEL_WIDTH-1 )) 1 ;else 0 ;if (usm_fil_enable)else return 0 ;int unsharp_masking(int pix_mat[3 ][3 ], ap_uint<K_BITLEN> k)int xy[3 ][3 ];3 ];int result=0 ;for (int m=0 ; m<NUM_ADC_K; m++){ 2.0 ;for (int i=0 ; i<=16 ; i += 8 ){for (int j=0 ; j<3 ; j++){for (int k=0 ; k<3 ; k++){0xf f; 0 ][0 ] -(half)xy[0 ][1 ] -(half)xy[0 ][2 ]1 ][0 ] +(9.0 /fk+8.0 )*(half)xy[1 ][1 ] -(half)xy[1 ][2 ]2 ][0 ] -(half)xy[2 ][1 ] -(half)xy[2 ][2 ];9.0 ;int z = (int )(y + 0.5 ); if (z<0 ) 0 ;else if (z>255 )255 ;return (result);
最後に、unsharp_mask_axis_tb.cpp を示す。
#include <stdio.h> #include <stdlib.h> #include <string.h> #include <math.h> #include <ap_int.h> #include <hls_stream.h> #include <iostream> #include <fstream> #include <ap_axi_sdata.h> #include "bmp_header.h" #include "unsharp_mask_axis.h" int unsharp_mask_axis(ap_uint<1 > usm_fil_enable, ap_uint<K_BITLEN> k_fixed, hls::stream<ap_axis<32 ,1 ,1 ,1 > >& ins, hls::stream<ap_axis<32 ,1 ,1 ,1 > >& outs);int unsharp_masking_soft(int pix_mat[3 ][3 ], int k, int num_adec_k);int unsharp_mask_axis_soft(ap_uint<1 > usm_fil_enable, ap_uint<4 > usm_fil_k, hls::stream<ap_axis<32 ,1 ,1 ,1 > >& ins, hls::stream<ap_axis<32 ,1 ,1 ,1 > >& outs, int width, int height);#define CLOCK_PERIOD 10 #define K 2.5 // 鮮鋭化の強さ #define NUM_ADEC_K 2 // Kの小数点の位置 int main()using namespace std;32 ,1 ,1 ,1 > > ins;32 ,1 ,1 ,1 > > ins_soft;32 ,1 ,1 ,1 > > outs;32 ,1 ,1 ,1 > > outs_soft;32 ,1 ,1 ,1 > pix;32 ,1 ,1 ,1 > vals;32 ,1 ,1 ,1 > vals_soft;int m_seq = 1 ; int i;int xor_shift;int *rd_bmp, *hw_usmd;int blue, green, red;if ((fbmpr = fopen("test.bmp" , "rb" )) == NULL){ "Can't open test.bmp by binary read mode\n" );1 );sizeof (char ), 2 , fbmpr);sizeof (long ), 1 , fbmpr);sizeof (short ), 1 , fbmpr);sizeof (short ), 1 , fbmpr);sizeof (long ), 1 , fbmpr);sizeof (BITMAPINFOHEADER), 1 , fbmpr);if ((rd_bmp =(int *)malloc (sizeof (int ) * (bmpihr.biWidth * bmpihr.biHeight))) == NULL){"Can't allocate rd_bmp memory\n" );1 );if ((hw_usmd =(int *)malloc (sizeof (int ) * (bmpihr.biWidth * bmpihr.biHeight))) == NULL){"Can't allocate hw_usmd memory\n" );1 );for (int y=0 ; y<bmpihr.biHeight; y++){for (int x=0 ; x<bmpihr.biWidth; x++){1 )-y)*bmpihr.biWidth+x] = (blue & 0xf f) | ((green & 0xf f)<<8 ) | ((red & 0xf f)<<16 );for (int i=0 ; i<5 ; i++){ 0 ;for (int j=0 ; j < bmpihr.biHeight; j++){for (i=0 ; i < bmpihr.biWidth; i++){32 >)rd_bmp[(j*bmpihr.biWidth)+i];if (j==0 && i==0 ) 1 ;else 0 ;if (i == bmpihr.biWidth-1 ) 1 ;else 0 ;int usm_k = (int )(K * pow(2.0 , (double )NUM_ADEC_K));1 , (ap_uint<K_BITLEN>)K, ins, outs);1 , usm_k, ins_soft, outs_soft, bmpihr.biWidth, bmpihr.biHeight); "outs" << endl;for (int j=0 ; j < bmpihr.biHeight; j++){for (i=0 ; i < bmpihr.biWidth; i++){32 > val = vals.data;32 > val_soft = vals_soft.data;int )val;if (val != val_soft){"ERROR HW and SW results mismatch i = %ld, j = %ld, HW = %d, SW = %d\n" , i, j, (int )val, (int )val_soft);if (vals.last)"AXI-Stream is end" << endl;"Success HW and SW results match" << endl;if ((fbmpw=fopen("temp_usm.bmp" , "wb" )) == NULL){"Can't open temp_usm.bmp by binary write mode\n" );1 );sizeof (char ), 2 , fbmpw);sizeof (long ), 1 , fbmpw);sizeof (short ), 1 , fbmpw);sizeof (short ), 1 , fbmpw);sizeof (long ), 1 , fbmpw);sizeof (BITMAPINFOHEADER), 1 , fbmpw);for (int y=0 ; y<bmpihr.biHeight; y++){for (int x=0 ; x<bmpihr.biWidth; x++){1 )-y)*bmpihr.biWidth+x] & 0xf f;1 )-y)*bmpihr.biWidth+x] >> 8 ) & 0xf f;1 )-y)*bmpihr.biWidth+x]>>16 ) & 0xf f;return 0 ;int unsharp_mask_axis_soft(ap_uint<1 > usm_fil_enable, ap_uint<4 > usm_fil_k, hls::stream<ap_axis<32 ,1 ,1 ,1 > >& ins, hls::stream<ap_axis<32 ,1 ,1 ,1 > >& outs, int width, int height){32 ,1 ,1 ,1 > pix;32 ,1 ,1 ,1 > usm;int **line_buf;int pix_mat[3 ][3 ];int usm_fil_val;int i;if ((line_buf =(int **)malloc (sizeof (int *) * 2 )) == NULL){"Can't allocate line_buf[3][]\n" );1 );for (i=0 ; i<2 ; i++){if ((line_buf[i]=(int *)malloc (sizeof (int ) * width)) == NULL){"Can't allocate line_buf[%d]\n" , i);1 );do { while (pix.user == 0 );for (int y=0 ; y<height; y++){for (int x=0 ; x<width; x++){if (!(x==0 && y==0 )) for (int k=0 ; k<3 ; k++){for (int m=0 ; m<2 ; m++){1 ];0 ][2 ] = line_buf[0 ][x];1 ][2 ] = line_buf[1 ][x];2 ][2 ] = pix.data;0 ][x] = line_buf[1 ][x]; 1 ][x] = pix.data;int )usm_fil_k, 2 );if (x<2 || y<2 ) if (x==0 && y==0 ) 1 ;else 0 ;if (x == (HORIZONTAL_PIXEL_WIDTH-1 )) 1 ;else 0 ;if (usm_fil_enable)else for (i=0 ; i<2 ; i++)return 0 ;int unsharp_masking_soft(int pix_mat[3 ][3 ], int k, int num_adec_k)float y;int xy[3 ][3 ];float rgb[3 ];int result=0 ;float fk = (float )k;for (int m=0 ; m<num_adec_k; m++){ 2.0 ;for (int i=0 ; i<=16 ; i += 8 ){for (int j=0 ; j<3 ; j++){for (int k=0 ; k<3 ; k++){0xf f; float )xy[0 ][0 ] -(float )xy[0 ][1 ] -(float )xy[0 ][2 ]float )xy[1 ][0 ] +(9.0 /fk+8.0 )*(float )xy[1 ][1 ] -(float )xy[1 ][2 ]float )xy[2 ][0 ] -(float )xy[2 ][1 ] -(float )xy[2 ][2 ];9.0 ;int z = (int )(y + 0.5 ); if (z<0 ) 0 ;else if (z>255 )255 ;return (result);
2015年10月11日 05:28 |
Vivado HLS
| トラックバック:0
| コメント:0
”
Vivado HLS によるアンシャープマスクキング・フィルタの作製8（C++ の任意精度固定小数点型2） ”の続き。
前回、int 型で予め左シフトして小数を整数にして演算するよりも、固定小数点型にしたほうが、LUT 使用量は減ったが、FF 使用量は増えた。
今回は、固定小数点型で更にリソース使用量の削減、レイテンシの削減を図る。使用しているのは Vivado HLS 2014.4 。
（2015/10/13：C++ソースコードが間違っていたので、修正した） まずは、”
Vivado Design Suite ユーザー ガイド 高位合成 UG902 (v2015.1) 2015 年 4 月 1 日 ”の550ページ ” C++ の任意精度固定小数点型”を読むと、固定小数点型のデフォルトの量子化モードは AP_TRN、デフォルトのオーバーフロー・モードは AP_WRAP に指定されている。
量子化モードの AP_TRN は切り捨てで、オーバーフロー・モードの AP_WRAP は折り返しと、後での演算が必要無いモードになっている気がする。
今の固定小数点のモードは、量子化モードは AP_RND で、正の無限大への丸め、オーバーフロー・モードは AP_SAT で飽和にしている。これを本当に飽和演算の必要な z 以外はデフォルトにすることにした。
更に、z を飽和演算は必要なので、オーバーフロー・モードは AP_SAT の飽和だが、量子化モードを AP_TRN にしてみる。
これで、C から HDL への合成を行った。結果を下に示す。
FF 使用量は 1997 個だった。LUT 使用量は 1993 個だった。”
Vivado HLS によるアンシャープマスクキング・フィルタの作製8（C++ の任意精度固定小数点型2） ”の時の、FF 使用量が 2304 個、LUT 使用量が 2835 個の時よりも少なくなっている。
Analysis 結果を示す。
36 ステートだった。
順番が逆になったが、Cシミュレーションを行った。
誤差が大きくなってしまった。
次に z の量子化モードを AP_RND に戻す。
これで、Cシミュレーションを行った。
問題ないようだ。
C から HDL への合成を行った。
FF 使用量は 1966 個、LUT 使用量は 2131 個で、 z の量子化モードが AP_TRN の場合ののリソース使用量よりも増えている。
Analysis 結果を示す。
36 ステートだった。 z の量子化モードが AP_TRN の場合と同じだ。
ほとんどの固定小数点型の数はオーバーフローしないようにビット長を決定しているので、量子化モードやオーバーフロー・モードは関係ないので、演算が軽いデフォルトで使用する。最後に飽和演算が必要な場合にだけ、必要な量子化モードとオーバーフロー・モードを設定したほうが良いと思う。
最後に、unsharp_masking() を示す。
int unsharp_masking(int pix_mat[3 ][3 ], k_fixed_td k_fixed)8 , 8 > xy[3 ][3 ];int result=0 ;8 , 8 , AP_RND, AP_SAT> z;9 /(x1y1_fixed_td)k_fixed + (x1y1_fixed_td)8 ; for (int i=0 ; i<=16 ; i += 8 ){for (int j=0 ; j<3 ; j++){for (int k=0 ; k<3 ; k++){0xf f; 0 ][0 ] -xy[0 ][1 ] -xy[0 ][2 ]1 ][0 ] +x1y1*xy[1 ][1 ] -xy[1 ][2 ]2 ][0 ] -xy[2 ][1 ] -xy[2 ][2 ];9 ;0.5 ; if (y < 0 )0 ;else if (y > 255 )255 ;else return (result);
次に、unsharp_mask_axis.h を下に示す。
#ifndef __UNSHARP_MASK_AXIS_H_ #define __UNSHARP_MASK_AXIS_H_ #define HORIZONTAL_PIXEL_WIDTH 64 #define VERTICAL_PIXEL_WIDTH 48 #define ALL_PIXEL_VALUE (HORIZONTAL_PIXEL_WIDTH*VERTICAL_PIXEL_WIDTH) #define PRECISION 6 // 小数点以下の桁数、精度(0 以上の数を指定する） #define K_BITLEN 4 // k のビット長 #define NUM_ADC_K 2 // k の小数点の位置 typedef ap_ufixed<K_BITLEN, K_BITLEN-NUM_ADC_K> k_fixed_td;typedef ap_fixed<6 +PRECISION+NUM_ADC_K, (6 +PRECISION+NUM_ADC_K)-PRECISION> x1y1_fixed_td;typedef ap_fixed<6 +PRECISION+NUM_ADC_K+8 +3 , (6 +PRECISION+NUM_ADC_K+8 +3 )-PRECISION> y_fixed_td;#endif
2015年10月10日 05:32 |
Vivado HLS
| トラックバック:0
| コメント:0
今年（2015年）の5月8日に、”
Vivado HLS 2014.4 vs Vivado HLS 2015.1 vs Vivado HLS 2015.3（AXI4-Stream版ラプラシアンフィルタ IPの比較） ”という記事を書いたが、今回はその記事をコピーして、そこに、新しく出たVivado HLS 2015.3 の結果を追加してみようと思う。
AXI4-Stream版ラプラシアンフィルタ IPで、Vivado HLS 2014.4 と Vivado HLS 2015.1 と Vivado HLS 2015.3 の高位合成結果を比較してみた。
C++ ソースコードは、すべて同じもので、”
Vivado 2014.4 でAXI4-Stream版ラプラシアンフィルタIP を作製する１（C++ ソースコードの公開） ”で示したものだ。但し、lap_filter_axis.h は実際の 800 x 600 ピクセルに変更した。lap_filter_axis.h を下に示す。
// lap_filter_axis.h
クロック周期 10 ns ・Vivado HLS 2014.4 クロック周期 10 ns で Vivado HLS 2014.4 で高位合成を行った結果を示す。
Timing の Estimated は 7.58 ns だった。FF は 382 個、LUT は 626 個使用している。
・Vivado HLS 2015.1 クロック周期 10 ns で Vivado HLS 2015.1 で高位合成を行った結果を示す。
Timing の Estimated は 9.40 ns だった。FF は 387 個、LUT は 556 個使用している。
・Vivado HLS 2015.3 クロック周期 10 ns で Vivado HLS 2015.3 で高位合成を行った結果を示す。
Timing の Estimated は 6.91 ns だった。FFは 411 個、LUTは 445 個を使用している。
FFは3つのバージョンの中で一番多いが、LUTは一番少ない。FFとLUTの数がバランスしている方がFPGAのSliceを有効に使えて良いと思う。
クロック周期 9 ns ・Vivado HLS 2014.4 クロック周期 9 ns で Vivado HLS 2014.4 で高位合成を行った結果を示す。
Timing の Estimated は 7.58 ns だった。FF は 382 個、LUT は 626 個使用している。つまり、クロック周期が 10 ns の時と同じ回路だと思う。
・Vivado HLS 2015.1 クロック周期 9 ns で Vivado HLS 2015.1 で高位合成を行った結果を示す。
Timing の Estimated は
9.40 ns で、クロック周期 9 ns に対して遅くなり
エラー になっている。FF は 387 個、LUT は 556 個使用している。これも、クロック周期が 10 ns の時と同じ回路だと思う。
・Vivado HLS 2015.3 クロック周期 9 ns で Vivado HLS 2015.3 で高位合成を行った結果を示す。
Timing の Estimated は 6.91 ns だった。FFは 411 個、LUTは 445 個を使用している。クロック周期が 10 ns の時と同じ回路だ。クロック周期が 6.91 ns なので、回路を変える必要はない。
クロック周期 8 ns ・Vivado HLS 2014.4 クロック周期 8 ns で Vivado HLS 2014.4 で高位合成を行った結果を示す。
Timing の Estimated は 6.91 ns だった。FF は 435 個、LUT は 627 個使用している。今回は回路が変更されているようだ。
・Vivado HLS 2015.1 クロック周期 8 ns で Vivado HLS 2015.1 で高位合成を行った結果を示す。
Timing の Estimated は
9.40 ns で、クロック周期 8 ns に対して遅くなり
エラー になっている。FF は 436 個、LUT は 556 個使用している。FF が増えているので回路は変更されているようだ。
・Vivado HLS 2015.3 クロック周期 8 ns で Vivado HLS 2015.3 で高位合成を行った結果を示す。
Timing の Estimated は 6.91 ns だった。FFは 411 個、LUTは 445 個を使用している。クロック周期が 10 ns の時と同じ回路だ。クロック周期が 6.91 ns なので、回路を変える必要はない。
クロック周期 7 ns ・Vivado HLS 2014.4 クロック周期 7 ns で Vivado HLS 2014.4 で高位合成を行った結果を示す。
Timing の Estimated は 6.88 ns だった。FF は 455 個、LUT は 627 個使用している。今回も回路が変更されているようだ。
・Vivado HLS 2015.1 クロック周期 7 ns で Vivado HLS 2015.1 で高位合成を行った結果を示す。
Timing の Estimated は
8.77 ns で、クロック周期 8 ns に対して遅くなり
エラー になっている。FF は 455 個、LUT は 564 個使用している。FF が増えているので回路は変更されているようだ。
・Vivado HLS 2015.3 クロック周期 7 ns で Vivado HLS 2015.3 で高位合成を行った結果を示す。
Timing の Estimated は 6.88 ns だった。FFは 491 個、LUTは 455 個を使用している。初めて、FF、LUT 共に増えた。
クロック周期 6 ns ・Vivado 2014.4 クロック周期 6 ns で Vivado HLS 2014.4 で高位合成を行った結果を示す。
Timing の Estimated は
6.88 ns で、クロック周期 6 ns に対して遅くなり
エラー になっている。FF は 473 個、LUT は 637 個使用している。
・Vivado HLS 2015.1 クロック周期 6 ns で Vivado HLS 2015.1 で高位合成を行った結果を示す。
Timing の Estimated は
6.88 ns で、クロック周期 6 ns に対して遅くなり
エラー になっている。FF は 473 個、LUT は 566 個使用している。
・Vivado HLS 2015.3 クロック周期 6 ns で Vivado HLS 2015.3 で高位合成を行った結果を示す。
Timing の Estimated は
6.88 ns で、クロック周期 6 ns に対して遅くなり
エラー になっている。FF は 509 個、LUT は 465 個使用している。FF、LUT 共にクロック周期が 7 ns の時よりも増えていて、回路が変わっているようだが、Estimaed は同じでここで限界なのかもしれない？
クロック周期 2.5 ns ・Vivado HLS 2014.4 クロック周期 2.5 ns で Vivado HLS 2014.4 で高位合成を行った結果を示す。限界を見極めるためだ。
Timing の Estimated は
6.88 ns で、クロック周期 2.5 ns に対して遅くなり
エラー になっている。FF は 1367 個、LUT は 693 個使用している。これだけFFを使用してもタイミングを満たさないので、ここが限界のようだ。
・Vivado HLS 2015.1 クロック周期 2.5 ns で Vivado HLS 2015.1 で高位合成を行った結果を示す。
Timing の Estimated は
6.88 ns で、クロック周期 2.5 ns に対して遅くなり
エラー になっている。FF は 1335 個、LUT は 622 個使用している。これだけFFを使用してもタイミングを満たさないので、こちらもここが限界のようだ。
・Vivado HLS 2015.3 クロック周期 2.5 ns で Vivado HLS 2015.3 で高位合成を行った結果を示す。
Timing の Estimated は
6.88 ns で、クロック周期 2.5 ns に対して遅くなり
エラー になっている。FF は 1333 個、LUT は 646 個使用している。これだけFFを使用してもタイミングを満たさないので、ここが限界のようだ。
Vivado HLS 2015.3 は FF の使用量は多いものの、LUTの使用量は少ない。但し、クロック周期 2.5 ns を除けば、FF とLUT の数は大体同じようなので、バランスが良いと言える。今後はVivado HLS 2014.4 の代わりにVivado 2015.3 を使いたいと思う。
2015年10月09日 04:54 |
Vivado HLS
| トラックバック:0
| コメント:0
Vivado HLS 2015.3 が出た。普通は”Vivado 2015.3 が出た”と書くと思うのだが、なるべくVivado HLS を使っていこうと思っている私にとって、Vivado HLS が新しくなったのが大きなニュースだ。
今度のVivado HLS は1つのテストしかしていないが、今まで使ってきたVivado HLS 2014.4 よりも良くなっていると思う。今やっている固定小数点型の比較が終わった時点でVivado HLS 2015.3 に乗り換えたいと思う。
まずは、2015.3のリリースノートはまだ日本語がないので、
英語の2015.3のリリースノート を参照している。10ページにVivado HLS の新機能が書いてある。
それによると、
・Open Wave Viewer toolbar buttonが付いた
だそうだ
一番、大きな変更は、Vivado HLS 2015.3 ではOpen Wave Viewer toolbar button が付いたことだ。今まで、Vivado を立ちあげて、Tcl Console からTcl コマンドを入力してとやっていたが、Open Wave Viewer toolbar button をクリックすれば、それらを全部やってくれて、Vivado が立ち上がり波形を表示することができる。
次に、AXI-Lite (s_axilite) に独自クロックを調べてみた。
AXI4 Stream にAXI4 Lite Slave インターフェースが付いている回路で、AXI4 Lite Slave インターフェースに独自クロックを追加する。
C++ソースコードで、s_axilite ディレクティブを編集する。
Vivado HLS Directive Editor で clock name (optional) に axils_clk を入力した。
すると、s_axilite ディレクティブに”clock=axils_clk”が追加された。
C から HDL へ合成を行った。
lap_filter_axis.v を見ると、”axils_clk”と”ap_rst_n_axils_clk”が追加されている。
lap_filter_axis.v のモジュール宣言を貼っておく。
module lap_filter_axis (
AXI4 Lite Slave インターフェースの独自クロックのタイミング制約を何処でするか？はまだわかっていない。
2015年10月08日 05:22 |
Vivado HLS
| トラックバック:0
| コメント:2
”
Vivado HLS によるアンシャープマスクキング・フィルタの作製7（C++ の任意精度固定小数点型） ”の続き。
前回はC++のソースコードを公開した。今回は、Cシミュレーションを行ってから、C++ から HDL への合成を行って、int 型でシフトを使って演算した実装と比較する。
（2015/10/13：全面的に修正） まずは、Cシミュレーションを行った。int 型でシフトを使って演算のCシミュレーション結果よりも精度が良い。
固定小数点型で書いた今回のC++ ソースコードを HDL へ合成した。下に結果を示す。
BRAM_18K は 4 個、DSP48E は 18 個、FF は 2304 個、LUT は 2835 個使用している。
次に、int 型でシフトを使ってアンシャープマスキング・フィルタの演算を行った例として”
Vivado HLS によるアンシャープマスクキング・フィルタの作製3（固定小数点で実装してみた） ”の unsharp_masking() を固定小数点型での実装と同様に、x1y1 をループの外に出した。
unsharp_masking() を示す。
#define PRECISION 6 // 小数点以下の桁数、精度（1以上） int unsharp_masking(int pix_mat[3 ][3 ], int k, int num_adec_k)int y;int xy[3 ][3 ];int result=0 ;int z;int x1y1 = (9 <<(PRECISION+num_adec_k))/k + (8 <<PRECISION);for (int i=0 ; i<=16 ; i += 8 ){for (int j=0 ; j<3 ; j++){for (int k=0 ; k<3 ; k++){0xf f; 0 ][0 ]<<PRECISION) -(xy[0 ][1 ]<<PRECISION) -(xy[0 ][2 ]<<PRECISION)1 ][0 ]<<PRECISION) +x1y1*xy[1 ][1 ] -(xy[1 ][2 ]<<PRECISION)2 ][0 ]<<PRECISION) -(xy[2 ][1 ]<<PRECISION) -(xy[2 ][2 ]<<PRECISION);9 ) >> num_adec_k; 1 <<(PRECISION-1 )); if (z<0 ) 0 ;else if (z>255 )255 ;return (result);
これで、C++ からHDL への合成を行った。結果を示す。
BRAM_18K は 4 個、DSP48E は 18 個、FF は 1462 個、LUT は 1849 個使用している。
FF も LUT も、固定小数点の方が多い。
FF と LUT が固定小数点型の方が増えているのは、次に示すAnalysis の結果でもわかるが、パイプラインの段数が増えているからではないか？と思う。
固定小数点型での、Analysis 結果を示す。
C40 まである。
int 型でシフトを使ってアンシャープマスキング・フィルタの演算を行った例のAnalysis 結果を示す。
C31 までで、固定小数点型よりも 9 ステージ少ない。
2015年10月07日 04:17 |
Vivado HLS
| トラックバック:0
| コメント:0
”
Vivado HLS によるアンシャープマスクキング・フィルタの作製4（固定小数点で実装してみた2） ”の固定小数点は自分で小数点の位置を管理していた。
今回は、Vivado HLS に備わっている C++ の任意精度固定小数点型で書いてみようと思う。C++ の任意精度固定小数点型については、”
Vivado Design Suite ユーザー ガイド 高位合成 UG902 (v2015.1) 2015 年 4 月 1 日 ”の550ページ ” C++ の任意精度固定小数点型”を参照のこと。
（2015/10/13：C++ソースコードを書き換えました） 小数点以下の数は前回同様にPRECISION で指定するので、整数部分を決定しようと思う。
num_adec_k（Kの小数点の位置）は、define で定義された NUM_ADEC_K に変更しようと思う。
NUM_ADEC_K が大きければ、小さい小数がありえて、例えばNUM_ADEC_K = 2 だと、0.25が最小値だが、k で割るところでは値が4倍になる。NUM_ADEC_K が8だったら、256倍になる可能性がある。（k は0以外）
よって、
iint x1y1 = (9 <<(PRECISION+num_adec_k))/k + (8 <<PRECISION);
は、
ap_ufixed<5+PRECISION+NUM_ADC_K, (5+PRECISION+NUM_ADC_K)-PRECISION, AP_RND, AP_SAT> x1y1 = 9/k_fixed + 8;
に変更した。
バグが出てデバックしていたが原因が分かった。今のところ、int型から固定小数点型への変換がうまく行っていないのと、整数リテラルと相対的に精度の低い固定小数点型の演算の結果を精度の高い固定小数点型に入れると桁落ちするようだ。
int unsharp_masking(int pix_mat[3 ][3 ], k_fixed_td k_fixed)8 , 8 , AP_RND, AP_SAT> xy[3 ][3 ];int result=0 ;8 , 8 , AP_RND, AP_SAT> z;5 +PRECISION+NUM_ADC_K+8 +3 , (5 +PRECISION+NUM_ADC_K+8 +3 )-PRECISION, AP_RND, AP_SAT> y;9 /(x1y1_fixed_td)k_fixed + (x1y1_fixed_td)8 ; 9 /k_fixed + 8 ;"x1y1 = " << x1y1 << endl;"x1y1_2 = " << x1y1_2 << endl;
一部抜粋だが、この結果は下に示すようになった。
Compiling ../../../unsharp_mask_axis_tb.cpp in debug mode
ちなみに typedef を下に示す。
typedef ap_ufixed
int型から固定小数点型への変換がうまく行かない件は最初から固定小数点型をハードウェア化する関数に渡すように変更した。
つまり、ハードウェア化するとポートになるということだが、うまく4ビット幅の入力ポートになった。これで使える。
但し、ap_ufixed<8, 8, AP_RND, AP_SAT> z; とか小数部分が無い固定小数点型ならば int型から代入しても問題ないようだ。
ソースを貼っておこうと思う。
まずは unsharp_mask_axis.h から貼っておく。
#ifndef __UNSHARP_MASK_AXIS_H_ #define __UNSHARP_MASK_AXIS_H_ #define HORIZONTAL_PIXEL_WIDTH 64 #define VERTICAL_PIXEL_WIDTH 48 #define ALL_PIXEL_VALUE (HORIZONTAL_PIXEL_WIDTH*VERTICAL_PIXEL_WIDTH) #define PRECISION 6 // 小数点以下の桁数、精度(0 以上の数を指定する） #define K_BITLEN 4 // k のビット長 #define NUM_ADC_K 2 // k の小数点の位置 typedef ap_ufixed<K_BITLEN, K_BITLEN-NUM_ADC_K> k_fixed_td;typedef ap_fixed<6 +PRECISION+NUM_ADC_K, (6 +PRECISION+NUM_ADC_K)-PRECISION, AP_RND, AP_SAT> x1y1_fixed_td;typedef ap_fixed<6 +PRECISION+NUM_ADC_K+8 +3 , (6 +PRECISION+NUM_ADC_K+8 +3 )-PRECISION, AP_RND, AP_SAT> y_fixed_td;#endif
次に、 unsharp_mask_axis.cpp を貼っておく。
#include <stdio.h> #include <string.h> #include <ap_int.h> #include <ap_fixed.h> #include <hls_stream.h> #include <ap_axi_sdata.h> #include <iostream> #include "unsharp_mask_axis.h" using namespace std;int unsharp_masking(int pix_mat[3 ][3 ], k_fixed_td k_fixed);int unsharp_mask_axis(ap_uint<1 > usm_fil_enable, k_fixed_td k_fixed, hls::stream<ap_axis<32 ,1 ,1 ,1 > >& ins, hls::stream<ap_axis<32 ,1 ,1 ,1 > >& outs){#pragma HLS INTERFACE ap_none port=usm_fil_enable #pragma HLS INTERFACE ap_none port=k_fixed #pragma HLS INTERFACE axis port=ins #pragma HLS INTERFACE axis port=outs #pragma HLS INTERFACE ap_ctrl_none port=return 32 ,1 ,1 ,1 > pix;32 ,1 ,1 ,1 > usm;int line_buf[2 ][HORIZONTAL_PIXEL_WIDTH];#pragma HLS array_partition variable=line_buf block factor=2 dim=1 #pragma HLS resource variable=line_buf core=RAM_2P int pix_mat[3 ][3 ];#pragma HLS array_partition variable=pix_mat complete int usm_fil_val;do { while (pix.user == 0 );for (int y=0 ; y<VERTICAL_PIXEL_WIDTH; y++){for (int x=0 ; x<HORIZONTAL_PIXEL_WIDTH; x++){#pragma HLS PIPELINE if (!(x==0 && y==0 )) for (int i=0 ; i<3 ; i++){for (int j=0 ; j<2 ; j++){#pragma HLS UNROLL 1 ];0 ][2 ] = line_buf[0 ][x];1 ][2 ] = line_buf[1 ][x];2 ][2 ] = pix.data;0 ][x] = line_buf[1 ][x]; 1 ][x] = pix.data;if (x<2 || y<2 ) if (x==0 && y==0 ) 1 ;else 0 ;if (x == (HORIZONTAL_PIXEL_WIDTH-1 )) 1 ;else 0 ;if (usm_fil_enable)else return 0 ;int unsharp_masking(int pix_mat[3 ][3 ], k_fixed_td k_fixed)8 , 8 , AP_RND, AP_SAT> xy[3 ][3 ];int result=0 ;8 , 8 , AP_RND, AP_SAT> z;9 /(x1y1_fixed_td)k_fixed + (x1y1_fixed_td)8 ; for (int i=0 ; i<=16 ; i += 8 ){for (int j=0 ; j<3 ; j++){for (int k=0 ; k<3 ; k++){0xf f; 0 ][0 ] -xy[0 ][1 ] -xy[0 ][2 ]1 ][0 ] +x1y1*xy[1 ][1 ] -xy[1 ][2 ]2 ][0 ] -xy[2 ][1 ] -xy[2 ][2 ];9 ;0.5 ; if (y < 0 )0 ;else if (y > 255 )255 ;else return (result);
最後に、unsharp_mask_axis_tb.cpp を貼っておく。
#include <stdio.h> #include <stdlib.h> #include <string.h> #include <math.h> #include <ap_int.h> #include <hls_stream.h> #include <iostream> #include <fstream> #include <ap_axi_sdata.h> #include "bmp_header.h" #include "unsharp_mask_axis.h" int unsharp_mask_axis(ap_uint<1 > usm_fil_enable, k_fixed_td k_fixed, hls::stream<ap_axis<32 ,1 ,1 ,1 > >& ins, hls::stream<ap_axis<32 ,1 ,1 ,1 > >& outs);int unsharp_masking_soft(int pix_mat[3 ][3 ], int k, int num_adec_k);int unsharp_mask_axis_soft(ap_uint<1 > usm_fil_enable, ap_uint<4 > usm_fil_k, hls::stream<ap_axis<32 ,1 ,1 ,1 > >& ins, hls::stream<ap_axis<32 ,1 ,1 ,1 > >& outs, int width, int height);#define CLOCK_PERIOD 10 #define K 2.5 // 鮮鋭化の強さ #define NUM_ADEC_K 2 // Kの小数点の位置 int main()using namespace std;32 ,1 ,1 ,1 > > ins;32 ,1 ,1 ,1 > > ins_soft;32 ,1 ,1 ,1 > > outs;32 ,1 ,1 ,1 > > outs_soft;32 ,1 ,1 ,1 > pix;32 ,1 ,1 ,1 > vals;32 ,1 ,1 ,1 > vals_soft;int m_seq = 1 ; int i;int xor_shift;int *rd_bmp, *hw_usmd;int blue, green, red;if ((fbmpr = fopen("test.bmp" , "rb" )) == NULL){ "Can't open test.bmp by binary read mode\n" );1 );sizeof (char ), 2 , fbmpr);sizeof (long ), 1 , fbmpr);sizeof (short ), 1 , fbmpr);sizeof (short ), 1 , fbmpr);sizeof (long ), 1 , fbmpr);sizeof (BITMAPINFOHEADER), 1 , fbmpr);if ((rd_bmp =(int *)malloc (sizeof (int ) * (bmpihr.biWidth * bmpihr.biHeight))) == NULL){"Can't allocate rd_bmp memory\n" );1 );if ((hw_usmd =(int *)malloc (sizeof (int ) * (bmpihr.biWidth * bmpihr.biHeight))) == NULL){"Can't allocate hw_usmd memory\n" );1 );for (int y=0 ; y<bmpihr.biHeight; y++){for (int x=0 ; x<bmpihr.biWidth; x++){1 )-y)*bmpihr.biWidth+x] = (blue & 0xf f) | ((green & 0xf f)<<8 ) | ((red & 0xf f)<<16 );for (int i=0 ; i<5 ; i++){ 0 ;for (int j=0 ; j < bmpihr.biHeight; j++){for (i=0 ; i < bmpihr.biWidth; i++){32 >)rd_bmp[(j*bmpihr.biWidth)+i];if (j==0 && i==0 ) 1 ;else 0 ;if (i == bmpihr.biWidth-1 ) 1 ;else 0 ;int usm_k = (int )(K * pow(2.0 , (double )NUM_ADEC_K));1 , k_fixed, ins, outs);1 , usm_k, ins_soft, outs_soft, bmpihr.biWidth, bmpihr.biHeight); "outs" << endl;for (int j=0 ; j < bmpihr.biHeight; j++){for (i=0 ; i < bmpihr.biWidth; i++){32 > val = vals.data;32 > val_soft = vals_soft.data;int )val;if (val != val_soft){"ERROR HW and SW results mismatch i = %ld, j = %ld, HW = %d, SW = %d\n" , i, j, (int )val, (int )val_soft);if (vals.last)"AXI-Stream is end" << endl;"Success HW and SW results match" << endl;if ((fbmpw=fopen("temp_usm.bmp" , "wb" )) == NULL){"Can't open temp_usm.bmp by binary write mode\n" );1 );sizeof (char ), 2 , fbmpw);sizeof (long ), 1 , fbmpw);sizeof (short ), 1 , fbmpw);sizeof (short ), 1 , fbmpw);sizeof (long ), 1 , fbmpw);sizeof (BITMAPINFOHEADER), 1 , fbmpw);for (int y=0 ; y<bmpihr.biHeight; y++){for (int x=0 ; x<bmpihr.biWidth; x++){1 )-y)*bmpihr.biWidth+x] & 0xf f;1 )-y)*bmpihr.biWidth+x] >> 8 ) & 0xf f;1 )-y)*bmpihr.biWidth+x]>>16 ) & 0xf f;return 0 ;int unsharp_mask_axis_soft(ap_uint<1 > usm_fil_enable, ap_uint<4 > usm_fil_k, hls::stream<ap_axis<32 ,1 ,1 ,1 > >& ins, hls::stream<ap_axis<32 ,1 ,1 ,1 > >& outs, int width, int height){32 ,1 ,1 ,1 > pix;32 ,1 ,1 ,1 > usm;int **line_buf;int pix_mat[3 ][3 ];int usm_fil_val;int i;if ((line_buf =(int **)malloc (sizeof (int *) * 2 )) == NULL){"Can't allocate line_buf[3][]\n" );1 );for (i=0 ; i<2 ; i++){if ((line_buf[i]=(int *)malloc (sizeof (int ) * width)) == NULL){"Can't allocate line_buf[%d]\n" , i);1 );do { while (pix.user == 0 );for (int y=0 ; y<height; y++){for (int x=0 ; x<width; x++){if (!(x==0 && y==0 )) for (int k=0 ; k<3 ; k++){for (int m=0 ; m<2 ; m++){1 ];0 ][2 ] = line_buf[0 ][x];1 ][2 ] = line_buf[1 ][x];2 ][2 ] = pix.data;0 ][x] = line_buf[1 ][x]; 1 ][x] = pix.data;int )usm_fil_k, 2 );if (x<2 || y<2 ) if (x==0 && y==0 ) 1 ;else 0 ;if (x == (HORIZONTAL_PIXEL_WIDTH-1 )) 1 ;else 0 ;if (usm_fil_enable)else for (i=0 ; i<2 ; i++)return 0 ;int unsharp_masking_soft(int pix_mat[3 ][3 ], int k, int num_adec_k)float y;int xy[3 ][3 ];float rgb[3 ];int result=0 ;float fk = (float )k;for (int m=0 ; m<num_adec_k; m++){ 2.0 ;for (int i=0 ; i<=16 ; i += 8 ){for (int j=0 ; j<3 ; j++){for (int k=0 ; k<3 ; k++){0xf f; float )xy[0 ][0 ] -(float )xy[0 ][1 ] -(float )xy[0 ][2 ]float )xy[1 ][0 ] +(9.0 /fk+8.0 )*(float )xy[1 ][1 ] -(float )xy[1 ][2 ]float )xy[2 ][0 ] -(float )xy[2 ][1 ] -(float )xy[2 ][2 ];9.0 ;int z = (int )(y + 0.5 ); if (z<0 ) 0 ;else if (z>255 )255 ;return (result);
2015年10月04日 08:04 |
Vivado HLS
| トラックバック:0
| コメント:0
DSF2015 の
C-6 ”Xilinx社のFPGAにおける高位合成ツールVivado HLSの効果と性能” で説明したAXI4 Masterインターフェースの例をブログで説明したいと思います。
最初に
GitHub のmarsee101/multi_axim にVivado HLS 2014.4 のプロジェクト があります。これを git の clone でも zip ファイルでダウンロードでも良いので、自分のパソコンにダウンロードして下さい。
zip ファイルでダウンロードの例を説明します。
Download.zip ボタンをクリックすると保存ダイアログが開いて、multi_axim-master.zip をダウンロードすることができます。
multi_axim-master.zip を展開すると、multi_axim-master フォルダが出てきます。これが、Vivado HLS 2014.4 のプロジェクト・フォルダです。
multi_axim-master フォルダに入ると、multi_aixm.c, multi_axim_tb.c, solution1 フォルダがあります。他のファイルやフォルダもあります。
multi_aixm.c がハードウェアにするC ソフトウェアです。
multi_aixm_tb.c がハードウェアにするC ソフトウェア用のテストベンチです。
ファイルを開いて見てみましょう。
multi_aixm.c は、x[10] の配列の1つの要素とその要素を+1 した数の積を取って、y[10] の配列の要素に代入します。それを10個要素それぞれに付いて行います。
関数の引数で、値渡しの引数は入力ポートになります。ポインタ渡しの引数は入力ポートにも出力ポートもなります。または出力ポートと入力ポート両方を生成することもできます。
#pragma HLS INTERFACE m_axi port=y depth=10 offset=slave このディレクティブで y はAXI4 Master インターフェースになります。offset=slave はAXI4 Lite Slave インターフェースのレジスタとしてオフセットレジスがマップされます。
x も同様です。
#pragma HLS INTERFACE s_axilite port=return はブロックレベルのインターフェースを AXI4 Lite Slave にするというディレクティブになります。
動作は、ｘ[]のアドレスでAXI4 Master Read を行って、演算してから y[] のアドレスに結果を AXI4 Master Write します。
multi_aixm_tb.c は見ればひと目でわかると思います。
solution フォルダの下にCシミュレーションの結果（csim フォルダ）、CからHDL への合成結果（syn フォルダ）、C/RTL協調シミュレーション結果（sim フォルダ）、IP化の結果（impl フォルダ）が入っています。
multi_axim-master\solution1\csim\report フォルダに multi_axim_csim.log があるので見てましょう。（Vivado HLS をインストールしていない人向けに書いてありますので、持ってい方はVivado HLS で csim のリポートを見れば同じです）
Cシミュレーションの結果が、multi_axim_csim.log に書いてあります。
multi_axim-master\solution1\syn フォルダには、C からHDL へ合成した結果が入っています。
report フォルダは合成結果が入っています。
systemc, verilog, vhdl フォルダには、合成した結果のHDL が入っています。
report フォルダを見てみましょう。
multi_axim_csynth.rpt を開いてみてください。
multi_axim_csynth.rpt にはCからHDL への合成時のレポートが入っています。
Timing Summary の Target 10.00 の単位は ns でターゲットの動作周期です。
Estimated が合成によって推定された動作周期です。これが 8.75 ns です。
Latency と Interval も見て下さい。
次に、verilog フォルダを開いてみてください。
ファイルが4つありますが、multi_axim.v がトップなので開いてみてください。
s_axi_AXILiteS_... がAXI4 Lite Slave インターフェースの信号
m_axi_gmem_... がAXI4 Master インターフェースの信号です。
multi_axim_AXILiteS_s_axi.v を開いてみてください。
45行目から Address Info が書いてあります。これが、AXI4 Lite Slave のアドレスマップです。
Data signal of x が x[] 配列のオフセット・アドレス用レジスタです。ここに x[] 配列があるアドレスをセットします。
Data signal of y が y[] 配列のオフセット・アドレス用レジスタです。ここに y[] 配列があるアドレスをセットします。
0x00 : Control signals の bit 0 - ap_start に 1 を書くと、このIP の処理が始まります。bit 1 - ap_done が 1 になるとIP の処理が終了しています。
残りのファイルを見て下さい。
solution1 フォルダに戻って、次は sim フォルダに入ります。
sim フォルダの中の verilog フォルダに入ります。
ここに、multi_axim.wdb と multi_axim.wcfg があるので、これをVivado のTcl Console から開いてRTL シミュレーション波形を確認します。
Vivado を持っていたら、Vivado を起動します。
フォルダを cd コマンドで移動します。私の環境では、
cd c:/Users/Masaaki/Documents/Vivado_HLS/ZYBO/examples/multi_axim-master/solution1/sim/verilog
ですが、自分の環境の multi_axim-master/solution1/sim/verilog フォルダに移動して下さい。コマンドを入れるとフォルダの選択肢をTcl Console が表示してくれます。
続けて
current_fileset
をTcl Console に入力します。3つのコマンドをコピー＆ペーストしても問題無いです。
そうすると波形が表示されます。
波形をじっくりご覧下さい。
AXI4 Lite Slave， AXI4 MASTER Write 部分の波形を下に示します。
AXI4 MASTER Write 部分を引き伸ばしてみると、y[] 配列に書き込んでいるデータ（m_axi_gmem_WDATA[31:0] が見えます。
AXI4 Master Read と AXI4 MASTER Write を一緒に見てみましょう。
最後にIP 化した部分を説明します。
solution1 フォルダに戻って、impl フォルダに入ります。
更に、ip フォルダに入って下さい。ここがIP のフォルダです。
drivers -> multi_axim_v1_0 -> src フォルダがドライバのソースファイルです。
例えば、multi_axim.c を開いてみましょう。
ここにドライバの関数が並んでいます。
例えば、XMulti_axim_Start() はIP の処理を開始させる関数です。
Vivado HLSの生成したドライバの使い方です。
最初にX<関数名>_Initialize() 、またはX<関数名>_LookupConfig() とX<関数名>_CfgInitialize（） の組ベアメタル・アプリのDeviceIdは最初のインスタンスは0、次は1 X<関数名>_Set_入力ポート で入力ポートの値をWriteするX<関数名>_IsIdle でアイドル状態であることを確認X<関数名>_Start でIPのステートマシンをスタートX<関数名>_IsDone 、X<関数名>_出力ポート_vld を確認X<関数名>_Get_出力ポート をReadするいろいろとC ソースファイルを読んでみると面白いです。
ベアメタル・アプリケーションでは、SDKからこれらの関数を使うことができます。
LinuxではUIO でドライバを使うことができますが、デバイス・ツリーに登録する必要があります。
ip フォルダのxilinx_com_hls_multi_axim_1_0.zip がIP を圧縮したファイルになります。中身を下に示します。
これで、
DSF2015 の
C-6 ”Xilinx社のFPGAにおける高位合成ツールVivado HLSの効果と性能” で説明したAXI4 Masterインターフェースの例の説明を終わります。
2015年10月02日 14:40 |
Vivado HLS
| トラックバック:0
| コメント:0
”
Vivado HLS によるアンシャープマスクキング・フィルタの作製5（Vivado プロジェクトの作製） ”の続き。
前回はVivado 2015.2 のブロックデザインを作製し、アンシャープマスキング・フィルタIP をHDMI 入力 - HDMI 出力のAXI4 Stream 間に挿入した。
今回は、制約ファイルを作製してから、プロジェクトを論理合成、インプリメント、ビットストリームの生成を行って、実機で検証する。
最初に、ラプラシアンフィルタIP の時の制約ファイル（dvi2vga.xdc）をプロジェクトに追加した。
SW0 の配置制約はとりあえず削除した。
Synthesized Design を開いて、Package を表示した。
sw[3:0] をSite を割り当てた。I/O Std は LVCOMS33 に設定した。
追加した SW[3:0] の制約ファイルを下に示す。
dvi2vga.xdc を下に示す。
set_property PACKAGE_PIN P20 [get_ports {vga_pBlue[0]}]
論理合成、インプリメント、ビットストリームの生成を行って成功した。
Project Summary を示す。
ZYBO を使って実機で検証した。下に表示した画面を示す。
paint.net で ガウスボケを半径 1.5 をかけた画像を示す。これが元画像だ。
アンシャープマスキング・フィルタ k= 3.5 をかけた画像を下に示す。文字の輪郭がシャープになっている。
写真をとった位置が違っているので、文字の大きさが異なり、比較が難しいかもしれないが、アンシャープマスキング・フィルタ k= 3.5 をかけた画像の方が元画像より文字がくっきり見えているのがわかると思う。
2015年10月01日 04:00 |
ZYBO
| トラックバック:0
| コメント:0
