錬金術並みに難しい「FPGA」を、AIで民主化させるLatticeの野望

【図1】Latticeの説明会資料より。ちなみに「この設計者の意図」はさすがにラフすぎるので、実際にはもう少し細かく設定しない(そもそもLatticeのどのデバイスを使うのかすら指定していない)とBitstream生成にはたどり着かないという話だった

　今月も雑談を3つほど。

AI時代のLattice Prompt

　Latticeは9月16日、新FPGAと併せて、Lattice Promptを発表した。

　Lattice Promptとは何か？というと、要するにFPGAの設計をAIコーディングするためのツールである。

　具体的にいえば、既存のAIというか、LLMベースのIDE(Claude CodeだったりCursorだったり)に、LatticeのFPGA向けの設計に必要になるスキルセット+MCPを提供することで、これらのIDE上で直接Lattice用のVHDLを生成できるのだ(図1)。このVHDLはLatticeの開発ツールであるLattice Radiantに直接喰わせることが可能で、そのままBitstream生成まで行ける、というものである。

　実際の事例では、たとえばCUDAで記述されたコードをそのまま読み込ませ、そこからPython→ブロックレベルのRTLを生成する(図2)とか、既に存在するコードのタイミング最適化を行なう(図3)といったことも可能だという。

　LLMベースのIDEそのものはユーザーが契約を行なう必要がある(おそらく無償枠で使える範囲では大したことはできないだろう)が、Promptで提供されるMCPとスキルセットは無料である。要するに、必ずしもHDLに習熟していないユーザーであっても、FPGAのプログラミングが可能になる、という道が公式ツールとして開かれたわけだ。

【図2】途中で一度Pythonを挟むところが面白い

【図3】要件200MHzというのはつまりサイクルタイム5nsで、そこに5nsのタイミング違反というのはサイクルタイム10nsになる。実際元の設計では98MHzでしか動作しなかったらしい

　「FPGAに慣れていないプログラマーにFPGAのプログラミングをしてもらう」というのは昔からFPGA業界の悲願だ。普通のプログラマは山ほどいるが、HDLが書けるプログラマーは非常に少ないため、このプログラマーの少なさがFPGA普及のネックの1つになっていたのだ。

　たとえば、旧Xilinxが昔リリースしたSDSoC(C/C++でFPGA Fabricの設計ができるツール)は、確かにC/C++でプログラミングが可能だったものの、実際に使ったユーザーからすると「初心者とプロの書いたコードで性能が100倍以上違う」とかいう話もあったあたり、実用的か？といわれるとちょっと疑問だった。

　その後、SDSoCの機能はVitisに統合されたが、「HDLを書かずにFPGAをプログラミングする」という観点では決して十分とはいえないというか、やはりFPGAに慣れたプログラマーでないとFPGAの性能を引き出すのは難しかった。これはAlteraのQuartus PrimeとかMicrochipのLibero IDEとかも同じである。

　今回のLattice Promptはこうした流れに一石を投じたものに筆者には思える。

　もちろん現時点では、大規模なFPGAの開発に使うのは無理があるだろう。Latticeは小～中規模のFPGAしかラインナップしておらず、一番大きいAvant-Xでも最大637K SLC(System Logic Cell)、LUT4換算でいえば397,000個でしかない(し、この規模の設計を一発で行なえるかどうかも謎だ)。あとPromptは任意のIDE(というか、LLM)と組み合わせて使えるという話になっているが、どのLLMと組み合わせても同じように最適化ができるのかとかはまだ未知数である。

　そもそも現状でも、まったくRTLを書けないプログラマーがPromptを利用してコードを生成したとして、それが正しいかどうかを判断するのは難しいだろう。

　とはいえ、この方向には、間違いなく可能性がある。おそらくAMDやAltera、Microchipなども、開発ツールにAIコーディングを組み合わせる方向のソリューションを今後リリースするであろうことは想像に難くない。FPGA業界が長らく待ち望んでいた、「RTLの書けないプログラマーにFPGAを扱わせる」ための黒船がやってきた気がする。それがLatticeから最初に出てきた、というのは正直ちょっと意外ではあったが(もっともAMDやAlteraだと、もっと容量の大きいFPGAが山ほどあるから、これをサポートするのに手間取っている可能性はあるが)。

ルネサス GreenPAKの新製品

　FPGAというか、プログラマブルデバイスつながりで。9月24日、ルネサス エレクトロニクスはGreenPAK製品に新しく「SLG46801」を追加した(図4)ことを発表した。

　GreenPAKという製品は、もともとSilego Technologyが開発したアナログデジタル混載のProgrammable Logic Deviceである。このSilegoは2017年にDialog Semiconductorが買収したが、2021年にルネサスがDialogを買収したことでルネサスの製品ラインナップに加わることになった。

【図4】今回の発表資料より。MTP(Multi-Time Programmable)は「複数回の書き込みが可能」という意味であって、別に動作中にプログラムを書き換えられるの意味ではない。低コスト版はOTP(One-Time Programmable)であり、これとの対比である

　ちなみにルネサスは、やはりDialogがラインナップしていた「ForgeFPGA」という小容量FPGAも製品ラインナップに加えている。このForgeFPGAというのは、Dialogが(2024年にADIに買収された)Flex Logixが提供していたEFLX IPのライセンスを受けて開発したもので、現在は1K(1,120)LUTと2K(2,240)LUTの2種類、4つの製品をラインナップしている。

　1,000個あたりの価格でいえば1.67～2.54ドルと非常に安価である。そもそも1K～2K LUTだから、それほどたくさんの機能を実現できるというものではなく、むしろグルーロジック的に利用される用途だから、これでも余るというケースも少なくないだろう。

　ただ、ForgeFPGAは純粋にデジタル回路で、I/OもGPIOとLVDSだけであり、デジタル回路同士をつなぐグルーロジックには十分でもアナログ回路が必要な場合には足りない。

　こうした用途向けに提供されていたのが「GreenPAK」で、以前の説明ではこんなこと(図5)が実現できる、としていた。DialogはこのGreenPAKをCMBU(Configurable Mixed Signal Unit)と称していたが、これ古いところでは旧CypressのPSoC 1/3/5に搭載されていたアナログ回路ブロック(オペアンプとスイッチトキャパシタを組み合わせて任意のアナログ回路を構築できるもの)とか、Microchipの一部MCUに搭載されているIntelligent Analog Moduleとかにも通じる構成である。このCMBUに、わずか(LUT数でいえば10～19)のDigital Blockを組み合わせているのが、現在ラインナップされているGreenPAKである。

【図5】これは2019年、まだDialog Semiconductorの時代の説明会資料

　2024年10月にもTIのPLDの話をご紹介したが、今回わざわざルネサスが新製品を発表したというのは、まだまだ市場ではこうした超小容量Programmable Deviceの需要が高いということなのだろう。

　Latticeも最近では小容量のiCE40シリーズよりもNexusプラットフォームの新製品に力を入れているし、Microchipも最近の新製品はPolarFireシリーズがメインで、旧MicrosemiのIGLOOシリーズは(発売こそしているが)あまり力をいれている感じがない。結果として主要なFPGAベンダーがあまり力を入れていないところに、TIとかルネサスが入り込んでゆくという構図は、歴史は繰り返すという感じで非常に面白いと思う。

熱処理をどうする3D HBM？

　先月の話題もHot Chipsに絡めたわけだが、そのHot Chips初日のチュートリアルがなかなか興味深かった。午前中がメモリ技術、午後がRISC-Vだったのだが、その午前中が

という感じで、もう完全に次の世代HBMの議論になっているわけである。

　ここでの議論をラフに要約すると、消費電力や転送速度の観点から、2.5D(つまりシリコンインターポーザーでASICの横にHBMを置く)で接続するのはHBM5あたりが限界であり、その先はASICの上にHBMを積層する3D HBM(zHBM)の構造になる、としているわけだ(図6、7)。

【図6】Samsungの説明スライドから。帯域が大幅に増え、それでいて消費電力削減になるから結果的にGPUにより多くの電力を供給できるとする

【図7】SK HynixはHBM4世代までのパッケージ技術を中心とした説明で3D HBMに関しては方向性を示しただけだが、まぁやっぱり3Dになるとする

　ちなみにd-Matrixは逆に、DRAMの上にASICを置く構造を提唱している(図8)。

【図8】これはd-Matrixが試作したRaptorと呼ばれる生成AIの推論向けプロセッサのもの。既にEarly Siliconが製造されており、この評価に関しての論文がISCAで発表されている

　で、こうしたものを見ていて筆者が思い出したのは、6月に行なわれたVLSI SymposiumのShort Courseでimecが示したこのスライド(図9)である。

【図9】これはimecのDwaipayan Biswas博士(Program Director, Cross Technology Co-optimization (XTCO) Memory Program)による"3D Augmented Dimensional Scaling with Design-System Technology Co-optimization"という講演のスライドより

　2.5Dだと69.1℃で収まっているメモリの温度は、単に乗せただけだと141.7℃まで跳ね上がる。そこから一生懸命ダイの余分なものを削ったりしても大して減らず、結局GPUの動作周波数を半減させ(これで120℃→99.2℃まで下がる)、さらに両面冷却(87.4℃→70.8℃まで下がる)を組み合わせて、やっと常用できる範囲になるとしているわけだ。

　つまり、全部で70.9℃温度を下げる要素のうち、ダイを削ったり最適化したりといったことで減るのは33.5℃分しかなく、残りは動作周波数を落とす(=性能も半減)+力業の強制冷却が37.4℃と、こっちの方が冷却効果が大きい、という試算が示されている。

　逆にいえば、動作周波数を下げないままだとHBMの温度は90℃を超える計算で、なんかリフレッシュ間隔が定格の10分の1ぐらいに減りそうな気もしなくもない。

　なんというか、まず高温でも動作するDRAMを作るのが先ではないか？というのが率直な感想なのだが、HBM5の先は本当に3D積層に移行するのだろうか？(もちろん発熱が少ないASICの上に載せるのはアリなのだろうが)。