CktEvo: Repository-Level RTL Code Benchmark for Design Evolution

本論文は、大規模言語モデル（LLM）がハードウェア設計の機能性を維持しつつ電力・性能・面積（PPA）を改善するリポジトリレベルの RTL 進化を評価するためのベンチマーク「CktEvo」と、ツールチェーンからのフィードバックを用いた自動改善フレームワークを提案し、実用的な設計最適化への道筋を示すものである。

要約

🏗️ 物語の舞台：半導体の設計室

半導体（CPU やメモリなど）を作るには、設計者が「RTL（レジスタ転送レベル）」という、いわば**「電子回路の設計図（Verilog という言語で書かれたもの）」**を書きます。

この設計図は、単なる 1 つのファイルではなく、**何十、何百ものファイルが複雑に絡み合った「巨大な図書館」**のようなものです。

• 目標: 電力（Power）、性能（Performance）、面積（Area）のバランス、通称**「PPA」**を最善にすること。
• 現状の課題: 設計図は完成しても、さらに「もっと小さく、もっと速く」できないか？と試行錯誤します。しかし、人間が一つずつファイルを見て修正するのは大変で、AI に任せるには「文脈（他のファイルとの関係）」を理解させるのが難しかったのです。

🚀 登場するヒーロー：CktEvo（シクエボ）

この論文が提案したのは、**「CktEvo」という新しい仕組みです。
これは、AI が設計図を「ゼロから作る」のではなく、「既存の完成された設計図を、AI が自動でリファイン（改良）していく」ための「試験場（ベンチマーク）」と「自動運転システム」**です。

🧩 3 つの重要なポイント（日常の例えで）

1. 「断片」ではなく「全体」を見る

• これまでの AI: 料理のレシピの「卵を割る」部分だけを見て、「もっと美味しくなるように」と言われても、鍋の火加減や他の具材との関係がわからないため、失敗しやすい。
• CktEvo: 料理全体（レストランのメニュー）を見て、「この料理の材料を少し変えれば、お店全体の利益（PPA）が上がる」と提案します。
  • 例え: 巨大な図書館（設計図）の中で、特定の本（モジュール）を直すだけでなく、その本が他の本とどう繋がっているかを理解して直します。

2. 「自動運転」のループ（クローズドループ）
AI が適当に直して「これで OK！」とするのではなく、**「AI が提案 → 工具でチェック → 失敗したら直す → また AI が提案」**というループを回します。

• 例え:
  1. AI（料理人見習い）: 「このレシピ、卵を 2 個減らして、塩を少し増やせば美味しそう！」と提案。
  2. EDA ツール（厳格な味見担当）: 「うん、味はいいけど、塩分濃度が基準を超えてる（エラー）」と指摘。
  3. AI: 「了解、塩を戻して、代わりに火加減を変えよう」と修正。
  4. 味見担当: 「よし、基準内だし、味も良くなった（機能は変わっていない）」と合格。
  • この「味見（検証）」を AI 自身が繰り返すので、「壊れた設計図」が完成品として出てくることはありません。

3. 「ボトルネック」を見つける探偵
AI は闇雲に直すのではなく、**「どこが一番遅いのか、どこが面積を占めているのか」**をツールから教えてもらい、そこだけを狙い撃ちで直します。

• 例え: 渋滞している道路（設計図）で、AI は「あそこの交差点が詰まっているから、信号のタイミングを変えよう」というように、問題の核心だけを突いて直します。

📊 実験の結果：どれくらい良くなった？

研究者たちは、このシステムを使って 11 種類の異なる設計図（CPU や通信機器など）を改良しました。

• 結果: 人間の介入なしで、「面積（チップの大きさ）」と「遅延（処理速度）」の両方を同時に改善することに成功しました。
  • 特に、「処理速度（遅延）」は約 8% 向上し、「面積×速度」の総合スコアは約 10.5% 改善されました。
• 驚き: すでにプロの設計者が完成させた設計図でも、AI は「もっとこうすればいい」という新しい発見（例：状態遷移図の整理、無駄な回路の削除）を見つけ出し、さらに最適化できました。

🌟 この研究がなぜすごいのか？

1. AI は「生成」から「進化」へ:
   今までの AI は「ゼロからコードを書く」のが得意でしたが、CktEvo は**「完成されたものをさらに良くする」**という、より高度で実用的なタスクに挑戦しています。
2. 安全な自動化:
   「AI が勝手に直して、回路が動かなくなったらどうしよう？」という心配を、厳格な自動チェック機能で解消しています。
3. 未来への布石:
   これは、AI が単なる「コードを書く助手」から、「設計の専門家（シニアエンジニア）」として、半導体開発の現場で自律的に活躍する第一歩です。

💡 まとめ

この論文は、**「AI に半導体の設計図を『自動で磨き上げ』させるための、新しいルールと練習場」**を作ったという報告です。

まるで、**「完璧に完成された自動車を、AI が自動でパーツを交換して、より燃費が良く、速い車に進化させる」**ようなイメージです。これにより、将来は半導体開発のスピードが劇的に上がり、より高性能で安価なチップが生まれることが期待されています。

技術概要

CktEvo: デザイン進化のためのリポジトリレベル RTL コードベンチマーク

技術的サマリー（日本語）

本論文は、大規模言語モデル（LLM）を用いたハードウェア設計の自動化において、既存の課題を解決し、産業レベルの実用性を追求する新しいベンチマーク「CktEvo」と、それを支える閉ループ進化フレームワークを提案するものです。

1. 背景と課題 (Problem)

現在の LLM を活用したハードウェア設計の研究には、以下の 2 つの主要なギャップが存在します。

• 自然言語からの生成・デバッグの限界: 既存の多くは自然言語プロンプトからの RTL 生成やデバッグに焦点を当てていますが、曖昧さやハルシネーションにより、機能的・セキュリティ要件を満たさないコードが生成されやすく、専門家によるレビューが必須となります。
• モジュール単位の最適化と依存関係の欠如: 形式入力（C/C++ や HLS）からの最適化や、単一モジュールの改善に留まる研究が多く、ファイル間依存関係（Cross-file dependencies）を考慮して、リポジトリ全体としての Power, Performance, Area (PPA) を最適化するアプローチが不足しています。

実際の RTL 設計は、複数のファイルとツールチェーンの相互作用から PPA が生まれる「リポジトリ規模の反復プロセス」です。この現実的なプロセスを LLM に適用するための基準と枠組みが求められていました。

2. 提案手法とメソドロジー (Methodology)

2.1 タスクの定式化

CktEvo は、初期の「ゴールドデザイン（未最適化だが機能的に正しい）」リポジトリを与えられ、機能性を維持したまま、PPA メトリクス（特に面積と遅延）を改善する一連の編集を行うタスクを定義します。

• 入力: 複数の Verilog ファイルからなるリポジトリ $D_0$ と制約ファイル $\Phi$。
• 出力: 機能等価性を保ちつつ、コスト関数 $J$（面積 $\times$ 遅延）を最小化するリポジトリ $D_T$。
• 検証: 論理等価性チェックツールによる形式検証と、論理合成・静的タイミング解析（STA）による評価が必須です。

2.2 CktEvo ベンチマーク

• 構成: 11 種類の高品質なオープンソース RTL デザイン（プロセッサ、コントローラ、高速インタフェース、エンコーダ/デコーダなど）を収録。
• 特徴: 単一モジュールではなく、ファイル間依存関係を持つ完全な IP コアを対象とし、Yosys（オープンソース）と商用ツールチェーンの両方で合成可能な安定性を保証しています。
• 規模: 数百行の簡易設計から、42 モジュール構成の RISC コア（risc）など、多様なスケールを網羅。

2.3 閉ループ進化フレームワーク

LLM を駆使した自律的な最適化を行うための参照フレームワークを提案しています（図 1 参照）。

1. EDA ツールチェーンによる評価: 現在の設計を合成・解析し、面積とタイミングレポートを取得。
2. グラフベースコードアナライザ: RTL ソースを制御データフローグラフ（CDFG）に変換し、EDA ツールのレポートからボトルネック（クリティカルパス、高面積モジュール）を特定し、コードに注釈付けを行います。
3. プロンプトジェネレータ: 注釈付きの CDFG と RTL スニペットを文脈として LLM に提示し、具体的な修正コード（diff 形式）を生成させます。
4. 修正と直修正（Rectification）: 生成されたコードの構文エラーを LLM 自身で修正。
5. 形式検証: 修正後のコードが元のゴールドデザインと機能的に等価かを確認。等価であれば採用、そうでなければロールバックまたは微調整を行います。
6. 進化アルゴリズム: 「島モデル（Island-based）」を採用し、複数の個体群（島）間で多様性を保ちながら、成功した進化をアーカイブに蓄積し、次の世代の親として利用します。

3. 主要な貢献 (Key Contributions)

1. リポジトリレベル RTL 進化タスクの定式化: 機能保存を前提とした、エンドツーエンドの検証と論理合成フローに紐付いた PPA 最適化タスクを確立。
2. 初のベンチマーク「CktEvo」の公開: 11 種類の多様なカテゴリにわたる、人間がレビューした高品質なマルチファイル Verilog デザインを収録。
3. 閉ループ進化フレームワークの提供: ツールチェーンからのフィードバック、ファイル間編集、反復的な修復を可能にする LLM ベースの参照実装。

4. 実験結果 (Results)

4.1 オープンソースツールチェーンでの結果

Yosys と Skywater130nm ライブラリを用いた実験では、LLM（DeepSeek-v3, GPT-4o, Qwen3-coder）が人間の介入なしに PPA 改善を達成しました。

• 全体性能: DeepSeek-v3 を使用した場合、ADP（面積×遅延）の平均 10.50% 削減を達成。
• 遅延改善: 面積削減（2.80%）に比べ、遅延削減（7.92%）の効果が顕著でした。特に hsm（ハードウェアセキュリティモジュール）ではタイミングが 34.97% 改善されました。
• 設計特性による差異: コントロール集約型の設計（mem_ctrl, risc など）では大幅な改善が見られましたが、成熟した標準インタフェース（usb, ethmac）では改善が限定的でした。

4.2 商用ツールチェーンでの結果

Synopsys Design Compiler（compile_ultra）を用いた実験では、改善幅は小さくなりましたが（ADP 1.77% 削減）、依然として有効性を示しました。

• 理由: 商用ツールの最適化能力が非常に高いため、LLM が生成した RTL レベルの変更が、ゲートレベルのネットリストにおいて元のコードと同等化されてしまうケースが多いためです。
• 意義: すでに最適化された設計においても、audio デザインでクリティカルパス遅延を 10.61% 削減するなど、産業レベルで価値のある微細な改善を自動化で達成できることを示しました。

4.3 コード進化の分析

LLM はランダムな変更ではなく、以下の 3 つの戦略的アプローチを適用していました。

1. コーディングスタイルの最適化: 合成ツールが効率的に処理しやすい構文への変換（ブロッキングからノンブロッキング代入への変更など）。
2. ロジックの平坦化と剪定: 深いネストされた条件分岐の並列化、タイミング余裕があるパイプラインレジスタの削除。
3. 状態機械の最適化: 複数の状態フラグを統合したバイナリエンコード状態レジスタへのマージ、冗長状態の削除。

5. 意義と将来展望 (Significance & Future Work)

• 実用性の確立: CktEvo は、LLM を単なる「コード生成器」から、ツールチェーンのフィードバックを踏まえて設計を「進化させるエンジニア」へと昇華させるための厳密な基盤を提供します。
• 今後の課題:
  • 局所最適化からアーキテクチャ改修へ: 現在の LLM はローカルなコーディングスタイルの改善に留まりがちです。将来の研究では、リポジトリ全体を俯瞰し、データフローや制御フローを再構築する高レベルなアーキテクチャ変換を行うエージェントの開発が必要です。
  • ドメイン適応: 特定の PDK や EDA ツールチェーンに特化した「最適化ルール」を LLM に学習・適用させるための手法（RAG やドメイン適応型ファインチューニング）の検討が不可欠です。

本論文は、ハードウェア設計の自動化において、LLM が実務的な PPA 改善を自律的に達成できる可能性を証明し、そのための標準的な評価基準と手法論を確立した点で画期的です。