Vivado HLSのCoSim がNorton Endpointの検疫に引っかかってしまった。
Vivado HLS のバージョンは2017.1 だが、2016.4 も同様に引っかかっている。
あるVivado HLS のプロジェクトを作成した。
C-Simulation を行ったら通った。
けれどもC コードの合成を行って、CoSim を行ったらエラー発生。
同時にNorton Endpoint の検疫に引っかかっていた。
詳しいダイアログを表示した。
CoSim 時に自動生成されたcosim.pc.exe が検疫されているではないか。。。
このファイルはCoSim 時に自動生成されているので、これがウィルスということはないと思うのだが。。。怪しい動きをしていたのだろうか？
ちなみに検出結果は”
SONAR.SuspScript!g3 ”ということだった。
Norton Endpoint を立ち上げて、「設定の変更」ボタンをクリックし、
「ウイルス対策とスパイウェアの設定」ダイアログの「グローバル設定（G)」タブで「例外：」の「リスト表示（L)」ボタンをクリックし、
「例外」ダイアログの「追加（A)...」ボタンをクリックして、「SONAR例外」→「フォルダ」を選択して、Vivado HLS のプロジェクトのあるフォルダを指定したところ、CoSim が通った。
2017年05月31日 15:00 |
Vivado HLS
| トラックバック:0
| コメント:0
ニューラルネットワークの推論のハードウェア化をやってみようと思う。
以前、ニューラルネットワークのハードウェア化をやっていたが、それは、2層のニューラルネットワークをその形のままFPGAにハードウェア化していた。ニューラルネットワークを画像フィルタとして使用していたが、パイプライン化されたニューラルネットワークから 1 クロックごとに出力することができていた。そして、積和演算をDSPで行ったのでは、DSPが足りなかった。そこで、ニューラルネットワークの形のまま実装するということは、重みは固定で良いので、乗算をシフト+加算の形に変換した。そして、シフト+加算の形でVHDLを書くのはとっても大変なので、重みの表からシフト+加算の形のVHDL を出力するRuby スクリプトを作成した。これによって、FPGAの使用リソースを削減することができた。また、DSPは使わずにロジックだけで実装することができた。
この方式の欠点は、演算器が片方の定数入力に対して最適化されていて重みが変更できないことだ。ディープなニューラルネットワークで、FPGAに入らない場合はどうするか？ということになる。この場合はFPGAのコンフィギャラブルという最大の利点を生かすソリューションを使うと良い。つまりパーシャルリコンフィギュレーションを使うのだ。パーシャルリコンフィギュレーションを使用すると、層単位または複数層でも良いが、適当な区切りで回路を入れ替えて実行することができる。
例えば、10層のニューラルネットワークだったら、2層ごとにパーシャルリコンフィギュレーションで回路を入れ替えながら、5回やれば良い。各層の重みは定数で良いので、DSPを使用する必要もなく、回路も削減できる。パーシャルリコンフィギュレーションを使えるのはFPGAだけの特権だと思う。ただし、パーシャルリコンフィギュレーションの速度が問題になると思うが、これから検証していこうと思う。
これから、オライリーの本「
ゼロから作る Deep Learning 」の「
5章 誤差逆伝播法 」のPython コードを元に、量子化をソフトウェアで行って、結果を確認しながらニューラルネットワークのハードウェア化を行っていきたいと思う。なお、「
ゼロから作る Deep Learning 」のPython コードはオライリー・ジャパンの
oreilly-japan/deep-learning-from-scratch にあって、MITライセンスなので改変したものを公表することができる。
重みやバイアスの統計データを「
「ゼロから作る Deep Learning」をやってみる4（4章 ニューラルネットワークの学習） 」の「W1, W2, b1, b2の統計データ」に書いておいたが、適当な値に分布しているので、使いやすそうだった。
2017年05月31日 04:38 |
DNN
| トラックバック:0
| コメント:0
Vivado HLS の符号付 C++の任意精度固定小数点型について疑問があったので調べてみた。
Vivado HLS の C++の任意精度固定小数点型は、C++のテンプレートを使用して、ap_[u]fixed
で宣言される。（Xilinx社のUser Guide 高位合成 UG902 (v2016.4) 2016年11月30日 192 ページ「C++ の任意精度固定小数点型」参照）W ：ワード長（ビット数）
#include <stdio.h> #include <ap_fixed.h> int main(){9 , 1 , AP_TRN_ZERO, AP_SAT> a;float f;0.5 ;"0.5: %f\n" , f);1.0 ;"1.0: %f\n" , f);1.0 ;"-1.0: %f\n" , f);0.5 ;"-0.5: %f\n" , f);2.0 ;"2.0: %f\n" , f);1.5 ;"-1.5: %f\n" , f);0.9 ;"-0.9: %f\n" , f);
0.5: 0.500000
2017年05月29日 15:05 |
Vivado HLS
| トラックバック:0
| コメント:0
”
BNN-PYNQ のトレーニングを試してみる1 ”の続き。
前回は、Theano やpylearn2 をインストールして、mnist のトレーニングを行った。33時間20分かかってトレーニングが終了した。
今回は、その結果を見ていこう。
~/BNN-PYNQ/bnn/src/training ディレクトリに mnist_parameters.npz ができていた。
トレーニングされたmnist の重みをバイナリにしてみよう。
python mnist-gen-binary-weights.py を実行した。
表示出力の全文を示す。
masaaki@masaaki-VirtualBox2:~/BNN-PYNQ/bnn/src/training$ python mnist-gen-binary-weights.py
すると、binparam-lfc-pynq ディレクトリができていた。
binparam-lfc-pynq ディレクトリの中身を示す。
これはちょうど ~/BNN-PYNQ/bnn/params/mnist ディレクトリと同じだ。
CIFAR-10 ConvNet は、どれだけ時間がかかるか恐ろしい。今、GPU のGTX106０を購入したので、Ubuntu とWindowsのデュアルブートにして、Ubuntu でどのくらいトレーニングに時間がかかるか？調べてみたいと思う。
2017年05月29日 04:47 |
DNN
| トラックバック:0
| コメント:0
BNN-PYNQ は
以前もやった のだが、今回はトレーニングを試してみることにした。
BNN-PYNQ/bnn/src/training/ を参考にしてやってみることにした。
ただし、GPU は持っていないので、CPU のみでやってみる。
早速、やってみよう。
とりあえず、
Installing the Training Environment: からやってみた。
VirtualBox 上のUbuntu 16.04 でやっているので、Install Nvidia Drivers, CUDA and cuDNN はやらなかった。
Install Python Packages から行った。
まずは、必要なツールをインストールした。
sudo apt-get install git python-dev libopenblas-dev liblapack-dev gfortran -y pip は既にインストールしていあるので省略
Theano をインストール。
pip install --user git+https://github.com/Theano/Theano.git@rel-0.9.0beta1 Lasagne をインストール。
pip install --user https://github.com/Lasagne/Lasagne/archive/master.zip ./theanorc を作成した。GPUの代わりにCPUを使用するように変更した。
echo "[global]" >> ~/.theanorc .theanorc ができた。
pylearn2 のインストール。
pip install --user numpy==1.11.0 # Pylearn2 seems to not work with the latest version of numpy
git clone https://github.com/lisa-lab/pylearn2 cd .. Download Datasets を実行した。
export PYLEARN2_DATA_PATH=~/.pylearn2 mnist と cifar10 をダウンロード。
python download_mnist.py ”export PYLEARN2_DATA_PATH=~/.pylearn2”を.bashrc に追加。
BNN-PYNQ が古くなっていたので、消去して、git clone しなおした。
BNN-PYNQ/bnn/src/training/ ディレクトリに移動した。
cd BNN-PYNQ/bnn/src/training/ mnist のトレーニングをスタートした。
python mnist.py スタートしたのが、2017/05/27 5時10分頃だ。
現在、8時13分だが Epoch 92 だ。
1 つのEpoch を実行するのに、約 125 秒かかっているので、1000 Epoch では、34時間43分くらいかかることになる。
ネイティブのUbuntu とGPU がとっても欲しくなった。。。
（追記）
次の日の14時30分頃、Epoch 1000 が終了しました。約33時間20分かかりました。
best epoch: は 824 でした。それを示します。
2017年05月27日 08:18 |
DNN
| トラックバック:0
| コメント:0
”
DnnWeaverをやってみる5（Windows 10 のVivado 2016.2でやってみた1） ”の続き。
前回は、ZYNQ7 Processing System を含むブロックデザインをPYNQボード用に変更した。今回は、ビットファイルを生成して、SDKでPYNQボードにビットファイルを書き込んで、アプリケーションソフトをコンパイルして試してみたい。
Generate Bitstream をクリックして、ビットファイルの生成を行う。
論理合成、インプリメント、ビットファイルの生成を行った。Project Summary を示す。
critical warning が 1 個ある。これを表示してみよう。
ROM.v で読んでいる norm_lut.vh が無いという critical warning だった。
norm_lut.vh は、dnnweaver.public/fpga/hardware/include にあった。
norm_lut.vh を持ってきて、Vivado のプロジェクトに追加した。
論理合成、インプリメント、ビットファイルの生成を行ったところ、critical warning は無くなった。
ビットファイル付きで、ハードウェアをエクスポートして、SDK を立ち上げた。
standalone アプリケーション・プロジェクトを作成した。
dnnweaver.public/fpga/aram_software/src から platform.c と standalone.c を standalone アプリケーション・プロジェクトの src フォルダにコピーした。
同様に、dnnweaver.public/fpga/aram_software/lib から platform.h と platform_config.h を standalone アプリケーション・プロジェクトの src フォルダにコピーした。
standalone.elf ができた。
PYNQボードの電源を入れて、JTAG モードにし、SDK でビットファイルをダウンロードした。（Xilinx Tools メニューからProgram FPGA を選択）
standalone.elf をデバックモードで起動して、ステップオーバーでアプリケーションソフトを実行していった。
wr_address にアドレスを読み込むところで 0xdeadbeef が読み込まれている。
そのため、次にステップオーバーすると、DataAbortHandler に飛んでしまう。
と言う訳で、PYNQボード用のDnnWeaver を動作させることができなかった。
2017年05月25日 05:05 |
DNN
| トラックバック:0
| コメント:0
”
DnnWeaverをやってみる4（「PYNQ祭り」延長戦の成果 ）”の続き。
今まで、DnnWeaver のVivado 2016.2 のGUI では、トップレベルにいろいろなソースコードが入っていたので、これをスクリプトでまとめてビットファイルを生成していたのかと思っていた。しかしよく見てみると、zynq_wrapper.v の下に階層構造ができている。
これで、ビットファイルを作ればOKじゃないか？ということで、Vivado 2016.2 単体でやってみた。
Windows 10 でやってみたいということで、Ubuntu から移行することにした。
Ubuntu 16.04 上で、File メニューからArchive Project ... を選択する。
Archive Project ダイアログが表示された。今回のコンパイル結果は、ZC702 のものなので、include run results のチェックを外してOK ボタンをクリックする。
すると、dnnwever.xpr.zip が生成された。
USB メモリ経由でWindows 10 に持ってきて見ているが、dnnwever.xpr.zip の中には、dnnweaver フォルダがある。
dnnweaver フォルダを dnnweaver_162 として、PYNQ フォルダにコピーした。
Windows 10 上のVivado 2016.2 で開いてみた。
トップの zynq_wrapper.v を開いてみると、DDR とFIXED_IO だけの配線で、これだと配線位置が決まっているので、制約ファイルも要らない。
さて、ZC702 からPYNQ ボード用に変更しよう。Project part のZYNQ-7 ZC702 Evaluation Board (xc7z020clg484-1) をクリックする。
Project device: の… ボタンをクリックして、FPGAを変更しよう。
Select Device ダイアログで、Select: を Parts にして、下の図のようにFilter を選択し、xc7z020clg400-1 を選択した。
Project Settings のProject device にxc7z020clg400-1 が入った。
Project Summary を見ても、Project part にxc7z020clg400-1 が入っているのが分かる。
これで、ブロックデザインのzc702.bd を開くと、FPGA パーツを変更したので、IP をアップグレードする必要がある。Upgrade Selected ボタンをクリックして、IP をアップグレードする。
IP をアップグレードしても、ZYNQ7 Processing System はZC702 用のままなので、いったん削除する。
削除した状態を示す。
新しくZYNQ7 Processing System をAdd IP した。
ZYNQ7 Processing System をダブルクリックして、設定画面を開く。
Presets をクリックして、Apply Configuration を選択する。
Digilent 社のPYNQ サイト のZynq Presets をダウンロードして解凍した pynq_revC.tcl を選択する。
すると、PYNQ の設定がZynq Block Design に反映されているのが分かる。
ついでに設定を行う。
PS-PL Configuration で、M AXI GP0 interface と S AXI HP0 interface にチェックを入れた。
Clock Configuration で PL Fabric Clocks の FCLK_CLK0 を 150 MHz に設定した。
配線をやり直して、ブロックデザインが完成した。
次に、Address Editor で、M_AXI_GP0 を右クリックして、Assign Address を選択して、アドレスをマップした。
S_AXI_HP0 も同様にアドレスをマップした。
アドレス・マップ後。
これで、zc702.bd （PYNQボード用に変更はしたが名前はそのまま）は、PYNQボード用になった。
2017年05月24日 04:54 |
DNN
| トラックバック:0
| コメント:0
”
DnnWeaverをやってみる3 ”の続き。
”
「PYNQ祭り」延長戦 : FPGAディープラーニング実践懇親会 ”では、DnnWeaver のARTY-Z7-20 への実装をやってみるというお題でやってみた。6 時間という時間の制限があったので、五里霧中だったときは苦しかったが、徐々に気が楽になり、気分が乗ってきた。それでも家でリラックスしてやっているときより気が付かない。やはり、私はハッカソンよりも家で家事をやりながら、やったほうがひらめくようだ。しかし、いろいろな方とお知り合いになれて、いろいろなお話ができたし、実りは多かったと思う。そうそれに、研究室の卒業生が来ていて、同じ班で、以前と同じように協力して課題に取り組めたのは良かった。昔を思い出した。彼がソフトウェアで、私がハードウェア担当でいろいろと実験コードを書いてもらいながら、協力してバグフィックスしていたのを思い出した。
そうそう、彼が、私のノートパソコンがarm-xilinx-eabi-gcc が動作しなかったので、直してくれた。64 ビットLinux から 32 ビットのアプリケーションが動作しない問題だと言っていたので、”
64bit-Linuxで32bitバイナリ実行環境を構築 ”の辺りの解決策を試してくれたのだと思う。
さて、PYNQ祭り延長戦で分かったDnnWeaver の構成とその後、私が解明した事実を書いておく。
まずは、~/dnnweaver.public/fpga ディレクトリにある Makefile について。
Makefile オプションについて書いておく。
test : iverilog でシミュレーションを行う。
ELF : ソフトウェアのコンパイルを行う。
launch : XMD でZynq に standalone.elf をダウンロードし、起動する。
つまり、DnnWeaver を動かすときは、make launch を実行すると動作させられるはずだったが、どこが悪かったのか？PYNQ祭り延長戦では、Arty-Z7-20 で動作しなかった。
Vivado での処理は、tcl/vivado_2016_2.tcl を呼び出して処理を行っている。
vivado_2016_2.tcl PYNQ祭り延長戦では、DnnWeaver はXilinx 社のZC702 ボード用なので、Arty-Z7-20 に移行することを考えてみた。
vivado_2016_2.tcl の最初の部分で、FPGAの型番とボード・ファイルを指定している。Arty-Z7-20 に移行するには、ここを書き換える必要がある。
更に、ここを書き換えただけではだめで、その下で、
source tcl/zynq_1AXIHP0_1AXIGP0.tcl
でzynq_1AXIHP0_1AXIGP0.tcl を実行している。
これは、
ブロックデザインを開いて、File メニューから Export -> Export Block Design... を選択した ときに、出力される tcl ファイルそのものなので、ここで、Zynq のProcessing System がそのまま入ってしまう。よって、ここも書き換える必要があった。
DnnWeaver の tcl/vivado_2016_2.tcl を引用する。
上の vivado_2016_2.tcl から下へ書き換えた。
まずは、FPGA はZC702 の484 ピンから 400 ピンに書き換える必要がある。
次に、
Arty-Z7-20 のボード・ファイルをDigilent から持ってきて、Vivado 2016.2 にインストール した。それで、ボード・ファイルの行を書き換えている。ポイントは xilinx.com から digilentinc.com に書き換えて、バージョン番号を 1.0 にすることだった。
次に、zynq_1AXIHP0_1AXIGP0.tcl の代わりに、Arty-Z7-20 用の zc702.tcl を作ったので、それを実行するように書き換えた。zc702.tcl の出力方法については後述する。
DnnWeaver の tcl/vivado_2016_2.tcl を引用してArty-Z7-20 用に書き換えた。
zc702.bd zc702.bd を Arty-Z7-20 用に変更する。すでにDigilent 社のボード・ファイルをVivado 2016.2 に入れてあるものする。
Vivado 2016.2 を起動して、~/dnnweaver.public/fpga/vivado/dnnweaver.xpr を読み込ませる。
Vivado のGUI 画面を示す。ZC702 用に設定されている。
Preject part の ZYNQ-7 ZC702 をクリックして、Arty-Z7-20 に変更しよう。
クリックすると、Project Settings ダイアログが表示される。右の・・・ボタンをクリックして、Arty-Z7-20 に変更した。これでOK ボタンをクリックする。
これでボード・ファイルをArty-Z7-20 に変更できた。IP のアップグレードを求められるので、行う。
それでもZynq のProcessing System は更新されていない。更新するためには、いったん削除して、もう一度、Add IP する必要がある。
Arty-Z7-20 用のZynq のProcessing System を追加したら、S_AXI_HP0 interface のチェックボックスにチェックを入れる。
次に、PL Fabric Clocks の FCLK_CLK0 にチェックを入れる。
これでブロックデザインが完成した。
次に、このブロックデザインを生成するためのTCL スクリプトを生成しよう。
File メニューから Export -> Export Block Design... を選択すると、Export Block Design ダイアログが表示される。この際に、ブロックデザイン名の TCL スクリプトが生成される。名前が気に入らなければ、名前を変更する。
このように、Arty-Z7-20 用に変更されたブロックデザイン生成用 tcl ファイルを得ることができた。
tcl/vivado_2016_2.tcl はすでに zc702.tcl が動作するように書き換えてある。
これで、もう一度、make を行うと Arty-Z7-20 用に変更されてビルドを行うことができた。
PYNQ祭り延長戦では、VirtualBox 上のUbuntu 16.04 から make launch を行って、接続されたArty-Z7-20 を動作させようとしたが、うまく動作しなかった。
そこで、/fpga/synthesis-output ディレクトリをUSB メモリにコピーして、Windows 10 のVivado SDK でプロジェクトを作成した。
.hdf ファイルを読み込むと SDK のハードウェア・プラットフォームが生成できる。詳しくは、
FPGAプログラミング大全 Xilinx編 の巻末の説明を参照のこと。
SDK のプラットフォームに standalone プロジェクトを作成して、~/dnnweaver.public/fpga/arm_software/src/standalone.c, platform.c と ~/dnnweaver.public/fpga/arm_software/lib の platform.h, platform_config.h などをコピー & ペーストをしてアプリケーション・プロジェクトを作成した。それをデバックモードで動作させたが、どこかのレジスタが 0xdeadbeef で動作しなかった。残念。
SDK は他の人に任せたので、詳しい説明になっていない。
次は、Vivado のGUI でインプリメントできたので、それをブログに書いておこうと思う。
2017年05月22日 05:28 |
DNN
| トラックバック:0
| コメント:0
”
DnnWeaverをやってみる2 ”の続き。
前回は、エラーで終了してしまったので、今回はそのエラーの解消を図る。
実は、コメント欄で解決方法を教えてもらったのだ。管理人のみ閲覧できますコメントだったのでお名前は書かないがありがとうございます。
教えてもらったことをやってみよう。それは、ディレクトリを作ろうということだった。
~/dnnweaver.public/fpga/arm_software ディレクトリの下に、obj ディレクトリを作って、その下に、standalone 、linux ディレクトリを作る。
cd ~/dnnweaver.public/fpga/arm_software 次に、~/dnnweaver.public/fpga ディレクトリに戻って、make を行った。
cd ~/dnnweaver.public/fpga 成功した。
synthesis-output ディレクトリを見てみよう。
zynq_wrapper.bit、 zynq_wapper.hdf、 standalone.elf、 linux.elf がある。
vivado ディレクトリに行ってみた。dnnweaver.xpr がある。
vivado 2016.2 を起動してdnnweaver.xpr を開いてみたが、トップのファイルがないな。。。GUIはこのままでは使えないね。
今日は、
「PYNQ祭り」延長戦 : FPGAディープラーニング実践懇親会 に行くのでこれまでとします。
2017年05月20日 04:39 |
DNN
| トラックバック:0
| コメント:0
”
DnnWeaverをやってみる1 ”の続き。
Vengineer さんにDnnWeaver は、TensorFlow をインストールすると make できるというのを教えて頂いたので、VirtualBox 上のUbuntu 16.04 にTensorFlow をインストールすることができた。
今回は、~/dnnweaver.public/fpga ディレクトリで make してみよう。
Vivado 2016.2 は2016.2 と2016.3 の間に壁があるので、インストールすることにして、インストールを行った。
~/dnnweaver.public/fpga ディレクトリに cd して、
make を行った。
途中省略
「Fatal error: can't create arm_software/obj/standalone/standalone.o: そのようなファイルやディレクトリはありません」というエラーが出て止まってしまった。
make 後の全表示を貼っておく。
(tensorflow) masaaki@masaaki-VirtualBox2:~/dnnweaver.public/fpga$ make
~/dnnweaver.public/fpga ディレクトリは、Vivado のログを除くと、synthesis-output, vivado ディレクトリが新規作成されて、fsm_encoding.os, get-pip.py が増えている。
2017年05月19日 05:19 |
DNN
| トラックバック:0
| コメント:1
Vengineer さんにDnnWeaver は、TensorFlow をインストールすると make できるというのを教えて頂いたので、VirtualBox 上のUbuntu 16.04 にTensorFlow をインストールすることにした。
”
Installing TensorFlow on Ubuntu ”を参考にした。
まずは、
sudo apt-get update python-pip python-dev python-virtualenv をインストール。
sudo apt-get install python-pip python-dev python-virtualenv Python のバージョンを確認すると、2.7.12 だった。
python -V tensorflow ディレクトリを作成して、virtualenv 環境を生成し、virtualenv 環境をアクティベートした。
mkdir tensorflow Python のバージョンに合ったTensorFlow Python package を
このWeb ページ から選んで、pip でインストールする。
pip install --upgrade https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-1.1.0-cp27-none-linux_x86_64.whl このWeb ページ から「動作確認」のPython コードを引用した。
正常にインストールできたようだ。
2017年05月19日 04:51 |
DNN
| トラックバック:0
| コメント:0
DnnWeaver をやってみようと思う。
DnnWeaver は、「FPGA上でディープニューラルネットワーク（DNN）を加速するための最初のオープンソースのフレームワーク」（Google 翻訳使用）だそうだ。
DnnWeaver のダウンロードページ を見ると、git で clone するようなので、Windows 10 上のVirtualBox でインストールしたUbuntu 16.04 を使用することにした。
まずは、Ubuntu 16.04 のホームで git clone を行った。
git clone https://bitbucket.org/hsharma35/dnnweaver.public.git すると、dnnweaver.public ディレクトリができた。
DnnWeaver のダウンロードページ では、python 2.7 と Vivado 2016.2 が必須だが、Python 2.7.12 がインストールされているし、Vivado も 2016.4 だが、インストールされているので、これでやってみることにする。
DnnWeaver のダウンロードページ では、fpga ディレクトリに行って、「make PROTOTXT=your_prototxt_here」するようにとのことだった。
dnnweaver.public/fpga に行ってみるとMakefile があった。
しかし、Makefile を見ると、すでに PROTOTXT が定義されているようなので、make だけでやってみることにする。
make すると、google.protobuf.internal の enum_type_wrapper が無いと言われてしまった。
caffe_pb2.py を見ると、、google.protobuf.internal や、google.protobuf からのインポートがたくさんある。
これらはどうやら、
googleのprotobuf というものらしい？
googleのprotobuf から protobuf-python-3.3.0.tar.gz をダウンロードしてホームディレクトリに解凍した。
caffe_pb2.py のインポートするべきファイルがあった。
今回、protobuf のインストールは行わないで、ファイルだけを利用してみようと思う。
ファイルを利用するためにPYTHONPATH にprotobuf-3.3.0/python を追加する。
export PYTHONPATH="/home/masaaki/protobuf-3.3.0/python:$PYTHONPATH" そして、もう一度、
make を行った。
やはり、エラーで今度は six モジュールが無いとのことだった。
six モジュールは pip でインストールするということで、まずは pip をインストールする。
wget https://bootstrap.pypa.io/get-pip.py get-pip.py が取得できた。
スーパーユーザー・モードで get-pip.py を起動した。
sudo python get-pip.py six モジュールをインストールする。
sudo pipinstall six make すると、今度は、descripter_pb2.py が足りないらしい。
descripter_pb2.py はどうやってゲットするのか？調べていたら、
「Why do I see “cannot import name descriptor_pb2” error when using Google Protocol Buffers? 」がヒット。それによると、descripter_pb2.py はコンパイルして生成するものらしい？
（注：このWebサイトには、protobuf をインストールするように書いてあったが、インストールしないでやっている。結局うまく行っていないので、インストールしてみようと思う）
続きます。
2017年05月18日 05:38 |
DNN
| トラックバック:0
| コメント:0
引き続き、オライリーの本「
ゼロから作る Deep Learning 」をやってみよう。コードはオライリー・ジャパンの
oreilly-japan/deep-learning-from-scratch にあって、
MITライセンス なので、これをjupyter notebook ででやりながらやってみることにした。この本はとっても良い本なので、購入されて勉強することをお勧めする。
今回は、ディープラーニングについて学習する。この辺りになると、論文の紹介が多くなる。概要が見れてうれしい。
演習は畳み込みニューラルネットワーク2層、プーリング1層、畳み込みニューラルネットワーク2層、プーリング1層、畳み込みニューラルネットワーク2層、プーリング1層、全結合1層、ドロップアウト1層、全結合1層、ドロップアウト1層の合計13層のディープラーニング・ニューラルネットワークをdeep_convert.py で実装している。それを train_deepet.py で訓練すると、99.39 |% の正確さでMnist の数字を認識できた。
最後には、64ビット長の浮動小数点数を使ったときと、16 ビット長の浮動小数点数を使ったときの認識精度は変化が無かった。（half_float_network.py）
2017年05月17日 04:01 |
DNN
| トラックバック:0
| コメント:0
引き続き、オライリーの本「
ゼロから作る Deep Learning 」をやってみよう。コードはオライリー・ジャパンの
oreilly-japan/deep-learning-from-scratch にあって、
MITライセンス なので、これをjupyter notebook ででやりながらやってみることにした。この本はとっても良い本なので、購入されて勉強することをお勧めする。
今回は畳み込みニューラルネットワーク をやってみた。説明は分かりやすかった。
Convolution レイヤやPooling レイヤの実装を学習したが、いまいち頭に入っていないので、あとでもう一度、やってみることにする。
今までの全結合ニューラルネットワークと同様にPython で書けるのは素晴らしい。
畳み込みニューラルネットワークでMnist を学習したときのテストデータの正確さは 98.76 % だった。
2017年05月16日 04:50 |
DNN
| トラックバック:0
| コメント:0
引き続き、オライリーの本「
ゼロから作る Deep Learning 」をやってみよう。コードはオライリー・ジャパンの
oreilly-japan/deep-learning-from-scratch にあって、
MITライセンス なので、これをjupyter notebook ででやりながらやってみることにした。この本はとっても良い本なので、購入されて勉強することをお勧めする。
今日は、2章のパーセプトロンだ。ゲートをパーセプトロンで作っている。AND、NAND、OR
XOR は閾値が線形だと表せないので、パーセプトロンをつないで作っている。
2017年05月08日 04:46 |
DNN
| トラックバック:0
| コメント:0
「
「PYNQ祭り」延長戦 : FPGAディープラーニング実践懇親会 」に参加するためにDeep Learning Nerual Network (DLNN) を勉強することにした。
勉強するために「ゼロから作る Deep Learning」の本をやってみることにしたのだが、老眼で本を読むのがつらいので、
オライリーの「ゼロから作る Deep Learning」 のPDFを購入して、それを見ながらやってみることにした。
コードはオライリー・ジャパンの
oreilly-japan/deep-learning-from-scratch にあって、
MITライセンス なので、これをjupyter notebook ででやりながらやってみることにした。この本はとっても良い本なので、購入されて勉強することをお勧めする。
最初に第1章からやってみる。Python は大体わかっていたので、Numpyと matplotlib の使い方を学習した。
売り物の本の内容なので、jupyter notebook を貼るだけにする。ちなみにjupyter notebook は本の通りにAnacondaをインストールして、そこから起動している。
2017年05月07日 04:32 |
DNN
| トラックバック:0
| コメント:0
FPGAマガジンNo16 のAXI4 Master のソースコード と、
FPGAマガジン No.17 のAXI4-Stream のソースコード を公開しているが、
taksei さんから「ソースコードを64bit Linux版VivadoでC-Sim実行してみたのですが、long型が8バイトとして確保されるため、BMPファイルのリード・ライトに失敗するようです。」との報告があった。 long型で4バイトのところ、8バイトになっていたようだ。
そこで、taksei さんに教えて頂いたように、stdint.h を使用して、uintX_t や intX_t を使用することにした。taksei さん、ありがとうございました。
私もVirtualBox 上に64ビット版のUbuntu 16.04 をインストールしてあって、その上にVivado 2016.4 をインストールしてある。よって、それ上のVivado HLS 2016.4 で確かめてみよう。
まずは、64ビット版Ubuntu 16.04 の Vivado HLS 2016.4 を起動した。
まずは、以前のままの bitmap_header.h でやってみよう。
これで C シミュレーションを行った。
”Can't allocate rd_bmp memory”エラーになってしまった。
taksei さんによると、”stdint.h” を使えば良いらしい。
”stdint.h” は、少なくとも 8, 16, 32, 64 ビット長の intN_t, uintN_t という型を宣言してるようだ。つまり、ビット長が明確に定義されている。
これを使用して、
BMPのフォーマットに関しての資料 を参考に、 intN_t, uintN_t で bitmap_header.h を書き直してみよう。実際には、taksei さんのコードを検証しながら、コピー＆ペーストを行った。
更に、lap_filter_tb.c にもBMPのフォーマットがあるので、それも同様に、 intN_t, uintN_t に修正した。
修正後に C シミュレーションを行ったところ、今度は成功した。
C コードの合成結果を示す。Windows 10 での結果と同じレイテンシだった。
C/RTL協調シミュレーション結果を示す。これも、Windows 10 での結果と同じだった。
lap_filter0_axim/solution1/sim/wrap_pc ディレクトリを見ると、test_lap.bmp が出来て、正常にラプラシアンフィルタ処理が行われているのが分かる。
Export RTL も正常に行うことができた。
更新した bmp_header.h, lap_filter_tb.c を Windows 10 のVivado HLS 2017.1 に持って行っても正常にシミュレーション、合成を行うことができた。
OS によって、int, long の型のビット長は変化するので、ビット長が決まっている変数を宣言する場合は、stdint.h の intN_t, uintN_t を使用して書いたほうが良い。
（2017/07/24： 追記）
新しい bmp_header.h を貼っておきます。
#include <stdio.h> #include <stdint.h> typedef struct tagBITMAPFILEHEADER {typedef struct tagBITMAPINFOHEADER{typedef struct BMP24bitsFORMAT {unsigned char blue;unsigned char green;unsigned char red;
2017年05月05日 16:25 |
Vivado HLS
| トラックバック:0
| コメント:0
「
美女と野獣 」（映画）を奥さんと見てきました。
アニメは子供たちのお供で何度も見ていたので、歌や映像に見覚えがあって懐かしかったです。
なかなか良かったです。女性受けすると思います。エマ・ワトソンは綺麗で素敵でしたね。
2017年05月03日 20:14 |
日記
| トラックバック:0
| コメント:0
今回は、Zynq-7000 VIP について書いてみようと思う。
Vivado 2017.1 からZynq-7000 VIP のライセンスが無料になって、Zynq のPS 込みでシミュレーションできるようになったようだ。（Vivado 2016.4 でPS 込みのシミュレーションをしたところ、AXI BFM のライセンスエラーになってしまった）
Zynq-7000 VIP の資料で見つかったのは唯一”
AR# 69031 Zynq-7000 All Programmable SoC VIP - リリース ノートおよび既知の問題 ”だった。
それによると、「Zynq-7000 All Programmable SoC VIP は Processing System7 IP からのみアクセスできます。」だそうだ。
サンプル・デザインで、Zynq-7000 VIP が試せるという情報があったので、File メニューから Open Examples Project... を選択して、サンプル・プロジェクトを作成した。サンプル・プロジェクトのテンプレートは、Base Zynq を選択した。
Base Zynq プロジェクトが開いたところだ。
ブロックデザインを示す。
Address Editor の画面を示す。
Flow Navigator のSIMULATION -> Run Simulation -> Run Behavioral Simulation を選択して、シミュレーションを行った。
シミュレーションの波形が示された後に、”run all”を行ったときのVivado画面を示す。
AXI VIP Test PASSED が表示された。
まずは、シミュレーションの階層を示す。
シミュレーション用のテストベンチ・ファイルのzynq_tb.v にPS からPL へのアクセス方法が書いてあった。zynq_tb.v の一部を画像で引用する。
tb.zynq_sys.base_zynq_i.processing_system7_0.inst.write_data(32'h40000000,4, 32'hDEADBEEF, resp);
で0x40000000 番地に 0xDEADBEEF を書いて、
tb.zynq_sys.base_zynq_i.processing_system7_0.inst.read_data(32'h40000000,4,read_data,resp);
で 0x40000000 番地のデータを read_data に読んでくることができる。階層はシミュレーション階層の図の通りだ。
その前にLED を点灯するために 0x41200000 に 0xFFFFFFFF を書いている。
さて、シミュレーション波形を見てみよう。全体の波形は省略するが、Read /Write する場面の波形を示す。
0x41200000 に 0xFFFFFFFF を書いているのが分かると思う。その後のトランザクションはよく見えないので、もう少し拡大してみよう。
上の波形を見ると、0x40000000 番地に 0xdeadbeef を書いて、0x40000000 を読むと 0xdeadbeef なのが分かる。
これで、PS のままのプロジェクトでもシミュレーションを行うことができた。これは便利だ。今まで、わざわざシミュレーション用にAXI4-Lite のMaster モジュールを付けた専用のプロジェクトを作る必要が無くなった。
2017年05月02日 04:23 |
Vivado
| トラックバック:0
| コメント:0
”
Vivado 2017.1 の新機能6（AXI Verification IPの使い方の覚書2） ”の続き。
前回、AXI Verification IPのWrite トランザクションについて記事を書いたが、どうしてもWVALID をディアサートする方法が分からなかった。本当はランダムにできれば良かったのだが、WVALID を変化させる方法が分かったので、覚書を書いておく。
”
AXI Verification IP v1.0 LogiCORE IP Product Guide Vivado Design Suite PG267 April 5, 2017 ”の60 ページの”Figure C-2: Write Command and Data Flow”の一部を引用する。
ここでピンクの四角で囲ってある”Data Inter-Beat Delay (Transaction)”がWVILD に当たることができるDelay のようだ。
ここで、”
AR# 68234 AXI Verification IP - AXI VIP のリリース ノートおよび既知の問題 ”のXILINX_AXI_VIP_2017_1.zip を展開した資料を見てみる。
上の図でもわかるように set_beat_delay() があった。これを使用してみたが、updated の設定の仕方が分からない。
set_beat_delay() を使って、2番目のWrite トランザクションのバースト転送の2番目、4番目、6番目を遅らせてみた。2番目のWrite トランザクションのSystemVerilog のコードを示す。
task wr_tran_method_two();
ここで、
wr_transaction.set_beat_delay(2,8);
が今回書き加えた部分だ。
このシミュレーション波形を示す。
2番目のWrite トランザクションでWVALID がトグルしているのが分かるが、同じ updated の値にしたのに、それぞれのWVALID がディアサートされている間隔が違っているのはなぜだかわからない？
2番目のWVALID のディレイの長さは 40 ns 、4番目のWVALID のディレイの長さは120 ns 、6番目のWVALID のディレイの長さは140 ns だった。
2017年05月01日 05:01 |
Vivado
| トラックバック:0
| コメント:0
