NVIDIA Research が HORIZON を発表、無人監視エージェントが RTL チップ設計ベンチマーク全体を100%通過に押し上げる
- NVIDIA Research が提案する HORIZON は、ハードウェア設計をリポジトリレベルのコード進化として管理する。ユーザーは1本のMarkdown仕様書を書くだけで、システムがそれを自動的に「プロジェクトパック」にコンパイルし、無人監視のエージェントループが隔離されたGitワークスペースで繰り返しコードを修正・シミュレーションを実行し、検証に通れば初めてコミットされる。
- ChipBench、RTLLM-2.0、Verilog-Eval、そして9つのCVDP検証カテゴリにおいて、HORIZONは同一の無人監視ループで全ベンチマークを100%通過率に到達させた。
- エージェントの初回イテレーションの総合通過率はわずか47.8%、最難関のCVDPチェッカー生成カテゴリでは初回わずか3.8%。同じループが最終的に全カテゴリを100%まで磨き上げるが、1~2ラウンドで通過する問題もあれば、82ラウンドを要する問題もある。
- 正確性が飽和した後は、トークンコストこそが真の差別化シグナルとなる。9つのCVDPカテゴリだけで全トークンの97.1%（約2億390万）を消費し、そのうち約91%は再利用可能なキャッシュ入力だった。
- 著者らは「エージェント型ハードウェア設計が解決済み」とは明言しておらず、現行のフィードバック機構には「過剰最適化／報酬ハッキング」のリスクがあると指摘。今後のベンチマークではデバッグ用フィードバックと最終的な隠しスコアリングを分離すべきだと提言している。
NVIDIAのこの論文が言っていること
NVIDIA Researchチームは最近、エージェント型ハードウェア設計フレームワーク HORIZON を提案する論文を発表した。チップ設計をリポジトリレベルのコード進化として管理する枠組みだ。
システムに1本のMarkdown仕様書を渡すだけで、まったく人の目が付かない状態のエージェントが隔離されたGitワークスペースの中で繰り返しコードを修正し、シミュレーションを走らせ、検証に通ったときだけコミットする。最終的にはRTL（レジスタ転送レベルのハードウェア設計。チップ内の各クロックでの動作をコードで記述する層）ベンチマーク一式を丸ごと100%通過させてしまう。
AIにVerilogを一度書かせるだけでは全然足りない理由
Verilogはチップのロジックを記述するハードウェア用コードだ。RTL設計は鋭い試金石になる。あるモジュールが正しいかどうかは、クロックの各拍での挙動、リセットの取り決め、インターフェースのハンドシェイク、各信号のビット幅、そしてシミュレーターが吐き出すフィードバックにかかっている。だから「一見それらしく見えるVerilog」はまるで足りない。
モデルは自分でデータパスのビット幅、ステートマシンの遷移、リセットの取り決め、ready-valid ハンドシェイクプロトコル、メモリの読み書き、さらに自然言語ではしばしば明記されないエッジケースまで推論しなければならない。つまり、文法的に正しいモジュールはあくまでスタート地点にすぎない。本当に役立つ自動化には、「書く」ことを「コンパイル、シミュレーション、波形と失敗トレースの確認、そして修正」という一連の流れに接続する必要がある。一周してみて違っていればまた戻って直し、直したらまた走らせる。
HORIZONの核心的な発想は、この一連の流れを丸ごと自走可能なループに閉じ込めてしまうことだ。
1本の仕様書がどうやって自走可能なプロジェクトパックになるか
ユーザーが提供する唯一の入力は、構造化されたMarkdown仕様書であり、コードではない。そこには高レベルの意図、リポジトリのコンテキスト、期待される成果物、評価基準、そしてドメイン知識が書かれる。ドメイン知識は特に有用だ。なぜなら、ファイルを見ただけでは推測できない不変条件、ツールの取り決め、失敗パターンを明示的に書き出せるからだ。
「ブートストラップエージェント」がこの仕様書を「プロジェクトパック（project pack）」にコンパイルする。これがシステム全体のコントロールプレーンとなる。仕様書は4つの構成要素を持ち、それらは5つ組のランタイム設定にコンパイルされ、無人監視ループを駆動する。
- 目標／タスク
- ドメイン知識の指針
- 評価器の仕様
- 受け入れ基準
π_agentポリシープロンプトとツール契約E_p実行可能な評価器（コンパイル／シミュレーション／カバレッジ）A_p受け入れ基準（コミット可否）Γ_pバージョン管理と成果物ポリシーΩ_pドメインスキルとリポジトリ操作手順
- 状態を読む
- ワークスペースを編集
- 評価ツールを呼ぶ
- 修正またはコミット
プロジェクトパックは新入社員に渡す完全な入社資料一式のようなものだ。何をすべきかだけでなく、評価基準、ツールの使い方、引き継ぎ手順まで書かれている。社員はこれを一通り読めば独り立ちできる。そばに誰かが付いて説明する必要はない。
重要なのは、この問題が特定のチップ用リポジトリ形式にではなく、汎用的なGitワークスペース上で定義されている点だ。だからこの組み立て方はRTLやEDAに専属するものではない。あるタスクが「永続的なGitワークスペース」「機械的にチェック可能なフィードバック」「バージョン管理された成果物」の3条件を備えてさえいれば、同じやり方で組み立てられる。分野を変えれば、評価器のスロットはユニットテスト、定理証明器、パフォーマンスプロファイラー、セキュリティスキャナー、論理合成ツール、あるいは人手によるレビューゲートにも置き換えられる。