1月24日発売予定

Interface 2026年3月号 別冊付録 FPGAマガジン特別版 No.5 にて、KV260 と ラズパイカメラを組み合わせて 1000fps で非接触動き量計測(オプティカルフロー計測)を行う記事を書かせて頂きました。

Interface(インターフェース) 2026年3月号

Amazon楽天市場

Amazonの情報を掲載しています

こちらなどでも技術紹介している技術内容の詳細解説記事となっておりますので、よろしければ読んでいただければ幸いです。
ラズパイカメラ(IMX219)は、非常に安価である反面、ローリングシャッターでBYAER配列という、マシンビジョンに向かないセンサーですが、当サイトが長年取り組んでいる高速駆動の設定と、FPGAならではの信号処理の工夫を行うことで非接触での振動計測を行っております。

本格的なグローバルシャッターカメラも販売中

記事内でも少しだけ紹介させて頂きましたが、KV260 に接続可能な、高速度グローバルシャッターカメラも開発しております。特にモノクロセンサー版はBAYER問題を持たない上、高速度ならマルチバンド光源との組み合わせなどもできるのでおススメです。
本格的なマシンビジョンには、グローバルシャッターのイメージセンサーが有効ですが、それらを備えた産業用カメラなどをFPGAに接続するのは一般に非常に高価(数十万円から数百万円)になりますが、当方では10万円以下でKV260に試せるものをコンセプトに開発しております。

こちらも、オープンハードウェアとして設計を公開しておりますので、興味のある方ぜひ挑戦してみてください。ご自身での基板製造するのが大変と言う方向けには BASE や BOOTH でも販売中です(すぐに使える完成品もございます)。

FPGAでしかできない高応答性の信号処理の世界で、新しい画像処理アルゴリズムやAIに挑戦したい方にお勧めです。１ミリ秒でのAI認識なども行っております。

以前に 64×96 のOLED(有機EL)を 869fps で駆動した記事を書きました。今回は 64×64 のLEDパネルを1000fps以上で駆動する話です。

OLED(有機EL)高速駆動

PMOD用にZyboに繋がるOLEDがDigilentから販売されているので今回試してみました。こちらのページのとおりやってみるとあっさり動作しました。Digilentのライブラリの充実っぷりに驚きです。 次にこのOLEDパネルを、高速度撮...

rtc-lab.com

2018.02.19

当サイトでは画像処理などでの計測対象のダイナミクスに対して十分小さな遅延で信号処理を行うことでゼロ遅延信号処理を目指しています。止まっているディスプレイは60Hz程度あれば、特殊な訓練を受けていない一般人には十分なのですが、残念ながら人間の生活する動線の中に情報表示を行う場合は秒速1m程度のゆっくりな動きでも 16.6ms あれば 1.66cm もブレたりズレたりしてしまい文字など読めなくなってしまいます。動くものを写真に撮るとブレるのと同じですね。
では、もっと速く表示することでいろんなところに情報を出したいわけですが、上記のOLED同様に、デバイスは高速な性能を持っているのにコントローラがタコなので低速でしか信号入力できないモジュールで溢れているという事情があります。

液晶のような物理的に低速なデバイスは別として、OLEDやDMDやプラズマディスプレイなど高速なデバイスは、人間の目で見たときに綺麗な階調画像を作るのには少し信号処理が必要です。FPGAなどを習得しているプログラマであれば無問題であっても、そうでない人には普通の映像信号が入力できないと困ってしまいます。したがってそれらを代替するコントローラを搭載することで簡単に使えるようにする反面、低速入力しかできないようにしてある製品が大多数です。というかそうしないと売れないので結局市場から消えているのだと思います。

そんな中、最近大変面白い情報を頂きました。なんとバカ仕様のまま売られている、つまり折角の超高性能をわざわざ封印するという事をしていないパネルが割と安価に流れているとの事でした。
早速ゲットしてみましたので今日はその話です。

上記の Kenta IDA さんに紹介いただいたこちらを買いました。探すと他にもいろんなものが売られているようですね。ご指摘いただいた通りインテリジェントでないバカ仕様のものを探すのが重要そうです。

Oscarvo 2個 P10 フルカラー屋外 LED モジュール HUB75 SMD3535 32×16 ピクセル LED ディスプレイ パネル 3…

Amazon楽天市場

Amazonの情報を掲載しています

HUB-75E 仕様を使った高速表示

HUB75で検索するといろいろ出てくるのですが、こちらとか AI とか、実物に張ってるチップを眺めたり、いろいろしながら仕様理解を進めていきます。
詳しい説明は多数サイトがあるので行いませんが、私が買ったものの要点をかいつまむと

• 32×64 が2セット組み合わさった構造
• 列方向にシフトレジスタでデジタル値を転送
• 列の値をラッチできるラッチICがシフトレジスタと別にある
• ラッチした値に対して選択した行を点灯
• 点灯時間はOEで制御可能でPWMで輝度も制御できる
• ラッチが終わればラッチ後の値の点灯と次の値の伝送を同時に行える
• 転送は25MHzぐらいまで動きそう(実物での実験による)

と言った感じです。
ラッチパルス以外は転送できますので、バイナリ値においてはほぼ ピクセルクロック 25MHz で書き込みができ、OE制御で階調が作れるという事になります。
25MHzで32×64(を2並列)送ればいいので、単純計算でバイナリで 12000 fps 近い性能が出ます。

この手のものの表示の常套手段としては、画像をbitプレーンに分解して表示します。
8bit階調(RGBあるので24bit色)とすると、まず 8bit目を書き込んで 100% の点灯、次に7bit目を書き込んで 50% の点灯、5bit目を書き込んで 25% の点灯、のようにやっていくと階調表示ができます。12000 fps を 8 で割っても 1500fps 近いですので、24bit カラーが 1000fps 以上で表示できます。トランジスタのスイッチが追いつくならこのやり方で 10bit階調(30bit色)ぐらい行けそうですが、実際には最後の方のパルスが小さくなりすぎるので適当なところで打ち切ります。
これでもまだ 1000fps 以上ありますので、さらにやりたければフレーム間で変調するとか空間ディザを掛けるとかいろいろあるのですが私の目的は 1000fps のカメラの信号処理結果を遅延なく出すことなのでこの辺りにしておきます。

KV260にはPMODが1個しかないので、とりあえず ZYBO-Z7 を使いましたが、まずは静止画表示で64×64 に縮小したマンドリルの画像がそこそこ見れるレベルで表示できました。

シミュレーションですが、8つのbitプレーンが 1ms よりも短い間隔で１巡しています。

拡大するとこんな感じで、bit によって OE を下げる時間を倍々で変化させています。

注意点としてはこの段階ではガンマ1.0のディスプレイになっています。
もっとも当方はガンマ1.0の信号をそのままマシンビジョンとして処理して、そのままガンマ1.0で表示するので問題ありませんが、PCなどでガンマ2.2などの信号を扱っている方は注意が必要です。

おわりに

今日は静止画の表示テストまででしたが、また近いうちに自作1000fpsカメラとの組み合わせをやりたいと思います。
世の中の画像信号処理は、歴史的経緯から 50Hz ～ 60Hz ぐらいが多く、電灯の電源周波数との干渉を避けて微妙な周波数になってるとかいろいろと負の遺産を引き継いでいる部分があり、このデジタルの時代のHDMI規格にすら入り込んでいます。
一方で、最近はやりのフィジカルAIだとか、エンボディドAIなどの分野だとこんな柵は無視して本当に必要なスペックで信号処理やアルゴリズムや学習モデルを構築すべきだと思います。
このような従来の規格に縛られない生のおバカ仕様というのは、必要なスペックを自分の好きなように再定義してFPGAで作り直すというのに大変適していると思います。

インテリジェントと呼ばれている従来のコントローラのスペックに縛られずに、自由に設計できるのが低レイヤーの良いところかと思います。
今回は 1000fpsカメラの為の1000fps表示コントローラと言う、オレオレ仕様を作ったわけですが、既製品にとらわれず新しいことをやりたい方の参考になれば幸いです。

LEDマトリックスパネル、64X64解像度 ボード上の4096個のRGB LED 3mmピッチHUB75入力出力、

Amazon楽天市場

Amazonの情報を掲載しています

FPGAこそのプログラミング

RTLなどのプログラミングを覚えると、それを活用してみたいと思いますよね。その際にFPGAを使うのはLSI開発に比べて手軽な選択肢の１つです。
そしてマイコンではなくFPGAでRTLを書くメリットの出し方としては大きく２つ

• マイコンなどでもできることをFPGAでもっと効率的にやる
• そもそもマイコンなどでは出来ないことをFPGAでやる

が、あると思います。
昨今では特に AIアクセラレーターのようなものをFPGAで挑戦したいという人も増えたことから前者に挑戦する人も増えていますが、明らかな差別化として後者のFPGAでしか出来ない領域に手を出すこともお勧めです。特にFPGAでしか出来ない機能と組み合わせることで前者の技術も生きてきます。

イメージセンサとの接続

「マイコンでは難しいがFPGAなら実現できる」ものの１つに、イメージセンサーとの接続があります。もちろん世の中にはMIPIなどのインターフェースを備えておりマイコンに接続可能なイメージセンサも一部に存在しますが、そうでないものが多数存在します。

イメージセンサーと言っても色々な種類のものがあります。大半は CCDイメージセンサとCMOSイメージセンサに分類できますが、それ以外の特殊なものもあります。
また、CMOSイメージセンサーの中にも、高速度カメラや赤外カメラや偏光カメラのようなものからイベントベースのイメージセンサーやSPADセンサーまで、本当にあらゆるものがあります(使ったことないものが多いですが)。
一般的には組み込みマイコンから使うイメージセンサはRGBのローリングシャッターが大半ですので、ちょっとした特殊撮影を行いたい場合にFPGAが使えると、イメージセンサの選択肢が一気に広がります。

CCD(Charge-Coupled Device)イメージセンサーは原理的にグローバルシャッター撮影となり、これはこれでとても面白いのですが、センサーとしてはほぼアナログデバイスで、アンプやADCや、その名の由来となっている内部のCCD構造の制御信号や、そのためのマイナス電圧含めた多系統の電源準備なども外部に必要で、アナログフロントエンドチップとFPGAなどを組み合わせて、さらにそれなりのアナログ回路を設計することになります。
一方で、CMOSイメージセンサは、その構造上様々な制御回路を内部に構成でき、電源や出力信号もシンプルであるため、外部から見ると、かなりの部分をデジタル回路設計の知識で対応することができます。

ちなみに様々なインターフェースタイプのCMOSイメージセンサがあることについて「どうしてMIPIとかに統一しないの？、なぜマイコンに繋がらないCMOSイメージセンサがあるの？」という疑問を持たれた方もおられるかもしれません。筆者はイメージセンサーのユーザーでしかないので設計する側の知識はありませんが、想像するに

• デバイス性能を最大限引きだそうとすると規格に合わない部分が出てくる
• 画質を上げるためにノイズ源／熱源となるデジタル回路は最小限にしたい
• 独自インターフェースの中での後方互換性の確保

などがあるのではないかと思います。
一方でFPGAなどを用いてこれらにきめ細かに対応が出来れば

• MIPIなどの標準仕様からはかけ離れたデバイス固有機能で特殊撮影が行える
• システム最適化された高リアルタイム性／低コスト／低消費電力な設計ができる

などのメリットが生まれます。これは

• RGBカメラだけで画像処理研究している人たちの一歩先を行ける
  (アクティブセンシング／マルチスペクトル撮影／特殊撮影各種)
• 低遅延で現実世界にフィードバックを掛けたときに起こる事象変化自体を研究対象にできる

などのメリットを生み出します。

イメージセンサの映像信号をFPGAで受信する方法

信号伝送の方式

イメージセンサに限らないのですが高速で大量のデジタルデータを送る方法は多数存在し、本当に様々なイメージセンサーがあります。

• クロック同期シングルエンド [LVCMOSなど]
• クロック同期差動信号 [MIPI/LVDS/subLVDSなど]
• CDR(Clock Data Recovery) [SLVS-EC など]

幸いなことに昨今の多くのFPGAがこれらに対応しています(どちらがどちらに合わせて進化したのかなどはいろいろありそうですが)。

CDR は基本的にはFPGAのハードマクロのトランシーバーコアを使う事になりますので、本記事では触れず、シングルエンドや差動信号によるクロック同期での信号受信について触れていこうと思います。

クロック同期高速データ信号の受信方法

これらはクロックとデータが別々の信号線で送られることを前提としており、しばしデータの方は複数のチャネルが存在します。
そしてこれらにはクロックとデータとの関係がいくつかあります

• クロックの片方のエッジを使うもの(SDR)
• クロックの立ち上がりエッジと立ち下りエッジの両方を使うもの(DDR)
• クロックを1:7などで逓倍して使うもの

またセンサー出力のデータが変化する位相関係においても

• センサー出力のクロックエッジと同時にデータも変化するもの
• クロックエッジがデータの中央付近に来るもの

などがあります。まずはイメージセンサーのデータシートをよく読むことが必要です。

また、低速な信号はクロックエッジなどを見ておけばいいのですが、昨今の高速なイメージセンサーのデータを受信するには、配線遅延やそのバラツキや個体差や温度変化や経年劣化での変動を意識する必要があります。

本記事では今回はそのあたりにフォーカスしていきたいと思います。

配線遅延への対応

以降はFPGAメーカーによってできることも変わってきますが、配線遅延への主な対処方法として

• クロックを受信するピンの遅延タップを調整する
• データを受信するピンの遅延タップを調整する
• 受信したクロックの位相をPLLで調整する

と言うものがあり、特にデータの遅延タップ調整はデータ線個別に調整することもでき、基板の配線を等長配線しただけでは取り切れない細かなバラツキまで対応できます。

また、これらの遅延調整も

• 製造後の基板に合わせてソフトウェア設計時に値を決定し固定する
• 運用時にイメージセンサ起動の度に自動調整を行う
• イメージセンサ起動後も適応的に自動調整しながら動く

などなどあり、イメージセンサーの方も、起動時やブランキング期間で調整の為のトレーニングパターンを出力できるものもあります。

これらをどこまで拘って実装するかは、すべてRTLで記述できますのでプログラマの腕次第で様々なレベルで実装可能です。
もっとも、FPGAベンダーが提供するIPやアプリケーションノートのサンプルがそのまま使えるケースも多いので、それらをそのまま使う事も多いです。
一方で、リソースの節約や電力削減であったり、移植性の確保であったり、様々な理由であえてそれらを使わずに自分でRTLを書くこともあります。

自動遅延調整の考え方

ここから先は少し具体的な説明も行う為に必要に応じて AMD(Xilinx)の 7シリーズの仕様も引用します。ただし他のFPGAでも基本的な考え方は応用できると思います。

トレーニングパターンがある場合

トレーニングパターンがある場合は比較的扱いが簡単です。また SERDES を使う場合のアライメント探しに bitslip などの調整もここで行う事が多いです。場合によっては極性反転の自動検出なども可能です。

イメージセンサーの多くは SPI や I2C などのインターフェースで制御できますので、レジスタ仕様を見ながらまずはトレーニングパターンが出力されている状態まで設定します。
私は基本これらの制御もRTLで書いたり、マイコンを使いがちですが、こんなのやこんなのを使って開発するのもよく見かけます。

とにもかくにも「今こういうパターンが受信されるはず」という状態になれば、あとはPLLの位相や遅延タップなどを変動させてそのパターンが受信できる範囲を調べ、範囲の中央に位相調整します。

例えば 7シリーズの MMCM の場合 UG472 を見ると、下記のような信号が見つかり、位相調整が行えます。この調整機構の素晴らしいところは運用中にも動かしたまま微調整が出来る事で、適応的な調整も可能です。

また遅延タップに関してはUG471に IDELAYE2の記載があり、各I/Oに配置されているIDELAYE2を信号が通るように適切に記述したのちに、同じように遅延調整ができます。

なお、IDLEAYE2 を利用するには別途 IDELAYCTRL に基準クロック(200MHz)を供給しておく必要があります。これは基本的には IDELAYCTRL インスタンスを生成してクロックを接続しておけばOKですが、利用するI/Oを限定して最適化したい場合は IODELAY_GROUP などの属性でコントロールできます。7シリーズのライブラリガイドを参照ください。

トレーニングパターン無しで調整する場合

決まったトレーニングパターンを出す機能が無い場合、受信した値が正しいのか化けているのかデータだけでは判定できないため、もう少し複雑な方法で調整を試みることになります。

このレベルの調整が必要となる高速信号では LVDS などの差動伝送が使われるケースが多いですが、IDLEAYE2 などの調整可能な遅延タップはシングルエンド利用も加味してI/Oの数だけ存在する為、差動ペアの受信時には１つの信号に IDLEAYE2 を2個使う事が出来き、XAPP1017 から引用すると下記のような構成が可能です。

1つの差動受信(IBUFDS)からの受信を2つの遅延量設定の異なる IDELAYE2 を通した後に同様に ISERDES でデシリアライズして比較することが可能になります。
この時、信号のEye(綺麗に0/1を判別できる範囲)が十分開いており、調整マージンが一定量ある状態を仮定すると Master 側の IDLEAY の調整範囲に十分なマージンが取れている状態では Slave 側の IDLEAY を多少 Master とずらしても同じ値が得られるはずですし、異なる値が得られる場合は少なくとも何らかの調整が必要な状態にあることがわかります。したがってオール0やオール1などの、差が取れないデータを除外したのちに Slave側 との値を比較しながら自動調整を行う事が可能です。
運用方法も様々で、ある程度必要なマージン幅やEyeの幅が既知であれば、Master と Slave の遅延差を一定幅になるように設定し、Slave側が一致するかしないかの境界に来るように、例えば一致すればPLL位相を遅らせ不一致なら進めるといった適応制御も可能です。

bitアライメントのやりかた

ここまででデータを適切なタイミングで取り込めるようになったとして、次にbitの区切りがどこにあるのかと言うアライメントの調整があります。
AMD の SERDES だと bitslip という信号があり、デシリアライズするときの区切りをずらしていくことができます。

トレーニングパターンを使う場合は、目的のパターンになるまで bitslip を繰り返すことになります。そうでない場合でも、SYNCコードなど絶対にそのbitパターンはそこでしか現れないようなコードが用意されている場合など何らかの方法でbitの区切り位置を満たしすまで、カウンタを用意して、タイムアウトするまでに目的のコードが取れなければ bitslip させます。
また贅沢にバレルシフタを置くようなことも可能で、あらかじめシフトさせたマッチパターンを複数用しておいて並列比較してSYNCコードを見つけてその順に後から並べ替えてしまうような方法も取れます。この方法だと捨てるデータが発生しないため毎ラインの先頭で再アライメントしないといけないようなケースにも対応できます。

もう一つ、逓倍クロックを用いる場合は、クロック信号自体がアライメント位置を表すケースもあります。7:1 アライメントなどが有名で XAPP585 などに詳細があります。
ドキュメントを引用させてもらうと下記のようになっており。

Received Clock の位相からどのビットがワードの開始かを知ることができます。このやり方の場合、クロック自身もPLLに入力するだけでなく、ISERDESに入力するパスを持ち、クロック波形パターンを見ることになります。

7:1方式はディスプレイパネルなどでよく使われるようですが、カメラでも CameraLink などの仕様で見かけることができます。

(余談) set_input_delay などの設定

外部同期の信号の受信にあたって sdc ファイルなどに set_input_delay などの制約を書くことをご存じの方もおられると思います。実際にこれらの設定はしばし重要です。

一方でここまでの話を見て気づいた人もおられるかもしれませんが、AMDの7シリーズの場合、IDELAY や SERDES や PLL/MMCM などや、クロックバッファ(BUFIO/BUFR)などは、ハードウェア的に決まった場所にしか存在せず、今回のような使い方だと RTL を書いた段階で利用されるリソースが一意に確定してしまう為、合成器や配置配線ツールにはなんら頑張る余地がないケースがあります。
そうなると set_input_delay の設定は結局のところワーニングを抑止するための気休めのようなものになってしまうケースもあるように思います。

イメージセンサーの設定の制御

イメージセンサーで設定できるものは多岐にわたりますが、FPGAからの制御で重要なものとして大きく

• シャッタータイミング(露光時間)
• 撮影パラメータ(ROI/ゲイン/黒レベルなど)

の２つです。

シャッタータイミングの制御

シャッタータイミングの調整と言うと普通の写真の撮影においては自動露光調整や、高速シャッターと長時間露光を組み合わせたHDR撮影などが思い浮かぶと思いますが、マシンビジョンも範疇に入れるともっと様々な使い方ができます。

多くのグローバルシャッターカメラは、FPGAからかなり厳密にシャッタータイミングを入力することが可能で、これは照明などの制御と連携することで様々な特殊撮影やアクティブセンシングを可能とします。
これは本当に様々なことが可能で、ストロボ照明のフレーム単位でON/OFFを繰り返して撮影して差分を取れば背景光を削除できますし、左右のストロボ照明を交互に点灯させれば照度差ステレオも可能です。さらには高速度カメラなどでマルチスペクトル照明での撮影も可能です。
他にも、カラーカメラを使い１つの露光区間で R-G-B のストロボ照明を順番に発光させた場合、１枚の画像の中で、R画素、G画素、B画素はそれぞれ少し時間のずれたタイミングを撮影していることになりますので、１枚のフレームに３つの時刻の撮影が重畳出来たりもします。

またこれらは、固定的に行うのではなく、前のフレームの画像処理結果に応じてさらに適応的に次のフレームのセンシング内容を動的に変化させることも可能です。

撮影パラメータの制御

撮影パラメータはSPIやI2Cで設定することが多いですが、決まった時刻までに設定しておくことで次フレームの撮影時に反映されます。
これもFPGAであれば極めて容易に時間保証できますので、２つ前のフレームの画像処理を使って、次のフレームの設定を動的に変更することが可能です。

オーソドックスには、自動ゲイン調整などですが、センサーによってはもっと大胆にROI(センサーの一部だけ読み出す機能)の位置を変えたり、フレームレートを変えたりすることもできます。

実際のイメージセンサーの事例

オンセミ社 PYTHON300の概要

ここでは私が開発しているオンセミ社のPYTHON300イメージセンサーとAMD社の Spartan-7 FPGA を組み合わせた、グローバルシャッターMIPI高速度カメラ を例に説明したいと思います。

早速データシートを眺めてみると、１ページ目のからさっそく

• PYTHON 300: 640 x 480 Active Pixels
• 4 LVDS Data Channels
• 815/545 frames per second @ VGA (ZROT/NROT)
• Each channel runs at 720 Mbps

などの、なかなかワクワクする単語が見受けられます。
VGA(640×480)という小さいサイズながら、815fps などの撮影が出来てしまうようです。

インターフェースとしては 4チャネルの LVDS があり、それぞれ DDR で 720Mbps のデータを出してくるようですね。トータルで 2.88Gbps の帯域があることになります。

起動と終了

イメージセンサーを利用するには起動と終了が重要です。PTHON1300シリーズのデータシートにもちゃんと記載があり下記のような記載がありました。

今回は各電源系とEN信号をFPGAに繋ぎ、クロックもFPGAから供給するようにして、この部分の制御もすべてFPGAで行いました。
正しい手順で起動／終了すればこれでも十分なのですが、「いきなり電源を抜く」というパソコンなんかでもやってはいけない事をやると、違反となり、破損の可能性が出てきます。
そこで念のため別途入力電源を見張ってPGOOD信号を生成して、電圧低下を感知した時点で Power Down シーケンスが強制的に走る仕組みも入れました。FPGAのコア電圧自体は1.0Vなどですので、I/O電圧が下がり始めてもしばらくの間はバイパスコンデンサに溜まっている電力で動作できます。システム全体としてある程度コンデンサ容量を持っていれば保険になります。
（もっとも、今回のカメラを接続する対象は ZYBO や KV260 など、SDカードで Linux を動かすシステムですので、そもそも突然の電源切断はそちらにもダメージを与えてしまいますので、正しくON/OFFすべきなのですが)。

SPIからレジスタを読み書きしよう

世の中のイメージセンサーの中には電源を入れると早速映像を出し始めるものもありますが、多くのイメージセンサーは適切な値を制御レジスタに書かないと起動しません。
PYTHON300の場合は SPI 端子からレジスタの読み書きができます。
データシートにもきちんと読み書きの波形が記載されています。

9bitのアドレスと、Write/Read判定の1bitと、16bit のデータを使う通信のようです。
このような通信回路を書くのはFPGAの得意とするところですので、RTLの勉強にも最適です。

SPIからレジスタに様々な値を書くことで、イメージセンサを起動させたり、トレーニングパターンを出したり、撮影範囲(ROI)や、露光時間、ゲイン、フレームレートなど様々な設定が行えるようになります。

オンセミ社PYTHON300センサーを調べてみる

はじめに当サイトでは現在、オンセミ社様のPYTHON300というイメージセンサーと Spartan-7 FPGA を組み合わせて、KV260 向けにグローバルシャッターの高速度カメラモジュールを開発中です。ようやく少し動き始め、撮影を行った...

rtc-lab.com

2025.08.05

なお、SPIでのレジスタ設定をRTLだけですべて書くことも可能ですが、今回のカメラはZYBOやKV260にMIPIケーブル経由で接続する構成にしていたので、LinuxからまずI2C経由でカメラにアクセスして、そこからさらに上記のSPI仕様でアクセスできるように作りました。ただ Spartan-7 と別FPGAの通信は今回の記事の範疇ではないので割愛いたします。

高速映像信号を受信しよう

センサーには8bitモードと10bitモードがあるようですが、今回は 10bit モードに設定して使う事にしました。この場合720MbpsでSERDES後のデータが10bitになります。8bitモードではその場合は 576Mbps になり結果的に同じピクセルレートのようです。またデータの 4ch の他に、今どのようなデータを出力しているかを出力してくれる SYNC というチャネルがあり LVDS としてはクロック1レーン、データ5レーンを受信することになります。

そしてこの値はSPIからレジスタを操作して順に起動していくと、デフォルトではトレーニングパターンとして 10’h3a6 というコードを繰り返し出してくれるようです。トレーニングパターン自体をSPIから別のコードにすることもできるようですが今回はこのまま使います。

720Mbps というのは決して遅くはないですが、基板設計がしっかししていれば4本チャネル個別調整するほどでは無さそうです。
なお Spartan-7 は LVDS を受信するための内部の100Ω終端を持っていますが、これはI/O電圧が2.5Vの時に使えます。今回私は3.3Vのバンクで受信する必要があったためFPGA外部に100Ωの終端抵抗を実装したボード設計としました。

Spartan-7 は受信したクロックを BUFIO でサンプリングクロックとして利用し、BUFR で分周クロックを作ることで、PLL や MMCM を使わずにクロック同期のSERDES受信回路を作ることができるようになっています。UG472 から引用した図が下記です。

各I/Oブロックの中のISERDESのサンプリングクロックにBUFIOからのクロックを使い、SERDES後の分周クロックにBUFRからのクロックを使えます。BUFRは1～8までの分周機能があるのですが、今回 DDR なので 5分周すれば丁度 1:10 にSERDES した際の 72MHz を生成できます。

この際、クロック入力の I/O ブロックの中にある IDELAYE2 ユニットを通すことで、クロックに遅延を加えることができます。
トレーニングパターンとして 10’h3a6 が安定してとれる遅延量を探索したところ0だと稀にダメで、1～ 15 個の間の遅延タップ挿入でトレーニングパターンが受信できました。当然ながらマージンが最大となる中央の 8 に設定しました。

シンクコードを判定して AXI-Stream に変換する

映像信号には映像部分の他に、垂直ブランキングであったり水平ブランキングなども含まれます。また多くのイメージセンサーでは黒レベル補正の為に、物理的に黒塗りされた画素領域(Optical Black)の読み出しが含まれるものも多いです。
(今回は使っていませんが PYTHON300の場合は複数のROI設定も可能なようです)

これらの今出ているデータが何を示すかは、イメージセンサーによって仕様が異なり、垂直同式信号や水平同期信号を別の専用線で伝えるようなものや、映像データと同じ信号線の中にエスケープシーケンスのように専用のコードを埋めるものもあります。
PYTHON300 の場合は 先に述べた SYNC 用の専用のLVDSチャネルから今データチャネルに何が出ているかを示すコードが出力されるようです。

データシートにも下記のようにいろいろ記載されています。

とはいえここまで動けば実機でも試せますので、論よりRUNで実際にILAを埋めて覗いてみると結果として下記のようになるようです。

なんだかフレームエンド信号がデータシートと違うような気もするのですが勘違いでしょうか？
こういう場合、実機を見るとデータシートの読み方を間違えていたのに気付けるケースや、データシートの誤記を見つけてしまったりもあるので、すぐに実機で試せるFPGAの良いところかと思います。

なお私はこの信号を早々に AXI-Stream に変換してしまいました。AMD(Xilinx) では、映像信号を AXI-Stream で扱う IP が多く、AXI-Stream にすると何かと便利です。説明はこちらなどにありますが、要は valid/ready でハンドシェークしつつ、フレームスタートを tuser、ラインエンドを tlast で示すようにしています。
valid/ready のハンドシェークは、FIFOでクロックを載せ替えたり、AXIバス経由でメモリと読み書きする際にも便利です。

画素を並び替える

これでやっと映像信号になったかと思いきや、さらにPYTHON300固有の処理として画素の並べ替えの必要があります（これはおそらく高速度撮影向けにROIをラインだけでなくカラムを制限した場合でも読み出し面積に応じてフレームレートを上げられるように工夫された結果ではないかと予想しています）。

当然データシート通り入れ替えればいいのですが、ここはFPGAらしく実際に並び替え前の状態で絵を撮影してみて確認しながらコードを書くことにしました。
AXI-Streamまで持ってこれたあたりで、既存のIPなどを使って画像をメモリに溜めて何とか読み込んで表示するようなことができるようになります。
ここは本記事では解説しませんが、「イメージセンサーの制御はしたことが無いが、HDMIなどの画像受信はやったことがある」みたいな方は、きっと手元に画像を表示するためのRTL資産がある事でしょう。そうでない場合でも大きな「FPGAを持ってきて信号をILAで数ライン溜めて、CSVに保存して Python で映像化」とか、「HDMIで出力してUSBビデオキャプチャで映像化」とかいろいろテクニックがあります。

話を本題に戻すと、とにもかくにも実際の映像を見ながら並び替えを試行錯誤することが出来ました。当然これがASIC設計なら一発勝負となるわけですが、FPGAだとトライアンドエラーを繰り返すことができるのでデバッグがとても楽です。

露光タイミング制御

この辺りからが FPGA でイメージセンサを制御する醍醐味になってくるのですが、多くのグローバルシャッターイメージセンサーでは露光タイミングをFPGAから制御することができます。

• ロボットの位置や、別のセンサーが反応した瞬間など外部タイミングでシャッターを切る
• 逆にシャッタータイミング時のロボットの位置や他センサーの値を画像に紐づけて保存する
• 露光タイミングの中で照明やレーザーやパターン照射などを動的制御する
• フレームレートや露光時間に変調を付けて特殊撮影をする

などの応用ができます。

例えば、回転しているプロペラを避けて隙間だけでシャッターを切るとか、きまったブレードだけを移し続けるとかも可能です。
ロボットなどで、シャッターを切った時刻のサーボモーターのエンコーダー値を記録しておけば、いつどこでどういう状態を写した画像かわかるので、動きながら補正を行うのに活用できます。
他にも照明と連動させることで、マルチスペクトル撮影をしたり、照度差ステレオ撮影や、場合によってはパターン投影を行ってストラクチャードライト計測なども可能です。

これらはグローバルシャッター＋FPGAカメラの応用の賜物です。
特にFPGAで画像認識まで行う場合、コマ落ちすることもなく毎フレーム決まった時刻に処理結果を出力することもできますので、画像処理結果を他の機構のフィードバック制御に使う事もできます。特にPYTHON300は少しROIサイズを絞れば1000fps撮影以上の計測も可能ですので、多くの用途に利用可能です。

おわりに

結構長文になってしまいましたが如何だったでしょうか？
折角RTLを覚えたのでRTLでしか出来ないプログラミングをしてみたい方 イメージセンサー＋FPGAの構成を自分で作ったり、そういう基板を買ってきたりして、自分だけの特殊素撮影制御のできるマシンビジョンカメラに挑戦してみるのも楽しいと思います。

特にイメージセンサーは出力されるデータ量が膨大ですので、FPGAで処理するのにとても向いています。
イメージセンサーのデータシートを読み解きながら、時には書いてないことを自己解析しながら、プログラミングを行う事は大変なことではありますが、それだけ真似するのが難しいことでもあります。
まだ誰も見たことが無いものを見てみたいから、そのためのカメラを自作するというのは新規性のある研究開発の第一歩になります。
案外世の中には「ある刺激を外から与えて、特別な波長を当てて、ある一瞬でシャッターを切るという事を繰り返して重ねると初めて見えてくるもの」なんて沢山あります。

RTLとFPGAで、新しいプログラミングの扉が開くことを期待して、終わりにしたいと思います。

以前、AXIバス や AXI Stream などで使われている valid/ready 方式のハンドシェークについて、下記のようなブログを書きました。

組み込み屋の為のVerilog入門 その5 VALID&READYのハンドシェーク

＜はじめに＞ 最近はXILINXが各コアでAXIバス(ARM社AMBAバス仕様の１つ)を使い始めていることもあって、VALIDとREADYでのハンドシェークを用いることが増えてきた。 この方式に限った話ではないのだが、バスプロトコル関係のハ...

rtc-lab.com

2012.09.11

一方で相変わらず、Verilog 初学者が嵌りやすいポイントであると思っています。
RTL記述が適している一直線に処理できるパイプライン処理は比較的わかりやすいのですが、ready 信号と言うバックプレッシャーの仕組みが入ったとたんに難易度が上がります。そしてなまじシンプルなので理解はできるのですが、なぜか実装するとバグるというのを私自身経験しましたし(というか今でもバグ書きますし)、ここ20年ぐらいFPGAを薦めた非常に多くの皆様を苦しめている気がしています。
とはいえCPUの命令実行のストールなどもっと面倒なバックプレッシャー処理は山ほどありますので、最初の一歩としてとても重要になります。
そこで、改めてもう少し深堀しながら、今度は回路図を書くのではなく、ソフトウェア的フローとしてコードを眺めながら何が難しいのか見ていこうと思います。

SystemVerilog超入門: はじめて学ぶハードウェア記述言語

篠塚 一也

Amazon楽天市場

Amazonの情報を掲載しています

valid/ready 制御を深く見てみる

状態遷移表を書いてみる

何らかのマスターデバイスとスレーブモジュールがあり valid/ready のハンドシェークでマスターからスレーブへ次々とデータを渡していくことを考えます。
その際のルールは下記のようなものです。

• マスター側は送りたいデータがあるときは データとともに valid を 1 にする
• スレーブ側はデータが受付可能なときに ready を 1 にする
• マスター側が valid を 1 にするか否かの判断に ready を使ってはならない
• クロックエッジが来た段階で valid と ready の両方が 1 であればデータ転送成立とする
• マスター側は valid を 1 にした後は、データ転送が成立するまで valid も data も変化させてはいけない

などです。
で、このルールで状態遷移表を書いてみようとしたら案外悩みました。

理由としては、マスターとスレーブはそれぞれ独立して設計するにもかかわらず、両方の状態を加味しないとインターフェース部分の valid と ready の次の状態が決まらない というところにある気がします。
これでは、マスター側を設計するときにどうすればいいのか、スレーブ側を設計するときにどうすればいいのか、独立した設計に落とし込むのが難しい気がします。
また、バスアービタのように複数の接続を調停する場合など、遷移表はなかなか複雑になりそうな気もします。

組込みエンジニアのための状態遷移設計手法―現場で使える状態遷移図・状態遷移表の記述テクニック― (MBD La…

久保孝行

Amazon楽天市場

Amazonの情報を掲載しています

具体的なサンプルを書いてみる

少々無理のある想定だよなと思いつつも下記のような２つの例を書いてみました。
マスター側は「データがあれば送信を要求」し、受信側は「busyでない、もしくは、データが2なら受け付ける」と言うものです。

module master(
            input   var logic           clk     ,
            output  var logic   [7:0]   data    ,
            output  var logic           valid   ,
            input   var logic           ready   
        );

    always_ff @(posedge clk) begin
        if ( !valid || ready ) begin
            if ( 次のデータあり ) begin
                data  <= 次のデータ;
                valid <= 1'b1;
            end
            else begin
                data  <= 'x;
                valid <= 1'b0;
            end
        end
    end

endmodule

module slave(
            input   var logic           clk     ,
            input   var logic   [7:0]   data    ,
            input   var logic           valid   ,
            output  var logic           ready   
        );

    logic           busy    ;   // 受信不能
    logic           rx_en   ;   // 受信データ有効
    logic   [7:0]   rx_data ;   // 受信したデータ
    always_ff @(posedge clk) begin
        busy <= 次の状態;
        if ( valid && ready ) begin
            rx_en   <= 1'b1;
            rx_data <= data;
        end
        else begin
            rx_en    <= 1'b0;
            rx_data  <= 'x;
        end
    end

    assign ready = !busy || (valid && data == 2);

endmodule

module master(
            input   var logic           clk     ,
            output  var logic   [7:0]   data    ,
            output  var logic           valid   ,
            input   var logic           ready   
        );

    always_ff @(posedge clk) begin
        if ( !valid || ready ) begin
            if ( 次のデータあり ) begin
                data  <= 次のデータ;
                valid <= 1'b1;
            end
            else begin
                data  <= 'x;
                valid <= 1'b0;
            end
        end
    end

endmodule

module slave(
            input   var logic           clk     ,
            input   var logic   [7:0]   data    ,
            input   var logic           valid   ,
            output  var logic           ready   
        );

    logic           busy    ;   // 受信不能
    logic           rx_en   ;   // 受信データ有効
    logic   [7:0]   rx_data ;   // 受信したデータ
    always_ff @(posedge clk) begin
        busy <= 次の状態;
        if ( valid && ready ) begin
            rx_en   <= 1'b1;
            rx_data <= data;
        end
        else begin
            rx_en    <= 1'b0;
            rx_data  <= 'x;
        end
    end

    assign ready = !busy || (valid && data == 2);

endmodule

動作例としては例えば下記のような感じです。

マスター側は input は ready しかないのに、valid を 1 にするのに ready を見てはいけないルールなので、自己都合だけでデータがあれば valid を1にする動作しかできません。
そして、valid を 1 にした後にやってくる次のクロックエッジ時点で ready も 1 なら受け付けられたことになります。つまり valid を 1 にした後にそれが受け付けられたかどうかを知るのはその次のサイクルになります。

次にスレーブ側は自己都合の busy を 1 や 0 にするようにしてますが、ここがややこしいところで、スレーブ側は valid を見て ready を作っても良いルールです。なので assign 文などを使って組み合わせ回路で、「busyでない、もしくは、データが2で ready = 1」というようなコードが書けてしまいます。
実際、波形を見てもらうと data = 2 の個所では、busy = 1 なのに ready = 1 になっています。

フローチャートを書いてみる

ここでおもむろにソフト屋っぽく、マスター側とスレーブ側でそれぞれ分けてフローチャート的なものを書いてみることを試みます。
なお SystemVerilog の場合、ある時刻のタイムスロットの処理で、ACTIVEリージョンで代入予約だけ行って、NBAリージョンで実際に代入されるというような事が起こるわけですが、そのような挙動は理解の上で、ノンブロッキング代入を読んでください。

まずマスター側を見てみますが、先ほど valid を 1 にした後にそれが受け付けられたかどうかを知るのはその次のサイクルと書きました。なので @(posedge) でクロックエッジを待ってから受け付けられたかどうか判定して分岐するフローチャートにしています。
もちろん SystemVerilog の文法上、always_ff の先頭でイベント待ちするわけですが、解釈的にはここに持ってきて読み替えた方がわかりやすかったので移動させてみました。
「無限ループなのでどこから書き始めても等価でしょ」という乱暴な書き方をしております。
（ある意味 @(posedge clk) は CUDA の __syncthreads() みたいなものとも言えるかもしれません。）

次にスレーブ側ですが、こちらもデータの受付に関しては、とにかくノンブロッキング代入で取り込んで、「valid と ready の両方が1だったならその時のデータ有効だよ」という後付け判断をしておりこれが一番簡単です。
ただし、スレーブに関しては valid に依存して ready を作っていいことになっていますし、こちらが ready をどう弄ろうが valid に変化が起こらないことが保証されています。なのでクロックエッジを待たずに、次のエッジでは必ずvalidとreadyが1になるようにするという次のクロックエッジを待たずに起こる事象を確定して別の信号を作り始めるような制御も出来てしまいます(今回のSystemVerilogのコードにはいないですが)。

ある意味でスレーブ側の方がマスター側よりわかりやすいのですが、ポリシーが違うため、例えばバスアービタなどの同じモジュールにマスターもスレーブも入っているのを書くときにとても混乱するわけです。

おわりに

定期的に valid/ready は記事にしたい欲求の波がやってくるのですが、今回もまったくもってうまく説明出来た気がしません。うまい表現方法が出来ないという事は私もまだ理解しきれていないのかもしれません。
分かってしまえばなんてことは無いような気もしますが、今の段階でも嘘書いてる部分や間違ってる部分がありそうでドキドキしてますが、とにもかくにも valid/ready の壁に悩んでいる初学者の気づきになる事が１つでも書けていたらいいなと思う次第です。

あとまあ、AXIやAXI-Streamなどが扱えて valid/readyに悩まなくて済む高位合成言語(HLS)が流行る理由の一つでもあるのかもしれないななどとは思いました。

高位合成によるFPGA回路設計

長瀬雅之, 岩渕甲誠, 田中亮佑, 川口敦史, 松本茂樹, 梶原信樹, 田中悠一朗, 田向権

Amazon楽天市場

Amazonの情報を掲載しています

追記的まとめ

Xなどでも少しご意見いただきつつもう少し深く考察してみたところ

• 厳密に言うとFFの値が状態で、イベントはクロック立ち上がりただ一つだが、それだと状態遷移表はただの１列の縦長の表になるだけで状態遷移表の意味合いが薄れる。
• なので、クロック時の入力変化をイベントとみなすが、そうすると、真の意味で同時にいろんなイベントが起こる。これは、mutexやスピンロックなどの排他制御も含めた、イベントを１つずつ処理する(イベントは同時に１つしか起こらないとみなせる)CPUなどでの処理と本質的に異なる。
• さらにクロック時の入力変化のみをイベントとすると、組み合わせ回路で次のクロックを待たずにアクノリッジを返してくる相手に、モジュールに閉じた表が書けなくなる(表にあるイベントと別のところで状態遷移先に分岐条件を作ってしまう)。

などがある気がします。
Verilog の always 文は、CPU での処理だと、タイマ割り込みハンドラに近いものはありますが、真の意味で同時に動いており、時間を待つというよりも、他の always文との同期の意味が強いです。文中、CUDA の __syncthreads() と書きましたが、OpenMP の #pragma omp barrier や、あとはあえて言うなら join() などが近い程度で、他に似た機能があまりCPUの世界にはないような気がします。
この辺りが、CPUのプログラミングから、RTLのプログラミングに入ってくる人の一つの敷居になってる可能性はあるのかもしれません。
まあ、GPUプログラミングを始めるときの別の意味での敷居がありますし、綿らしいプログラミングパラダイムを覚えるの少なからず難しいものが出てくることがあるのだなと思う次第です。

10月24日発売予定

Interface 2025年12月号の別冊付録にて、Tang Mega 138K Pro Dock にラズパイカメラの IMX219 をステレオで取り付ける記事を書きました。

Interface(インターフェース) 2025年12号

Amazon楽天市場

Amazonの情報を掲載しています

KiCAD で作った変換基板にて、ラズパイカメラのカメラモジュールを Tang Mega 138K Pro Dock に接続し、ステレオ撮影した２系統の動画を HDMI 経由でディスプレイに表示するところまでの開発体験談を記事にさせて頂いております。
付録雑誌ではありますが、書店で見かけることがあれば是非手に取ってみてください。あわよくば買ってください。
こちらの目次の第３部の「独自MIPIカメラ・モジュール製作挑戦記」を書かせて頂いております。

ソースコード、変換基板の設計データなど

設計データは GitHub など下記に置いております。また自分で基板作るのが大変な方は私の方で余分に作った若干数をBOOTHにて販売中です。

• Tang Mega 138k Pro で IMX219 をステレオ表示するプロジェクト
• KiCADの基板設計データ
• 忙しい人の為の変換基板のBOOTHへの出品

また変換基板は当ページでも下記に記事にしております。

Tang Mega 138K Pro Dock 用 IMX219 MIPI 変換基板

試作開発したものを下記でBOOTHに出品しております。Tang Mega 138K Pro Dock 用 IMX219 MIPI 変換基板Tang Mega 138K Pro Dock 用 IMX219 MIPI カメラ基板(イメージセンサ...

rtc-lab.com

2025.07.21

Tang Mega 138K Pro Dock の紹介

Tang Mega 138K Pro Dock の詳しい仕様はこちらです。
安くはありませんが、MIPIコネクタ含めて、付いている機能などを考えるとかなりコスパの良いボードかと思います。

Sipeed Tang Mega 138K Pro Dock Gowin GW5AST RISCV FPGA AIボード ギガビットイーサネット、SFP+、PCleイ…

Amazon楽天市場

Amazonの情報を掲載しています

Sipeed Tang Mega 138K Pro Dock Gowin GW5AST RISCV FPGA AIボード ギガビットイーサネット、SFP+、PCleイ…

Amazon楽天市場

Amazonの情報を掲載しています

去る2025年7月30日にパナソニック コネクト株式会社様に浜離宮ビルの本社にお邪魔してコネクトタレントコミュニティさんのラジオにアルムナイ枠で出演させて頂きましたので、微力ながら宣伝とともにブログ記事にさせて頂きます。

リモート時代になりいろいろなところでしゃべる機会は増えてはいたのですが、きちんとしたスタジオで撮影も合わせての収録と言うのは初体験でして、お恥ずかしい部分も多々ありますが、総じてとても楽しい思いをさせて頂きました。

当日はゆっくり行ってブログ用に浜離宮ビルの写真とかも撮ってこようとか企んでいたのですが、時間ギリギリに駆け込むことになってしまいました。実はこの日、カムチャツカ半島付近でマグニチュード８.７の地震があった日でして、全国的に津波警報など出ていて交通がやや混乱していて思った以上に移動に時間がかかってしまいました。
ということで立派な浜離宮ビルの写真は無いのですが、ご厚意でスタジオ内でブログ用に記念写真撮らせて頂き、写っている皆様からもSNSやブログでの利用を快諾頂きましたので、当記事のアイキャッチにさせて頂いております。

スタジオでは非常に和やかな雰囲気で「失敗しても編集でリカバリできますから、気楽にしゃべってくださいね」というお言葉に甘えつつ、後半いつものノリで大変楽しくしゃべらせて頂いてきました。

ラジオ出演で思った事

今回、アルムナイと言う企画から、キャリアプランと言う重要なテーマについて話をさせて頂きましたので、それに際して少し考えさせられたことなどを改めて少し書いておこうと思います。

時代の移り変わり

最初に知り合いにお声がけいただいたのは今年の6月ごろだったのですが、お話を頂いて時代も変わったものだと改めて驚かされました。終身雇用が当たり前の一昔前であれば、定年退職以外で辞めた人間に声を掛けるというのは、声をかける方も掛けられる方も気まずかったんじゃないかと想像します。こういったイベントをカジュアルに進められるのは、組織も人も変わってきたなと感じた部分です。

パナソニック コネクトと言う会社は、パナソニックグループの中にあってもその設立以来、良くも悪くも製造業からIT業に舵を切ろうとしている会社です。100年以上続く古き良き日本の製造業という歴史を根っこに持ちながらも、私が辞める少し前ぐらいからメンバーシップ型からジョブ型への切り替えもかなり精力的に行われておりました。人材の出入りに対してIT企業らしいカジュアルな対応ができる会社になったというのは、多少なり松下電器産業時代の昔も知っている人間からすると本当に時代の変化を感じました。

製造業からどう変わっていくのか

ラジオの中でも少し語らせて頂いていますが、いわゆるビッグテックと言われる会社などで、例えば Meta社が Questa を作ったり、Google が Pixel や TPU を作ったり、Apple が iPhone や アップルシリコン作ったりと言った、IT大手がハードウェアも作るというのは、今や誰もが知るところで成功しているものも多いかと思います。
一方で、ハードウェア作りにはどこにも負けないノウハウを持っているはずの日本の製造業がITをやろうとしてどういうわけかイマイチぱっとしない例というのは結構沢山あるのではないでしょうか。

完全に私見ではあるのですが、IT企業で成功しているところは、ハードウェアをソフトウェアの作り方で作っているように思っております。
逆にそれらにシェアを奪われ、停滞している事例の多くがハードウェアやソフトウェアを依然ハードウェアの作り方で作り続けている、言い方を変えると、作り手である人間の方の時代に合わせたスキルシフトが進まなっかった部分があるのじゃないかと思うわけです。
どこかの漫画で「フレンチのシェフがフランス料理として作ったなら、ご飯の上に卵をかけただけでもそれはフランス料理だ、フランス料理を作ろうとするな、フランス料理のシェフになれ」という趣旨のセリフを読んだことがありますが、まさにそんな感じです。
IT企業になりたければ大事なのは人間のスキルシフトや、思考のチェンジが必要だと思うわけですが、そういう人に関わる部分を果敢に変えていこうとしているのがコネクトという会社なのではないかと思います。

成功している「モノ作りもできるIT企業」みたいなものをゴールとして考えたときアプローチとして、少し極端な例ですが

1. 製造業をIT企業化する
2. IT企業の中でハードウェア開発に挑戦していく

の２方面からアプローチを考えてみると、パナソニックコネクトが目指しているのが１で、現在私がメインで身を置いているのが2の方になります。
これはどちらがいいとか悪いとかではなくどちらも利点欠点沢山抱えていますので、最終的にゴールにたどりつけるかどうかは組織や中の人が正しく自分の位置を把握し、ゴールに向かえるだけのポテンシャルを持っているかに掛かっているかと思います。
IT分野に活路を見出すのであれば、やはりジョブ型雇用のようなものは避けて通れないと思いますし、個人としてはその時その時で自分の力が活かせる方を随時選んで活躍すればいいと思ってしまうわけですし、企業の側としても必要な人材に選んでもらえる組織になる必要があります。
そういう意味ではマッチングと言うのは非常に重要な時代になっておりますし、中の見えるオープンな組織であったり、技術者の横のつながりであったり、なりふり構わず活躍できる場所を作ったり求めたりしてくことが大事なんだと思います。
私の場合、計算機の知識を活かしたいという想いが強く、さすがにコネクトで計算機作ろうとはならないでしょうから、結果オーライだった部分も多いですが、一つ思い切ってチャレンジしてみて視界が開けた部分もありますし、今後とも垣根を越えていろんな方と交流できればと思う次第です。

終身雇用が消えゆく時代の若者へエールを送りたい

私のようないい歳したおじさんが、役職にしがみ付いたまま「これからはジョブ型雇用の時代だ」と若者に言っても説得力ゼロですが、今回幸いにも会社を飛び出したばかりの立場なのでちょっとだけ書かせて頂きます。

これまたラジオの中でも少し話しておりますが、キャリアプランを考えたとき今の若者は本当に大変だと思います。何をするにも自己責任という言葉がついてまわります。
終身雇用の時代は良くも悪くも滅私奉公的なものを美徳とし「一生面倒見てやるから黙ってこれをやってくれ」と言えた時代であり、その反面、会社にとっては必要だが、個人にとってはその会社でしか役に立たないスキルというものに対しても組織として投資可能であり、ここから勝利の方程式を組み立てて高度経済成長に成功した時代でもありました。
一方で、残念ながらいろんなものコモディティー化が進み、従来のやり方では競争に生き残れない分野が多数出てきました。その結果の終身雇用の終焉であり、自己のスキルをどう磨き、どうキャリアを身に着けるかが自己責任になってきています。IT業界はその最前線にいるのではないかと思います。

とはいえ変化の激しいIT業界で活躍するのに必要なスキルを、人それぞれ自分の適性に合ったものを効率的に身に着けたい場合、ある程度個人の裁量で自由に動き、場を変え人を変え自分で自分を育てるというのは非常に理にかなっているとは思っております。
ただ、ここで最大の不安要因がAIなのではないかとは思う次第です。ここ10年のAIの台頭は目覚ましく、10年後にどんな影響を及ぼしているのか計り知れません。そんな社会的な大きな波が来ている中で、自己責任という言葉は若者に重くのしかかっているのではないかと思います。

色んなことを考えたり、悩んだりしないといけない若者も多いかと思いますが、キャリアを考えるうえで、マッチングと言うのは非常に大事ですので、社内外問わず、いろんな人と付き合って、いろんなところで自己アピールして、次は何を身に着けるか、次は誰と何をやるか、いろんな可能性を模索頂ければと思います。
私もなんだかんだで身に着けてきたスキルや人脈は何一つ無駄になってませんので、恐れずに如何にして活躍するかを大事に考えていただければと思います。
また、パナソニックコネクトのような会社には、是非ともこれからも時代に合わせた変化を続けて頂き、若者が自らを育てていくための大きな社会の器としての機能をより一層果たしてほしいと願う次第です。

おわりに

なんだか偉そうなこといっぱい書いてしまいましたが、私にとってもキャリアを見直したり、時代の移り変わりを再確認するとても良い機会を頂きました。

私が言うのもなんですが、就職を考えている新卒の方、転職を考えている方、パナソニックグループの中でも少し変わった風土を持っているコネクトを候補の一つとして調べてみては如何でしょうか？
また、私以外のアルムナイの方、とても楽しい体験ができますので、機会があれば是非後に続いていろいろなご意見を発信いただければと思います。

今回は、本格的なスタジオでの収録というめったにない貴重な体験をさせて頂きました。スタッフの皆様、サイコーでした！ 改めて感謝申し上げます。
また記念に頂いた 音波振動歯ブラシのDoltz もとても気に入っております。最後にこれを商品宣伝して本ブログの締めにしたいと思います。

パナソニック(Panasonic) 【2023年発売】パナソニック 音波振動ハブラシ ドルツ ハイグレードモデル W音波…

Amazon楽天市場

Amazonの情報を掲載しています

(追記) Webページにご紹介いただきました

積み重ねた技術力、つながりは裏切らない。「自分を試してみたい」とフリーランスの道へ - Connect Talent Community Hub - パナソニック コネクト採用サイト

パナソニック コネクト株式会社が開設する、アルムナイ（退職者）や内定辞退者、同社主催イベントの参加者など、過去に接点持っていただいた方や、同社に興味をお持ちいただいた多くの方々と、ゆるやかにつながり続けるタレントコミュニティ「Connect...

connect.panasonic.com

当方はリアルタイムコンピューティングをやることを主軸に計算機アーキテクチャやアルゴリズムを考える事をメインに活動しおります。とりわけFPGAを用いたアプローチは有効で、FPGAを使った Real-Time OS であったり、オプティカルフローのビジュアルフィードバックであったり、カメラの高速駆動など、様々な取り組みをしてきております。
これらはリアルタイム性は置き去りにしてスループットばかり追い求めるGPGPU分野などとは方向性の違うアプローチであり、ニッチな分野ではあれ、レッドオーシャンで戦う体力のない個人開発や小規模研究としては取り組みやすい分野でもあります。

ですので当方の取り組み自体にAIは必須ではないのですが、AIが出来て困ることもないので、リアルタイムコンピューティングの枠組みの中で使えるAIも検討しております。そういった中で LUT-Network というアイデアにたどり着き、BinaryBrain などをリリースさせて頂いたのをきっかけに「FPGAでAIがやりたい」という方々との交流も増えてきております。

FPGAでAIを行う場合のいくつかの種類があると思います

1. FPGAを前提としつつも、AIモデルや方式そのものに新規性/進歩性がある
2. AIモデルそのものには新規性はないが、計算機アーキテクチャに新規性がある
3. AIモデルにも計算機アーキにも進歩性はないが他との組み合わせ応用に新規性がある

などです。
ここで困ったことに、LUT-Network などが、比較的 1. の側面を持っていたために、リアルタイムコンピューティングを置き去りにしたままの議論になる事も多く、結果として何の新規性も生れてこない空中戦の議論に終始してしまう事も増えてしまっているようにも思います。
そこで、再度リアルタイムコンピューティングとAIを整理しておこうと思います。
基本的に画像認識などセンシングにAIを使う話になると思います。

コンピュータビジョン最前線 Summer 2025

井尻善久, 牛久祥孝, 片岡裕雄, 藤吉弘亘, 延原章平

発売日: 2025/06/10

Amazon楽天市場

Amazonの情報を掲載しています

リアルタイムにAIをやる価値

何度も持ち出す絵になりますが、わかりやすいパターンとしてCNN構造でのFPGAリアルタイム認識の絵を描きに示します。

非常に低遅延で画像処理できますし、当方はこれを1000fpsなどのハイサンプリングレートでアルゴリズム最適化しながら実施しますので、認識性能の向上と高い応答性の両立を狙っており、例えば攻殻機動隊の光学迷彩であったり、電脳コイルの電脳メガネみたいなものを実現しようとするとこれぐらいのものが必要になります。
FPGAではデバイスと演算器が同期動作できますので、カメラからフレームの最後のピクセルが読み出されるときに、そのピクセルが無いと計算できないこと以外並行して計算を先に終わらせておくといった変態じみたことが可能で、その効果が最大限出せるようにアルゴリズムと計算機アーキテクチャを組み立てます。

次に対局となるGPUの例を見ておきます。

まずCPUやGPUはロード/ストアアーキテクチャの宿命としてメモリにあるデータしか処理できません。加えて同期を行うにもコストがかかり、多くの場合フレーム単位などで同期します。
従って、カメラから最後のピクセルが出てきてメモリに１フレーム入ってから計算を始めるというのが基本スタイルです。
つまり、GPUが計算を始めるときには当方のFPGAはすでに計算を終えているというような事が起こります。

例えばカメラなどでセンシングする世の中のものは、動いてるものが沢山ありますので、計算している間に起る予測不能な現実世界の変化(モノの動きなど)はすべて計測誤差になります。
ようするに早く計算するだけで計測誤差が減るんですね。
そもそも交通事故を起こしてからブレーキ踏んでも間に合いませんし、そこまでいかなくとも工場などでも画像検査の為に、いちいち対象を一度固定して静止させる装置に余分なコストを掛ける事になります(なので人間に非人間的な作業をさせた方が安上がりになりがちです)。

ですので基本的に、速くではなく早く計算することにはそれ自体結構高い付加価値があるのですが、早い計算にはいろんな制約があるので、その制約の中で問題を解くアルゴリズムを考える、という事が重要で、この枠組みの中で出来る事を増やしていくというのはそれ自体に新規性があるわけです。
一方で、この枠組みの中でやってるという事の価値を正しく理解していただいてから会話をしないと「何が新規なのかさっぱりわからん」という事になりかねません。ですのでまず初見の方にはそういった説明から始めさせて頂いております。

リアルタイムAIの何が難しいのか

絶対的な演算量の問題

100倍早くする(応答時間を1/100にする)と当然ながら新規の入力から新しい出力の更新までに使える計算機パワーも 1/100 になります。これは認識率を上げるために計算量をどんどん増やしていくというGPGPUを前提としたモデル研究の真逆です。
一方で、下記で書いたような、認識対象のダイナミクスよりも高いサンプリングレートとすることで計算量低下をリカバリできるアイデアも沢山あるわけです。

リアルタイムRNNの考察

はじめに少し前に早稲田の学生さんとやり取りしていて、お絵描きしたのですが、埋まる前にこちらにも貼り付けて保全しておきたいと思います。以前下記の記事で書いた話の延長です。リアルで連続的な情報を使うという事従来CNNでは、ResNet にせよ ...

rtc-lab.com

2025.08.02

これらをうまく活用できるアルゴリズムを考案して、認識率低下を補っていくという事は、低フレームレートでは出来ないことですので、高応答性を目指すが故にできるメリット、としてアルゴリズムに組み込んでいく必要がありますし、新規性のある事項になります。

一方で、ここでしばし「従来のGPUのネットより精度下がってるじゃないか、新規性なんて無いよ」という査読者に当たってリジェクトされてしまうのは非常によくある話なので、Abstract はしっかり書きましょう、という話になるわけですが。

計算機アーキテクチャの難しさ

ではハイサンプリングレートを活かして少ない演算量で精度の出るモデル(アルゴリズム)を考えればそれでいいのかと言うと全くそんなことはありません。早いコンピューティングとして実装不可能なアルゴリズムになってるケースなんてしばし見てきました。特に下手に HLS(高位合成言語)に走った学生などに見られがちで、「それGPUで実行したほうが早い(応答性)し速い(スループット)よ」というものを、成果として自信満々に出してくる学生さんもしばしいらっしゃいます。

要するに計算機アーキテクチャを十分に理解してないまま、PyTorch や HLS の掌の上で踊らされながら、FPGA を活用した凄い研究をやってる気になってしまうというパターンです。
まあ、実利として言えば PyTorch が使えて HLS が使えれば、欲しい企業さんはそれなりに居そうな気もするわけですが、アカデミック分野でとなるとそれでは成果にならないわけです。
このあたりは「なんで就職せずに院やドクターに行くの？」という話にも繋がってくるのですが、学位を取ろうとされてる以上は研究観点での価値もちゃんと示さないなとダメなのではないかとは思うわけです。
(まあ、そういう私は研究者になりたいわけではなく早くエンジニアになりたかったクチなので、学士しか持ってないのですが、この歳になって修士や博士を取りたいという人のお手伝いをする機会を頂くという得難い経験をさせて頂いていたりするわけですが)

並列性に時間軸が入る難しさ

GPUなどの Memory-to-Memory の並列計算機であれば、アルゴリズムに計算種類や計算順序や計算タイミングなどは(FPGAと比べれば)あまり考えなくてよいです。とにかく命令キューに演算が積まれていれば空いてるプロセッサが次にやらなきゃいけない計算を割り当てて消化してくれます。

一方で、FPGAでのリアルタイムコンピューティングでは、現実世界と繋ぐ外部デバイスと同期したパイプライン演算が基本となってきますので

• データがどのような順で入ってくるか
• 出力までのクリティカルパスはどこか？
• どういう演算器を何個どのように配置するか
• 矛盾なくデータが流れ／演算器は十分に稼働するか
• データ分配や供給は破綻しないか
• メモリ容量は足りるか、転送は間に合うか

などなどの事を、タイミングチャート上でしっかりと思い浮かべながら、データフローとアルゴリズムを考えていく必要があります。

跡えば ResNet など残差ネット１つとっても、後で足しこむためのオリジナルを畳み込み計算している間に遅らせて届けるパスでリソース消費する、などの基本的なことを織り込んで考えられるア頭にしておく必要があります。

よくある失敗例として

• 例えば輝度平均と分散での正規化のような、フレームが全部そろわないと計算できないような処理をたくさん含めてしまう。
• リアルタイム処理しようとすると、すさまじい規模のクロスバースイッチ(マルチプレクサ)が生成されるようなコードになっている(ノイマン型のランダムアクセスがそのままできると思っている)
• 殆ど稼働しない演算器で埋め尽くしてしまう。例えばフレームの最後に一回１サイクルしか動かないところに巨大な行列ソルバーがいたりする
• 不必要に高精度で計算してしまう

などなど、「それGPUでやった方がいいよね」な、ストリーム処理できないアルゴリズムを書きがちです。
しかしこういう処理を含むコードでも、HLSに掛けるとCPUのような動きをするコアとして合成してしまうものだから、合成結果のリソース量だけ見て「FPGAに収まる新しいアルゴリズムが出来ました」と持ってきてしまったりしちゃうわけです。
そうなると、残念ながらGPUで実行したほう、早い速いし、従来のアルゴの方が精度がいい、とかで、何一つメリットがないなんてことになりかねないのです(せっかく新規性のある土俵を用意してたはずなのに、土俵の外で戦ってしまっていたと)。

改善方法としては

• フレームグローバルな処理は前のフレームの結果からの予測で代替する
• 入力画像のデータ順序を常に意識て前方参照しない方法を考える
• ハードウェアリソース規模を常に意識して演算量を見積もりつつ常に処理パイプラインを念頭に置いておく。
• ハードウェアコストが減るように数式を組み替えたり、パラメータを統合したりする。
• 精度低下を許容してでも、ハードウェアに優しい処理順序に組み替えることを考える
• ハードウェアコストの低い演算に置き換える／ハードウェアに優しい近似方法を考える
• 現実世界で本当に必要な精度を検討する

などなど、いろんな考え方が必要になります。

DDR4-SDRAMやカメラなど外部デバイス利用の難しさ

タイミング設計をしたり、計算精度を考えたりするときに、例えばカメラの感度だとか露光タイミングだとかSNRだとか、SDRAMの転送特性だとかデータ帯域だとか、これらをちゃんと把握しておかないと適切な設計は難しいです。
（逆にこの辺りは「カメラの特性に合わせて、各層の演算精度を INT1～INT16 まで細かく最適化する研究」みたいな新規性幾らでも出てきそうな分野なんですが、案外学生には人気なかったりもしますｗ）

特に SDRAM って結構罠でして、ありものIPを理解して使うにしても、AXI 仕様の概要ぐらいは知っておくべきですし、計算したいタイミングに合わせてデータ持ってこないといけません。
無駄に要求してもバスが詰まってシステムデッドロックしますし、不足すると間に合いませんし、良くも悪くも FIFOバッファとかクロックの載せ替えとか出てくるので、案外最低限必要なものの準備が大変です。なによりシミュレーション環境作る難易度が一気に上がります。
授業で icarus verilog でちょろっとシミュレーションしてレポート書いてただけのレベルだと、SDRAMを含んだシミュレーション環境作るだけでも一苦労かと思います。

このあたりはLEDチカチカから初めて、地道に「なんでもいいから動くシステムを作ってみる」を繰り返さないと身につかないところはあるので実践的ではあれど、なかなかハードルが高いところには思います。
特にアルゴリズム設計でデータパスをあれこれ考察する場合、実装可能で破綻しないメモリアクセス機構を組めるかどうかは意識しておかないといけないところです。

またカメラなんかのデバイスも、動的にROI(切り出し範囲)を変えたり、シャッタータイミングを変えたり、アルゴリズムと連携した制御、つまりはアクティブセンシング的な要素を入れていくとこれはこれで研究余地増えるんですが、ここもなかなかハードルが高いようですね。

AIモデル設計の難しさ

「リアルタイムアーキテクで実装可能なアルゴリズム」でありさえすれば、実際に実装までしなくとも十分な研究成果だとは思います。
なので、「AIやっていてFPGAに興味がある」という学生さんにはそちらをお勧めするのですが、出発点として「何が実装可能なアルゴリズムなのか？」が判断できることが重要です。
そのうえで設計するのであれば PyTorch などで研究しても全く問題ないわけです。
一方で発生することとして

• INT1/2/4/8, FP16/32 などGPUが得意な精度以外を多用することになる(補償するコードを沢山挟むことになる)
• PyTorch で用意されてない演算をベタ書きすることも増える
• 前のフレームを活用しようとするとリカレント構造になりがちなのでどうやって学習させるか悩むことになる
• 学習データの準備も特殊なものを自分で用意したり加工することになる

などになります。LUT-Netなんか最たる例ですが、PyTorchでGPUを使いながらあえて、GPUに苦手なモデルを学習させるという一見非効率なことをやることになるので、きちんとした理解のもと取り組む必要があります。
ちなみにリカレント構造はやはり難しいのでBPTTやそれ以外の学習方法を考えるとか、DNN自体はCNNなどに留めてい置いて、前後にルールベースアルゴリズムの拡張をする手もあります。
画像には向かない気はしています、リザバーコンピューティングなどもその一種でしょう。

このあたりもしっかりと自分が何をやってるのか理解して取り組まないと、

• 気づかないうちに想定以上の精度で計算してしまっていた
• 現実性のないデータセットを用意してし待っていた
• 学習が一向に進まない。GPUメモリが足りずに途方に暮れる

なんてことになりかねないわけです。

おわりに

まあなんか、ぐだぐだと駄文を書いてしまったのですが、ルールベースのリアルタイムコンピューティングだけなら案外誤解は起こりにくかったことが、AIを持ち込んだとたんに迷走する人が増えているように思います。

折角FPGAという他人とは違うものを使って差をつけようとしているわけですから

• GPUではなくFPGAを使う利点をどこに出そうとしているのか？
• それは何を評価すれば実証したことになるのか？
• それは本当にFPGAで実現可能か？
• 自分が実証したいことを証明するミニマムな構成とは何なのか？
• どうすれば自分のやっていることがGPUとは違う価値を持つことを簡潔に説明できるか？

など、どんな研究においてもいえる基本的なところを押さえてから取り組んで、是非是非高い成果を出してほしいと思うわけです。

普通のやつらの上を行け —Beating the Averages—

ハッカーと画家 コンピュータ時代の創造者たち

ポール グレアム

Amazon楽天市場

Amazonの情報を掲載しています

今回は久しぶりに家電修理記事です。例によって家電修理は自己責任でお願いいたします。
冷温庫とかミニ冷蔵庫とか電子冷蔵庫とかいろいろ呼び名があるようですが、いわゆるペルチェ式冷蔵庫の話です。

大学に行った娘が置いて行ったペルチェ式冷蔵庫(EENOUR CWP-20L)があったのですが、当初、下段が故障して冷えない状態になっており、ペルチェ素子の交換を行って私の晩酌を冷やすのに使っていたのですが、今回ファンが大きな異音を出すようになってしまいました。

買い換えようかとも思ったのですが、ちゃんとは調べてはいないものの、どうもペルチェ冷蔵庫も家電リサイクル法の範疇になるらしく、手間を考えると直した方が楽そうという結論に達して修理しました。折角なのでペルチェ交換とファン交換をまとめて紹介します。

EENOUR 冷温庫 20L ミニ冷蔵庫 ポータブル 保冷庫 小型 2ドア 同時保温保冷可能 温冷庫 -2℃～60℃ 温度調節…

Amazon楽天市場

Amazonの情報を掲載しています

開けてみる

まず電源を抜いて、水滴などがあればよく拭いておきます。
開けるのは非常に簡単で、プラスドライバーで裏面の外周にある8個のねじを外すだけです。

ここまで長くなくてよいですが、長めでネジが磁力でついてくれるものがあると作業がです。

ベッセル(VESSEL) クリスタライン ドライバー 〈長軸タイプ〉 +2×200 6300

Amazon楽天市場

Amazonの情報を掲載しています

開けると中はとても簡素で、電源基板と制御基板の２つがあるだけです。
ファンやケーブルのコネクタが取り外せると楽なのですが、防水の為か樹脂で固められておりましたので、蓋が完全に取り外せず、写真ぐらいの位置に養生テープで固定して作業にかかりました。
左下はいわゆるスイッチング電源と呼ばれる電源基板で、こっちには100V系がおりますので基本触らないのが吉です。それ以外は基本的に 12V 以下の電子回路の領域となりそうです。

ヒートシンク部分のねじを外すとペルチェ素子にたどり着けます。
ペルチェの型番は TEC1-12704 と書かれています。検索するといろいろ出てきますが、ペルチェ素子自体はセンサーを冷やしたりする実験でも使えそうなのでAmazonで3個入りを買いました。

3PCS TEC1-12704 40x40MM 1.57×1.57inch Thermoelectric Peltier Cooler Semiconductor Refrigeration Chip

Amazon楽天市場

Amazonの情報を掲載しています

ファンの方は型番 JSF9225HS と書かれおり、DC12V 0.16A との事です。

こちらは完全い同じ型番のものは入手が面倒そうでしたが、パソコンなどで使われている92mm x 92mm x 25mm ファンの形状ですので、定格が収まっていればまず問題ないはずです。

今回は、AINEXのCFY-90Sを発注しました。

アイネックス(AINEX) ケース用ファン92mm 静音タイプ CFY-90S

Amazon楽天市場

Amazonの情報を掲載しています

交換作業

今回のファンは3本線のものを買ってしまいましたが、赤と黒がモーターの駆動で、白はパソコンなどが回転数をモニタするためのもので今回未使用なので未結線とします。

基板のコネクタ側が樹脂で固められていましたので、ここは素直に、ケーブルを切断して半田付けしてヒシチューブ(熱収縮チューブ)などで止めていくという安直な方法で交換しました。
また、ペルチェ素子周辺については、周りの断熱材をなるべく壊さないように交換し、CPU用に買っていた熱伝導グリスを綺麗に塗っておきます。

アイネックス 熱伝導グリス 大容量タイプ GS-04A

Amazon楽天市場

Amazonの情報を掲載しています

熱収縮チューブ 絶縁チューブ 防水 高難燃性 収縮 チューブ ブラック Φ1mm～14mm (127ピースセット)

Amazon楽天市場

Amazonの情報を掲載しています

無事修理完了

最後にタイラップ(結束バンド)などで配線を整理して、閉じにかかります。
熱収縮チューブや結束バンドなんかは100均でも手に入ると思いますし手元にあると便利です。

ヘラマンタイトン 結束バンド インシュロック AB150-W 100本入 耐候・屋内外用グレード 黒

Amazon楽天市場

Amazonの情報を掲載しています

容量の多い下段は温度が下がるのに時間がかかっていますが、無事に温度が下がり始め、ファンの異音もなくなりました。
しばらくこれで様子を見てみようと思います。

なお、くどいようですが、もしも真似される場合はくれぐれも自己責任でお願いいたします。

追記

筆者は一応電機メーカーに20年以上勤めていた経験もあり、電安法などの法律も多少は知っておりますし、電気工事士の資格なども持ってはおりますが、それでも常時稼働する家電の修理は万一を考えると怖い為、なるべく安全な領域に限って自己責任で行うようにしております。
幸い、ペルチェ冷蔵庫は、電源アダプタや自動車のシガー電源ソケットで動くタイプもある通り、白物家電と言うより、パソコンのCPUの冷却などの黒物家電に近い部分があります。
自作パソコンと同じとまでは言えませんが、なるべくそれに近くなるように弄らないといけない範囲をある程度見極めて、触るようにはしております。
正しい知識で、皆様の快適なライフハックが捗ることをお祈りしております。

当サイトは基本的にFPGA推しですが、そうはいってもFPGAのどこにメリットがあるのか正しく把握する必要があるので、今日は Jetson Orin Nano Super などと比較してみようと思います。
KV260 が現在 Digikey で ¥43,751円、Jetson が秋月電子さんで 49,830円 なのでまあまあ近い価格感かなと思います。
もちろん KV260 が 16nm プロセスなのに対して、Jetson Orin は 8nm なので、かなり不平等な比較にはなりますが、FPGAに比べると、GPGPUが先端プロセスで次々新製品を出してくるのも事実なので、ここは現実的に比較してみましょう。

なお、Jetson の性能は ここ から参照させてもらいました。

性能を比較してみる

ここはAIを前提に INT8 で比較していきます。KV260 は DSP が 1248個あり、1個で INT8 の積和が2個できます(積和なので4演算)。最高周波数が 644MHz ですので、644M x 1248 x 4 = 3.2TOPS になりそうです。電力はまあ適当ですがアダプタなどの定格や経験則から15Wを置いておきます(xlnx_platformstatsコマンドとか電力計とかの経験上)。

Orin の方は Dense の数値を持ってきています。

ぐらいの性能差となっており、おそらく生の数値では TOPS/W でも TOPS/$ でも、Orin に分がありそうです。
ここではKV260はDSPしか計算に入れていないのでLUTを使ったもっと低bitの演算を追加できる可能性はあるのですが、経験上DSPをフル稼働させようとするとそこにパラメータやデータを供給するための機構で結構がっつり相応のリソース持っていかれたりもします。
もちろん、同じプロセスで作ればFPGAも十分同じぐらいのスコアにはなりそうな希望は見えますが。

ではどういうときにFPGAを使うのか

この点だけに着目すると、普通のAIをやるのに演算性能観点でFPGAを使うメリットは殆どないです。特にパラメータやデータをSDRAMに置いて、転送しながら計算する DPU のようなアーキテクチャだとかなりGPUと同じことしかできないので単独での性能勝負ではメリットが出なくなります。
そのためFPGA向けのAI研究で価値を出そうとすると、

• 例えば特殊な構造や疎行列や非対称性や、複数精度の混在など、GPUだと対応しきれないが、FPGAなら対応できるモデル構造を研究する
• 応答性などリアルタイム性の要求が極めて高いところで特殊な要件を満たすような環境向けに、レイテンシが短くなるようにモデル構造に工夫する
• 通信ルーターなどもともとFPGAが活躍している場所に組み込むためのAIモデルを研究する
• FPGAのI/Oの多様性を生かして、イメージセンサやアクチュエータ、特殊なデバイスなどと密結合して連携するAIモデルを研究する
• ASIC化を前提に、AIエンジン検討のプロトタイプとしてFPGAを使う

など、単なるAI計算のスループットが欲しいだけだけではない分野の探索が必要です。
まあ、そもそもFPGAはAI以外の用途に使った方が面白そうだとは思っていますが、ある程度AIも出来ないとまずかったり、AIを研究したい人が増えているのでこの辺りの整理は重要です。

それでもFPGAでAIをやる意味

AIの研究というと、既存AIを特定ドメインに適応させる系と、AIそのものを進化させる系が多い気はしていますが、前者は特定ドメイン知識の蓄積が必要だし、後者は膨大なデータと計算機資源が必要になりがちです。

そういったなかで、そうはいっても「AIそのものを進化させる系」がやりたいという人は一定するいますし、私の BinaryBrain なんかもそのクチですので、FPGA使えばそういう可能性が開ける可能性と言うのは提示できると面白いとは思うわけです。

「FPGA用に新しいAIのモデルを発明しました！」と言った時に「でもそれGPUで実行したほうが速いよね？ GPUでいいなら〇〇社がもっと精度の高いモデル最近発表したよ」と言われないために、よくよくハードウェアの特性を理解して臨んで頂ければと、思う次第です。

節電 エコチェッカー ET30D

Amazon楽天市場

Amazonの情報を掲載しています

具体的には、AMD の DPHY-TX のIP にはいくつかのクロックを供給しなければいけないのですが、このなかで通信速度の半分の周波数のクロックを位相が90度のものと合わせて２つ供給しなければなりません。
そこでこのクロックを生成しているMMCMの設定を動的に変更してみることにしました。MMCMやPLLの周波数変更はDRPポートを読み書きすることで可能で、詳細は XAPP888 にあります。

とはいえ、データシートを真面目に読んで値を作るよりも、コアジェネレータでIPを生成して、どういう値になっているか読み出してみる方が間違いが無さそうです。

そこで、ZYBO用の 950Mbps の為の、475MHz 設定の MMCM と、KV260 用の 1250Mbps の為の 625MHz の設定と２つの設定を作って値を読み出してみました。

GUIで生成したIPは開いていくと内部ソースが覗くことができ、MMCME2_ADV のインスタンス生成が見えます。

読み書きのやり方は意外に簡単で、UG427 に説明のある MMCME2_ADV に対して、リセットを掛けた状態でクロック(DCLK)を入れて、アドレス(DADDR[6:0])と、DEN、DWE、DI[15:0]、DO[15:0]、DRDY などを使って読み書きするだけです。注意点はデータが出てくる DRDY まで待つ必要がある点でしょうか。

今回はもともとI2C経由でイメージセンサーの16bitのレジスタにアクセスする為のインターフェースを準備していたので、同じ 16bit で比較的簡単に実装できました。

興味本位でデータシートにないアドレスも全部読んでみましたが下記のようになっていました。

灰色部分はXAPP888に記載のなかったアドレスですが何か値が入っている部分があるようです。
結果的に黄色い部分だけが差分となりました。

以上、作業記録みたいなものですが、同じことをしようとする方の参考になれば幸いです。

FPGAプログラミング大全 Xilinx編 第2版

小林 優

Amazon楽天市場

Amazonの情報を掲載しています