”
PetaLinux 2017.3 をインストールする ”の続き。
前回では PetaLinux をインストールできたので、今回はUltraZed-EG Starter Kit 用のPetaLinux をビルドして、UltraZed-EG Starter Kit でPetaLinux 2017.3 をブートしてみようと思う。
”
PetaLinux ツール資料 リファレンス ガイド UG1144 (v2017.2) 2017 年 6 月 29 日” を参考にして進めることにする。
最初にPetaLinux 作業環境のセットアップを行う。
PetaLinux ディレクトリにいるので、2017.3 ディレクトリに cd する。
cd 2017.3/ でPetaLinux の作業環境をセットアップする。
echo $PETALINUX でPETALIUX 環境変数の設定値を確認した。
example1 プロジェクトを生成してみよう。
まずは、PetaLinux のプロジェクトを置いておくディレクトリのpetal_work ディレクトリを生成する。
次に、その下に example1 ディレクトリを生成しよう。
mkdir petal_work 次に、ハードウェア記述ファイル(.hdf) を生成するために、”
UltraZed-EG Starter Kit のチュートリアル3 ”で作ったVivado 2017.3 プロジェクトがある。
そのプロジェクトで、ハードウェアをエクスポートした。
そして design_1_wrapper.hdf が生成された。
example1 ディレクトリに design_1_wrapper.hdf をコピー＆ペーストした。
petalinux-config --get-hw-description=. を実行して、ハードウェア・コンフィギュレーションのインポートを行った。
コンフィギュレーション画面が立ち上がった。
Subsystem AUTO Hardware Settings -> Advanced bootable images storage Settings に行った。
boot image settings -> image storage media (primary sd) にセットした。
u-boot env partition settings -> image storage media (primary sd) にセットした。
Kernel image settings -> image storage media (primary sd) にセットした。
jffs2 rootfs image settings -> image storage media (manual) にセットした。
dtb image settings -> image storage media (from boot image) にセットした。
ここを primary sd にセットしたかったが、primary sd にセットして、Micro SD カードに system.dtb を入れておいても、system.dtb が認識できないようで、system.dtb はどこにあるのか？と聞かれてしまう。
設定が終了したので、Exit した。
build と componets ディレクトリが増えた。
petalinux-build コマンドでシステム・イメージのビルドを行った。
images/linux ディレクトリが生成された。
petalinux-package --image -c kernel --format uImage uImage を生成した。
uImage が生成できた。
BOOT.BIN を生成する。
cd images/linux/ BOOT.BIN が生成された。
example1 ディレクトリに戻って、ビルド済みイメージのパッケージを行う。
cd ../.. exampl1 ディレクトリの下に、pre-built ディレクトリが生成された。その下のディレクトリ構造をtree コマンドを使用して表示した。
FAT32 のMicro SD カードに、example1/images/linux ディレクトリのBOOT.BIN と image.ub を書いた。
2017年11月30日 05:43 |
Linux
| トラックバック:0
| コメント:0
Ubuntu 16.04.3 LTS 上のVivado 2017.3 のLaunch Runs ダイアログが透明になってしまうバグがあって、論理合成ができなくなってしまった。
状況はUltraZed-EG Starter Kit のVivado プロジェクトを新規作成して、IP Integrator でブロック・デザインを作成した。
出来上がったので、Flow Navigator からGenarate Bitstream をクリックして、論理合成、インプリメント、ビットストリームの生成を行おうとした。
No Implementation Results Available ダイアログが表示された。Yes ボタンをクリックした。
次に、Launch Runs ダイアログが表示された。このダイアログが透明で何も選べなかった。
解決方法がわかる方は情報をお待ちしています。コメント欄でお知らせください。よろしくお願いいたします。
もしかして、パッケージが何か足りないのかな？
（追記） その後、Ubuntu を使っていたら、全く反応しなくなって、どうしようもなくなり電源OFF。
再度、電源ONして、Ubuntu を起動し、Vivado を起動して、もう一度、やってみたら、Launch Runs の表示が正常にできました。
何かUbuntu がおかしくなっていたようです。皆さん、ありがとうございました。自己解決できました。
ダイアログの中が透明になったら、リブートしたほうが良さそうです。。。
2017年11月29日 05:00 |
Vivado
| トラックバック:0
| コメント:0
UltraZed-EG Starter Kit の Linux をビルドするにあたって、まずは、Avnet からも情報が出ている
Xilinx 社のLinux のPetaLinux をインストールすることにした。
”
PetaLinux ツール資料 リファレンス ガイド UG1144 (v2017.2) 2017 年 6 月 29 日 ”を参考にしてPetaLinux をインストールしていこと思う。
なお、予め、
Xilinx 社のエンベデッド開発ダウンロード・ページ の”PetaLinux - 2017.3 インストレーション ファイル - 2017.3” の” PetaLinux 2017.3 インストーラー (TAR/GZIP - 7.79GB)” （petalinux-v2017.3-final-installer.run）をダウンロードしておいた。
まずは、”
PetaLinux ツール資料 リファレンス ガイド UG1144 (v2017.2) 2017 年 6 月 29 日 ”の 7 ページの”インストール要件”から、たくさんのパッケージをインストールする必要があることがわかった。
”
aster_ismの工作室 ”さんの”
Windows用Vivado開発環境 ”の”Xilinxツールのインストール”から”依存ツールのインストール”を使用させてもらった。実際には、”
a5teri5m/xilinx2017.2_dep.sh ”にシェル・スクリプトがある。
これをxilinx2017.2_dep.sh としてファイルに落とした。
次に、ホーム・ディレクトリにPetaLinux ディレクトリを作成し、PetaLinux のインストーラー（petalinux-v2017.3-final-installer.run）をコピー＆ペーストした。そのPetaLinux をインストールするディレクトリとして 2017.3 ディレクトリを作成した。
mkdir -p PetaLinux ./xilinx2017.2_dep.sh を実行して、パッケージをインストールした。
これでPetaLinux をインストールする準備が整った。
./petalinux-v2017.3-final-installer.run 2017.3/ を実行してPetaLinux 2017.3 をインストールした。
最初にライセンス承認を3回聞かれたが、その後、問題なくインストールできたようだ。
PetaLinux 2017.3 がインストールされた 2017.3 ディレクトリの内容を下に示す。
最後にインストール・ログを貼っておく。
masaaki@masaaki-H110M4-M01:~/PetaLinux$ ./petalinux-v2017.3-final-installer.run 2017.3/
2017年11月28日 05:31 |
Linux
| トラックバック:0
| コメント:0
”
intel HLS コンパイラを試してみる13（mm_slave その3） ”の続き。
今回は、examples\tutorials\interfaces\explicit_streams_buffer を試してみよう。
これは、”
intel HLS コンパイラを試してみる7（image_downsampleを試す1） ”でもやったAvalon Streaming インターフェースだが、ihc::buffer<>でストリーム入力が宣言されている。
image_inversion.cpp だがハードウェア化関数は、img_invert1() と img_invert_buff() がある。
二つの関数の宣言部分を引用する。
component void img_invert(int W,int H,unsigned char > &a,unsigned char > &b) {
component void img_invert_buff(int W,int H,unsigned char , ihc::buffer<64 > > &a,unsigned char > &b) {
上に示すように、 img_invert_buff() の方の入力が、ihc::stream_in
で定義されている。それでも同様に a.read() でストリームのデータを読むことができる。これは、ストリームのバッファの容量を指定する方法のようだ。build default を実行した。
2017年11月27日 05:12 |
intel HLS
| トラックバック:0
| コメント:0
FPGA+SoC+Linux実践勉強会 に参加する予定なので、ZYBO Z7 用のMicroSDカードを用意しよう。
ikwzm さんの”
FPGA+SoC+Linux+Device Tree Overlay+FPGA Region(ブートイメージの提供) ”を見ながら、MicroSDカードを作っていこう。
家のパソコン環境はWindows 10 上にUbuntu 16.04 をVirutalBox を使って動作させている。
まずは、”
FPGA+SoC+Linux+Device Tree Overlay+FPGA Region(ブートイメージの提供) ”の通りにコマンドを実行して、github.com/ikwzm/FPGA-SoC-Linux をダウンロードし、ROOT_FS もダウンロードした。
git clone git://github.com/ikwzm/FPGA-SoC-Linux
FPGA-SoC-Linux ディレクトリの内容を示す。
MicroSDカードをフォーマットしよう。FAT32 + ext3 にフォーマットする。これは、”
FPGA+SoC+Linux+Device Tree Overlay+FPGA Manager(PYNQ-Z1対応)”を試してみる2（Micro SDカードの準備） ”の通りにやってみた。
MicroSDカードの第1パーティションはZYBO_Z7_BOOT と設定したつもりが、名前が長すぎたのか？ZYBO_Z7_BOO になってしまった。第2パーティションはROOT_FS と名前を付けたが、先にROOT_FS がマウント・ポイントにあったので、マウントされたときのディレクトリ名がROOT_FS1 になってしまったが、ROOT_FS がなければ、ROOT_FS にマウントされるはずだ。
次のコマンドを実行した。
sudo cp ~/FPGA-SoC-Linux/target/zynq-zybo-z7/boot/* /media/masaaki/ZYBO_Z7_BOO/
ここまでやると、ZYBO_Z7_BOO にBOOT.bin などのファイルが入って、ROOT_FS にDebian のルート・ファイル・システムが入った。
ROOT_FS/home/fpga には、fpga-soc-linux-drivers-4.12.14-armv7-fpga_0.0.8-1_armhf.deb と fpga-soc-linux-services_0.0.7-1_armhf.deb が入った。
これで、umount した。
sudo umount /media/masaaki/ZYBO_Z7_BOO
しかし、またオートマウントされてしまったので、nautilus から取り出しを行った。
これで、Micro SDカードの準備はOK。
ZYBO Z7 にMicroSDカードを入れて電源ON した。
Debian 9 が立ち上がった。
fpga ユーザーでパスワード fpga で入れた。
sudo dpkg -i fpga-soc-linux-drivers-4.12.14-armv7-fpga_0.0.8-1_armhf.deb を実行した。
ls -1 /lib/modules/4.12.14-armv7-fpga/ikwzm/ を実行すると、/lib/modules/4.12.14-armv7-fpga/ikwzm の元にカーネルドライバがインストールされているのが見えた。
sudo dpkg -i fpga-soc-linux-services_0.0.7-1_armhf.deb を実行した。
sudo systemctl status device-tree-overlay.service を実行した。
sudo systemctl status udmabuf.service を実行した。
sudo systemctl status zptty.service を実行した。
”
FPGA+SoC+Linux+Device Tree Overlay+FPGA Manager(PYNQ-Z1対応)”を試してみる4（環境の整備） ”を参考に、Xming でX のGUI を表示できるようにした。nautilus の画面を示す。
pip3 install numpy で、numpy をインストールした。ソースファイルからコンパイルした様で時間がかかった。
sudo apt-get install lrzsz で ZMODEM での転送ソフトをインストールした。
rz コマンドを使用して、Tera Term から ZMODEM で転送するとファイルをZYBO_Z7 に転送することができる。
2017年11月26日 04:35 |
ZYBO Z7
| トラックバック:0
| コメント:0
”
intel HLS コンパイラを試してみる12（mm_slave その2） ”の続き。
前回は、シミュレーション波形を比較したが、今回はレポートでリソース使用量などを比較してみよう。
まずは、part_1_basic_component のSummary を示す。
ALUｓ が 2026 個、FFｓ が 2223 個、RAMｓ が 12 個使用している。
次に、part_2_slave_component のSummary を示す。
ALUｓ が 2026 個、FFｓ が 2223 個、RAMｓ が 12 個使用していて、part_1_basic_component と全く同じだ。
part_3_slave_register_arguments のSummary を示す。
ALUｓ が 2026 個、FFｓ が 2223 個、RAMｓ が 12 個使用していて、part_1_basic_component 、part_2_slave_component と全く一緒だ。なぜ、回路が違うので、リソース使用量が同じなんだろう？
part_4_slave_mem_args のSummary を示す。
ALUｓ が 511 個、FFｓ が 377 個、RAMｓ が 16 個使用している。さすがにスレーブばかりのインターフェースではリソース使用量が少ない。ただし、RAMｓ は 16 個で増えている。
part_1_basic_component のComponent viewer 画面を示す。
do, N, x がすべて外に出ている。
part_2_slave_component のComponent viewer 画面を示す。
do だけ CSR として component swp_int_end の中に入っている。
part_3_slave_register_arguments のComponent viewer 画面を示す。
do, N, x ともに CSR として component swp_int_end の中に入っている。
part_4_slave_mem_args のComponent viewer 画面を示す。
x が無くなっていて、Ｎ と do がＣＳＲ として、 component swp_int_end の中に入っている。やはり、スレーブなので、全く違うな。。。
2017年11月25日 04:34 |
intel HLS
| トラックバック:0
| コメント:0
”
ソニーのNeural Network Console をやってみた2 ”の続き。
ソニーのNeural Network Console がVer. 1.1.0 になった ので、やってみた。
zip ファイルを展開してからNeural Network Console を起動した。
ENGINEはGPU に設定した。CPU よりも断然速い。GPU はNVidia のGTX1060 を搭載している。
LeNet.sdcproj をやってみた。
TRAINING を実行した。
EVALUATION を実行した。
重みやバイアスの値を見たいので、ACTION をクリックして、Open Result Location をクリックした。
F:\NN_console\samples\sample_project\image_recognition\MNIST\LeNet.files\20170804_140639 フォルダが開いた。
どうやら parameters.h5 に重みやバイアスが書いてあるらしい？
見るためには、hdfview が必要のようだが、Windows 用はダウンロードできなかった。
そこで、簡単に手に入るUbuntu 用の hdfview を使うことにした。
Fall Creaters Update をWindows 10 にインストールすると、ストアからUbuntu をWindows 10 にインストールすることができる。
Ubuntu をインストールして、
sudo apt update
を行った。
sudo apt install hdfview でhdfview をインストールした。
時間がかかったが、インストールできた。
GUI が起動するので、設定を行う必要がある。
”
Windows 10 fall creators update のWindows Subsystem for Linuxを試してみた ”
”
Windows 10 fall creators update のWindows Subsystem for Linuxを試してみた3 ”
を参考にしながらやっていく。
sudo apt-get install x11-apps を実行した。
vi .bashrc で .bashrc を編集して、
export DISPLAY=:0.0
を追加した。
source .bashrc を実行して、.bashrc の内容を反映させた。
日本語表示ができるように、次のコマンドを実行した。
sudo ln -s /mnt/c/Windows/Fonts /usr/share/fonts/WindowsFonts Xming を立ち上げてから、
hdfview を実行した。
GUI で hdfview が立ち上がった。
File メニューから open を選んで、F:\NN_console\samples\sample_project\image_recognition\MNIST\LeNet.files\20170804_140639 フォルダの prameters.h5 を選択した。
ネットワークの重みやバイアスを見ることができた。
表示しているConvolution_2 のW をすべて選択して、Ctrl+C を押して、コピーし、LibreOffice のCalc を起動してCtrl+V をクリックするとコピーすることができた。
これで、重みやバイアスをいろいろ加工することができそうだ。
2017年11月24日 05:31 |
DNN
| トラックバック:0
| コメント:0
”
intel HLS コンパイラを試してみる11（mm_slave その1） ”の続き。
前回は、4つのAvalon Slave インターフェース（最初の1つはAvalon Master だが）を i++ でコンパイルした。今回は、ModelSimでシミュレーション波形を見ていこう。
今回も intel HLS のチュートリアルの F:\intelFPGA_lite\17.1\hls\examples\tutorials\interfaces\mm_slave を題材にする。
part_1_basic_component 最初に、part_1_basic_component.cpp のシミュレーション波形を見ていく。
シミュレーション波形全体を下に貼る。
1つのRead 区間とWrite 区間は 260000 ps (260 ns) でクロックが 1000 ps なので、260 クロック分あるが、Read で見ると 2 クロックで1転送で、転送数は 130 個、ビットレーンごとに 4 回繰り返しているので、130/2 = 32.5 個だが、中途半端な数なので、たぶん32個ずつ処理していて、4クロック分は余計に必要なんだと思う。
次にStart 信号を見てみよう。
Start 信号が 1 クロック分出て、その後に、Read 転送が入っているのが見える。Avalon-MM の Read 転送は”
Avalon® Interface Specifications MNL-AVABUSREF 2017.05.08 ”の 23 ページの”Figure 7. Read and Write Transfers with Waitrequest”を見ると、read が 1 の時の最初のクロックでアドレスを認識して、次のクロックでRead データを受け取るようだ。
Read は同じアドレスを4 回 Read しているようだ。
Write は 1 クロックでWrite できるようだ。バイト・レーンの変換で、1バイトごとに書いているが、最初にバイト・レーン・イネーブルが 08 と 80 でアドレスを大きくしてデータを書いていって、次は、04 と 40 で、その次は01 と 10 で、最後に 02 と 20 でデータを書いていく。
part_1_basic_component.cpp では、同じアドレスの int 型の変数から 4 バイト・レーン読んで、4 バイト・レーン書いているので、C の記述とハードウェア化された動作が違っているが、最適化のためだろう？と思う。
最後に done の波形を貼っておく。
part_2_slave_component 次に、part_2_slave_component.cpp のシミュレーション波形を見てみよう。
最初に全体の波形を示す。
Start 信号や busy, done, stall などの信号は無くなっている。その代わりに、avs_xra_... の信号が追加されていて、スタートを支持したり、エンドを知ることができる。
アドレスマップは、F:\intelFPGA_lite\17.1\hls\examples\tutorials\interfaces\mm_slaves\part_2_slave_component.prj\components\swp_int_end フォルダのswp_int_end_csr.h ファイルにあった。swp_int_end_csr.h の一部を引用する。
最初のスタートを見てみよう。
最初に、avs_xra_... の信号で、アドレスの2番地、3番地、1番地の最下位バイトに 1 を書いている。
2番地が 0x10 で、interrupt_enable[0:0] に 1 を書いて、Enable interrupt として、3番地が 0x18 で、interrupt_status is write 1 to clear なので、interrupt_status をクリアしているようだ。そして 1 番地が 0x8 で、 start[0:0] を 1 にしているようだ。
最後に、avs_xra_... の信号で、アドレスの3番地から 3 を読みだしている。これは、0x18 で、done[0:0] と interrupt_status[0:0] が共に 1 になっている。
part_3_slave_register_arguments part_3_slave_register_arguments.cpp のシミュレーション波形を見ていく。
シミュレーション波形全体を下に貼る。 x と N が無くなっている。これはレジスタにマップされている。swp_int_end_csr.h の一部を引用する。
最初の設定部分を拡大する。レジスタへの設定が表示されている。
レジスタマップを示す。 x と N がレジスタにマップされているのが分かる。swp_int_end_csr.h の一部を引用する。
Avalon Slave へのWrite が見えるが、
最初は2番地で、0x10 の interrupt_enable[0:0] を 1 にしているようだ。
次の 3 番地は 0x18 で、interrupt_status[0:0] を 1 にしている。
4 番地は 0x20 で x[63:0] に 0x71b810 を書いている。
5 番地は 0x28 で、N[31:0] に 0x1000 を書いている。
1番地は 0x8 で、start[0:0] に 1 を書いて、スタートしている。
波形の最後は、、avs_xra_... の信号で、アドレスの3番地から 3 を読みだしている。これは、0x18 で、done[0:0] と interrupt_status[0:0] が共に 1 になっている。
part_4_slave_mem_args 最後のpart_4_slave_mem_args.cpp のシミュレーション波形を見ていこう。
シミュレーション波形全体を示す。他のと違っている。すべてスレーブだからか？
最初にスタート信号は無い。まずはスレーブなので、swp_int_end のメモリにデータをバイトごとに書いているのだろう？すべて受け身になるので、こうする必要がありそうだ。
データを書いた後でスタートするようだ。スレーブ・インターフェースしかないため、自分で読むことができないので、書かれてからスタートするしかないのだと思う。
アドレスマップを示す。 x はスレーブで書かれるので必要ないようだ。N だけレジスタマップされている。swp_int_end_csr.h の一部を引用する。
最初は2番地で、0x10 の interrupt_enable[0:0] を 1 にしているようだ。
次の 3 番地は 0x18 で、interrupt_status[0:0] を 1 にしている。
4 番地は 0x20 で、N[31:0] に 0x1000 を書いている。
1番地は 0x8 で、start[0:0] に 1 を書いて、スタートしている。
スタートは良いのだが、結果もマスタが読んでくる必要があるようだ。つまり、何もアクセスが無い時間はスタートして処理を行っている時間ということだ。処理時間は、4.111 us だった。
スタートしてから、4.111 us 後には 3 番地、0x18 をRead すると 3 が出て、、done[0:0] と interrupt_status[0:0] が共に 1 になっているのが分かる。
Read もバイトごとにRead している。バイト・イネーブルが1バイトごとにイネーブルになっていく。
これで、4 つのパターンの特徴が分かった。自分で一番使うとしたら、part_3_slave_register_arguments だろうかな？
2017年11月23日 08:15 |
intel HLS
| トラックバック:0
| コメント:0
”
intel HLS コンパイラを試してみる10（examples\tutorials\interfaces\mm_master_testbench_operators その2） ”の続き。
前回は、examples\tutorials\interfaces\mm_master_testbench_operators をやってみたが、今回は、intel HLS のチュートリアルの F:\intelFPGA_lite\17.1\hls\examples\tutorials\interfaces\mm_slave をやってみることにする。
mm_slave は、intel HLS によるAvalon-MM Slave インターフェース・モジュールのいろいろな実装をテストすることができるサンプルだ。これを見れば、intel HLS によるAvalon-MM Slave インターフェースの実装の仕方が分かるのではないか？と思っている。
mm_slave にはpart_1_basic_component.cpp、part_2_slave_component.cpp、part_3_slave_register_arguments.cpp、part_4_slave_mem_args.cpp の4つのC++ ソースファイルがある。
READMEに説明が書いてある。README の説明に従ってやってみることにする。
part_1_basic_component.cpp はintel HLS の通常の Start , busy, done などがある intel HLS のデフォルトのインターフェースになる気がする。
component void swp_int_end() の動作としては、32ビット幅のデータの8ビットごとの入れ替えで、エンディアンを変換する関数のようだ。
component void swp_int_end (int * x,int N ) {
intelFPGA_lite\17.1\hls\examples\tutorials\interfaces\mm_slave のpart_1_basic_component.cpp を引用する。
part_2_slave_component.cpp は、 Avalon-MMスレーブインタフェースとして実装されるようだ。（hls_avalon_slave_component）
hls_avalon_slave_componentvoid swp_int_end (int * x, int N ) {
intelFPGA_lite\17.1\hls\examples\tutorials\interfaces\mm_slave のpart_2_slave_component.cppp を引用する。
part_3_slave_register_arguments.cpp は、コンポーネントの引数をコンポーネントのAvalon-MMスレーブインタフェースのメモリマップに追加しているそうだ。コンポーネントの引数のそれぞれがスレーブレジスタとして指定されているということだ。（hls_avalon_slave_register_argument）
hls_avalon_slave_componentvoid swp_int_end (hls_avalon_slave_register_argument int * x,int N ) {
intelFPGA_lite\17.1\hls\examples\tutorials\interfaces\mm_slave の part_3_slave_register_arguments.cpp を引用する。
part_4_slave_mem_args.cpp は、ポインタ（Avalon MM-Master）インタフェースを、M20Kを使用した整数配列を格納するスレーブ・メモリに置き換えるそうだ。ｘ のみ hls_avalon_slave_memory_argument() が使用されている。x はAvalon-MM マスタ・インターフェースになるのかもしれない？
hls_avalon_slave_componentvoid swp_int_end (hls_avalon_slave_memory_argument(BUFFER_SIZE*sizeof (int )) int * x,int N) {
intelFPGA_lite\17.1\hls\examples\tutorials\interfaces\mm_slave の part_4_slave_mem_args.cpp を引用する。
build.bat を引用する。14行目をArria10 からCyclone Vに変更した。
build.bat を起動した。
part_1_basic_component.cpp、part_2_slave_component.cpp、part_3_slave_register_arguments.cpp、part_4_slave_mem_args.cpp の4つともPASSED になった。
F:\intelFPGA_lite\17.1\hls\examples\tutorials\interfaces\mm_slaves フォルダの内容を示す。
F:\intelFPGA_lite\17.1\hls\examples\tutorials\interfaces\mm_slaves\part_1_basic_component.prj\components\swp_int_end フォルダのswp_int_end_inst.v の内容の一部を示す。
swp_int_end swp_int_end_inst (
Start などのブロックレベルの信号とメモリ・インターフェースがある。
F:\intelFPGA_lite\17.1\hls\examples\tutorials\interfaces\mm_slaves\part_2_slave_component.prj\components\swp_int_end フォルダのswp_int_end_inst.v の内容の一部を示す。
swp_int_end swp_int_end_inst (
start, busy, done, stall などの信号が消えて、avs_cra_.... のAvalon Slave の信号が増えた。
F:\intelFPGA_lite\17.1\hls\examples\tutorials\interfaces\mm_slaves\part_3_slave_register_arguments.prj\components\swp_int_end フォルダのswp_int_end_inst.v の内容の一部を示す。
swp_int_end swp_int_end_inst (
part_2_slave_component.prj とひかくすると、ｘ と N が消えて、.avs_cra_address が 2 bit から 3 bit になった。つまり、x と N もレジスタにマップされたようだ。
F:\intelFPGA_lite\17.1\hls\examples\tutorials\interfaces\mm_slaves\part_4_slave_mem_args.prj\components\swp_int_end フォルダのswp_int_end_inst.v の内容の一部を示す。
swp_int_end swp_int_end_inst (
part_3_slave_register_arguments.prj と比較すると、avmm_0_rw_.... のAvalon MM-Master インターフェースが avs_x_..... のAvalon-MM slave インターフェースに置き換えられている。
2017年11月21日 05:25 |
intel HLS
| トラックバック:0
| コメント:0
”
intel HLS コンパイラを試してみる9（examples\tutorials\interfaces\mm_master_testbench_operators） ”の続き。
前回は、Avalon MM インターフェースのチュートリアルをやってみて、ModelSim で波形を観測した。今回は、レポートとQuartus Prime を動かしてコンパイルしてみた。
まずは、レポートを貼っておく。
Summary
Loops analysis
Area analysis of system
Area analysis of source
Component Viewer
Component memory viewer
Verification statistics Latency は min = 24, max = 89, avg = 68 だった。
Quartus Prime 17.1 を立ち上げた。
F:\intelFPGA_lite\17.1\hls\examples\tutorials\interfaces\mm_master_testbench_operators\operators.prj\quartus の quartus_compile.qpf を読み込んだ。
コンパイルを実行した。
Entity の quartus_compile の下の、add_x をダブルクリックして開くと、IP のシンボルを見ることができた。
2017年11月19日 04:51 |
intel HLS
| トラックバック:0
| コメント:0
今回は、F:\intelFPGA_lite\17.1\hls\examples\tutorials\interfaces\mm_master_testbench_operators を試してみることにした。まだ、Avalon MM インターフェースはやっていないので、やってみることにした。
Avalon MM インターフェースについては、”
Avalon® Interface Specifications MNL-AVABUSREF 2017.05.08 ”を参照のこと。
build.bat を書き換えた。
set "DEVICE=Arria10"
から
set "DEVICE=CycloneV"
に書き換えた。
次に、i++ のオプション -ghdl を追加した。こうするとシミュレーション結果の波形 vsim.wlf が出力される。
ハードウェア化するソースコードは、F:\intelFPGA_lite\17.1\hls\examples\tutorials\interfaces\mm_master_testbench_operators\operators.cpp から引用する。
component void add_x(mm_src_t &src, mm_dst_t &dst, unsigned int x) {
src と dst はAvalon MM インターフェースになっていて、x は最初は 0x10 が入っている。
build default コマンドを実行した。
operators.prj フォルダができた。
その中はお馴染みのcomponents、quartus、reports、verification フォルダができていた。
F:\intelFPGA_lite\17.1\hls\examples\tutorials\interfaces\mm_master_testbench_operators\operators.prj\verification フォルダのvsim.wlf ファイルをModelSim で開いた。
Avalon MM インターフェースのRead は rw_address で指定したアドレスが rw_read が 1 の時に有効になるようだ。それが上の図のピンクの四角で囲った領域だ。
Read データが来るのは、その後で、 rw_readdatavalid が 1 になったときのようだ。 1 になったときにrw_readdata にデータが出力されている。
Avalon MM インターフェースのWrite は rw_address にアドレスを出力して、rw_write を 1 にすると同時に、rw_writedata にデータを与えれば良いようだ。
Read データと Write を見比べてみると、Read データに0x10 を加算した値が Write データになっているのが分かる。
2017年11月18日 05:48 |
intel HLS
| トラックバック:0
| コメント:0
”
UltraZed-EG Starter Kit のチュートリアル2 ”の続き。
前回はSDKでアプリケーションソフトを作成してHello World をUltraZed-EG Starter Kit で動作させた。今回は、チュートリアルの続きやってみよう。
PS User LED を点滅させるのをやってみた。
PS User LED は、
UltraZed™ I/O Carrier Card Version 1.0 の 7 ページによるとUltraZed-EG Starter Kit のPS のMIO[31] に接続されている。つまり、PS 側なので、ソフトウェアだけで動作するということになる。
まずは、SDKでFile メニューからNew -> Application Project を選択した。
New Project ダイアログが開いた。Project Name にPS_User_LED を入力し、Board Support Package は、Use existing のラジオボタンをクリックして、standalone_bsp_0 を選択した。（といっても１つしかBSPを作っていないので、一択だった）
Next -> ボタンをクリックして、Empty Application を選択し、Finish ボタンをクリックした。
PS_User_LED プロジェクトが生成された。
UltraZed_EG_SK_Tutorial_2016_4_v1.zip\ultrazed_eg_starter_kit フォルダにPS_User_LED を点滅させるソフトウェアの ps_user_led.c がある。
SDK の PS_User_LED プロジェクトの src フォルダ内にドラック＆ドロップした。
すると、File Operation ダイアログが開く。デフォルトで Copy files のラジオボタンがチェックされているので、そのままOKボタンをクリックした。
ps_user_led.c がコンパイルされて、PS_User_LED.elf が生成された。
SDK のPS_User_LED プロジェクトを右クリックし、右クリックメニューからRun As -> Launch on Hardware (System Debugger) を選択して、PS_User_LED.elf を実行した。
UltraZed-EG Starter Kit のPS_User_LEDが点滅した。赤く光っているLED がPS_User_LED だ。
ギガビット・インサーポートのテスト ギガビット・インサーポートのテストを行った。
SDK のFile メニューからNew -> Application Project を選択して、表示されたNew Project ダイアログで、Project Name にEth_Test を、Board Support Package のCreate New ラジオボタンをクリックして、Eth_Test _bsp を入力した。
Next -> ボタンをクリックした。
Templates のAvailable Templates で、IwIP Echo Server をクリックし、Finish ボタンをクリックした。
Eth_Test と Eth_Test_bsp プロジェクトが生成された。
SDK のEth_Test プロジェクトを右クリックし、右クリックメニューからRun As -> Launch on Hardware (System Debugger) を選択して、Eth_Test.elf を実行した。
stdout に IwIP TCP echo sever の表示が出た。
SDK のFile メニューからNew -> Application Project を選択して、表示されたNew Project ダイアログで、Project Name にPeriph_Test を、Board Support Package のUse existing ラジオボタンをクリックして、standalone_bsp_0 を選択した。
Next -> ボタンをクリックした。
Templates のAvailable Templates で、Peripheral_Tests をクリックし、Finish ボタンをクリックした。
Pheriph_Test プロジェクトが生成された。
まずはFPGA をコンフィギュレーションするために、SDKのXilinx メニューからProgram FPGA を選択した。
Program FPGA ダイアログが表示された。Program ボタンをクリックした。
SDK のPeriph_Test プロジェクトを右クリックし、右クリックメニューからRun As -> Launch on Hardware (System Debugger) を選択して、Periph_Test.elf を実行した。
stdout に結果が出力された。
1つFail になった。
2017年11月17日 05:32 |
UltraZed-EG
| トラックバック:0
| コメント:0
今朝、Windows のUpdate があって、Vivado 2017.3 が動かなくなった。
今回のアップデートは、Windows 10 Fall Creators Update がかかってしまい、Vivado 2017.3 が起動しなかった。
これは
なひたふさんのツィート で知ったのだが、Windows 10 Fall Creators Update をかけてしまうと、Vivado 2017.3 が起動しないということだ。
解決策はツィートにあるように、”
AR# 69908 2017.3 - Windows 10 Fall Creators Update で Vivado が起動しない ”を参照のこと。
AR#69908 を引用しておく。
1．(Vivado インストール ディレクトリ)\2017.3\bin\unwrapped\win64.o に移動する。
2017年11月16日 14:40 |
Vivado
| トラックバック:0
| コメント:0
”
UltraZed-EG Starter Kit のチュートリアル1 ”の続き。
前回は、UltraZed-EG Starter Kit のチュートリアルを初めて、Vivado で論理合成、インプリメント、ビットストリームの生成まで実行できた。今回は、SDKでアプリケーションソフトを作成して、実機テストしてみよう。
前回、インプリメントが成功したので、File メニューからExport -> Export Hardware... を選択して、ハードウェアをエクスポートした。
File メニューからLaunch SDK を選択して、SDK を起動した。
SDK の File メニューからNew -> Board Support Package を選択した。
standalone を選択している。Finish ボタンをクリックした。
Hardware Platform をクリックして見ると、プロセッサが全選択できるようだ。
Board Support Package Settings ダイアログが開いた。
Overview の standalone をクリックすると、stdin と stdout が psu_uart_0 になっているのが見えた。
OKボタンをクリックすると、SDK で standalone_bsp_0 が生成された。
SDK のFile メニューから New -> Application Project を選択した。
Project Name にHello_UltraZed と入力し、Board Support Package は先ほど生成した standalone_bsp_0 を選択した。
Next -> をクリックして、次のTemplate 画面でデフォルトの Hello World を選択したままで、Finish ボタンをクリックした。
SDK にHello_UltraZed が生成された。
Console 画面を示す。
UltraZed_EG_Starter_Kit_Tutorial_VIvado_2016_4.pdf の 29 ページの”7 Setting up the Hardware ”からUltraZed-EG Starter Kit の設定を引用する。
Please perform the following steps to setup the UltraZed-EG Starter Kit.
この後で、UltraZed-EG Starter Kit のUSB-Serial のドライバが無かったので、Silicon Labs のCP21XXのドライバをインストールした。
Hello_UltraZed を右クリックし、右クリックメニューからRun As -> Launch on Hardware (System Debugger) を選択した。
Tera Term に Hello World が表示された。
2017年11月16日 05:29 |
UltraZed-EG
| トラックバック:0
| コメント:0
”
intel HLS コンパイラを試してみる7（image_downsampleを試す1） ”の続き。
前回は、image_downsample で build test-msvc と build test-x86-64 をやってみた。今回は、build test-fpga をやってみる。
build test-fpga コマンドを実行した。
test-fpga.exe を実行したが、実行に1時間半くらいかかってしまった。
レポートを見てみよう。
Summary 当たり前だが、counter よりもリソース使用量が多い。
Loops analysis 左の行をクリックすると対応するソースコードがハイライトされる。
Area analysis of system こちらも左の行をクリックすると対応するソースコードがハイライトされる。
Area analysis of source
Component Viewer
Component memory viewer
Component memory viewer
Verification statistics Latency は 257012 クロックだった。
Quartus Prime 17.1 を立ち上げて、プロジェクトを読み込んだ。
コンパイルを行って、成功した。
resize:resize_inst をダブルクリックすると、IP Parameter Editor が立ち上がった。
ModelSimを立ち上げて、 intelFPGA_lite\17.1\hls\examples\image_downsample\test-fpga.prj\verification のvsim.wlf を読み込んだ。約257 us シミュレーションしている。
wave ウインドウを拡大した。
wave ウインドウをさらに拡大した。
original_image のready と valid はこの画面ではすべて 1 だが、resized_imag の valid は1クロックおき位に 1 と 0 を繰り返している。これは、リサイズした画面のほうが小さいからだろう。
2017年11月15日 04:36 |
intel HLS
| トラックバック:0
| コメント:0
F:\intelFPGA_lite\17.1\hls\examples\counter\test-fpga.prj\reports フォルダにある report.html だが、たくさん画面があったので、貼っておきたいと思う。
まずはデフォルトのSummary 画面。
View report をクリックするとメニューが出てくる。ここから見たい項目を選択する。
Loops analysis を選択した。
Loops analysis
Area analysis of system
Area analysis of source
Component Viewer。これ面白そう。
コンポーネントにマウスをオーバーライドすると、情報が表示される。
Component memory viewer。counter では情報が無いみたいだ。
Verification statistics
2017年11月14日 04:42 |
intel HLS
| トラックバック:0
| コメント:0
UltraZed-EG Starter Kit のチュートリアルをやってみることにした。
UltraZed-EG Starter Kit Tutorial – Vivado 2016.4 をダウンロードして、その中に UltraZed_EG_Starter_Kit_Tutorial_Vivado_2016_4.pdf が入っているので、それを見ながら、Vivado 2017.3 でチュートリアルをやっていくことにした。
UltraZed_EG_SK_Tutorial_2016_4_v1.zip には、UltraZed-EG Starter Kit のボードファイルが入っていたが、ES のものだったので、
Github/Avnet のbdf/ultrazed_3eg_iocc/1.0 にC バージョンのボードファイルがあった。
Vivado 2017.3 の Vivado\2017.3\data\boards\board_files フォルダに ultrazed_3eg_iocc フォルダをコピーした。
Vivado 2017.3 を立ち上げて、プロジェクトを新規作成した。
デフォルトで進むダイアログは書かないことにする。
Project Name ダイアログ。
Default Part ダイアログ。無事に UltraZed-3EG IO Carrier Card が出てきた。
New Project Summary ダイアログ。
プロジェクトが作成された。
Create Block Design を行った。
ブロックデザインで、Add IP を行った。 zynq で検索して、Zynq UltraScale + MPSoC をダブルクリックした。
zynq_ultra_ps_e_0 が追加された。Run Block Automation をクリックする。
Run Block Automation ダイアログ。
UltraZed-3EG IO Carrier Card の設定が入ったはず。
zynq_ultra_ps_e_0 をダブルクリックして、設定ダイアログを表示した。
I/O Configuration 画面 1/3 、Zynq よりもMIO が増えているようだ。
I/O Configuration 画面 2/3。
I/O Configuration 画面 3/3 、GT Lane もMIOにできているみたいだ。
Clock Configuration 、pl_clk0 が見当たらないがどこにあるんだろうか？
Clock Configuration に Output Clocks タブがあった。ここで、PLへのクロック周波数を設定していた。
DDR Configuration
PS-PL Configuration
ダイアログを閉じた。
Vivado の真ん中上のウインドウで、DIP switches をダブルクリックした。
Connect Board Component ダイアログが開いた。デフォルトのままOKボタンをクリックした。
axi_gpio_0 が Add IP されたので、Run Block Automation をクリックした。
Run Block Automation ダイアログが開いた。デフォルトのままOKボタンをクリックした。
2つ IP が追加され、配線された。
Vivado の真ん中上のウインドウで、LED をダブルクリックした。
Connect Board Component ダイアログが開いた。デフォルトのままOKボタンをクリックした。
axi_gpio_0 に GPIO2 が追加された。
Vivado の真ん中上のウインドウで、Push buttons をダブルクリックした。
Connect Board Component ダイアログが開いた。デフォルトのままOKボタンをクリックした。
axi_gpio_1 が追加された。Run Block Automation をクリックした。
Run Block Automation ダイアログが表示された。デフォルトのままOKボタンをクリックした。
ブロックデザインが完成した。
Validate Design をクリックした。
成功した。
Vivado の真ん中上のウインドウをSource タブをクリックし、design_1 を右クリックして、右クリックメニューから Create HDL Wapper... を選択した。
Creater HDL Wapper ダイアログが表示された。デフォルトのままOKボタンをクリックした。
design_1_wrapper.v が生成されて、トップのファイルになった。
Flow Navigator から Generate Bitstream をクリックした。
ダイアログがいくつか開いたが、デフォルトのままOKボタンをクリックした。
論理合成、インプリメント、ビットストリームの生成が行われ、成功した。結果を示す。
2017年11月14日 04:15 |
UltraZed-EG
| トラックバック:0
| コメント:0
”
intel HLS コンパイラを試してみる6（counter.cpp のコードを変更した） ”の続き。
今回から counter を終了して、次のexample の image_downsample を試してみよう。 image_downsample はbmp ファイルの縦横のサイズを小さくするアプリケーションのようだ。
image_downsample のフォルダを示す。
ファイルがたくさんあるが、bmp_tools.cpp は bmp のread と write を受け持っているようだ。
resize.cpp は画像のリサイズをするようだ。ここにハードウェアになる予定の
component void resize(unsigned ratio, int rows, int cols, input_image_stream& original_image, output_image_stream& resized_image);
がある。
ここでは、入出力が
input_image_stream& original_image, output_image_stream& resized_image
で行われているが、これは、resize.h で
typedef ihc::stream_in<unsigned int ="" > input_image_stream;typedef ihc::stream_out<unsigned int ="" > output_image_stream;
で定義されている。
これらは、Avalon® Streaming Interface のようだ。
Intel High Level Synthesis Compiler User Guide のAvalon® Streaming Interface Arguments を見ると書いてある。
Avalon® Streaming Interface は入力は、read メソッドでストリームから読めて、出力は write メソッドでストリームに書けるようだ。
resize をどこから使っているか？というと main.cpp で呼ばれている。
test.bmp を読んで、downsampled.bmp にダウンサンプリングして、expected.bmp と縦横サイズを比較しているようだ。
さて、build してみよう。その前に build.bat を -march=CycloneV -ghdl に修正した。
これで
build test-msvc を実行した。
次に、
test-msvc.exe で実行した。
増えたファイルを示す。
test.bmp がこれだ。
downsampled.bmp がこれだ。
次に、
build test-x86-64 コマンドを実行した。
test-x86-64.exe を実行した。
増加したファイルを示す。
2017年11月13日 04:57 |
intel HLS
| トラックバック:0
| コメント:0
”
intel HLS コンパイラを試してみる5（ ihc_hls_enqueue() と ihc_hls_component_run_all() ） ”の続き。
前回は、ihc_hls_enqueue() でキューに入れた実行待ち行列を ihc_hls_component_run_all() で実行するとパイプライン実行されるということが分かった。カウンタでは、1クロックごとに 1 カウントアップされている。
それでは、パイプライン実行しないとどうなるのか？をやってみた。
まずは、examples フォルダの下に、counter2 フォルダを作成して、build.bat と counter.cpp をコピーした。
そうして、counter.cpp を下の様に修正した。これは、ihtel HLS の counter.cpp のコードを参照して、変更している。
build test-fpga を実行した。
ModelSim を立ち上げて、F:\intelFPGA_lite\17.1\hls\examples\counter2\test-fpga.prj\verification の vsim.wlf を読み込んだ。
ihc_hls_enqueue() と ihc_hls_component_run_all() を使用したときは、1クロックで1カウントしている。
しかし、ihc_hls_enqueue() と ihc_hls_component_run_all() を使用していない今回は、11クロックで 1 カウントだ。
（2017/11/12：修正 startの 1 へのアサートが1クロックだけなので、11クロックに1クロックしかカウントしないことになっていました。つまりテストベンチの問題のようです。ハードウェアには関係ないようです。@Venginner さん、ご指摘ありがとうございました） 次に、Quartus Prime でコンパイルしてみたところ、パイプライン実行の時と同じリソース使用量だった。何でだろうか？
次に、普通に for() 文で書いたらどうなるのだろうか？
counter3 フォルダも作って、もう一度、build.bat と counter.cpp をコピーした。
component 文を修正して、for() 文に変更した。
#include "HLS/hls.h" #include <stdio.h> using namespace ihc;const int SIZE = 100 ;int count(unsigned int &cnt) {for (int i=0 ; i<SIZE; i++)return (0 );int main() {unsigned int cnt=0 ;if (cnt == 100 ) {"PASSED\n" );else {"FAILED\n" );return 0 ;
build test-fpga を実行すると、vsim.wlf が生成されなかった。何度かビルドを繰り返すと生成されるときがあった。
test-fpga はPASSED になっている。
ModelSim で vsim.wlf を見ると、avmm_0_rw_... のポートがあって、Avalon MM の信号が入っている。つまり、cnt を参照呼出しにしたので、メモリにRead/Write するようになったのだろうか？でも cnt は 0 になっている。動作しないようだ。
Quartus Prime を立ち上げた。トップファイルを見ると、やはりAvalon MM の信号が入っている。
コンパイルしてみたが、やはり、リソース使用量が多い。
このソースコードはうまく行かないようだ。
2017年11月12日 04:55 |
intel HLS
| トラックバック:0
| コメント:0
”
intel HLS コンパイラを試してみる4（ModelSim） ”の続き。
intel HLS は
Intel High Level Synthesis Compiler User Guide によると component で宣言された関数がHDLになるように書いてあるが、それだけでもないようだ。
intel HLS のサンプルの counter.cpp はcomponent 文の中身は
return c++
だけだが、100カウントするHDL が生成されている。これは、component 文だけではなく、main() の一部も合成されているのではないだろうか？今のところその境界がどこにあるのかが謎である？
さて、この counter.cpp には、
ihc_hls_enqueue(&result[i], &count);
で、count() を読んだ結果の戻り値を result[i] に入れて、キューに積んで、
ihc_hls_component_run_all(count);
でキューの内容を実行するとパイプライン実行になるようだ。これは、
Intel High Level Synthesis Compiler User Guide の High-Throughput Simulation (Asynchronous Component Calls) Using Enqueue Function Calls に書いてある。
この結果は、”
intel HLS コンパイラを試してみる4（ModelSim） ”の最後のModelSim のWave ウインドウを見るとわかる。
この波形を見ると1クロックで1カウント進んでいるのが分かると思う。count() の動作がインプリメントして、リターンするということを考えると、パイプライン実行されているということが言えると思う。
それじゃ、これを使わない実装にするとどうなるのか？
もうできているが、時間切れなので、明日書くことにする。
2017年11月11日 07:45 |
intel HLS
| トラックバック:0
| コメント:0
”
intel HLS コンパイラを試してみる3（Quartus Prime） ”の続き。
前回はintel HLS が生成したQuartus のプロジェクトをコンパイルしてみた。今回は、ModelSim を立ち上げて、シミュレーションを観察してみよう。
Intel High Level Synthesis Compiler User Guide の Debugging during Verification によると intel HLS コンパイラ・オプションに -ghdl を追加すると、シミュレーターでの信号ログがイネーブルになるということだ。
早速、build.bat に -ghdl オプションを追加した。
これで、
build clean してから
build test-fpga した。
すると、F:\intelFPGA_lite\17.1\hls\examples\counter\test-fpga.prj\verification フォルダに vsim.wlf ができた。
ModelSim を立ち上げた。（ModelSim を使うのは久しぶりだ。。。）
File メニューから Open... を選択した。
Open File ダイアログが開いた。ファイルの種類を展開して、Log Files(*.wlf) を選択した。
F:\intelFPGA_lite\17.1\hls\examples\counter\test-fpga.prj\verification フォルダに vsim.wlf を選択して、開くボタンクリックした。
vsim.wlf が開いた。
Instance ウインドウで tb が選択されて、その信号がObjects に表示されている。Object のファイルをCTR-a キーで全選択して、右クリックし右クリックメニューから、Add Wave を選択した。
Wave ウインドウに波形が入った。
count_inst_returndata_data を右クリックしてRadix → Unsigned を選択した。これで 10 進数で表示できた。
tb の波形が表示できた。
Instance ウインドウの count_inst をクリックして、その Objects の波形をすべてWave ウインドウに追加した。 count_inst がカウンタ本体のはず。
Wave ウインドウの最後を拡大してみたところ、100 までカウントしているのが確認できた。C ソースコードと同じ動作だった。
2017年11月10日 04:40 |
intel HLS
| トラックバック:0
| コメント:2
”
intel HLS コンパイラを試してみる2（counterサンプルが動いた） ”の続き。
@Vengineer さんが
Intel HLS CompilerのexampleでのFPGAターゲットはArria10になっています。Lite Editionでは、Arria10は使えないので、CycloneVに変えましょう。
と言っていたので、build.bat を見ると、-march=Arria10 と書いてある。
これを -march=CycloneV に変更した。
そして、もう一度、
build test-fpga を実行した。
もう一度、
test-fpga も実行したが、PASSED だった。
F:\intelFPGA_lite\17.1\hls\examples\counter\test-fpga.prj\reports に行って、report.html を表示した。
右にcounter.cpp コードが書いてあって、左にリソース使用量が書いてある。
counter.cpp を見ると、100 まで数えるカウンタを実装するのかな？
C ソースコードはIP になるんじゃなくてプロジェクトのトップのHDL ファイルを生成するみたいだ。
F:\intelFPGA_lite\17.1\hls\examples\counter\test-fpga.prj\quartus にQuartus Prime のプロジェクトがある。
quartus_compile.qpf だ。Quartus Prime を立ち上げて、プロジェクトを見てみよう。
Quartus Prime を立ち上げて、File メニューから、Open Project ... を選択して、プロジェクトを開いた。
Start Compilation アイコンをクリックして、コンパイルした。
成功した。
デバイスは、5CEFA9F23I7 だった。これってファミリーをCyclone Vにしておけば、自動的に良さそうなのを選んでくれるのだろうか？
Logic utilization (in ALMs) が 46 個、Total registers が 79 個だった。
なんか、コンパイルが速い気がする。。。
トップのファイル quartus_compile.v の quartus_compile モジュールを観察した。
module quartus_compile (
count_start, count_busy, count_done, count_stall があるので、スタートとdone があって、カウントしているときは busy がずっと 1 になっているのではないか？と思う。
count_returndata が 32 ビットあって、これが、カウントする値だろうか？
2017年11月09日 04:53 |
intel HLS
| トラックバック:0
| コメント:0
”
intel HLS コンパイラを試してみる ”の続き。
前回はinit_hls.bat に失敗したので、今回はVisual Studio 2010 Professional をインストールしてからやってみた。
なお、 @cinimlさんに全面的に教えて頂いたので、この場でお礼を申し上げます。ありがとうございました。
@cinimlさんがトライアルのVisual Studio 2010 Professional ではなく、 Visual Studio 2010 Express で動かせるようにする手順を書いてくれました。”
Windows10 64bitでQuartus Prime (Lite) 17.1付属のIntel HLS Compilerを試す ”です。ありがとうございました。
まずは、
Visual Studio Community 2017 (version 15.4)のダウンロードページ から「以前のダウンロード エクスペリエンスに戻す」をクリックして、[Trial] Visual Studio 2010 Professional リリース日 2010/08/26 の日本語版をダウンロードした。これは、DVDイメージで約 2.5 GB あった。
ja_visual_studio_2010_professional_x86_dvd_517404.iso がダウンロードできたので、ダブルクリックするとPower2Go （たまたまインストールしてあったので）が起動してG: に仮想ドライブとしてマウントすることができた。
G: から setup.exe を起動してVisual Studio 2010 Professional をインストールできた。
@cinimlさんの
start_intelhls_vs2010pro.bat を使わせてもらって、intelFPGA_lite のフォルダを F: に変更した。
コマンドプロンプト上で、
start_intelhls_vs2010pro.bat を起動した。
もう１つコマンドプロンプトが開いた。こっちで、
cd exmaples\counter してから
build.bat を起動した。
見事に test-x86-64.exe ができた。やった。。。@cinimlさん本当にありがとうございました。
test-x86-64.exe を起動したら、PASSED と表示された。
どうやら、build.bat と起動するのと、
build test-x86-64 とオプションを付けて起動するは一緒の動作のようだ。
Getting Started Guide を見ると、test-fpga というオプションもあるようだ。
build test-fpga を実行した。
test-fpga.exe と test-fpga.prj ができた。
test-fpga .exe を実行すると PASSED と表示された。
tree test-fpga.prj /f > tree.txt でディレクトリ構造を tree.txt に保存した。
tree.txt を貼っておく。
F:\INTELFPGA_LITE\17.1\HLS\EXAMPLES\COUNTER\TEST-FPGA.PRJ
2017年11月08日 05:38 |
intel HLS
| トラックバック:0
| コメント:2
intel HLS コンパイラを試してみたくて、Windows 版 Quartus 17.1 をダウンロードしてインストールした。
INTEL® HLS COMPILER のページから
Getting Started Guide を開いて、やってみることにした。
PowerShell を開いて、F:\intelFPGA_lite\17.1\hls に cd した。
init_hls.bat を実行したところ、Visual Studio が必要だということが分かった。
Additional Software Requirements
Getting Started Guide から引用。
Visual Studio 2017, 2015 をインストールしてみたが、link.exe が無い。
Microsoft Visual Studio 2010 Professional をインストールするほかないかな？試してみるだけなので、試用ラインセンスでやってみようか？
2017年11月07日 06:15 |
intel HLS
| トラックバック:0
| コメント:0
今日はVivado HLS の小ネタをご紹介したい。
”
Vivado HLS でFIFO を作ってみた3（hiyuhさんに教えてもらった回路） ”でFIFO の C コードが書いてあるが、hiyuh さんに教えてもらったコードが興味深いので、試してみよう。
Vivado HLS 勉強会の乗算回路で、static const size_t を使用して PIPELINE指示子の II の値を指定する方法と、#define を使用してPIPELINE指示子（プラグマ指示子）を使用する方法だ。
参考にするのは、”
Vivado Design Suite ユーザー ガイド 高位合成 UG902 (v2017.3) 2017 年 10 月 04 日 ”の 54 ページの”#define と プラグマ指示子の使用”だ。
まずは、”#define と プラグマ指示子の使用”を参考に、プラグマを入れてみた。なお、multi_apuint() 関数の ap_uint 引数の幅は、static const size_t 宣言した値で記述することができた。
#include <stdio.h> #include <string.h> #include <ap_int.h> #define PRAGMA_SUB(x) _Pragma (#x) #define PRAGMA_HLS(x) PRAGMA_SUB(x) #define II_VAL_D 1 static const size_t INW = 8 ;static const size_t OUTW = INW * 2 ;void multi_apuint(ap_uint<INW > multi_in0, ap_uint<INW > multi_in1,OUTW > *multi_out){PRAGMA_HLS(HLS PIPELINE II=II_VAL_D) #pragma HLS INTERFACE s_axilite register port=multi_in1 bundle=AXI4LS #pragma HLS INTERFACE s_axilite register port=multi_in0 bundle=AXI4LS #pragma HLS INTERFACE s_axilite register port=multi_out bundle=AXI4LS #pragma HLS INTERFACE s_axilite port=return bundle=AXI4LS
これで C コードの合成を行った。結果を示す。
Interval は 1 になっていて、PIPELINE指示子が効いている。
次に、PIPELINE指示子の II の値を static const size_t で与えた。
#include <stdio.h> #include <string.h> #include <ap_int.h> static const size_t INW = 8 ;static const size_t OUTW = INW * 2 ;static const size_t II_VAL = 2 ;void multi_apuint(ap_uint<INW> multi_in0, ap_uint<INW> multi_in1,#pragma HLS PIPELINE II=II_VAL #pragma HLS INTERFACE s_axilite register port=multi_in1 bundle=AXI4LS #pragma HLS INTERFACE s_axilite register port=multi_in0 bundle=AXI4LS #pragma HLS INTERFACE s_axilite register port=multi_out bundle=AXI4LS #pragma HLS INTERFACE s_axilite port=return bundle=AXI4LS
こちらは、#pragma を使用して、Vivado HLS のコードそのものだが、PIPELINE 指示子のとことでワーニングが出てしまっている。
このワーニングを気にしなければ、C コードの合成結果は満足できる。
Interval が 2 になっていて、PIPELINE指示子が効いているのわかる。
2017年11月06日 05:09 |
Vivado HLS
| トラックバック:0
| コメント:0
”
Vivado HLS 2017.3.1 における識別子の違いによる任意精度固定小数点データ型の動作の違い1 ”の続き。
前回は、任意精度固定小数点データ型を使用した時に、量子化モードやオーバーフロー・モードの違いによるCシミュレーションの演算結果の違いについて検討した。今回は、任意精度固定小数点データ型を使用した時に量子化モードやオーバーフロー・モードの違いによる C コードの合成結果の違いについて検討する。なお使用するVivado HLS はUbuntu 16.04 上のVivado HLS 2017.3.1 を使用した。
まずは、
typedef ap_fixed<4, 3, AP_TRN_ZERO, AP_SAT> ap_fixed_def;
の時にC コードを合成してみよう。
結果を示す。
Latency は 1 クロックで、Interval は 2 クロックとなった。
FF は 11 個、LUT は 220 個使用されている。
Analysis 結果を示す。
次に、
typedef ap_fixed<4, 3, AP_TRN_ZERO, AP_WRAP> ap_fixed_def;
の時にC コードを合成してみよう。
結果を示す。
Latency は 0 クロックで、Interval は 1 クロックとなった。組み合わせ回路だ。
リソース使用量もFF が 0 になって、LUT は 33 個だった。やはり、ap_fixed<4, 3, AP_TRN_ZERO, AP_SAT>の時の方がリソース使用量が多い。
Analysis 画面を示す。
ap_fixed<4, 3, AP_RND, AP_SAT>
を使用した演算を合成した。結果を示す。
ap_fixed<4, 3, AP_TRN_ZERO, AP_SAT>と比較して、FF は変化ないが、LUT は 220 個から 212 個に減っている。
ap_fixed<4, 3, AP_TRN, AP_SAT>
を使用した演算を合成した。結果を示す。
なんと、Latency は 0 クロックで、Interval は 1 クロックとなった。飽和演算がついていても組み合わせ回路となった。
リソース使用量は、FF が 0 になった。LUT も 116 個と減少した。
最後に、最小のLUT を求めて、
ap_fixed<4, 3, AP_TRN, AP_WRAP>
でやってみた。
リソース使用量が LUT が 13 個になった。
このように、量子化モードやオーバーフロー・モードによって、リソース使用量が変化するのがわかった。
2017年11月04日 05:12 |
Vivado HLS
| トラックバック:0
| コメント:0
Zynq＋Vivado HLS 勉強会で使用する予定のVivado HLS 2017.3 における識別子の違いによる任意精度固定小数点データ型の動作の違いをブログに書いて置く。
任意精度固定小数点データ型とは、任意のビット長の固定小数点のデータ型のことだ。整数＋小数のビット幅と整数のビット幅を選ぶことができる。更に量子化モードとオーバーフローモードを選ぶことができる。つまり、自動的に飽和演算してくれるわけだ。とっても便利な任意精度固定小数点データ型を調査していこう。
なお、任意精度固定小数点データ型については、”
Vivado Design Suite ユーザー ガイド 高位合成 UG902 UG902 (v2017.3) 2017 年 10 月 04 日 ”の189ページからの”任意精度固定小数点デー タ型”を参照のこと。
まずは、ap_fixed_test.h から貼っておく。
// ap_fixed_test.h
ap_fixed_test.cpp を貼っておく。
// ap_fixed_test.cpp"ap_fixed_test.h"
ap_fixed_def &out){ out = in0 * in1; return(0);
ap_fixed_test_tb.cpp を貼っておく。
// ap_fixed_test_tb.cpp"ap_fixed_test.h"
ap_fixed_def &out); ap_fixed_def out; ap_fixed_test(1.5, 1.5, out); printf("1.5 x 1.5 = %f\n" , (float)out); ap_fixed_test(-1.5, 1.5, out); printf("-1.5 x 1.5 = %f\n" , (float)out); ap_fixed_test(2, 2, out); printf("2 x 2 = %f\n" , (float)out); ap_fixed_test(-2, 2, out); printf("-2 x 2 = %f\n" , (float)out); ap_fixed_test(3, 3, out); printf("3 x 3 = %f\n" , (float)out); ap_fixed_test(-3, 3, out); printf("-3 x 3 = %f\n" , (float)out); return(0);
ap_fixed_test プロジェクトを示す。
C シミュレーションを行った。結果を示す。
ここで使用している任意精度固定小数点データ型は全ビット数が4ビット、整数部3ビット、小数部1ビットだ。つまり、2の補数表示をすると、-4 〜 +3.5 までの 0.5 刻みの小数ということになる。
今回の量子化モードは AP_TRN_ZERO ： 0 への切 り捨て (デフォル ト )
オーバーフロー・モードは AP_SAT ： 飽和
1.5 x 1.5 = 2.000000
1.5 x 1.5 = 2.25 だが、0.5 刻みなので、0 へ切り捨てされて 2.0 になった。
-1.5 x 1.5 = -2.25 だが、やはり 0 方向に切り捨てるので、切り上がって -2.0 になった。
2 x 2 = 3.5 は整数部が負の値を含めて3ビットなので、実質2ビットで整数の絶対値を表すため、+3.5 〜 -4.0 なので、3.5が正の値の最大値であるため飽和演算されている。
-2 x 2 = -4.000000 は正しい。
3 x 3 = 3.500000 は正の値の飽和演算のテスト、正の最大値。
-3 x 3 = -4.000000 は負の値の飽和演算のテスト、負の最大値。
次にオーバーフローモードを AP_WRAP ： 折り返し (デフォル ト )にする。
typedef ap_fixed<4, 3, AP_TRN_ZERO, AP_WRAP> ap_fixed_def;
結果を示す。
1.5 x 1.5 = 2.000000
飽和演算が無くなったので、飽和演算をしていた下の演算の値が桁上げが無いためおかしくなっている。
2 x 2 = -4.000000
3 x 3 = 1.000000
-3 x 3 = -1.000000
AP_WRAP は演算してもオーバーフローしない時の演算に使用すると良い。飽和演算をするよりも使用リソースが少なくなる。
オーバーフロー・モードを AP_SAT に戻して、
量子化モードを AP_RND ： 正の無限大への丸め にしてみよう。
typedef ap_fixed<4, 3, AP_RND, AP_SAT> ap_fixed_def;
結果を示す。
1.5 x 1.5 = 2.500000
今回は、1.5 x 1.5 = 2.500000 が変わっている。正の無限大への丸めなので、2.25 が 2.5 に丸められている。
量子化モードを AP_TRN ： 負の無限大への切り捨て にしてみよう。
typedef ap_fixed<4, 3, AP_TRN, AP_SAT> ap_fixed_def;
結果を示す。
1.5 x 1.5 = 2.000000
今度は、-1.5 x 1.5 = -2.500000 となって、負の無限大への切り捨て となっているのがわかる。
このように量子化モードやオーバーフローモードで結果が変わってくる。
C コードを合成してもリソース使用量が変わるので次回やってみよう。
2017年11月03日 06:29 |
Vivado HLS
| トラックバック:0
| コメント:0
FPGAボードを持っていないreVISION をやっていても面白くないので、ZYBOのxfOpenCV をやってみることにした。
参考にするのは、”
ザイリンクス OpenCV ユーザーガイド UG1233 (v2017.2) 2017 年 9 月 22 日 ”の 10 ページの”カスタム プラットフォームでの xfOpenCV ライブラリの使用”だ。
ユーザーズ・ガイドの通りにやってみる。
SDx を立ち上げて、WorkSpace を設定した。
SDx のFile メニューからNew −＞ Xilinx SDx Project を選択した。
New Project ダイアログが表示された。Project name に accumulate_xfOCV と入力した。
Choose Hardware Platform で、 zybo を選択した。
Choose Software Platform and Target CPU はそのままとした。
Templates では、Empty Application を選択した。Finish ボタンをクリックした。
accumulate_xfOCV プロジェクトが開かれました。
Active build configuration をRelease に変更した。
Project Explorer で accumulate_xfOCV を右クリックして、右クリックメニューから C/C++ Build Settings を選択する。
Properties for accumulate_xfOCV ダイアログが開いた。
SDS++ Compiler のDirectories をクリックした。
xfopencv/include を include Paths に入れたが＜OpenCV_location＞\include フォルダーがどこを指すのかがわからない？
”
How to link OpenCV library with SDSoC ”によると /opt/Xilinx/SDK/2016.4/data/embeddedsw/ThirdParty/ ということだったので、”/opt/Xilinx/SDK/2017.2/data/embeddedsw/ThirdParty/opencv/aarch32/include”を追加した。
Apply をクリックした。
SDS++ Linker のLibraries をクリックした。
Libraries(-l) にライブラリを追加した。
Libraries search path (-L) に”/opt/Xilinx/SDK/2017.2/data/embeddedsw/ThirdParty/opencv/aarch32/lib”を追加した。
Apply をクリックして、OK ボタンをクリックしてダイアロを閉じた。
accumulate_xfOCV プロジェクトを展開して、src フォルダを右クリックし、右クリックメニューから Import を選択する。
File System を選択した。
Browse... ボタンをクリックした。
xfopencv/accumulate を選択して、OKボタンをクリックした。
.h と .cpp フォイルにチェックを付けて、Finish ボタンをクリックした。
これでプロジェクトが完成した。トンカチ・アイコンをクリックしてビルド開始。
エラー発生。
エラー内容を示す。
/opt/Xilinx/SDx/2017.2/SDK/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabihf/6.2.1/../../../../arm-linux-gnueabihf/bin/ld: -llzma が見つかりません
ライブラリが無いと言われている。lzma などのライブラリがどこにあるか探ってみたところ、”/home/masaaki/zcu102_rv_ss/sw/sysroot/usr/lib”にあるようだった。
Project Explorer で accumulate_xfOCV を右クリックして、右クリックメニューから C/C++ Build Settings を選択する。
Properties for accumulate_xfOCV ダイアログが開いた。
SDS++ Linker のLibraries をクリックした。
Libraries search path (-L) に”/home/masaaki/zcu102_rv_ss/sw/sysroot/usr/lib”を追加した。
これでトンカチ・アイコンをクリックして、もう一度ビルドした。
やはりエラー発生。
エラー内容を示す。
ERROR: [SdsCompiler 83-5019] Exiting sds++ : Error when calling 'arm-linux-gnueabihf-g++ /home/masaaki/workspace/accumulate_xfOCV/Release/src/xf_accumulate_image_accel.o /home/masaaki/workspace/accumulate_xfOCV/Release/src/xf_accumulate_image_tb.o /home/masaaki/workspace/accumulate_xfOCV/Release/_sds/swstubs/portinfo.o -L/opt/Xilinx/SDK/2017.2/data/embeddedsw/ThirdParty/opencv/aarch32/lib -L/home/masaaki/zcu102_rv_ss/sw/sysroot/usr/lib -lopencv_core -lopencv_imgproc -lopencv_imgcodecs -lopencv_features2d -lopencv_calib3d -lopencv_flann -llzma -ltiff -lpng16 -lz -ljpeg -ldl -lrt -lwebp -L /opt/Xilinx/SDx/2017.2/target/aarch32-linux/lib -L/home/masaaki/workspace/accumulate_xfOCV/Release/_sds/swstubs -Wl,--start-group -Wl,--end-group -Wl,--start-group -lpthread -lsds_lib -lxlnk_stub -Wl,--end-group -o /home/masaaki/workspace/accumulate_xfOCV/Release/_sds/swstubs/accumulate_xfOCV.elf'
2017年11月01日 05:34 |
reVISION, xfOpenCV
| トラックバック:0
| コメント:0
