Ryuz's tech blog

FPGAなどの技術ブログ

続・FPGAを始めるときの壁

はじめに

FPGAは、CPU や GPU などとは異なり、計算機そのものをプログラミングできます。したがって CPU や GPU には演算命令として存在しないような演算でも、自由に計算ロジックとしてプログラミングして、コンパイル(合成)して、プログラムをロードして実行できるデバイスです。

計算機の構造そのものを弄れますので、CPUやGPUのような横並びの並列演算だけではなく、パイプライン並列という縦並びの並列演算も得意です。

複雑な演算を深いパイプライン演算で高スループットで計算するのも得意ですし、逆にシンプルな演算を何万並列で実装するなんてことも得意です。

さらには I/O のプログラミング能力も高く、多くのセンサーやアクチュエーターを並列に、高いリアルタイム性で制御することも出来ます。

こんな面白デバイスのプログラミングに興味を持って下さる方も増えてきてはいるのですが、まだまだ環境面が弱く、興味を持って少し手を出してみたけど、どうにもうまく扱えずに引き返してしまう人も少なくありません。

以前、「FPGAを始めるときの壁」という記事を書きました。 当時は、せっかく RTL を覚えて計算ロジックを書いても、そこに自由にデータを出し入れするのに一苦労するという話を書きました。

一方で最近少し思うところも出てきたので、あらためて別の角度から考察してみようと思います。

私はしばし、FPGA に Arduino や Raspberry PI や M5Stack のような、初心者が Hello world から始められる、お手軽なボードが無いことを課題に挙げていたのですが、昨今 Tang Nano のような、三千円ぐらいでお手軽に LEDチカチカから始められるボードはあるわけで、原因はそこではない気がしています。

GPU を始めるのと比べてどうなのか?

FPGAとの対比として「GPUプログラミングを始めてみよう」とした場合はどうでしょうか。

FPGA に Verilog や VHDL や HLS があるように、CUDA や GLSL や OpenCL などいろいろプログラミング方法はあるわけですが、まずはGPUボードを買ってきてデスクトップPCの PCIe スロットに挿したり、Jetson を買ってきて LAN 経由で ssh 等で繋いだり、はたまたクラウドの GPU を借りてプログラミングすることになるかと思います。

初期費用の話

まずGPUプログラミングを覚える場合も、最初にGPUを用意する段階で数万円台の出費からスタートすることにはなるかと思います。

ところが、CUDA を 覚えるために 10万円のGPUボードを買ってくるのは許容できるが、Verilogを覚えるために5万円もするFPGAボードを買うなんて躊躇してしまうというのは少なからずあるわけです。

この原因はおそらく簡単で、GPUなら挫折しても別の使い道がある というのが大きいかと思います。

別に自分で CUDA 書かなくても、PyTorch 経由で cuDNN 呼ぶだけで、DL は加速し、cuBLAS呼ぶだけで算術演算が加速し、ローカルLLM もサクサク動き、 Steam でゲームを楽しめます。

一方、FPGA は使いこなせないと、部屋の棚の飾りにしかなりません。

そうなると、試すにしても最初は1万円以下ぐらいのFPGAから試して、使いものになると分かってからでないと怖くて投資できないというのもよくわかります。

通信帯域の話

また、GPU は、クラウドのものを使うにせよ、自分の手元に用意するにせよ、どうやっても 1G-Ether 程度の通信路はある上で使う事になるかと思います。

ところが困ったことに、1万円以下のFPGAボードの多くはスタンドアロンでしか動かないものが大半です。

今のご時世 IoT 機能がない というのはどうかと思いますが、Jetson とか RaspberryPI とかと同レベルの 「買ってきてOSイメージをSDカードに書き込めば Ubuntuが起動する」ようなボードはだいたい 5万円以上してしまいます。それ以外でもいろいろ手はあるのですが初心者の手には余る手段ばかりになってくるかと思います。

そうすると、安いボードでは LEDチカチカのあとは UART 作って遊ぶぐらいのところで終わってしまいます。

想像してみてください。Jetson と PC が UART でしか繋がらなかったら使いものに出来るでしょうか? クラウドの高火力GPU を使うのにインターネットの通信速度がパソコン通信時代並みの 115.2kbps だったら。

結局、ここで 通信帯域の壁で、「FPGA使えねー」となってしまって引き返す羽目になる人は多い気はします。

逆に言えば、みんな 1G-Ether 程度のLAN経由で GPU サーバー使っているわけですから、1Gbps を超える速度でPCと簡単に繋がる安いFPGAボードというのは一つの損益分岐点な気がしております。

プログラミング環境の話

個人的な意見ですが、あるべきプログラミング環境として、

  • ボードを買ってきてパソコンに繋ぐ
  • VS-Code で Verilog などの RTL や HLS(高位合成言語)で計算ロジックを書く
  • ボタン一個でコンパイル&ロード
  • Python などから send_data() するとデータが送り込まれて即座に計算される
  • 計算結果は やはり Python などから recv_data() すると受け取れる
  • ちゃんとFPGAの特性を活かせばCPUで計算するより速い
  • printf デバッグばりに簡単に埋め込みロジアナで波形とかも取れる
  • LEDチカチカとか、デバイス制御とかも RTL プログラミングでお手の物

ぐらいのものを用意しないとダメなんじゃないかなと思っているわけです。

以前、脱サラした際に、「いろいろ挑戦してみたいこと」というブログを書き、その中で「Arduino 的に使える FPGA ボード」というのを書いています。

もうちょっとだけ具体化したのが下記です。

現状 KV260 などを使っていますが、PC と KV260 間の帯域は 1G-Ether で十分非圧縮画像処理回路の評価が出来てますので、USB3.0(5Gbps) あればまあ十分だろうという目算です。

ボードのイメージ図

システム図

ぼくがかんがえたさいきょうのIoTかいはつかんきょう

当方、現実世界と超リアルタイムでインタラクションするのが目的のエッジ屋なので、まあ最終的には Zynq などの IoT環境になると思うのですが、そこに投入する要素技術の開発はお手軽な環境でやりたいわけです。

道半ばの中間成果物(Coming soon?)

で、上の妄想は K26SoM 向けの回路が作れる程度の大規模なボードを想定しているのですが、それだとまあ 5~10万円ぐらいするボードになりそうな気はしているので、Tang Primer 25k で、予備実験的な事をしようとしているのが下記です。

しかしながら、予備的と言いつつも逆に、今回書いたような内容に対する丁度良いツボを押さえられた気もしております。

  • Primer25k の コアモジュール別に買ってもギリ1万円ぐらいに収まる?
  • FT601で USB3.0 で高速にPCと繋がっている
  • バイナリ画像処理などで Core-i5 などミドルエンドのPC の CPUに性能で勝てた
  • カメラ画像も非圧縮でキャプチャできた
  • LEDチカチカやPMODでのUARTなど入門にも使える

というところで、本記事で述べてきた FPGA の壁を幾つか打破できるのではないかともくろんでおります。

一方で

  • JTAGが別に必要で USBケーブル2本差す開発スタイル
  • 言っても安価なFPGAなのでそこまで凄い事は出来ない
  • ボードも環境も全然枯れていない
  • VS-Codeでのお気軽な環境開発などまだ全くの手つかず

という状況ではあります。

正直、FPGA初学者の方に今の時点はまだお勧めできませんが、今後、いろいろな環境整備が進めば、これから FPGA を始めようとする人達にも使い易いものに育っていく可能性はあるのではないかとは思います。

また、少し余分に製造した分を製造原価程度で BOOTH などで販売しておりますので、腕に覚えのある方は、是非デバッグにご協力いただけると有難いです。

特にPC側の環境面においては 「AI に作ってもらう」 という事ができる昨今、ますます期待が持てるところです。

おわりに

個人的には FPGA はとても面白いプログラミング環境だと思っております。

せっかく興味を持って下さった方が、がっかりして引き返していかなくていい様に、今後とも面白みの体感できるものが作れるといいなと考えております。

研究開発者はどうAIと付き合えばいいのかという悩み

はじめに

例によって偏ったポジションからの意見の発露であることは断っておきます。

私はエンジニアとして、いわゆるR&Dなどの研究開発と言われるような分野に長らく身を置いてきました。

ピュアな研究でもなく、かといって、ガチガチの開発でもなく、実に微妙な立ち位置を今なお続けているわけですが、良くも悪くも何かしら世の中の役に立つ成果を求めて活動してきたつもりです。

そういった中で、別にAIそのものをメインの研究対象にするつもりは全くないのですが、AIを無視することも出来ないのでどう付き合って、どう取り組んでいくのかというのはなかなか悩ましい問題であるわけです。

ピュアな研究で求められることは、世界初または世界一である事です。「誰かが既にやってる研究をなぞった挙句二位以下の性能しか出ませんでした」では、何一つ世の中の役に立っていません。どこかに「二位じゃダメなんですか?」と言った人がいるとかいないとか聞きますが、スパコンにせよAIモデルにせよ、研究においては1位がすべての研究者のリファレンスとなり、別の研究に1位の座を追い抜かれるまでの短期間だけが「世の中に貢献していた」期間かと思います。

一方でガチな開発は「見積もり可能」なものです。「〇月〇日までに××円でこの要件のシステムを開発して納品します」という約束が成り立たないと、開発業務を請け負う事が出来ません。こちらはこちらで、見積もり技法/品質管理技法/工程管理技法/構成管理技法などさまざまなスキルが問われますが、まあそういう特性を持ったものです。

R&Dとは、「世界初/世界一のものを生み出すミッションと、それを見積もり可能な状態にして開発部隊に引き継ぐミッション」の両方を担いますので、それはそれでなかなか大変です。もっとも開発部隊に引き継ぐミッションを持っていることを理由に営利企業の中で存在が許されているという部分もあります。

そうは言っても現実問題として、

  • 研究開発とは名ばかりで、研究費としての節税が出来るだけの、事業部門の下請けと化しているケース
  • 論文や特許は出すが、お金になる出口が社内で見つからず、引継ぎ先が無くて迷走するケース
  • お金になる出口が先行し、専門とは全然違うやりたくもない研究をやらせれてるケース

などなどの問題はどこの会社の事例を聞いても散見されるように思います。

上はある意味どれもマッチングの話に帰着する気はしていますが、時代が求めるものは日々変化する中で、同じ人間だけを雇い続けて、狭い組織の中だけで研究と事業を100%マッチングさせ続けるというのは難しいですので、どうしてもある程度の歪は出てしまうのだとは思います。

そんななかで昨今、もう一つの問題として 非常に多くの研究分野でAIが無視できない という事態になっているかと思います。「自分の分野に既存のAIを持ってきて単にくっつけました」では研究とは呼びませんので、まあ何かしら自分の研究価値を高める形で独自のAIを作って組み合わせるという事がいろんなところで求められています。学生などの若者が「とりあえずAIやりたい」と言い出すのも、R&D内では分野問わず「専用のAI作ってそこに適用できます」が言えないと就職もままならなくなり始めている面があるのかと思います。

王道のAI研究とは

当サイトは基本的に邪道を行くサイトなので、その話をする前に王道を考えてみたいと思います。

まず研究である時点で王道/邪道を問わず、絶対性能、コストあたりの性能、電力あたりの性能など、何かしら性能指標が世界一であることが必要です。

その中で、特に王道路線のAI研究とは何かを私なりに考えてみました。それは

  • なるべく万人の役に立つほど良い
  • なるべく汎用的なデータを扱えるほど良い
  • もっとも普及している計算機(今はCUDA)で動くほど良い

ではないかと思います。

実際これらを満たす多くの分野でそれぞれ最先端の研究がなされており「我こそはSOTA(State-of-the-Art)なモデルなり」と次々とより精度の高いモデルが提案され、切磋琢磨の中でどんどん進歩しています。実際、中の人は血の涙を流しながら日夜大変な苦労をされており、本当に頭が下がります。

グローバルな競争にさらされている分野でまさに研究のメインストリームですがおそらく下記の特徴があります。

  • 他の論文投稿者と公平に精度比較できるテストデータを利用している
  • 推論時の性能は問われるが、学習のコストはそこまで問われない

これは裏を返すと

  • 特定の会社にしかない秘密のデータなどは含まず、お金を掛けることでより有利な学習データが集められる
  • 高額な巨大GPUクラスタを有しており、より大きなモデルからの圧縮や、多数の試行錯誤を出来る方が有利

ということであり、研究フェーズで一時的にSOTAのポジションを取ったとしても、それがビジネス的に美味しいとなれば、巨大な資本力で追撃されると、SOTAであり続けることが非常に難しいという点があるかと思います。

これは研究だけをやっている機関であれば、一度でも SOTA がとれたなら良しという面はあるのかもしれませんが、事業で利益を出してナンボという企業の研究開発部門にとっては頭の痛い話ではないかと思います。事業部門からすれば別に自社の研究開発部門の成果なんて使わなくても「アメリカのAIフロンティア企業のAIを使う方が儲かる」となってきますのでますます研究開発テーマの存続意義が問われてしまうわけです。

王道以外を考えてみる

AI に王道の反対を聞いてみると「邪道」「覇道」「外道」「異端」などだと教えてくれました。

先に上げた王道の条件はだいたいAND条件になってくるので、それを元にどれかを捨てて邪道を走る方法を幾つか考えてみることにします。

そうすると

  • 特定の人にしか役立たないものを作る
  • 特殊なデータを扱う
  • GPUが適用できない領域を狙う
  • 豪華なGPUクラスタを持っていても大して有利にならないものをやる

などのいずれかを満たしたまま(多分とても狭い分野だが)SOTAのポジションを取ればいいことになります。

特定の用途に絞る

学習データはどこにでもあるものが使えるが、「そんな使い方したいのはお前のところだけだ」みたいな特殊なアウトプットに特化したモデルであれば、他が参入してくる心配は少ない気がします。ただそれが「研究」と言えるものかはやや怪しげな気もします。

特殊なデータを扱う

恐らくこれが多くの弱小R&D部門の活路になっている気がします。

自社にしかない特殊な製造技術のAI化とか、機密保持契約があるので学習から推論まで工場内のクローズな環境に閉じ込めないといけないものとか、一般の汎用AIをそのまま持ってきても役に立たない部分をAI化したい場合に、独自に研究開発する必要があるかと思います。

しばし機密保持観点で、論文も特許も書けないなんてケースもありそうなので、あまり表に出てこないだけで、案外大勢がこういうところに生息しておられたりするんじゃないかとも邪推しております。

他にも、撮影対象は一般物なんだけど、「特殊なセンサーで撮ってみた」とかをするだけでも、王道路線の人とのガチンコ勝負を逃れられる可能性なんかもあるんじゃないかと思っています。私のRGB以外のデータとって遊ぼうよという取り組みも、ある種こういう切り口です。

GPUが適用できない領域を狙う

なんだかんだで最先端プロセスを真っ先に投入してくる先端GPUは、サーバーにせよエッジにせよ、絶対性能/コスト当たり性能/電力当たり性能のいずれも高いパフォーマンス出してきますので、通常これに勝つのは容易ではありません。なので

  • サイズ/重量/振動/防塵などの環境条件でGPUが適用できない領域
  • 一番安いGPUでも高価すぎて適用できない領域
  • 超低遅延やジッタのない処理が必須でGPUが採用できない

などの領域に手を出す事じゃないかと思います。

研究的にはここが一番おもしろそうだと思ってるんですが、1ミリ秒で認識したり、2,980円のFPGAボードでAIをやったりしています。

豪華なGPUクラスタを持っていても大して有利にならないものをやる

ここは、AI以外に新規性のある要素を持っていて、本筋の価値をブーストするのにAIを使うというのが前提にはなりますが、これも意外と重要なんじゃないかと思っています。

例えばAIの入門でおなじみの MNIST分類なんか、DGX なんか持っていなくいても、99.9% の認識率に達することができます。

とはいえ、「じゃあ機械学習を使わずにルールベースで 99.9% の認識率のルールベースのプログラム書けますか?」と言われたらほぼ無理です。

早い話が、AIを持ち込まないと価値が出せないが、高額な巨大GPUクラスタを有していたからと言ってさして有利にならない領域です。そしてまた、GPUなんか搭載するとオーバースペックすぎてコストに合わない分野でもあります。

本来とてもいいものを作っているのにAIを追加できないせいで、そこそこだけどAIで補っている商品に市場を取られたらたまりませんので、案外こういう部分をしっかり研究するのも重要なんじゃないかと思っています。

おわりに

思いつくまま悩んでることを書き出してしまっただけという感じもしますが、雑記という事でお許しください。

特に次の時代の技術者の方々は、どのようなスキルを身に着けて、どのような職に就けば今後生き残れるのか、悩み話もよく聞きます。

AIの研究がしたいという方はちゃんとした王道の研究が出来るところに行かれることがお勧めかとは思います。

一方で、私のようにAI以外の研究もやりたいなと思っている人間であっても、「それAI使えば済むよね」とか「AIと比べてどうなの?」とかを常に言われてしまうご時世なので、どうAIと付き合いながら、かつ、AIに飲み込まれない価値のある研究開発が出来るのだろうかというのは悩みの尽きない問題だったりもします。

引き続き楽しく「邪道」を模索できればなと思っている次第です。

専用レジスタと汎用レジスタと

はじめに

以前、「結局CISC/RISC論争とは何だったのか?」という記事を書きましたが、今日はさらに時代を少しさかのぼって、しばしインテルの 8086系 と モトローラの 68000系 の頃によく議論されていた専用レジスタアーキテクチャと汎用レジスタアーキテクチャについて、振り返ってみたいと思います。

ソフトウェア視点だと 68000系 の美しさは賞賛されていたかと記憶しておりますが、コスパやユーザー数で専用レジスタの x86 が生き残った経緯があります。

専用レジスタや汎用レジスタとは何か

今は x86 もかなり汎用化していますが、8086 やその元祖となる 8080 などでは、レジスタに専用の用途が割り当てられているものが多かったです。

加算結果はアキュムレータレジスタにしか書き込めないとか、レジスタ間接アドレスはベースレジスタしか使えないとか、ループ命令のカウンタにはカウンタレジスタしか使えないとか、そういう命令ごとに使えるレジスタに強めの制限があったのが、専用レジスタアーキテクチャです。

一方で、汎用レジスタのアーキテクチャでは、基本的には用意されているレジスタセットはすべて汎用にどの命令にも使えるし、どの命令の結果も好きなレジスタに書き戻せるというものでした。

本当に汎用レジスタが正解なのか?

現在CPU界の3大勢力は、x86、ARM、RISC-V かと思いますが、x86-64 がかなり汎用レジスタになってきたことを考えると、3つとも汎用レジスタアーキテクチャになっていると思います。

特に CPU の周波数を上げることで性能を伸ばしていた時代においては、

  • 多くのレジスタが同じように使える
  • レジスタがなるべくたくさんある

ことは、深いソフトウェアパイプライニングを行い、演算器に休むことなくデータを供給し続ける上で大いに重要だったように思います。

しかしながら、CPU の周波数向上がある程度収束し、多くの命令や演算を 一度にたくさん並列実行したい となってきてから、少し様相が変わってきているのではないかと思っています。

以前こんな記事を書きましたが、汎用であるという事は 全部の演算器が全部のレジスタに繋がってないといけない という事です。

要するに、一直線のパイプラインを速く深くしたかったときは良かったが、並列数を増やしたくなると接続の対角線の数が二乗のオーダーで増える という困ったことを起こしているように思います。

これがもし

  • 加算結果は決まったレジスタにしか書けない
  • 乗算結果は決まったレジスタにしか書けない
  • メモリからロードした値は専用レジスタにしか書けない
  • メモリへのストアは決まったレジスタからしか出来ない

であれば、ロードとストアと加算と乗算を同時に行う のは極めて容易です。すべて独立して実行可能で、なんの干渉もしません。

これが汎用レジスタだと、すべての読み書きの衝突がチェックされ、ぶつかっていたら矛盾なく実行されるようにオーダリングしないといけないわけで、ハードウェアコストが増大しているのもうなずけるのではないかと思います。

周波数を上げるのではなく、1クロックで如何に沢山の命令を並列に実行するかが問われる時代においては、案外専用レジスタアーキテクチャに回帰したほうが省エネなのではないか、などとも考えてしまうわけです。

レジスタからレジスタに演算するということ

CPU における演算とは、レジスタ読み出して何らかの計算を行い再びレジスタに格納する命令を、逐次的に次々実行することです。

これを一度に大量にやりたいというのが近代コンピューティングに求められていることだと思います。

ここで唐突に FPGA などの話を引き合いに出しますが、FPGA などのプログラミングで行われている RTL(Register Transfer Level)のプログラミングはまさにその意味においては大変直接的な並列記述を行うプログラミング言語です。

以前 Zennの方 で こんな記事 も書きましたが、FPGA における RTL プログラミングとは、FPGA の中にある、大量のレジスタ(フリップフロップ)に対して、レジスタからレジスタへの演算をひたすら列挙していきます。

そしてこれらの列挙された演算は、毎クロック、一斉に並列演算されます。

この時これは、専用レジスタなのか汎用レジスタなのかちょっと興味深く思います。

FPGAデバイスとしてはなんにでも使える汎用レジスタであるし、これにプログラマが専用の役割を与えて、専用レジスタ化する作業こそがRTLプログラミングとも言えると思います。

そして仮にその設計を ASIC化した場合、それはもう専用レジスタの塊なのではないかとも思います。

おわりに

CPUにせよGPUにせよFPGAにせよ、デジタル同期回路の計算機に対してプログラマがプログラミングして計算を行わせる場合、ほとんどのケースでレジスタからレジスタに演算を行う事になるかと思います。

しばし目的としては演算ですので、演算器に目が行きがちではありますが、レジスタのアーキテクチャというのも案外重要なのでは思う次第です。

CPU に関しては、なかなか汎用レジスタアーキテクチャでないものに触れられる機会は以前に比べると減少してきているかと思いますが、幸い FPGA を使う分には何でも出来てしまいます。

ここであえて専用レジスタアーキテクチャに再び目を向けてみるのも面白いかもしれません。

【温故知新】画像信号処理がデジタル化で失ったもの

はじめに

偉そうなタイトルをつけつつも、一応私もデジタル時代の人間でして、OPアンプなどを使ったアナログ回路というと

  • 大学時代の学生実験
  • お遊びで超音波センサーとかの受信信号の増幅
  • お仕事で簡単なDC-DCの設計

あたりをこのあたりの本を片手に苦戦しながら少し触った程度でしかなかったりはします。

とは言え、大学の恩師が OPアンプで何でも作ってしまう人であったり、若いころの職場でも似たような方々は一定数おられましたのでそういう世界を少しだけ覗く機会はあった世代かとは思います。

そこで、少し昔を振り返りつつ、デジタル時代と対比してみたいと思います。

アナログ時代の信号処理

ファミコンなどの古いゲーム機も含めて、テレビが地デジになる前のアナログ時代の画像処理は基本的に、ブラウン管を駆動するためのアナログ信号を直接扱っていました。

インターレースとかノンインターレースとかデジタル化されてもいろいろ方式は残ってはいますが、基本的には画面の左上から右方向に1ラインづつ走査しながら表示する為の信号です。

AIにイメージ図を頼んだらこんなのを書いてくれました。

ブラウン管の走査イメージ

ビームの位置を決める水平/垂直同期信号とRGBのそれぞれの強度の信号がブラウン管モニタには必要で、それらを生成するためのコンポジット信号が変調されてそのまま電波で放送されておりました。

画像信号処理においてはこの信号を直接的にOPオペアンプなどで処理することになります。

しかしデジタル時代と違って、前のラインをメモリに残しておいて参照するというようなことは容易ではありませんので、基本的には

  • 色合いやコントラストなど、アナログレベルに関する補正
  • 水平方向の周波数フィルタによるエッジ強調や平滑化などの横方向限定のフィルタ

などしか出来ませんでした。(もちろんこれを超えたエクストリームなこともいっぱい為されてはいたようですが)

デジタル化で起こったこと

デジタル化は急に起こったわけではないので、デジタル化にあたってもアナログ時代の信号にも相互変換できるようにHDMIなどの規格は設計されているように思います。

実際、垂直同期や水平同期などの信号やタイミングはそのままに、画素の値のみをデジタルサンプリングしたようなフォーマットが基本になっているように思います。これはこれで今となってはいろいろな足枷になっている気はしておりますが、それは一旦おいておいて、

デジタル化でラインメモリやフレームメモリが使えるようになった

というのが大きな変化の1つかと思います。

従って、デジタルにより画質劣化がなくなっただけではなく、メモリが使える というメリットの誕生により

  • 横だけではなく上下も使った画像フィルタが可能になった
  • 前後のフレームを使ったフレーム補間なども可能になった

などの、大きな変化があり、画質は格段に向上しました。

一方で、特にCPU/GPUで行うデジタル画像処理の多くは下記のようなアーキテクチャの変化を起こしました。

デジタル化

データを一度メモリに溜めることによって多彩な演算を行えるようになったものの、メモリにバッファリングした分遅延しますので、映像伝送は 高画質処理を沢山すればするほど遅延が増大する という問題を起こしました。

「テレビ放送から時報が消えた」

というのが、もっともわかりやすい事例ではないかと思います。

かつてアナログテレビ放送の時代では時報を聞いて、自宅の時計のずれを合わせたりしていたものですが、テレビによってばらばらの遅延時間が発生してしまうので正しい時間がブロードキャスト出来なくなってしまって、この放送は無くなりました。

他にもテレビ前面の HDMI 端子はゲーム用に、あまり高画質処理を掛けずに低遅延で表示するようになっているものがあったりとか、遅延の問題に関する取り組みは、テレビごとに個性を持つことになりました。

コンピュータビジョンはどうあるべきか?

コンピュータビジョンの世界も基本的には、HDMIなどのカメラやディスプレイの各種規格に大きく影響を受けてきました。

特に現在では画像認識の研究者の大半がGPU を使ってそれを行っておりますので、なんらかのビデオキャプチャシステムでメモリに画像を取り込んで、計算結果をメモリ上に作って、出力する、という流れかと思います。

一方で、メモリに一度溜めるというのは、それ自体が遅延となります。

これはオフラインでの画像処理においては何の問題もないのですが、昨今叫ばれているようなフィジカルAIのような分野では問題になりえます。現実世界は計算している間にどんどん変化していきますので、障害物にぶつかってからブレーキを踏んでも遅いのです。

ただし、CPUもGPUもそもそもロード/ストアアーキテクチャですので、メモリからしか入力できないし、メモリにしか出力できません。

メモリ=遅延素子と捉えると、必ず遅延を発生させてしまうのもノイマンボトルネックの一種と言えるのではないかと思います。

当サイトは、メモリは遅延素子としてではなく データを未来に転送する素子 としてのみ使うべきだと考えています。

FPGA などを活用すれば、メモリを介さず演算器に直接データを投入したり出力するモデルを考えることが可能です。

フィジカルAIの為に目指したいモデル

また、このモデルは、新しい情報が入力されたら即座に最新の出力が可能、という以外、何をメモリに保存するかも、過去のどんな情報にアクセスするかも自由であり、チューリング完全性を満たしておりますのでどんな計算でも可能です。

フレームの前方参照が出来ないという課題はあるのですが、それであれば、フレームの先が届くのを待つのではなく、前のフレームを使うべきですし、前のフレームとの変化が多すぎる(古すぎる)のが課題であればフレームレートを上げれば済む話だと思います(そもそもローリングシャッターが成立してる時点で同時性を求めてないですし)。

当サイトが好んでFPGAに高速度カメラを組み合わせて使っているのはそういう理由です。

では、このような計算機モデルに合うAIの学習モデルが真剣に研究されているかというと、案外そんなことは無いのではないかと思います。 SSM系のモデルはいろいろありますが、FPGAなどを前提に妥当なリソース量やメモリ帯域の最適化がなされている例はほとんど聞きません。

おわりに

そもそもAI研究者の大部分がGPU上で仕事をしておりますし、GPUで出来る事以上の事を避けている (意識するかしないか別として) 部分はあるように思います。

折角、すごく苦労して計算機アーキテクチャを勉強していて、AIもやってみたいという方。もし FPGA に手を出されるなら、現在の画像信号処理がアナログ時代から引きずっている負の遺産だったり、デジタル化で失ってしまったものだったり、言い方を変えると「GPU画像信号処理の弱点」のような部分を調べてみてください。

他の人には出来ない、新しいことに挑戦するヒントが沢山出てくるのではないかと思います。

お金は無いけどAI研究をやりたいならどうするべきか

はじめに

世の中の最先端のAIモデルの開発にはそれこそ 国家予算級の費用 が投じられる時代になってきているようです。

OpenAI、Microsoft、Google、Meta、xAI などのトッププレイヤーを Frontier AI Labs などと呼ぶらしいのですが(AIがそう言ってました)、まさに 札束で殴りあう 勝負になっている面は少なからずあろうかと思います。

では、「ウチの会社(大学)の研究費じゃ、国家予算には少し足りないな、GPUボード何枚か買ったら終わる」と言う研究者はもうAI の研究を辞めるべきなのでしょうか?

もちろんそんなことは無いのですが、同じ土俵で戦ってもひどい目にしかあいませんので、どういう考え方でターゲットを決めていけば多少なり太刀打ちできるポイントが見つかるのか日々考え悩んでいるわけです。

特にお金がかかるのが学習ではないかと思います。推論を量子化なり枝刈りなりで軽量化する際にも追加で学習コストはかかりますので、とにかく手元に用意できる学習資源の中でやり繰りできる範疇以外は、転移学習にせよ、あらゆるパラメータ加工にせよ、プロンプトエンジニアリングにせよ、結局は「Frontier AI Labs などが公開している成果をただ使うだけ」になってしまいます。

という事で、大雑把にこんな構図が頭に浮かんできます。

身も蓋もない話をすると、いわゆる「汎用」と呼ばれる分野は、すべからく Frontier AI Labs が独占するんじゃないかと予想しています。

これは現在の LLM などもそうですが、自動運転や汎用ロボットなどのフィジカルAI分野も含めてすべからくです。

必要な知識とやらなければいけないことがわかっている分野に関して、お金を掛けずに太刀打ちするのは極めて難しいと思います。

ドメイン特化とは何なのか?

知識(データ)がドメイン特化

必要な知識(データ)がドメイン特化している分野は、どうあれ自分で学習させざるを得ない分野です。

もし仮に、弁護士資格と医師免許と電気工事士と危険物取り扱いまでありとあらゆる資格を持ち、世界中の言語を話すマルチリンガルのような、スーパーマンがいたとしましょう。しかしそんなスーパーマンでも、一度も入ったことのない飲食店に連れてこられて「ウチの味で料理を作れ」と言われたら手も足も出ませんし、「その会社でしか通用しないローカル用語だらけの資料をチェックしろ」と言われても困るわけです。

初見では何が良くて何が悪いのか皆目見当のつかないものの判定や、特殊な手順を含むものは、ドメイン特化と言えるでしょう。

ただこの領域は先の図の右上の「お金のないドメインは置き去り」になりやすい分野な気もしています。

また、「データが違うだけで、モデルは工夫しても従来のものに勝てない」とかだと研究として価値が訴求しにくいです。 そのデータに特化した新しいモデルの提案が出来るかどうかなども問われてくるところだと思います。

物理条件がドメイン特化

これもモデルの accuracy ばかり語っていると案外見逃しがちですが、とても重要です。

例えば、特殊な波長の光で計測しないと計測できない、100マイクロ秒で認識しないと間に合わない、などのパターンです。

こちらも特殊なデータを収集したり、低遅延で結果の出る特別なモデルや計算機を考案したりする必要が出てきます。

ここが他の領域と比べるとまだ、先の図の右下の「貧乏人でもやる価値あり」が比較的まだ掘り起こせる分野な気がしております。

フィジカルAIに活路を見出そうとしているのは、案外、ここがボトルネックになっていて、自動化が進んでいない部分が多いからなのではないかと想像しております。

少子化による労働者不足が迫る中、中小企業だとか農林水産業だとか、多くのところで「お金さえあれば自動化できるのに人間が作業してる」というものが沢山ありそうな気はします。

そもそもAIを学習させる意義は?

そもそも最近、最先端のLLMがニュースを騒がせすぎるので、100 FLOPS ぐらいで出来る計算ですら機械学習には意義がある という事が過小評価されていそうな気がします。

例えば AtCoder のようなプログラミングコンテスト的な体裁で、テキストボックスが出てきて「入力された画像が犬か猫か判別するプログラムを書きなさい」と出てきたら、多くのソフトウェアプログラマは困惑すると思います。中には手も足も出ない人も居るでしょうし、機械学習なしに高い判別率を出すのはほぼ不可能だったと思います。

しかし例えば、「犬と猫を90% 以上の精度で区別出来ればよい」という程度の難易度のお題であれば「それなら データさえあれば うちのGPUボードでも学習できるかな?」というような印象を持つと思います。

学習コストが低くていいというのは、それだけ安く誰もが手を出せるという事ですから、AIをお金持ちの道具からもっと裾野の広いものに変えていける可能性もあろうかと思います。

認識精度の問題

お金を掛けられないという事は、お金を掛けた場合よりどうしても精度は下がる傾向にあります。

もちろん中にはもともと「100% じゃダメだ」という分野も沢山ありますが、「90%程度の精度で露払いしてくれるだけでも、検査員を半数に減らせる」みたいな現場もあろうかと思います。

また「100マイクロ秒で認識してくれるなら 50% でも十分、それで治具が壊れる前に緊急停止できるなら消耗品の損耗率が半分になる」なんて現場もあるかもしれません。

当サイトは基本的にリアルタイムコンピューティングの追究ですので、計算機アーキテクチャとアルゴリズムの工夫でリアルタイム性を高めて、フィジカルな分野に計算機の価値を提供するというのが軸足です。

それらは基本的に 予測の効かない 分野で威力を発揮するのですが、そのなかに異常系というのはそれなりに含まれます。

人間でも転んだときに「右に体を捻るか左に体を捻るか」の一瞬の判断が生死を分ける事すらあります。産業でもそういう異常系はつきもので、そういう時に100%ではないにせよ、ある程度有意な認識ができれば、事故率や損耗率を減少させることが出来る可能性はあるわけです。

要は、どういうターゲットを選ぶかというのはとても重要なわけです。

おわりに

当サイトのいつものノリで FPGA 推しで〆たいと思います(笑)。

当方の取り組みは別にAIでなくていいのですが、とにかくFPGAなどを使って低遅延かつ固定時間で結果を出せるアーキテクチャとアルゴリズムを探求したいわけで、100マイクロ秒で認識してくれるとかエクストリームな方向で仕組みづくりを行い、あとは「 データさえあれば 安いGPUで学習して実装できますよ」としたいわけです。

まあ、もっとも データを収集する というのが一番難しいのかもしれませんが、そういったプロトタイプを作りやすいのも FPGA のいいところだったりもします。

闇雲に SOTA なモデルを追いかけても、最後にお金の力不足で悲しい結果にならないように、どこなら戦えそうか考えるのは大事なことに思いました。

GPU上で出来る事は、「手に入らないデータを使う」以外で差別化しずらいですが、FPGA なら「FPGAを使ったデータ収集」や「特殊な計算機アーキテクチャで低遅延化」みたいな方向で戦える幅が広がりますのでおススメですよ~

身も蓋もない話をすれば、「AIなんかやらない」とか「AIも使うけど、それ以外のところでちゃんと研究価値を作っておく」とかすると、差別化が図りやすいのですが。

Verilogの課題を再考してみる

はじめに

RTL開発を行える言語は多数ありますが、Verilog と その後継である SystemVerilog はその有力な言語の1つかと思います。

一方で、もともとシミュレーション言語として開発された後に合成にも使われるようになった経緯と、そもそもとても長い歴を持っている、早い話が古い言語であるため、後方互換を捨てない限りは永久に負の遺産も抱え続けることになります。

詳しい言語の歴史は Wikipedia などを見て頂くとして、20年ほど前ぐらいに私が半導体関係のお仕事に携わってた頃は周りは Verilog-1995 を使っていたようです。もっともこのころ私はまだ Verilog は使っていなくて、後に FPGA をやり始めて、当時 Xilinx の ISE で Verilog-2001 あたりから使い始めたと記憶しております。

そののち Vivado になり SystemVerilog が使えるようになり、少しづつ試しつつ verilator との出会いなどもあって、SystemVerilog も限定的に使い始めたりしています。

Verilog に限った話ではないのですが、仕様の足し算で済む話は言語の進化でどんどん解消していきますが、引き算に関してはなかなか難しく、「新しくこういう機能用意したのでなるべく古いものは使わないでね」としていくしかないので、なかなか難しい問題があります。

私が持つ Verilog の不満どころ

ということで、私の思う Verilog の不満を少し書いてみるわけです。

合成とシミュレーションで動作が変わる場合がある

多分これが昔からある一番の課題でしょう。

  • うっかり書いたブロッキング代入で実行順序が保証されない
  • always_ff @( clock ) begin とかに勝手にコード補完されてて変なラッチが生成されてた
  • 源振の違う同じ周波数のクロックでsimだと誤差が無いので動いてしまった

とか、いろいろあるあるです。

この辺りが Veryl だと CDCの扱いなども含めてかなり解消されているようで、期待している次第だったりします。

バス幅ゼロを許容していない

地味にこれ私すごくフラストレーション持っているのですが、[0:0] 表記で1bit が生成されてしまうので 0bit 幅ってできないのですよね。

ポート数に合わせてIDの幅とか決めたいときに $clog2(N) みたいなことをすると、N=1 の時だけ個別に場合分けしないといけない。

しばし

parameter int ID_WIDTH = N > 1 ? $clog2(N) : 1;
logic [ID_WIDTH -1:0] id;

みたいなコードを書く羽目になり、N = 1 時には id には 0 しか来ないので 論理圧縮で消されるのを祈る みたいなことをよくやります。美しくないです。

Python や Rust など [0:10] や 0..10 の表記で 0から9までを生成してくれる系の言語に慣れていると特にいらいらしてしまうわけです。

マクロやジェネリクスがまだまだ弱い

Verilog-2001 から導入された generate 文は超強力で、parameter との組み合わせでかなりのメタプログラミングが出来るので、個人的にはこれはとても気に入ってる構文です。

一方で、ジェネリクスとして綺麗に定義されているわけでもなく、マクロに関しては C言語並みです。

もともと C言語のマクロが非力すぎるというのあって、IF しかないのでチューリング完全でなく、FORなどの繰り返しが無いので、割り込みテーブルの静的生成とか、特定用途のコード生成では MASM (マクロアセンブラ) にも負けていたように思います(苦笑)。

Verilog では generate 文でこのあたりはかなり解消されましたが、それでも Lisp や Rust のマクロのような、一度 AST に持っていくようなちゃんとしたマクロがあると応用性は高そうな気はしています。

Veryl にとっても期待しています。

勝手に wire 推定する

`default_nettype none

しないと 1bit の wire になってしまうのは、いまだに嵌ることがたまにあります。

言語的にはそうしないと後方互換が保てないのでどうしようもないような気がします。

automatic と書かない限り static になる

C言語に慣れていると、ブロックの先頭で定義した変数は自動変数っぽいイメージを持つが、実はこれ Verilog との互換の為にデフォルト static なのでうかつなことをするとラッチが生成されたりとかあらぬことが起こります。

ちょっと厄介なことに xsim(Vivado Simulator)がデフォルトで automatic だったりするので、しばらく気が付かなかったりしました(今はどうなったのかな?)。

仕様が膨大すぎる

1800-2017.pdf は 1315ページもあります。 先の nettype とか var と wire と データ型とか初心者泣かせすぎな仕様も結構ある気がします。

単に wire と書くとデフォルトの DataType で wire logic が推定され、単に logic と書くとデフォルトの kind として var logic が推定されるので SV が Verilog と見た目上の互換になるとか、マニアックすぎる後方互換確保にいまだに混乱してます。 ちゃんと理解できてる自身があまりないまま使っていたりします。

おわりに

今回は思いつくまま不満を書いてみる回になってしまいました。

今は AI もあるので、うっかりなバグは減りましたが、それでも罠になりうることを知っておくのは悪いことではないかとは思います。

SystemVerilog になって class や可変長配列など便利な機能も増えましたし SVA の登場や UVM の存在など、今後も進化は続くのかなとは思います。 一方で、仕様がより複雑になる事はあっても単純になる事は無いと思われるので、今後も覚えることは増えそうです。

足し算しか出来ない言語進化に対して、別言語を再定義することで結果的に引き算を行って、シンプルな言語を作ろうとする Veryl の意義を改めて再確認した次第です。

SOTAなモデルと戦うな

はじめに

AI研究でFPGAを使おうとする初学者の方へ、せっかく高い意欲をもってFPGAに興味を持ってくださった若者が辛い思いをしないよう、繰り返しになる部分もありますが書いておきたいと思います。

  • 「FPGAを使って面白いモデル改善をして実装までやりました!」
  • 「ふーん、で SOTA なモデルより何% 精度良くなったの?」

で、辛い目に合う若手を、もう何人見てきたことか。

意義深いことやってる筈なんですが、ちゃんと説明できないので折角の成果が認めてもらえないし、FPGAなんか知らない人には何やってるんだかよくわからないということが起こってしまうわけです。

もっとも、AI モデルをやってるのか、計算機アーキテクチャをやってるんだか、よくわからないまま、なんとなく「AIやりたい、FPGA面白そう」で深く整理しないまま手あたり次第手を動かしてる側にも問題はあるのですが(苦笑)。

リコンフ8策みたいな高尚なことは書けませんが、私も少し持論を書いてみるわけです。

SOTAなモデルと戦うな

で、表題に戻るんですが、FPGA で GPU や AI専用LSI と精度競争しても勝てるわけないんだから、前提をちゃんと置くべきなんです。

じゃあ何と戦うのか、条件を同じにした 従来のモデル と戦うべきだと思うわけです。

例えば昨今 フィジカルAI みたいなバスワードが流行ってますが、例えばあなたが数万円ぐらいの FPGA をターゲットにしていて、積和演算のできる DSP が 200個 ぐらい入っていたとしましょう。

ピクセルクロック 200MHz ぐらいで画像処理するとして、40G MAC/s 程度の演算リソースという事になります。

「今はFPGAで評価してるが、ASIC化して数百円で数百mW のチップで出来る事も視野に研究している」みたいなエクスキューズを挟むのもありでしょう。

実際、従来のモデルで 40G MAC/s で出来る事は極めて限定的で、著しく fps が下がったり、恐ろしく低精度な結果しか出ないでしょう。

30fps ぐらいで動かそうもんなら MNIST ぐらいならまだいいですが、CIFAR-10 クラスでも SOTA からは程遠い精度しか出ないはずです。

そういったものをまず定義して、特殊領域に AI を入れ込むことがいかに難しいかを先に述べて、そこを改善することの意義を述べましょう。

しばしこの辺りが全く述べられてない論文を書いてしまい、査読段階で「SOTAなネットとの比較を載せるべきだ」という指摘を食らって馬鹿正直に比較するリバイスをしてしまい拒絶される愚を見かけるわけですが、そこで行うべきは「SOTAなネットと比較する意味がない」ことをちゃんと書くことと、SOTAなモデルの技法であっても 同じ条件下ではろくでもない性能しか出ない ことをちゃんと示す事だと思うわけです。

FPGA のメリット

FPGAを使って AI をやるメリットは

  • 低遅延でリアルタイムに演算できる
  • CPUやGPUに存在しないデータ型を自由に定義できる(特に強い量子化や非線形表現)
  • 並列演算だけでなくパイプライン演算もできる
  • ヘテロジニアスな計算機も作れる
  • 特殊なセンサーデバイスとセットでディープセンシング出来る

などなど、いろんなものがあります。

そもそも GPU 上で研究と学習が行われている多くの従来モデルは、アンコンシャスバイアス的にGPUで効率が良くなるようにモデル設計されてるわけですから、それをそのままこういう特殊領域に持ってきたら碌なことにならないわけです。

如何に碌でもないことが起こるか最初にボコボコに叩いて、課題を挙げまくりましょう。

「あなた方が高価で発熱しまくるGPUで研究してるモデルは、いざコストと生産性に追われてる現場のおじちゃんおばちゃんには何一つ役に立ってないんだぞ」と(オブラートに包んで)きっちり言い返しておきましょう(笑)。

出発点が違うんだという事をしっかり主張しないと、お互い違う物差しで不毛な議論をすることになり、誰も幸せになりません。

リアルタイムコンピューティング的な解

で、当サイトは「低遅延でリアルタイムに演算できる」を最重視しているわけですが、結局、成果を見る側に下記の立ち位置の違いを理解してもらえる説明を如何にできるかだと思うわけです。

私の取り組みの原点は低遅延処理ですが、低遅延の為にハイサンプリングレートにすると、時間変化に対して連続性が生じるのでアルゴリズムが変わる、という事が起こり、それらをAIモデルに反映させるには計算機アーキテクチャごと再設計しないといけないけど、それは確かに成果があるという事です。

予想外にバズったつぶやきを下記に張りますが、同じようなことが AIモデルでも結構いろいろ出来るので、そういう研究って面白いのですが、そういう背景をうまく説明しないと 「SOTAなネットの方がよっぽど精度良いよ???」となってしまうAI研究者は多いので、ちゃんと万人に分かるように説明する ってとっても大事なのです。

おわりに

まあ、なにより、研究してる本人が、自分がやってることが他分野の人にどう見えてるのか客観的に理解することが大事なんだとは思います。

そうはいっても、AIも大変だし、FPGAのツールにも振り回されるし、悪戦苦闘して、なんか動かすのに精いっぱい となってテンパってる学生にそこまで求めるのも酷なのかもしれませんが、折角の成果が評価されないのも もったいない ですので少しでもうまく伝えるテクニックを考えてあげることが出来ればと思う次第です。