ODIN-Based CPU-GPU Architecture with Replay-Driven Simulation and Emulation

本論文は、ODIN チップレットアーキテクチャにおける CPU-GPU 統合の検証課題を解決するため、単一の設計データベースを用いた決定論的な波形の記録と再生（リプレイ）手法を提案し、複雑なシステムレベルのデバッグを加速し、1 四半期でのエンドツーエンドのシステム起動とワークロード実行を実現したことを報告しています。

要約

🎬 映画の撮影現場に例えた「リプレイ（再演）方式」

この論文の核心は、**「リプレイ・ド・シミュレーション（再生駆動シミュレーション）」**という技術です。これを映画撮影に例えてみましょう。

1. 従来の方法：毎回「即興劇」をする大変さ

以前は、CPU と GPU をつなぐテストをするとき、以下のような大変なことがありました。

• CPUは「監督」で、GPUは「俳優」です。
• 監督が「アクション！」と叫ぶと、俳優（GPU）が即興で演技をし、その反応を監督がチェックします。
• しかし、GPU という俳優は**「毎回違う演技」**をすることがあります（ランダムな要素や、複雑なタイミングの問題など）。
• トラブルが起きたとき、「さっきの演技、もう一度同じようにやってくれない？」と頼んでも、俳優は**「あの時の気分じゃ無理」**と言います。
• その結果、監督（開発者）は「どこでミスしたのか？」を特定するために、何時間も何日もかけて「さっきのシーン」を再現しようとして疲れ果てていました。

2. 新しい方法：「完璧な録画」を再生する

この論文で Intel などが開発した方法は、**「録画された映像を再生する」**というアプローチです。

• ステップ 1：完璧なリハーサル（キャプチャ）
  まず、GPU 単体のテストで、完璧な演技（データの流れや反応）を**「高画質で録画」**しておきます。この録画には、「監督の指示（リクエスト）」と「俳優の反応（レスポンス）」の両方が含まれています。
• ステップ 2：脚本化（ROM 化）
  その録画データを、コンピューターが読み込める「脚本（ROM）」に変換します。
• ステップ 3：本番での再生（リプレイ）
  いよいよ CPU と GPU をつなぐ本番（システム全体のテスト）です。
  • 監督（CPU）が指示を出すと、「録画された脚本」が自動的に再生されます。
  • GPU は「即興」ではなく、**「録画された完璧な演技」**をそのまま受け取ります。
  • もしトラブルが起きても、「同じ脚本」を何度でも再生できるため、「さっきと同じ状況」を瞬時に再現できます。

🚀 なぜこれがすごいのか？

この「録画再生方式」を使うと、以下のようなメリットが生まれます。

1. トラブルの特定が爆速になる
   「さっきエラーが出た！」と思ったら、**「同じ録画をもう一度流す」**だけで、全く同じエラーが再現できます。「いつ、どこで、何が悪かったか」が一目でわかります。
2. シミュレーションと実機テストが同じ
   以前は、パソコン上でのシミュレーションと、実際のハードウェア（FPGA など）でのテストで、準備する道具（シナリオ）が違っていました。でも、この方法なら**「同じ録画データ」**を両方で使えるので、準備が楽になり、結果のズレもなくなります。
3. 開発期間の短縮
   複雑な「即興劇」を用意する手間が省けるため、**「1 四半期（3 ヶ月）」**という短期間で、CPU と GPU が完璧に連携して動くシステムを完成させることができました。

🧩 チップレットという「レゴブロック」の文脈

最近のコンピューターは、大きな一塊のチップではなく、「レゴブロック」のように小さな部品（チップレット）を組み合わせる方式が主流になりつつあります。

• CPU ブロック
• GPU ブロック
• 通信路（NoC）ブロック

これらを組み合わせる際、ブロック同士の「会話（プロトコル）」が複雑になりすぎて、トラブルが起きやすくなります。この論文の方法は、**「レゴブロック同士をつなぐ瞬間の『会話』を録画して、後で完璧に再現する」**ことで、複雑な組み合わせを安全にテストできる仕組みを作りました。

💡 まとめ

一言で言えば、この論文は**「複雑なコンピューター回路のテストにおいて、『毎回違う反応をする俳優』に頼らず、『完璧に録画された映像』を再生することで、開発を劇的に加速させた」**という画期的な手法を紹介したものです。

これにより、AI やグラフィック処理を担う次世代のコンピューターが、より早く、より確実に世の中に届けられるようになったのです。

技術概要

ODIN ベースの CPU-GPU アーキテクチャにおけるリプレイ駆動シミュレーション・エミュレーション手法に関する技術サマリー

本論文は、Intel 社および関連企業によって提出されたもので、ODIN（On-Demand Integrated Node）と呼ばれるチップレットベースのアーキテクチャにおいて、CPU サブシステム、複数の Xe GPU コア、および構成可能なネットワーク・オン・チップ（NoC）を統合する際に直面する検証の課題と、それを解決するための**「リプレイ駆動検証手法（Replay-Driven Validation Methodology）」**について詳述しています。

以下に、問題定義、手法、主要な貢献、結果、および意義について詳細にまとめます。

---

1. 背景と課題 (Problem)

現代の AI やグラフィックワークロード向け SoC 設計において、制御指向の CPU と大規模並列計算能力を持つ GPU の統合は不可欠です。しかし、チップレットベースのアーキテクチャへ移行する中で、以下のような複雑な検証課題が発生しました。

• 大規模設計と高並列性: CPU、GPU、NoC が緊密に結合しており、設計規模が巨大である。
• 非決定性の実行: GPU の実行フローはメモリ依存性が強く、ランダム化されたメタステービリティ検証やパイプラインのステージングにより、シミュレーション環境での挙動の再現性が困難。
• プロトコルの複雑さ: 起動（ブート）、電源管理、タイミング、クロック制御などのプロトコルが複雑で、多くの場合プロプライエタリなインターフェースを使用する。
• シミュレーションとエミュレーションの断絶: 従来のバス機能モデル（BFM）ベースのフローでは、シミュレーションからエミュレーションへ移行する際にモデルの再コンパイルや設定変更が必要となり、設計データベースが分断され、整合性を保つのが困難だった。
• デバッグの困難さ: システムレベルでの不具合発生時、IP 実装、統合ロジック、システムレベルの相互作用のいずれが原因かを特定する（ルート・コーズ分析）のに多大な時間とリソースを要する。
• 検証サイクルの長期化: 現実的なワークロードでのフルチップ RTL シミュレーションは遅すぎて非現実的であり、エミュレーションは内部信号の可視性が限られる。

2. 提案手法：リプレイ駆動検証 (Methodology)

これらの課題を解決するため、**「リプレイエンジン（Replay Engine）」**を用いた検証手法が導入されました。この手法の核心は、スタンドアロンの GPU IP 検証時に取得した波形データを、システムレベルの検証（シミュレーションおよびエミュレーション）で決定論的に再生成することにあります。

2.1 リプレイエンジンのアーキテクチャ

• 波形のキャプチャ: GPU IP の周辺部（アーキテクチャ的に可視なデータ、制御、レスポンス信号）で、サイクルレベルの正確な波形をキャプチャします。
• BFM の不要化: 従来の BFM（バス機能モデル）のように、GPU の出力を消費してレスポンスを生成する動的なモデルは不要です。キャプチャされた波形には「リクエスト（刺激）」と「レスポンス（応答）」の両方が含まれているため、リプレイ時にこれらを再生成するだけで、応答するエージェントが存在しているように振る舞います。
• ROM 初期化フロー:
  1. キャプチャ: スタンドアロン GPU 検証中に波形を記録。
  2. オフライン変換: 記録された波形からインターフェース信号を抽出し、サイクル順序付きのビット表現に変換。刺激と応答をコンパクトな形式でエンコード。
  3. ROM 初期化: エンコードされたデータを SoC 設計内の ROM に格納。
  4. 実行: シミュレーションまたはエミュレーション実行時、Replay Engine がこの ROM 内容を読み取り、決定論的に波形を再生します。

2.2 シミュレーションとエミュレーションの統合

• 共通の設計データベース: シミュレーションとエミュレーションの両方で、単一の設計データベースと YAML ベースの構成、そして共有された「リプレイアーティファクト（波形データ）」を使用します。
• 役割分担:
  • シミュレーション: 詳細なデバッグ、波形の可視性、ルート・コーズ分析に利用。
  • エミュレーション: 高速なシステムレベル実行、長時間のワークロード実行に利用。
• 利点: 両環境間で刺激メカニズムが統一されているため、エミュレーションで発見された問題をシミュレーションで確実に再現し、詳細な解析を行うことが可能になります。

3. 主要な貢献 (Key Contributions)

1. 決定論的リプレイ手法の確立: GPU の複雑なプロトコル（ブート、電源管理など）を、BFM に依存せず、キャプチャされた波形データから決定論的に再生する手法を確立。
2. シミュレーション・エミュレーションの統一: 単一の設計データベースとリプレイアーティファクトを使用することで、両環境間の整合性を保ち、統合オーバーヘッドを大幅に削減。
3. デバッグ効率の飛躍的向上: 決定論的な再生により、システムレベルの失敗を特定の IP 境界まで迅速に遡って特定（ルート・コーズ分析）可能に。
4. チップレットアーキテクチャへのスケーラビリティ: ODIN のような複雑なチップレットシステムにおいて、サブシステム間のインターフェース検証を反復可能かつ正確に行うフレームワークを提供。

4. 結果 (Results)

• 高速なシステム統合: リプレイ駆動手法により、1 クォーター（3 ヶ月）以内で CPU-GPU-NoC 統合システムのエンドツーエンドのブートと GPU ワークロードの実行を達成しました。
• BFM 不要による加速: 専用の SoC レベルのテストベンチや BFM collateral を開発する必要がなくなり、最初の意味のあるシステムレベルテストの実行が早期化されました。
• エミュレーションでの成功: EP1 エミュレーションハードウェアプラットフォーム（16 ボード、64 FPGA）上で、フルチップの CPU-GPU-NoC システムをマッピングし、正常にブートおよびメモリ出力を確認しました。
  • リソース使用量は、LUT で約 83-88%、RAM で約 37-40% 程度に収まり、デバッグ用ロジックの余地を残しつつ設計が収容可能であることを確認しました。
• デバッグ時間の短縮: 再現性の高いリプレイにより、デバッグのターンアラウンドタイムが大幅に短縮されました。

5. 重要な知見と制限 (Key Learnings & Limitations)

• 決定性の確保: メタステービリティ検証のために使用されていたフリップフロップのランダム化を無効化し、決定論的な動作を確保する必要がありました。
• クロックモデルの制限: リプレイ駆動のエミュレーションでは、動的な周波数変更をサポートせず、固定周波数の仮定が必要となりました（ZEMI3 フローを通じた事前処理が必要）。
• ROM フットプリントの削減: 内部クロック論理の完全なキャプチャ・リプレイではなく、クロック生成ベースのリプレイを採用することで、ROM の使用量を削減しました。
• 自動化の重要性: キャプチャとリプレイロジックの挿入を自動化することで、手動エラーを最小化し、検証実行間の再現性を向上させました。

6. 意義と結論 (Significance)

本論文で提案されたリプレイ駆動検証手法は、CPU と GPU が緊密に結合し、システムレベルプロトコルが複雑化する次世代の SoC（特にチップレットベースの ODIN アーキテクチャ）の検証において、スケーラブルで決定論的な基盤を提供します。

従来の BFM ベースの手法が抱えていた「シミュレーションとエミュレーションの断絶」や「統合オーバーヘッド」という課題を解決し、単一の再利用可能なアーティファクトで両環境を統一することで、設計の信頼性を高め、市場投入までの時間を短縮する実用的なフレームワークを確立しました。このアプローチは、システムがさらに複雑化する未来の半導体設計において、サブシステムおよびチップレット境界における反復可能で正確な検証を実現する重要なステップとなります。