Posts Tagged with "Ultra96"

既に発行済みのブログであっても適宜修正・追加することがあります。
Even in the already published blog, we may modify and add appropriately.
posted by sakurai on April 15, 2019

Bocktechという会社にオーダーしていたPCBが届きました。 このメーカーだと、PCB製造に2.66日、PCB実装に1.02日、配送(DHL)に2.00日と、ネットでの支払い完了から数えて、わずか5.68日しかかかっていません。

それなのに、値段は送料込みで54.83 USDと最安でした。PCB製造が1.00 USD、PCB実装に29.83 USD、配送(DHL)に24.00 USDという内訳です。

後は品質がどうかということなので、部品を実装して、動作チェックしてみましたが、特に問題無く動作しました。2層なので電源ノイズは小さくない(300~400mVp-p)ですが、これは会社の問題では無いです。

総じて価格は最安、納期は最短ということで、当面この会社のサービスを利用することになりそうです。

図97.1
図97.1 PCB

試作なのでPCBは5枚オーダーしました。

図97.2
図97.2 PCB基板表面

そのうちの2枚にSMDを実装しています。最低の実装数量が2枚となっているためです。

図97.3
図97.3 PCB基板裏面


左矢前のブログ 次のブログ右矢

PCBの完成

posted by sakurai on April 7, 2019

FusionPCBにオーダーしていたメインPCBが届きました。実装も依頼したので、基板だけよりは時間がかかります。受注から実装完成まで18.94日、DHLによる配送が0.95日でした。FusionPCBは若干高いようですが、DHLの配送料込みなので、他社と価格比較する際はトータルで見る必要があります。

コストを抑えるため、実装はSMD部品のみ依頼し、残りのスルーホール部品はマニュアルによるハンダ付けとしました。

図96.1
図96.1 完成したPCB

部品を実装したボードをUltra96ボード、PMOD-VGAボード、PMOD-I2S(サウンド)ボード、PMOD-JOY-SWボードと組み合わせて、Space Invadersが正常に動作することを確認しました。

基板図の表、裏の両面を示します。

図96.2
図96.2 ガーバーデータ表

図96.3
図96.3 ガーバーデータ裏

UltraZedボードでは電源ONでリセットがかかったのですが、プロトタイプボードを実装して電源を入れたところ、電源スイッチをONしなければならないことが分かりました。ところが、Ultra96ボードの電源スイッチがインタフェースボードで隠されて押しにくいことが分かったので、新たに電源スイッチとついでに敵の強さを設定するDIP SWを設けました。回路は他は基本的には変えていません。ソルダーレジスト色は黒にしてみました。

図96.4
図96.4 SketchUPによる3D化

図96.5
図96.5 IndigoRTによるレンダリング


左矢前のブログ 次のブログ右矢

FSMのダイレクトリターン

posted by sakurai on April 4, 2019

さて、非リーフFSMコールの後、リーフコールがある場合は、単純に前記シーケンスの組み合わせとなります。図で示すと図95.1のようになります。

図95.1
図95.1 非リーフコールからリーフコール

ここで結構見られるのが、リーフを呼んで戻った後、何もせずにさらにcallerに戻るパターンです。これを実現するより効率的な方法として、ダイレクトリターン手法があります。これを図95.2に示すと、リーフをコールする前にスタックから戻り番地を取り出しreturnに入れ、リーフへジャンプします。リーフからは知らずにリターンすると、ダイレクトリターンが行われます。

図95.2
図95.2 ダイレクトリターン

特殊な場合として、上記のようにパラメータ設定だけしてリーフにジャンプするような場合は、そもそもリーフであるため、以下の図のような呼び出しとなります。

図95.3
図95.3 ダイレクトリターン

例として、残機表示サブFSMは、(リーフである)copyAreaを呼び出すので、returnを破壊するため非リーフですが、その後のシーケンスでcopyAreaを呼び出しダイレクトリターンを行います。その際には図95.3のダイレクトリターン手法は取れないため、図95.2のダイレクトリターン手法を取っています。


左矢前のブログ 次のブログ右矢

FSMのcall, returnメカニズム

posted by sakurai on March 31, 2019

前記事の共通シーケンスの続きとなります。

FSMのcall, returnメカニズムとして、returnレジスタを設置し、caller側で戻り先ステート(通常は現ステートの次)をreturnに格納しておいて、calleeを呼ぶ機構にしていることは、前記事で記載しました。

単純な場合はこれで動作しますが、callが2段以上になると、returnレジスタが1段であるため、returnレジスタの退避等が必要になります。言うまでもなくプロセッサではスタックがこの自動化を行うわけで、プロセッサの場合の疑似コードを書くと次のようになります。

call CALEE;
:
CALEE:
:
return;

動作的には、

rs[--sp] ← PC + 4;
PC ← CALEE;
:
CALEE:
:
PC←rs[sp++];

FSMの場合はPCはstateレジスタに相当しますが、それを退避するRS(リターンスタック)配列を設置し、SP(スタックポインタ)も設置します。とはいえ、ハードウェアでありリカーシブコールがあるわけでもないため、4段程度の簡素なスタックとします。2bitですがSPも実装します。実際にはreturnを除いて2段で済んだので(トータルで3段)、SPは1bitとしています。

さらに、上記のようにプリディクリメント、ポストインクリメントの処理とせず、ポスト処理のみとします。その理由はサイクルをかければプリ処理も可能ですが、Verilogが遅延代入であることから、簡単のためポスト処理のみとしています。

また、通常のスタックがpush down(積むと上から下にスタックが伸びる)であるのに比べて、実装するスタックは本当のスタック(地面に積むため、下から上に伸びる)にします。これはどちらでもコストは同等です。

以上のような設計だと、FSMのコールは、図94.1のような疑似コードとなります(caller saved)。

図94.1
図94.1 コールの疑似コード

これは全ての場合に動作しますが、リーフコールが多いのにも関わらず、リーフではスタックは不要です。従って、call先を見分ける必要はありますが、コードの効率化を考えて呼び出しをリーフ(緑)コールと非リーフ(赤)コールに分け、リーフをコールする際は以下の図のようなコードを用います。

図94.2
図94.2 リーフコールの疑似コード

これは、元から使用していたコードと同じものとなります。returnを破壊する一般FSMを赤、returnを破壊しないリーフFSMを緑で表しています。

今回はcaller savedで実装しましたが、callee savedのほうが若干容易かもしれません。caller savedでは呼ぶ前にcalleeがreturnを壊すか壊さないかを調べてからcallしなければならないのに比べて、callee savedであれば、全てreturnレジスタに入れてcallし、callee側でさらに呼ぶときは(つまりreturnを壊す場合は)スタックに入れるという流れであるためです。


左矢前のブログ 次のブログ右矢

posted by sakurai on March 24, 2019

FusionPCBにオーダーしていた基板が届きました。以前の設計時のブログの続きです。

非常に小さい基板で、以下に基板の100円硬貨との比較写真を示します。基板業者は前回と同じFusionPCBで、今回はOSCという速達配送業者を利用して9.9USDでした。基板のみで製造に7.94日、OSCによる配送にシンセンから日本まで3.13日かかっています。シンガポール郵便よりはだいぶ早いですね。9.9USDの内訳は、7.9USDが基板制作代、2.0USDがOSCの配送料のようです。

前回はソルダーレジストを白で製造しましたが、今回は黒にしてみました。Ultra96toPMODボードもオーダーしています。レベル変換ICのみSMDだったので、手ハンダはマイクロスコープ下のハンダ付け作業となり厳しいため、レベル変換ICのみ実装もオーダーしました。

図93.1
図92.1 基板写真

さらにこれを実装したものを次の図に示します。

図93.2
図92.2 基板に部品を実装した

UltratoPMODボードに取り付けて正常に動作することを確認しました。


左矢前のブログ 次のブログ右矢

FPGAで機械学習(3)

posted by sakurai on February 25, 2019

ブート

Ultra96にはMiniDPケーブル経由でディスプレイを接続し、またUSB経由でキーボードとマウスを接続しておきます。前回焼きこんだSDカードをUltra96に差し込み、電源を入れ、リセットスイッチを押すとLinuxがブートします。

ライブラリインストール

プログラムを展開します。文字が小さくて見づらかったのですが、なんとかターミナルを立ち上げられました。

root@ultra96:~# cd /home/linaro/
root@ultra96:/home/linaro# tar xvzf xlnx_dnndk_2.08_1901.tar.gz

これにより各種プログラムが展開されます。次にUltra96のディレクトリに移り、

root@ultra96:/home/linaro# cd xilinx_dnndk_v2.08/Ultra96
root@ultra96:/home/linaro/xilinx_dnndk_v2.08/Ultra96# bash install.sh Ultra96

により、必要なDNNライブラリをインストールします。ここで評価ボードの再起動が必要となります。

コンパイル&ラン

各種デモプログラムはコンパイルしてランするだけで全て動作しました。

図89.1
図89.1 ADAS認識デモ(SSD)

静止画の画像認識はResnet50やMobileNetを用いており、それぞれ25FPS、116FPSとかなり性能差があります。 また動画の画像認識は、face detectionはDenseBox、adas_detectionはYOLO-V3、video analisysはSSDを用いていることがわかりました。以下の性能表によればそれぞれ133FPS、30FPS、33FPSとなっています。ほぼリアルタイムで認識していることがわかります。

図89.2
図89.2 各デモの性能

認識ソフトウェアは、様々な動画フォーマットに対応しており、調べた限りではMOV, AVI, MP4に対して動作しました。また、解像度も柔軟に対応しています。ただしFPSは解像度により上下するため、比較する際には解像度を合わせないと、正しいネットワーク性能比較になりません。例えばデモ動画では、adas_detectionの動画は512x256の15FPS(640kbps)、video_analisysの動画は480x360の12FPS(954kbps)と微妙に異なっています。

認識率に関しては、YOLO-3はあまり問題を感じませんでしたが、SSDはかなりfalse positiveがあり、(バグかもしれません)このままでは使用できないと感じました。


左矢前のブログ 次のブログ右矢

FPGAで機械学習(2)

posted by sakurai on February 20, 2019

資料やデータの入手

まずXilinxのアカウントは所持しているものとします。次にXilinxのエッジAI開発者ハブのページに行き、以下に示すデータをダウンロードします。ここで対象の評価ボードは、過去記事でインベーダーゲームを搭載したUltra96ボードを使用します。

SDカードへブートイメージの焼きこみ

基本的には上記ユーザーズガイドに基づいて実施します。まずSD焼きソフトであるEtcherを入手します。次に上記評価ボードのブートイメージファイルを、zipは解凍しなくても大丈夫なので、そのままEtcherでSDに焼きます。

図88.1
図88.1 Etcher

デモプログラム類の書き込み

デモプログラムやデータを評価ボードに移さなければなりません。ユーザーズガイドではネットワークでscpすると記述されていますが、Ultra96の無線LANがうまくつながらなかったため、SDにあらかじめ移しておくことにしました。

VirtualBox等のVMを用いたLinuxでSDをマウントしてコピーします。USBインタフェースを持つSDカードリーダを使用しました。VMにおいてはUSBをVM側で見えるように設定しておく必要があります。

上記イメージを書き込んだSDは、図88.2のように第1パーティションがFAT32、第2パーティションがext4となっています。第2パーティションをGpartedで拡張しておきます。

図88.2
図88.2 Gpartedでext4を拡張

デモプログラムは800MB以上あるため第1パーティションには入らないので、第2パーティションにコピーします。

virtaul_machine # cp xlnx_dnndk_2.08_1901.tar.gz /run/media/user/ROOTFS/home/linaro/
virtual_machine # sync


左矢前のブログ 次のブログ右矢

FPGAで機械学習(1)

posted by sakurai on February 16, 2019

機械学習

そもそもFPGAボードを購入したのは機械学習(以降ML)をさせたかったのですが、その前に設計フローの勉強としてインベーダーゲームを作成しました。作成途中では拡張ボードが必要になり、急遽Pt板設計CADを勉強したりPt板を発注したりという作業が発生しましたが、今回からMLの話題に移ります。

エッジAI

AIもMLも同様な意味で使われていますが、本命はエッジAIです。現状は良いモデルの探求や膨大な学習の必要性から、クラウド側でGPUが多用されています。ただ、一旦学習が完了すればそれを多数の端末にデプロイします。せいぜい数十個のGPUがセンター側で必要なのに対し、車載ADAS/ADでは数百万台出荷されるため、半導体ビジネスからみると圧倒的にエッジAIのほうが魅力的です。

エッジAIの部品

エッジAIにおいては何より低電力、低コストが求められるので、一台10万円もするようなGPUは、コスト、電力、発熱共に使用できません。従来はFPGAも高価でしたが、近年のXilinx Zynq UltraScale+等のようなチップであれば価格はGPUの1/100のオーダーです。ということでFPGAでMLすることを考えます。

エッジAIのフレームワークDNNDK

フレームワークとはAIの業界ではTensorFlowやChainerを意味することが多いのですが、ここではエッジAIのソフトウェア基盤の意味で用いています。具体的にはDeePHiの作成した以下に示すDNNDKフレームワークを使用します。DeePHiはXilinxによって昨年買収されました。

図87.1
図87.1 DNNDKスタック


左矢前のブログ 次のブログ右矢

posted by sakurai on February 8, 2019

ゲームの完成

以前の記事で実装したインベーダゲームを、Ultra96及びUltra96toPMODインタフェースボードの組み合わせと、ジョイスティックで動作させることができました。絵も音も、UltraZedボードと全く同様に出ています。

動画のフルキーボードは全く使用していません。Ultra96に上記PMODインタフェースボードを接続し、それにPMOD-VGAボード、PMOD-I2Sボード、自作PMODジョイスティックSWボードを接続し、動画中のジョイスティック及びスイッチにより操作しています。

図86.1
図86.1 Ultra96のインベーダゲーム

共通シーケンス

ゲーム自体はまだ改良の余地があり、共通ステートシーケンスをソフトで言うところのサブルーチン化する等のリファクタリングを実施中です。図86.2にその一例を示します。パターンROMからいろいろな形、例えばインベーダ、自機、ベース、UFO等をVRAMに矩形転送するシーケンスは、多用されますが、それぞれにシーケンサを用意していると大変なロジック量になります。これをサブルーチンのように、{ソースX座標、ソースY座標、横幅、縦幅、デスティネーションX座標、デスティネーションY座標}の6個を入力パラメータとして、シーケンスを呼びだすことでシーケンスの共通化が可能です。呼び出す前には戻り番地をリターンレジスタに退避してから呼び出します。呼び出し先で戻るときにはリターンレジスタをステートに代入して戻ります。

図86.2
図86.2 共通シーケンス(=サブルーチン)

本来はプロセッサのソフトウェアで実行する、十分複雑なシーケンス制御をハードウェアで実装してみて判明したのは、まさにプロセッサの進化のリバース(逆行)だということです。FSMシーケンスを共用化する目的で、前述のようにリターンレジスタを実装しましたが、これはプロセッサのリンクレジスタと同じです。

水平マイクロ

現在マイクロプログラム処理をあまり見なくなったのは論理合成のためだと思います。論理合成が無い時代はハードウェア論理を変更するのは大変な作業で、それを簡単にするために、FSMではなくマイクロプログラム処理を考え、ROMの内容を書き換えることで、処理の変更を行ったわけです。今回のFSMシーケンス記述は、いわば、インベーダ処理プロセッサの超水平マイクロを書いているようなものです。ちなみに水平マイクロには、普通プロセッサレベルのISAには存在しない、マルチウェイ分岐等の強力な命令があります。

ESDAツール

最近ではSDSoCなりVivado-HLSなりが使えるので、Cで書こうかとも思いましたが、今回はVerilogで記述してみました。VerilogはCに対するアセンブラとも言われますが、コード量的にはそれほどの差はありません。20年ほど前にESDAツールがあったのですが、最近はどこへ行ってしまったのでしょうか。動作合成が進んだのでなくなったのかもしれません。同じアルゴリズムをCで書いてみると、ESDAが不要かどうかが分かると思います。


左矢前のブログ 次のブログ右矢

posted by sakurai on February 5, 2019

Ultra96対応だけであれば変換ボードに吸収しても良いのですが、 スイッチ類をUltraZedボードに差し替えて使用する場合には、前述のとおりインタフェースが必要になります。その理由は、遠い場所にあるスイッチは単なるロジックではなく電装線路扱いとしなければ、反射が起き、正常に動作しないためです。

この反射を抑えるために、図85.1のような回路を設計しました。

図85.1
図85.1 回路図

このボードを作成しました。手ハンダでも作成できるようにSMDは使用しないようにしています。

図85.2
図85.2 ボードレイアウト図

EagleUpを用いて3D化します。

図85.3
図85.3 ボードイメージ

前々回作成したUltra96からPMODへのインタフェースボードと組み合わせ、レンダリングしたものが図85.4です。フラットケーブルの先(反対側)には前回のジョイスティック及びスイッチを接続します。

図85.4
図85.4 結合ボードイメージ


左矢前のブログ 次のブログ右矢


ページ: