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

はじめに

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

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

X68000パーフェクトカタログ (G-MOOK)

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

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

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

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

コンピュータの構成と設計 MIPS Edition 第6版 上下巻セット

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

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

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

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

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

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

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

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

これがもし

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

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

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

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

大熱血！ アセンブラ入門

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

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

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

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

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

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

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

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

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

FPGAの原理と構成

おわりに

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

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

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

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

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

はじめに

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

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

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

定本OPアンプ回路の設計: 再現性を重視した設計の基礎から応用まで (定本シリーズ)

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

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

アナログ時代の信号処理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

デジタル化

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

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

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

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

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

図解入門よくわかる最新デジタル放送の基本と仕組み (How-nual図解入門Visual Guide Book)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

おわりに

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

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

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

FPGAの原理と構成

お金は無いけど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の教科書 現実世界へ歩み出す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も使うけど、それ以外のところでちゃんと研究価値を作っておく」とかすると、差別化が図りやすいのですが。

FPGAの原理と構成

Verilogの課題を再考してみる

はじめに

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

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

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

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

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

SystemVerilog設計スタ-トアップ: VerilogからSystemVerilogへステップアップするための第一歩 (Design Wave Advance)

私が持つ 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 と見た目上の互換になるとか、マニアックすぎる後方互換確保にいまだに混乱してます。 ちゃんと理解できてる自身があまりないまま使っていたりします。

コンパイラ 第2版: 原理・技法・ツール (Information&Computing 38)

おわりに

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

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

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

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

きつねさんでもわかるLLVM ~コンパイラを自作するためのガイドブック~

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なモデルの技法であっても 同じ条件下ではろくでもない性能しか出ない ことをちゃんと示す事だと思うわけです。

ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装

FPGA のメリット

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

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

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

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

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

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

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

FPGAの原理と構成

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

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

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

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

画像処理において「計算が追い付かないので処理できるフレームレート(fps)が下がっていく」と言うのがよく聞く一般常識なのですが。
むしろ1000fps とかのハイフレームレート計算をすると逆に計算量が激減するという事が普通に起こったりするケースもある。

— Ryuji Fuchikami (@Ryuz88) 2024年11月1日

おわりに

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

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

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

Sonyの卓球ロボ Ace を素人考察してみる

はじめに

先日 X で下記の動画が流れてきて初めて知りました。 （リアルタイムコンピューティング研究所を名乗っておきながら、この手の素晴らしい技術をまったくウォッチできておらずニュースで知るというのもお恥ずかしい話なのですが）

少し時間が出来たので今朝になって、こちら のプレスリリースを読み始めたところですが、大変興味深いので、私の好きなセンサー周りを中心に少し素人考察してみようと思います。例によって素人の感想ですので、間違いや嘘が混ざることもあるかもしれませんが容赦ください。

フィジカルAIというバズワードが流行り始めてしばらくたちますが、この分野で日本の技術が復活できる可能性を示してくれた、大変心強い成果であるように思います。関係者の方々に惜しみない賞賛を送りたいと思います。

プレスリリースでは、研究者や技術者の名前までは出ていませんが、こちら の Author を見て見ると実に 49名の連名者がおられ、国際色豊かな一大チームのようですね。

蛇足ですが、名前の入ってない方も大勢おられると思いますし、このクラスの研究者／技術者の年収を考えると人件費だけで毎年軽く10億円単位になっていると思われますので、大きなプロジェクトかと思います。私の研究所(自称)の数万倍ぐらいの予算規模ですね(笑)。

フィジカルAIの衝撃 「身体をもった人工知能」は2030年の世界をどう変えるか

システム構成を見てみよう

先のURLに図が貼られていましたので引用させてもらいます。

Ace構成図

イベントベースビジョンセンサー IMX636(EVS) ×3台

こちら のイベントベースビジョンセンサーで 1/2.5型 で 約92万画素 のセンサーのようです。1280 x 720 で レイテンシは 100 µs以下との事です。マシンビジョンといいつつ 1280 x 720 という AV機器で使われるサイズなあたりが Sony らしいなと思いつつも大変興味深いセンサーです。

これに ガルバノミラーのユニットを組み合わせて GCS(Gaze Control System) と呼んでいるようです。

ガルバノミラー＋高速度カメラで卓球の玉を追いかけるのは、東京大学、石川グループのこちら が古くから有名ですが、今回は 1000fps カメラではなく EVS を使っていることが特徴かと思います。

卓球の球は、およそ 30m/s 程度のようですので、1ミリ秒(秒1000コマ)で、3cm 移動する計算です。 一方で、ある程度の変化こそしますが、ラケットで打ったりしたとき以外は、1ミリ秒などの短時間の中ではほぼ等速直線運動をしますので、従来のフレームベースカメラでも1000fps程度あればPID制御などでセンサー中央に卓球の球を捉え続けることが可能なようです。

ではなぜ、今回フレームベースの高速度カメラではなく、もっと速い時間分解能を誇る EVS カメラを使っているのかというと、回転を測るため のようで、実に 500 rad/s (秒80回転)までの回転が測れるそうです。 従来のフレームベースカメラでいうと 10万fps などのオーダーになってしまう時間分解能です。

ちなみに回転が撮りやすいようにボールの方にもマーキングか何かあるっぽいですね。また露光量を稼ぐためと思われますが、赤外照明なども積極的に活用しているっぽいです。

一方で、一般に EVS は動くロボット側に搭載したり、今回のようなガルバノミラーとの組み合わせなどは、本来であれば非常に苦手です。変化したピクセルだけを測ろうとするので、背景が大きく変化すると背景の情報ばかりが出てきてデータ帯域を圧迫してしまい、本来の情報が取り出せなくなるためです。 （鳩の首振りのように細かくミラーを止めたりしているのかとか想像もしてみたのですが）どうも今回は画像処理によって背景成分の除去を行っているようですが、ある程度背景が均一な環境 というのが前提にある可能性が高い気はしています。 少し意地悪な話ですが、背景に観客が大勢いるスタンドが写ってるなどだと、ガルバノミラーが動くたびに大量の背景イベントが発生して困るとかあるんじゃないかと想像してみました。

イベントベースビジョンカメラ イベントカメラ SilkyEvCam (VGA) 標準セット（黒）センチュリーアークス

グローバルシャッターカメラ IMX273 200fps × 9台

こちらやこちらなどに情報があるデジカメでも使われているグローバルシャッターのセンサーのようです。 1456x1088@10bit モードで 226 fps で、カラーとモノクロがありますが、三角測量に用いているとのことですので、常識的にはモノクロの方なのではないかと想像します。

撮影ラインを絞ってフレームレートを上げることも出来る筈ですが今回逆に少し下げて 200fps での運用のようです。想像ですが、システム周波数が 1kHz のようですが、その倍数まで落として同期システムにしているのだと想像します。

一般論ですが、多視点カメラを用いて3角測量する場合に最も重要なことは

• グローバルシャッターで且つ複数カメラのシャッターをきっちり合わせる事
• カメラ位置／レンズ歪などきっちり事前キャリブレーションしておくこと
• 計測領域の被写界深度を確保するために、F値を下げても写る照明条件を確保すること
• 方向の異なる映像からきっちり取りたい点で交差する中心を測る画像処理を開発する事

などです。

再帰性反射材など使えると楽なのですが、あくまで競技のできる球を使っているようですので、ここは赤外照明とかでいろいろ頑張っているのではないかと思います。

露光は短くできるとしても 200fps (5ミリ秒) ですと卓球の球は計測中に 15cm ほど進んでしまう計算なのである程度の予測は必要です。ただこのレベルの予測でもボールにラケットを当てるだけの制御ならルールベースである程度行ける可能性はあるのではないかと思います。そこに先の回転の情報なども使って高度に勝つための打ち返し戦略を立てるAIを組み合わせることで、完成度の高いシステムになっているのだと予想します。

ちなみに、もしかすると、このグローバルシャッターカメラで測った位置情報は、先のガルバノミラーの制御にも使われているのかもしれませんね。

計算機構成

有償の論文は読めていないのですが、AI 経由で聞きだすと、どうやらNVIDIAのGPUと専用のハードウェアで計算を行っているようです。

無料の情報の範囲でも 1kHz (1ミリ秒周期)のシステムと、31.25 Hz(32ミリ秒周期)のシステムのハイブリッドと読み取れますので、FPGAなどの専用ハードウェア と GPU でそれぞれハイブリッドな、サブサンプションシステムを作っている可能性はあるのではないかと思います。

卓球はもともと人間同士が競技するものなので、一応人間技の範疇ではあり、身も蓋もない話をすると応答速度数十ミリ秒のGPUで予測だけでもできる可能性はあるのかもしれませんが、人間の持つ分解能の高い連続的な応答や、反射神経部分を補うために 1kHz システムがうまく活用されているのだと思います。

当サイトがいつも妄想しているこれですね。

サブサンプション

リアルタイム処理のサブサンプションはちゃんと考えてシステム設計せずに後付けでハイブリッドにしようとすると、以前こちらで書いたような罠に嵌りますので、初期コンセプトがとても大事だと思います。

深層強化学習（RL）によって訓練された制御ポリシーを使用しているようですが、この辺りも興味深いですね。

１ミリ秒クラスの応答は専用ハードウェアを用意しないとGPUでは難しい領域に入ってくるのですが、私の LUT-Netのように１ミリ秒でやれるAIももちろん、ちゃんと専用計算機を用意すればこのクラスの小規模AIももちろん可能なはずです。そしてなによりGPUでちゃんとAIをやるのと組み合わせることが大事ですね。

FPGAの原理と構成

アクチュエーション

こちらはもう全然私の知識では及ばなくなってくるのですが、卓球という競技に対応するための高度な機構設計がなされているようです。

一方で、これらを制御する電気的な仕組みについての課題は述べておく必要があるかと思っています。

汎用ロボットの類はしばしインターフェースが遅いケースがあります。私の知る限り、機構自体の応答性は極めて高くモーターに流れる電流が変化すると同時に電流量に応じた加速度がモーターに加えられます。高校物理の話です。

しかしながら、電流を変化させるまでの手順がしばし問題でして、USBなどは論外としつつも、Ether などでも TCP/IP などをまじめにやるとプロトコルスタックで消費する遅延量は大きいです。折角早く計算してもアクチュエーターに高速に指示が出せなければ意味がありません。

一番良いのは専用のものを作ってマイコンやFPGAから直接的にDACを制御することですが、高度なエンコーダーと制御ループの組まれた既存サーボシステムを置き換えるのも一般に容易ではありません。

で、今回のシステムを見ると EtherCAT の文字が書かれています。EtherCAT は物理層としては Ether 規格に準じながらも、TCP/IP のような複雑なことはせずに、機器をデイジーチェーンして超低遅延で制御する規格です。想像ですがこのような低遅延なI/Fに直接乗り入れできる計算機側の専用ハードウェアと、ロボットメーカーやサーボメーカーが誇る高度な制御システムを低遅延で接続することがある程度うまくいっているのではないかと思います。

EtherCAT 自体は個人では簡単には規格書が手に入らないので、私はオレオレプロトコルで以前に少し遊んだ程度なのですが、物理層としては Ether は非常に優秀で、PC用の機材が使えて安価なのでとても素敵ですね。

産業用ロボット The ビギニング

おわりに

久々にワクワクするニュースが飛び込んできたので、日曜の朝の時間を丸々費やしてしまいましたが、備忘録程度の記事にはなったのではないかと思います。

センシングだけだとなかなかシステムとして可視化できませんが、アクチュエーション入ると楽しいですね。

私も最近FPGAで下記のような１ミリ秒で画像計測の結果をガルバノミラーにフィードバックするおもちゃを作りました。しょぼいですが、年間研究予算は数十万円で一人でやってますのでその点だけは誉めてください(笑)

フィジカルAIという単語が、日本の技術の復権のきっかけになってくれると嬉しいなと思います。

なお、Ace のシステムはあくまで 32ms 後の行動を教師として学習を行っているようです。32ms という応答性は人間には不可能なので、人間からすると超絶技巧なわけですが、裏を返せば卓球という競技は人間でも成り立っているという点で 32ms 後の予測が大いに意味を成す世界なわけです。

ちなみに、私のところでやっている遅延１ミリの超低遅延技術はその10倍早いですので、もし仮に勝てるポイントを追求するとしたら、例えば、テーブルのサイズをどんどん小さくしていき、人間技では競技が成立しない領域に持っていくとか、ランダムに揺れるトラックの荷台で卓球させるとか、予測が効かず、力業の低遅延が生きてくる領域に持ち込んだ際でしょうか。

物理世界は特に人間がかかわるシステムの人間の機械への置き換えは、数十ミリ程度の予測はやりやすいものが多く、遅延で十分で１ミリ秒で予期せぬことに対応する能力が求められることは稀です。

一方で、上のガルバノレーザーのように人間の動きに合わせて遠隔で卓球ロボを制御させるような場合、人間の動きにさらに数十ミリ秒の遅延が乗ると致命的ですので、人間の拡張にAIを使う場合は低遅延は超重要になります。遠隔操作で卓球できるような世界が作れたら面白いとは思います。

私の方は引き続き、そもそも人間には不可能な作業をやらせる や、 人間を拡張する 部分にフォーカスして研究していきたいなと思います。

とはいえこのニュースは衝撃的でしたし、久々に感動させて頂きました。

実践 フィジカルAIの教科書　現実世界へ歩み出すAIの技術と活用事例

生涯技術者でいたいな

はじめに

別に寄席に聞きに行ったりするようなことも無いので、好きというのも語弊があるのかもしれませんが、飛行機に乗ると落語チャネルを聞いてしまったり、テレビ番組を見ていて笑点とかやってるとついつい見てしまう程度には落語とかの演芸は好きではあります。

で、笑点なんかだと歌丸さんにせよ円楽さんにせよ、立派な噺家の先生たちは天寿を全うされる直前まで高座に上がったりされていたわけで、「生涯現役ってこういうことだよなぁ」などとしみじみと思い返してみるわけです。

一方で、私の見てきた世界の大半がサラリーマン技術者の世界であったこともあって、技術者でこれをやれてる人ってあまり見たことないいな？ と、まあそんなことを考えてみたわけです。

実際、サラリーマン技術者ですと、まあ、そもそも管理職にならずに最後まで技術やってる人も案外少ないのですが、それでも60歳で定年となるとそこで技術から離れてしまわれるような方も多かったように思うわけです。 また、再雇用で会社に残ったとして、びっくりするような優秀な方が、これまたびっくりするような安い給料で雑用みたいな仕事をしてたりもまた良くある話でして。

ソフトウェアみたいな業種ですとまだあまりお金かからないからいいのですが、多くの技術は技術をするために設備だったり環境だったりいろんなものが必要ですので、何の準備もなく60歳になって組織から出てしまうと、幾ら技術が好きでもなかなか個人の力では何かを新しく始めるのも大変なのだと思います。

幸か不幸か、私の場合、50歳を迎える前に個人事業主という経験をする機会を得ましたので、次の10年を歩むにあたって何か準備ができないかなどを考えてみている次第です。

歌丸 極上人生 (祥伝社黄金文庫)

日本の技術者のポジション

私の場合、急に組織と言う後ろ盾を失って、途方に暮れていたところいろんな方に助けて頂いて今日があるわけですが、そもそも助けて下さる方がいて、今技術をやれているのは、私自身を会社組織関係なくそれなりにいろんな方に知っていて頂けていたからに他ならないように思います。 会社が会社のブランディングをやるように、個人のブランディングって技術続けるうえで重要なのではないかと改めて思ったわけです。

先の噺家さんの話のように芸能の世界におられる方は、まさに個人名がブランド化しているわけですが、そういえばそもそも日本の技術者ってあまり個人が目立たないよなとふと考えてみました。

アメリカなんかだと IR で、「〇〇開発チームに有名な〇〇氏に参画してもらう事になりました」なんてことは多少あるように思いますが、あまり日本ではそういう話も聞かないので、少し AI に聞いてみたところ

組織としては「誰がやっても同じ品質が出る」状態を理想とするため、特定の個人が目立ちすぎると、その人が離職した際のリスクを過大に評価してしまいます。

と、「あ、なるほど、確かにそういうところあるな」と納得してしまうような答えが返ってきました。

もちろん組織にもよりますし、時代によっても変わりますが、技術は個人ではなく組織に属すことを理想としている組織においては、属人化は仮にそうであっても隠しておきたい事項ですので、あまり個人は表に出さず、建前を通すために給料もだいたいみんな同じぐらい、60歳になれば全員一律定年退職、というのは確かにそうなりそうな気がします。

少し壁打ちしておりましたら AI が表にまとめてくれて、興味深かったので張っておきます。

項目	日本（伝統的企業）	アメリカ（シリコンバレー型）	欧州（ドイツ・北欧等）
技術者の位置づけ	組織を構成する「歯車・設備」	価値を生む「タレント・資産」	高度な「職人・マイスター」
個人名の扱い	組織に隠すべき（属人化リスク）	前面に出すべき（ブランド・信頼）	専門性で評価（ギルド的信頼）
知財（IP）の考え方	全て社内に囲い込む（総取り）	循環させてエコシステムを作る	共有と標準化を重視する
IRでのアピール	特許数、設備投資額	キーマンの経歴、開発コミュニティ	業界標準への貢献、持続可能性
流動性への態度	退職は「裏切り・損失」	退職は「エコシステムの拡大」	安定した専門性の移転
契約の力学	雇用に近い「拘束型」	プロの「知見利用型」	権利と義務の「等価交換型」

伝統的企業って、まあ所謂 JTC(Japanese Traditional Company) とか揶揄されるようなごく一部なところだと思います。

私がかつて20年以上務めた製造業も、最後の方は今風の社風に変わっておりましたが、入社したころはまあ JTC でしたねぇ(笑)。

世界一流エンジニアの思考法 (文春e-book)

如何にして技術者をブランディングするべきなのか

ニュースなんか見ていても、日本企業に勤める技術者の名前が出てくるのはノーベル賞とるぐらいの事をした時で、それですらノーベル賞とるまでは「知る人ぞ知る」レベルというのは良くある話かと思います。そしてこれそのまま社会の縮図であり、「〇〇社の技術はすごい」と知っていても、誰が作ってるかまでは競合他社に勤めていて特許回避に頭を悩ませてる技術者ぐらいにしか知られていない、なんてのは良くある話なのかと思います。

私の場合、学生のころからフリーソフトで ITRON 作って遊んでいただとか、今でいう OSS のようなことをしておりまして、社会人になってもそういう事はやり続けておりましたし、「機密保持義務」とか「副業禁止」とかいろいろあるので、お仕事とは違う技術をMITライセンスでOSSでとかでやるとか、まあ当時は一円にもならないことを地道にやっていたのが、今になって飯のタネになったりしているわけで、人間万事塞翁が馬といいますか不思議なものです。

まあ、私の場合、ソフトウェアというお金のかからない分野だったので何とかなったというところでしょうか。

で、話を戻すと、最終的に 60歳過ぎて、現役で技術者やってる人って結局

• 自分の技術をやるために自分で会社作った人
• 採算度外視して趣味で技術やってる人
• 個人のスキルに投資してくれる強力な支援者がついた人

などがありがちなところな気がします。

少なくとも、何の準備もせずに「他人の作った会社の中でしか知られてない状態で技術やってる」だけだと、定年退職などで組織という後ろ盾を失ったとたんに技術を続けるのがとても難しくなるように思います。

逆に最近の若い方々はこのあたりは良く心得ておられるようで、年寄りなんかより自己アピールの重要性がわかっておられるように感じます。終身雇用にどっぷりつかってきた世代と、ジョブ型雇用と自己責任論で危機感を持っている年代との差なのでしょうか。

転職を繰り返してキャリアアップしていくというのは、常に新しい会社に自己のブランドを売り込む行為ですので、その延長に定年というジョブチェンジを置くというのは、ある意味理にかなっているのかもしれません。

おわりに

結局なんの結論も得ていないのですが、今のところ自営業やっている限りは定年というものは無いようですので、１つでも２つでも世の中の役に立つ技術活動を１年でも長くやっていくことが出来ればなと思う次第です。

あとまあ、長く続けるコツって、多分好きな事をやることな気はしてますので、仕事のマッチングって大事だと思うのですよね。

そしていいお仕事に出会うためには、自分のスキルを高く評価してくれる人々に出会う事であり、やはりクローズにならずにオープンにやっていくというのは長く続けるために大事なことなのかなと改めて思って見た次第です。

三遊亭圓楽1「朝日名人会」ライヴシリーズ126「船徳」「浜野矩随」「一文笛」「ねずみ」