FluxBench、チップ設計エージェントを完全なRTL-to-GDSフローへ――同一モデルでもアーキテクチャ次第で最大86%の性能差

最近、技術コミュニティで注目を集めている研究がFluxBenchを提案した。AIコーディングエージェントが、もっともらしいVerilogコードを生成するだけでなく、チップ設計のRTL-to-GDSフローを実際に完遂できるのかを検証する試みだ。評価では、プロンプト、ツール環境、technology libraryを固定し、RTL生成、コンパイラのフィードバックに基づく反復修正、論理合成、placement and routing、Engineering Change Order（ECO）の自動化までを対象とする。オープンソースのツールチェーンに加え、PicoRV32を事例とした非公開の商用EDAフローも含まれている。

中心的な発見は、基盤モデルが同じでもエージェントの性能は収束しないという点だ。著者らによると、異なるエージェントシステムアーキテクチャ間のタスク性能差は最大86.27%に達した。達成度が近いシステム同士でも、tokenおよび実行コストに対する有効な設計改善を測るToken ROIには、最大105.92倍の差が生じた。研究で提案されたFluxEDAは、PicoRV32のエンドツーエンド評価で最高97.94を記録し、ドメイン固有のSkillを搭載したClaude Codeと比べて最大8.39倍の性能を達成したとしている。これは重要なエンジニアリング上の判断を裏付ける。すなわち、プロンプト用ドキュメントやドメイン知識を追加するだけでは、状態管理、エラーリカバリ、ツールフィードバックの解析、工程間のコンテキスト受け渡しを代替できない。

ただし、これらの倍率を先端チップへ直接外挿することはできない。論文が対象とするフレームワークとモデルは限られており、非公開の産業用フローも1種類にとどまる。一部のツールや環境については、外部研究者による完全な再現も難しい。また、エンドツーエンドスコアとToken ROIは、いずれも著者らが設計した指標である。さらに、arXivの記録によるとv2は一度撤回され、v3が7月23日に再アップロードされているため、数値を引用する際は最新版を参照すべきだ。今後注目すべき点は、公開harness、より大規模なRTLと多様なプロセスノード、そしてエージェントの生成結果が単にツールフローを完了するだけでなく、形式検証、タイミングクロージャ、消費電力制約を通過できるかどうかである。