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

This paper presents a replay-driven validation methodology that utilizes deterministic waveform capture and replay across simulation and emulation to efficiently validate a complex, chiplet-based ODIN CPU-GPU architecture, significantly accelerating debug cycles and enabling successful end-to-end system integration within a single quarter.

The Gist

Imagine you are building a massive, high-tech city called ODIN. This city has two main districts:

1. The Control Tower (CPU): This is the brain. It's great at making decisions, managing traffic lights, and handling urgent, one-off tasks.
2. The Factory District (GPU): This is the muscle. It has thousands of workers who can do the exact same task simultaneously (like painting a million bricks at once).

The goal of this paper is to get these two districts to work together perfectly before they are actually built in real life (a process called "pre-silicon validation").

The Problem: The "Black Box" Chaos

When you try to connect the Control Tower and the Factory, things get messy.

• Too Many Rules: They have to follow incredibly complex, secret handshake protocols to talk to each other.
• The "What If" Nightmare: If you try to simulate their conversation on a computer, it's so slow that you can't watch a whole day of work happen. If you try to speed it up on special hardware (emulation), you can't see inside the conversation to find out why a mistake happened.
• The "Blind" Test: Traditionally, engineers would write a script to tell the Factory what to do. But if the script is wrong, or if the Factory behaves unexpectedly, the whole city stops, and nobody knows who to blame. Was it the Control Tower? The Factory? Or the road between them?

The Solution: The "Replay Engine" (The Magic Tape Recorder)

The authors of this paper invented a clever trick called Replay-Driven Simulation.

Here is the analogy:
Imagine you are a director filming a movie. You have a very difficult scene where the Control Tower and the Factory have a perfect, complex conversation.

• Old Way: Every time you want to test a new road layout, you have to hire the actors, write a new script, and hope they remember their lines perfectly. If they mess up, you have to guess why.
• The New Way (Replay): You record the perfect conversation once on a high-quality tape recorder. Now, whenever you want to test a new road layout, you just play the tape.

The tape contains everything:

1. What the Control Tower said.
2. What the Factory said back.
3. Exactly when they said it (the timing).

How It Works in the Paper

1. The Recording (Capture): First, they take the GPU (Factory) and test it alone. They record every single signal it sends and receives during a complex task. This is the "Golden Tape."
2. The Playback (Replay): When they connect the GPU to the CPU and the rest of the city (the SoC), they don't ask the GPU to "think" and generate new traffic. Instead, they plug in the "Golden Tape."
   • The tape plays the GPU's requests to the CPU.
   • The tape also plays the CPU's responses back to the GPU.
   • The Magic: The system acts exactly as if the real GPU and CPU were talking, but it's actually just a recording playing on a loop.

Why This is a Game-Changer

• One Script for Two Stages: Usually, you need one script for slow computer simulations and a totally different one for fast hardware emulation. This method uses the same recording for both. It's like using the same movie reel for both a slow, detailed review and a fast-paced screening.
• Instant Debugging: If the city crashes, they don't have to guess. They can rewind the tape to the exact second the crash happened and see exactly what signal caused it. It turns a "Where did the fire start?" mystery into a "Here is the spark" fact.
• Speed: Because they don't have to write complex new scripts for every test, they got the whole system running and booting up in just one quarter (three months).

The Catch (The Fine Print)

Like any good magic trick, there are a few rules:

• No Improvisation: The actors (the chips) can't make things up on the spot. They have to follow the tape exactly. This means they had to turn off some "randomness" features that are usually used to test for rare glitches.
• Fixed Speed: The tape plays at a fixed speed. You can't speed it up or slow it down dynamically during the test.

The Bottom Line

This paper describes a method where engineers stopped trying to predict how a complex computer chip would behave and started recording how it behaves when it works right. Then, they used that recording to test the rest of the system.

It's like building a new car engine. Instead of trying to guess how the pistons will move, you record a perfect engine run, and then use that recording to test the new transmission, the new brakes, and the new tires. It saves time, reduces confusion, and ensures that when the car is finally built, the engine and the transmission know exactly how to dance together.

Technical Summary

1. Problem Statement

The integration of CPU and GPU subsystems into modern System-on-Chip (SoC) designs, particularly those adopting chiplet-based architectures (like the ODIN architecture), presents severe pre-silicon validation challenges:

• Complexity & Scale: Tightly coupled CPU-GPU subsystems involve massive parallelism, complex memory hierarchies, and intricate protocol interactions at chiplet boundaries.
• Non-Determinism: GPU execution is memory-driven and often relies on randomized modeling (e.g., for metastability coverage), making it difficult to reproduce specific failure scenarios deterministically.
• Validation Fragmentation: Traditional validation flows often require separate design databases and Bus Functional Models (BFMs) for simulation and emulation. Transitioning between these environments is costly, prone to inconsistency, and delays the creation of meaningful system-level tests.
• Debug Inefficiency: Root-causing failures in a full-SoC environment is time-consuming because engineers must backtrack through multiple abstraction layers to find whether an issue lies in the IP, integration logic, or system interaction.
• Performance Bottlenecks: Full-chip RTL simulation is too slow for realistic workloads, while emulation often lacks the internal visibility required for deep debugging.

2. Methodology: Replay-Driven Validation

The authors propose a Replay-Driven Validation Methodology that unifies simulation and emulation using a single design database and a shared stimulus mechanism.

Core Concept: The Replay Engine

Instead of relying on dynamic BFMs to generate responses during system integration, the methodology captures timing-accurate waveforms of the GPU IP during standalone validation. These waveforms are converted into a deterministic, ROM-initialized format.

• Capture Phase: During standalone GPU IP validation, the Replay Engine records architecturally visible interface signals (data, control, responses) at the GPU periphery.
• Conversion Phase: An offline post-processing step extracts these signals and converts them into a cycle-ordered bit representation. Both the stimulus (requests) and the corresponding responses are encoded.
• Initialization Phase: This data is used to initialize ROM structures within the Replay Engine in the SoC design.
• Replay Phase: During SoC-level simulation or emulation, the Replay Engine reads the pre-initialized ROM to drive the interface. It re-generates the exact responses observed during capture in the same clock cycles, effectively emulating a "responding agent" without needing a live BFM.

Simulation and Emulation Flow

• Unified Database: Both environments use the same design database and YAML-based configuration, eliminating the need for separate collateral.
• Simulation: Used for detailed functional debug and root-cause analysis with full waveform visibility. The Replay Engine ensures cycle-accurate, deterministic execution of complex boot and workload sequences.
• Emulation: Used for high-speed, scalable execution of long-running system workloads. The deterministic nature of the replay allows issues found in emulation to be reliably correlated back to simulation for detailed analysis.

3. Key Contributions

• Unified Validation Framework: Successfully demonstrated a methodology where a single replay artifact drives both simulation and emulation, removing the overhead of maintaining separate BFM-based databases.
• Deterministic Reproduction: Solved the non-determinism issue in GPU validation by capturing exact interface behaviors (including responses) and replaying them, enabling reliable reproduction of complex system-level failures.
• Accelerated SoC Bring-up: Eliminated the need to develop and validate dedicated SoC-level testbenches or BFMs for GPU integration. The system achieved end-to-end boot and workload execution significantly earlier in the integration cycle.
• Chiplet Boundary Validation: Proved the effectiveness of this approach for validating tightly coupled CPU-GPU subsystems within a chiplet-based architecture (ODIN), where protocol interactions are critical.
• Resource Optimization: Achieved a reduced ROM footprint by utilizing clock-generation-based replay rather than capturing full internal clocking logic.

4. Results

• Timeline Achievement: The team successfully achieved end-to-end system boot and GPU workload execution within a single quarter.
• Debug Efficiency: Debug turnaround time was significantly reduced. Issues observed in emulation could be immediately reproduced in simulation for root-cause analysis due to the deterministic replay mechanism.
• Emulation Feasibility: The full CPU-GPU-NoC SoC was successfully mapped to the EP1 emulation platform (using 16 boards/64 FPGAs). Resource utilization was within capacity (approx. 83-88% LUT usage), leaving margin for debug infrastructure.
• Validation Success: The methodology enabled the execution of the first meaningful system-level tests earlier than traditional flows, with successful output comparisons against golden references.

5. Significance and Limitations

Significance:
This paper establishes a scalable validation framework essential for the future of heterogeneous chiplet-based SoCs. By decoupling stimulus generation from dynamic BFM infrastructure and relying on deterministic replay, it addresses the "integration gap" that often stalls complex CPU-GPU projects. It allows for rapid iteration, consistent cross-platform validation, and efficient root-cause analysis.

Key Learnings & Limitations:

• Clocking Constraints: The clock simulation-based model does not support dynamic frequency changes; fixed-frequency assumptions are required during replay.
• Randomization: To achieve determinism, flop randomization (used for metastability coverage) had to be disabled during the replay phase.
• Tooling: Emulation required specific preprocessing (ZEMI3 flow via Synopsys BC) to handle clock simulation models.

Conclusion:
The replay-driven approach transforms the validation of complex, tightly coupled subsystems from a fragmented, BFM-heavy process into a streamlined, deterministic workflow. It provides a practical path forward for validating next-generation chiplet architectures like ODIN, ensuring that system-level integration confidence is maintained without sacrificing debug visibility or speed.