研究解説・小互解読

NVIDIA Research が HORIZON を発表、無人稼働のエージェントが RTL チップ設計ベンチマーク全種を100%通過に押し上げる

論文で初めて、エージェントが完全無人稼働のまま全 RTL ベンチマークを走破。大半の問題は2〜3ラウンドでクリアするが、最難関の一問だけは82ラウンドの反復が必要だった
概要
  • NVIDIA Research が提案した HORIZON は、ハードウェア設計をリポジトリレベルのコード進化として扱う。ユーザーは1本の Markdown 仕様書を書くだけで、システムがそれを自動で「プロジェクトパック」にコンパイルし、無人稼働のエージェントが隔離された Git ワークスペース内でコードの修正とシミュレーションを繰り返し、検証に通って初めてコミットする。
  • ChipBench、RTLLM-2.0、Verilog-Eval、そして CVDP の9つの検証カテゴリで、HORIZON は同一の無人稼働ループを使って全ベンチマークを100%通過率に引き上げた。
  • エージェントの初回イテレーションの集計通過率はわずか47.8%、最難関の CVDP チェッカー生成カテゴリの初回はわずか3.8%。同じループが最終的にすべてのカテゴリを100%まで磨き上げたが、1〜2ラウンドでクリアする問題もあれば、82ラウンドの反復を要する問題もあった。
  • 正しさが飽和したあとは、トークンコストこそが本当の差別化シグナルになる。9つの CVDP カテゴリだけで全トークンの97.1%(約2億390万)を消費し、そのうち約91%は再利用可能なキャッシュ入力だった。
  • 著者は「エージェントによるハードウェア設計はすでに解決済み」とは明言しておらず、現行のフィードバック機構には「過剰最適化／報酬ハッキング」のリスクがあると指摘し、今後のベンチマークではデバッグ用フィードバックと最終的な隠し採点を分離すべきだと提案している。
01NVIDIA のこの論文が言っていること

NVIDIA のこの論文が言っていること

NVIDIA Research チームは先ごろ論文を発表し、エージェント型ハードウェア設計フレームワーク HORIZON を提案した。チップ設計をリポジトリレベルのコード進化として扱う枠組みだ。

システムに1本の Markdown 仕様書を渡すと、誰も見張っていないエージェントが隔離された Git ワークスペースの中でコードの修正とシミュレーションを繰り返し、検証に通ったものだけをコミットし、最終的には RTL(レジスタ転送レベル。チップの各クロックでの動きをコードで記述する層)のベンチマーク一式を丸ごと100%通過に持っていく。

⚑
なぜ注目に値するか:著者らの知る限り、これは人手を介さずにエンドツーエンドで、評価対象の RTL ベンチマークスイート全体をやり遂げた初のエージェントシステムであり、ChipBench、RTLLM-2.0、Verilog-Eval、そして9つの CVDP カテゴリを網羅し、すべてで100%通過率を達成している。
HORIZON のアーキテクチャ全体図: Markdown 仕様書 → project_pack 制御プレーン → 無人稼働エージェントループが、Git ワークスペース上で進化していく
論文 Figure 1 のアーキテクチャ全体図。ユーザーが書いた Markdown 仕様書は project_pack という制御プレーンにコンパイルされ、無人稼働のエージェントループを駆動して Git ワークスペース上で絶えず進化させる。出典: NVIDIA Research／marktechpost
02まず押さえたいこと: 一度 Verilog を書くだけではまるで足りない理由

なぜ AI に一度だけ Verilog を書かせるのでは全然足りないのか

Verilog はチップのロジックを記述するハードウェアコードだ。RTL 設計は鋭利な試金石だ。あるモジュールが正しいかどうかは、クロックの各拍での挙動、リセットの取り決め、インターフェースのハンドシェイク、信号ごとのビット幅、そしてシミュレータが出す結果まで見て初めてわかる。だから「一見それらしい Verilog」というだけでは全く足りない。

モデルは自分でデータパスのビット幅、ステートマシンの遷移、リセットの取り決め、ready-valid ハンドシェイクプロトコル、メモリの読み書き、それに自然言語ではしばしば書かれていない細かなエッジケースまで推測しなければならない。つまり、文法的に正しいモジュールはあくまでスタート地点にすぎない。本当に役立つ自動化は、「書く」ことを「コンパイル、シミュレーション、波形と失敗トレースの確認、そして修正」という一連の鎖につなげ、一周回して不具合を見つけたら戻って直し、直したらまた回す、という形になっていなければならない。

モジュールを書く
→
コンパイル
→
シミュレーション
→
波形／失敗トレースを確認
→
修正
↺

HORIZON の核心的な発想は、この一連の鎖全体を自ら回り続けるループに閉じ込めてしまうことだ。

03コア設計その1: 1本の仕様書がどうやって自走可能なプロジェクトパックになるか

1本の仕様書がどうやって自走可能なプロジェクトパックになるか

ユーザーが唯一提供すべき入力は、構造化された Markdown 仕様書であり、コードではない。そこには高レベルの意図、リポジトリの文脈、期待される成果物、評価基準、そしてドメイン知識が書かれる。ドメイン知識は特に有用だ。ファイルを見ただけでは推測できない不変条件、ツールの慣習、失敗パターンを明示的に書き出せるからだ。

「ブートストラップエージェント」がこの仕様書を「プロジェクトパック(project pack)」にコンパイルする。これがシステム全体の制御プレーンとなる。仕様書は4つのコンポーネントからなり、それらは5つ組のランタイム設定にコンパイルされ、無人稼働のループを駆動する。

① Markdown 仕様書
  • 目標／タスク
  • ドメイン知識のガイドライン
  • 評価器の仕様
  • 受理基準
→
② プロジェクトパック(5つ組)
  • π_agent ポリシープロンプトとツール契約
  • E_p 実行可能な評価器(コンパイル／シミュレーション／カバレッジ)
  • A_p 受理基準(コミットできるかどうか)
  • Γ_p バージョン管理と成果物ポリシー
  • Ω_p ドメインスキルとリポジトリ操作の手順
→
③ 無人稼働ループ
  • 状態を読む
  • ワークスペースを編集
  • ツールを呼んで評価
  • 修正またはコミット
たとえて言うと・プロジェクトパック

プロジェクトパックは、新入社員に渡す一式の入社資料のようなものだ。何をすべきかだけでなく、評価基準、ツールの使い方、引き継ぎ手順まで添えてある。社員はこれを読めば独り立ちして仕事を始められ、誰かがそばに張り付いて説明する必要がない。

Hero・RTL に縛られない

肝心なのは、問題が特定のチップ用リポジトリ形式ではなく、汎用の Git ワークスペース上で定義されている点だ。だからこの組み立て方は RTL や EDA 専用ではない。「永続的な Git ワークスペース+機械的にチェック可能なフィードバック+バージョン管理された成果物」という3条件さえ揃えば、同じやり方で組織できる。領域を変えれば、評価器の枠はユニットテスト、定理証明器、性能プロファイラ、セキュリティスキャナ、論理合成ツール、あるいは人手によるレビューゲートに差し替えられる。