ZynqBerryで遊ぶ

ZynqBerryで遊んでみることにした。

ZynqBerry (TE0726)はTrenz electronic社が販売しているFPGAボードで、Raspberry Pi Model 2と互換製があるそうだが、本物のRaspberry Piを所有していないのでどの程度互換性があるのかは分からない。 このボードは2019年の12月にDigi-Keyで購入したのだが、忙しくて殆ど動かさずにいた。

搭載しているFPGAはZynq 7010、DRAMは512MByte DDR3L SDRAM、 Configuration 用 Flash memoryは16MByte、 I/Fは type-AのUSBが４、 10M/100M Ethernetが1、 μSDカードI/Fが１、JTAGとUSB-UART用にtype-BのUSB I/Fを１つ持っている。 EthernetはZYNQのGEMではなくSMSCのLAN9514というLSIを使っている。 LAN9514は4ポートのUSB 2.0 hubとしての機能と10/100Mbit Etnernetの機能を搭載しているLSIでZynqとはUSB 2.0で接続されている。

    (TRM-TE0726-02より引用）

この他にHDMI I/F、CSI(Camera Serial I/F)-2、 DSI (Display Serial I/F)用のコネクタ、Line-out用Audio ouputがZynqのPL部につながっているがPL部なので別の用途に使うことも可能だろう。

注意点としては、使用しているZynqのパッケージの制約から、SDカードからダイレクトにブート出来ない。 SDカードからブートさせる場合はSPI ROMのFSBLからu-bootを起動してそこから改めてSDカードからブートさせる必要があるそうだ。  また、残念な点が２つある。まず一つは、このボードの電源はtype-BのUSBコネクタから供給するが、type-AのUSB I/Fを４つ持っているのでこれらをフルに使う場合を想定すると、type-Bコネクタからの給電はちょっと不安だ。 もう一つはFPGAの再コンフィグやリセットをするためのスイッチを搭載していない。ただし、開発者もその点は判っているようで、＋５V給電用とリセット用のランドがそれぞれ設けられている。 そこで、ジャンク箱から適当な部品を探し出して給電用コネクタとリセットスイッチを取り付けた。

これでボードの準備は出来た。

次にTrenzのサイトからReference DesignをダウンロードしてVivadoでインプリしてみた。

Reference Designの最も最新バージョンは2020.2用のもので、TE0726-zynqberrydemo1とTE0726-test_boardの２種類あった。最初にTE0726-zynqberrydemo1を試してみた。このデザインにはCSI-2、DSI、HDMI、Audioとボードのほぼ全ての機能を動かす回路が入っているようだ。 vivadoでインプリしてみたところ、何とタイミングエラーが出てしまった。どこかデザインをイジったわけでもなく、そのまんまの状態でインプリしたのだが。。

細かくは見ていないが、タイミングエラーになっている箇所はAudio部分のクロック載せ替え部分とCSI-2 I/F部で起きているようだ。 別にこのデザインで遊びたい訳ではないので深追いはしないことにして、この状態でbitstream生成とハードウェアのエクスポート(xsaファイル生成）だけした。

また、もう一つのTE0726-test_boardの方も見てみたが、こちらはPL部には何もないデザインだった。

生成したTE0726-zynqberrydemo1のxsaを使ってpetalinuxのビルドをしてみた。このReference Designにはpetalinux用のテンプレートも入っているのでこれを利用した。実はこのボードのEthernetの実装の仕方はZYBO等の他のFPGAボードには見られない手法なのでデバイスツリーの書き方に興味があったのだが、特別な記述は無かった。ZynqからはUSBの先に繋がっているのでUSB-Ethernetコンバータとして見えるのだろう。 HDMIはsimple framebufferを使っている。起動直後HDMIの画面出力は全面黄色だったが、/dev/fb0に/dev/zeroをddでコピーしたら書換えできたので正常に動作しているようだった。

ということで、このボードでちょっと遊んでみようと思う。具体的には以前、ZYBOでLinaro linux + simple frame bufferでX Windowを動かしたが、今回はZynqBerry + petalinuxで同様のことをしてみようという訳だ。 

ブログ再開

遂に定年を迎えた。

定める年と書いて定年。　定める年・・・定年・・・　よく判らんが、人生において一つの大きなマイルストーンではある。　まぁしかし、普通の会社員として生きるのは非常にキツかった。この生き方は自分の性格に合ってないと思った。が、ここまで何とかやってこれたのはやはり妻のお陰だと思う。彼女の叱咤激励、時には足かせとなってくれたお陰で8回目の転職をしないで済んだ。妻には感謝しか無い。 幸いなことに定年後も今の勤務先で再雇用され、あと数年はFPGAを使った開発業務に従事できそうだ。

マイルストーンを超えたので、ぼちぼちブログを再開しようかと考えている。 ブログを休止してから約６年、その間に世の中も大分変わってしまった。 ALTERAはIntelになり、XilinxはAMDになった。LatticeはまだLatticeのままだが。 FPGAの基本特許切れによりGOWINを始めとする新興のFPGAメーカーも色々と出てきているようだ。 ブログ休止中も仕事ではFPGAを使った開発業務はやっていたのだが、デバイスに偏りがあるし twitterでFPGA関連のツイートを追うのをいつしか止めてしまったので現在なにが話題なのか分からない。 ６年前は高位合成がトレンドだったと思うが今どうなんだろう。

Verilog-HDL等のハードウェア記述言語よりも抽象度の高いC言語でFPGAの開発ができることが高位合成の利点な訳だが、 ChatGPTの登場により、今や、自然言語でFPGAの設計ができそうな時代が到来してしまった。 私も試しにChatGPTに浮動小数点加算器の生成を依頼してみた。最初に出てきたのは仮数部のみを加算するコードだったが、「この部分を考慮してやり直して」と考慮不足な部分の改善指示を何回かやり取りしたらイメージ通りの実用性のあるコードが生成された。 もう一つバイナリをBCDに変換するBIN2BCD回路の生成も依頼してみたが、こっちは最初に提示されたコードがイメージと大きくかけ離れていて使えないコードだったので１回目で諦めた。 ChatGPTの有料版はさらに精度が高いという話だし今後も進化して行くのだろうから、これはもう究極のCASEツールになるのだろう。

ChatGPTとはFPGA以外の話もしてみた。

「夫の頭が剥げている。笑いそうになるけどどうしたらいい？って妻が聞いているけどどう思う？」

って聞いてみたら、

「夫の頭が剃られているか、薄くなっているかは、その人の自然な外観であり、人々が異なる外観を持つことが普通です。もし夫が自分の外観に不安を感じているなら、彼の気持ちを尊重し、彼が自分自身を快適に感じられる方法を見つけるように支援することが大切です。

もし、夫が自分の頭髪に対して冗談を言っているのであれば、妻もそれに合わせて楽しんでいいでしょう。しかし、もし妻が自分の夫を見下すような態度をとるのであれば、それは不適切であり、夫を傷つける可能性があります。

最も重要なことは、お互いを尊重し、自然な外観や個性を受け入れることです。」

と返してきた。

たまたまこの日は私の誕生日だったので次に

「今日は僕の誕生なんだ。」

と入れてみた。そしたら、

「お誕生日おめでとうございます！素晴らしい1年を迎えられますように。 お誕生日は、新しい年を始める良い機会です。過去の成功や失敗を振り返り、新たな目標を設定することができます。自分自身に対する思いやりと共に、家族や友人との時間を楽しむことができる日でもあります。 この特別な日を過ごす際には、自分自身へのご褒美や大切な人たちとの時間を過ごすことをお勧めします。また、今年の目標を設定し、その目標を達成するために何かしらのアクションを起こすことも素晴らしいアイデアです。 再度、お誕生日おめでとうございます！良い1年になることを願っています。」

と返してきた。 惚れそうになった。

ChatGPTを使うことの懸念の一つにChatGPTにマインドコントロールされる可能性が上がっているが、何か判る気がする。 でも、ChatGPTの返しは言葉が優しく誠実なので 老人福祉ではかなり使えるんじゃないだろうか。会話を通して癒やされる人も居るだろうし。そのための会話なら話している内容の正誤は大して重要ではないかも知れないし。

妻はChatGPTが気に入り、（間違った回答をすることがあると理解した上で）調べ物とかで使っているようだ。最近では「チーちゃん」と呼び出した。

という訳で、ブログをぼちぼちと再開しようと考えている。休止中にもFPGAのボードを何種類かは購入した。買っただけで殆ど動かしていないのだが。 再雇用になると賃金は大幅にダウンするので、これからは新しいボードを安易には購入できない。今あるこれらのボードを使ってなにかやってみようと考えている。 どういう頻度になるかも継続できるかも分からないがマイペースでノンビリとやって行こうかなと考えている。

ホームページのアクセス数

このブログで作ったIPはホームページで公開しているが、これまでのホームページのアクセス数を分析してみた。  ホームページでは閲覧者のIPアドレスと日時のみをログファイルに記録している。ダウンロードの有無や項目は記録していない。

ブログを休止した2019年10月3日から本日迄の期間のアクセス数は862だった。
この数は単純にログファイルに記録されている数でありIPアドレスに重複もある。

IPアドレス毎のアクセス回数（重複数）で見ると、IPアドレス自体の数は１４１で、最も多くアクセスしているIPアドレスは米国のプロバイダのアドレスの４６回で、２位は中国のプロバイダのアドレスの31回であった。

 IPアドレスの割当先情報（国名や組織名）はwhoisでJPNICやAPNICから取得できる。
この情報を元に上述のIPデータを組織名毎に集計してみた結果は188であった。
組織はさらに、Company（企業）、Academia（学校や研究所等）、ISP（インタネットサービスプロバイダ）の３種に分類している。 （ISPは個人の他に自営業者や小規模な企業の可能性もあるが調べようが無いので、個人と見做している。） この３種の比率で見ると、ISPが49%、Companyが36%、Academiaが15%であった。また、国籍では日本を含めて28カ国からアクセスがあり、66.5%が国内からのアクセスであった。

ログを取り始めた2011年10月からの全期間でも見てみた。
全期間でのアクセス総数は１３３８２。 IPアドレス毎の集計ではIPアドレス数は２４７６、最も多くアクセスしているIPアドレスは国内のIPアドレスで2011回だった。また、組織名毎の集計では組織数は561で、３種分類ではCompanyが43%、ISPが42%、Academiaが16%だった。また国籍数は日本を含めて44カ国で、その内の66.5%が国内からのアクセスであった。

 ３種の項目でアクセスの時間帯に違いがあるかを見てみたところ以下のようであった。
 Companyでは14:57:42頃に突出したアクセスがある。
3時の休憩時間にアクセスしているんだろうか？














一方、ISP（個人）は突出したピークが無い代わりに真夜中の時間帯にも多くのアクセスがあった。














Academiaは以下のようだった。














ということで、時間帯でみるとちょっと面白い結果になった。

10万ページビュー

ブログの更新をしなくなって約２年半になるが、この間も日々僅かではあるが閲覧があり、閲覧数がこの度１０万を超えた。
大したことも書いていない、しかも休止中にも拘わらず１０万回に到達したというのは感慨深い。

ブログの統計情報によると、ブログを開始した2010年10月3日から本日までの全期間で、一番参照された記事は「ZYBO26(Linux + simple framebufferでX Windowを動かすまで)」で、次が「DFT IPの作成２」だった。

直近の1ヶ月で見ても、このsimple framebufferの記事は一番参照されていた。

ブログ休止中もFPGAの評価ボードは何種類か購入はしていた。色々と忙しくて殆ど弄れてなかったのだが。。。

また暇になりそうなので、ぼちぼちブログを再開しようかと考えている今日この頃だ。

GTX1050Ti と Tesla m2050 No.2 （BNN-PYNQのtrainingをやってみた）

BNN-PYNQのtraining（学習）をやってみた。　

手順はhttps://github.com/Xilinx/BNN-PYNQ/tree/master/bnn/src/trainingに記載されており、特に判りづらい点はなかった。

・ mnist.py
実行時間はうちの環境では107分だった。

・ cifer10.py

実行時間は542分だった。


冒頭のBNN-PYNQのREADME.mdによると、GRID K520 GPU (i.e., a g2.2xlarge instance on AWS.) でのmnist.pyの結果は実行時間が約2時間で、test errorが1.6%となっているので、だいたい同じ結果だった。　一方のcifer10.pyはGRID K520 GPUでは約１２時間となっているのに対してうちの環境（GTX1050Ti）では約９時間と３時間程短時間で済んだ。test errorに関しては20.42%に対して20.0%なので同等。同じソースとデータを使っている筈なので当然だろうと思う。


因みに、学習中のGPUのリソース使用状況をnvidia-smiで観察してみるとメモリは最大
300MByte位の使用量だった。以下のスクリーンショットの最下段のpythonの部分がBNN-PYNQのtraining processだ。GTX1050Tiの搭載メモリ容量は4GByteなので10%もメモリを使っていない。つまり、メモリリソース的には十分余裕がある。

個人でDeep learningの学習をするならAWSインスタンス等を使うよりもGTX1050TiクラスのGPUを購入してやったほうが良いような気がした。

TE0720 No.4 （BNN-PYNQを動かしてみる ２）

TE0720でBNN-PYNQを動かすことが出来た。
以下は前回に続いてBNN-PYNQが動くまでの記録。

gdb (GNU debugger）で例外が出る原因を調べてみた。
例外が発生しているのはシェアードライブラリ（python_hw-cnv-pynq.so）の中であり、これはpythonからダイナミックリンクされるのでpythonごと gdb で追えば何か判るのではないかと考えた。

run ./x.py としてx.pyスクリプトを実行させると、以下のようにSIGILLシグナルを受けて停止したが、かまわず cont と打って実行を継続させた。

すると、あのterminate called after throwing an instance of 'char const*'というメッセージが表示され、SIGABRTシグナルを受けてプログラムが停止した。ここでバックトレースを確認した。


関数FoldedMVInitの400行目で例外がthrowされているようだ。python_hw-cnv-pynq.soはデバッグ用の情報も付いているようなので、gdbを一旦終了しBNN-PYNQのソースファイルを/home/xilinx/test-newswg/下に展開してgdbを起動して上述と同じところまで操作した。
次に関数 FoldedMVInitをリスト表示し400行目付近を見てみた。

accelBuffer用の領域確保に失敗して例外を投げているようだ。そこで397行目にブレークポイントを設定してプログラムを再実行した。



accelBufInの確保も失敗してnullポインタが返ってきているようだ。

そこで、今度はallocAccelBuffer関数の中を追ってみることにした。

allocAccelBuffer内部では引数をcma_allocに渡してcma領域を確保していた。cma_allocはContiguous memory allocatorでカーネル内部に物理アドレスが連続したバッファを確保するための関数らしい。今の場合は30MB分の連続領域を確保しようとしている。ステップ実行したところ、cma_allocからnullポインタが返っていることが判った。

現在のOSのcma領域がどうなっているか確認したところ、そもそも全体でも16MB分の領域しかないことが判った。


そこで容量を128MBに増やしてみた。


増量して、cma_allocをコールする直前での空き容量を見ると70MBあるので今度は大丈夫の筈だが、ステップ実行してcma_allocからの戻り値を見るとnullポインタが返されていた。


そこで、今度はcma_allocの中を追ってみることにした。cma_allocのソースファイルは無いので、アセンブラレベルでのステップ実行になったが、その結果 ioctl コールでエラーが返っていることが判った。

現状のカーネルはpetalinuxのカーネルでバージョンは4.9.0なのだが、もしかしたらcma_allocのioctlコールの引数仕様がカーネル4.9.0で動作しているデバイスドライバの仕様と違っているのかも知れない。そこで、カーネルをPYNQのカーネルに代えてみることにしたのだが、カーネルのファイル名やファイル形式、デバイスツリーのファイル名等がpetalinuxとPYNQとでは異なっており、そのためにu-bootも変更することになってしまった。ところが、Xilinxのgitリポジトリからu-bootをcloneしてビルドして動かしてみたところ、mmcを認識しない。。。仕方がないのでZYBOのu-bootを使うことにした。

上記構成のSDカードにして起動し x.py を実行したところ例外は発生しなくなった。

PYNQのカーネルのバージョンは4.6.0だった。4.6.0と4.9.0ではcma_alloc関連の仕様が変わっているのかも知れない。また、4.9.0ではFPGAのコンフィグレーションのFPGA managerが追加になっているのでそれに関連してxdevcfgも変わっている可能性もある。。　ともあれ、例外が発生しなくなったのでjupyter notebookでCifar10.ipynbを実行してみた。


実行できた！！

で、推論をハードウェアで実行（PLにダウンロードして実行）した場合とソフトウェアのみで実行した場合との差は801108 / 3199 = 250倍となった。 ARMのシングルコアのみで実行するよりも推論部をPLにダウンロードしてハードで実行させると250倍高速に実行できた、ということだ。本物のPYNQボードだとどの位なんだろうか？





Road-Signs-Batch（道路標識の識別）も実行してみた。


こちらも実行できた。




カーネル 4.9.0でioctlがなぜsyscall エラーになるのかという点など、まだ頭の中に？マークがあるが、なんとか動くようになったので良かった。 ワーイ ＼(^_^)／