Appendix B — A Map of AI-for-Architecture Work
In this appendix, we consolidate the prior body of AI-for-architecture work that Architecture 2.0 builds on. We group established results into families, map each family to the principal lifecycle stages where cited work demonstrates activity, and show how our discipline in this book differs from any single family. We intend this map as a positioning statement rather than a comprehensive survey.
We have seen machine learning appear in computer architecture for decades. Early work proposed learned in-chip mechanisms and models of architectural design spaces. More recent systems couple learned methods directly to simulators, compilers, and implementation tools. The families below form the foundation our work draws on; because existing literature already provides comprehensive surveys (L. Chen et al. 2020), we offer a positioning aid instead (Table B.1).
When we examine these method families, most fall into three regimes, and each regime supports a distinct claim. Learned in-chip components occupy the mechanism regime, where we evaluate them against the mechanism’s own budget, such as mispredict rate at fixed storage and latency. Learned cost models occupy the design-space-model regime, where we evaluate them based on their predictive fidelity against the tool they approximate. Families that participate in the design process itself occupy the third regime. Benchmarks and datasets sit alongside these regimes as supporting evaluation infrastructure. We take the normative position that we must judge a complete third-regime result at the level of the architecture study rather than by the generated artifact alone. Confusing these regimes allows a bounded branch-prediction result to become evidence for trusting an agent with a floorplan, which it is not.
| Family of work | Representative results | Principal lifecycle stages demonstrated | Developed in | Key sources |
|---|---|---|---|---|
| Learned in-chip components | Perceptron branch predictors and learned prefetchers, where learning is embedded in the mechanism itself and does a bounded tactical job | Implement, Evaluate | Chapter 1, Chapter 5 | (Jiménez and Lin 2001; L. Chen et al. 2020) |
| Learned cost models and predictive DSE | Surrogates and regression models that predict performance and power across a Design Space Exploration (DSE) environment from cheap features | Explore, Evaluate | Chapter 4, Chapter 5 | (Ipek et al. 2006; Lee and Brooks 2006; Bai et al. 2021) |
| Autotuning and autoschedulers | Search and cost models for loop transformations, array layouts, and accelerator lowerings | Implement, Evaluate | Chapter 5, Chapter 9 | (T. Chen et al. 2018; Zheng et al. 2020) |
| Heuristic and BO design-space search | Bayesian optimization, genetic algorithms, and evolutionary strategies for parameter selection | Explore | Chapter 5 | (Bai et al. 2021; Krishnan et al. 2023) |
| RL for physical design, datapath, and flow tuning | Reinforcement Learning (RL) for macro placement and datapath synthesis, and commercial design-space tools | Explore, Implement | Chapter 3, Chapter 9, Chapter 11 | (Mirhoseini et al. 2021; C.-K. Cheng et al. 2023; Roy et al. 2021; Synopsys 2023) |
| LLMs for RTL and HLS generation | Register-Transfer-Level (RTL) generated from natural-language specifications, with High-Level Synthesis (HLS) as the older lowering lineage | Implement | Chapter 6, Chapter 5 | (Thakur, Ahmad, et al. 2023; Thakur, Blocklove, et al. 2023; Coussy and Morawiec 2008; Fu et al. 2023) |
| Agentic, tool-using exploration | AgentDSE, an agentic framework for design-space exploration, demonstrates simulator-in-the-loop exploration in which an agent proposes configurations, invokes the simulator, and uses returned results to choose another candidate | Explore, Implement, Evaluate | Chapter 3, Chapter 6, Chapter 8 | (Wang et al. 2026) |
| Benchmarks and datasets | QuArch, a benchmark dataset for architectural reasoning, tests architecture knowledge through question answering | Evaluate | Chapter 4, Chapter 10 | (Prakash et al. 2025) |
| ML for verification and validation | LLM-drafted assertions and testbenches, treated as candidate verification collateral that requires independent execution and review | Implement, Evaluate | Chapter 7 | (Yan et al. 2025; Qiu et al. 2024; Kang et al. 2024) |
These families are not mutually exclusive. When we run an agentic design-space search, our workflow might call a learned cost model, invoke an autoscheduler, and emit RTL. A single architecture study in our work can touch several rows at once.
The learned in-chip components family carries a constraint that the others do not. A proposed component is only useful when its inference fits the mechanism’s storage and latency budget. The perceptron predictor provides a bounded example, keeping within a 4 KB hardware budget and delivering a prediction in one cycle (Jiménez and Lin 2001). This result ties predictive accuracy directly to the hardware resources we consume inside the mechanism.
These families also occupy distinct regions of the territory we map in Figure 1. The learned-components, cost-model, and autotuning families live where computer architecture meets machine learning. Reinforcement learning for physical design and LLM-driven RTL generation live where machine learning meets electronic design automation (EDA). Learned models can use earlier-stage features to predict routing hotspots and downstream-flow outcomes (Kahng 2018). We view these surrogates as the cost-model family applied to physical design, where a cheap prediction guides our iteration before we run a more expensive downstream flow. Generated assertions and testbenches span both regions, but they remain candidate verification collateral that we must independently execute and review (Yan et al. 2025; Qiu et al. 2024; Kang et al. 2024). AgentDSE places tool feedback inside exploration, while QuArch contributes an Evaluate-stage test of architecture knowledge and question answering.
The stage column carries a telling asymmetry: Explore appears in four rows, Implement in six, and Evaluate in six, yet no row demonstrates Formulate, Interpret and Explain, or Review and Decide. We add those responsibilities directly to our normative standard for a complete architecture study.
Because we often combine these methods, what separates Architecture 2.0 from any single family is our unit of work. A learned branch predictor changes a single mechanism. A macro-placement agent proposes a candidate for one implementation step. An RTL-generating model produces a single artifact. Prior work judges each result on that bounded output alone.
Our work instead takes the complete architecture study and its reviewable claim as our fundamental unit. For us as architects, the question is not just whether a model produced a plausible artifact, but whether the whole loop supports an architectural decision that another architect can inspect and challenge. The families mapped here supply our methods. Our discipline supplies the standard of judgment that decides what their outputs are actually worth.
B.1 The Latent Architectural Space Map
A central theme across Architecture 2.0 is that machine learning models do not operate directly on raw physical silicon. Instead, they transform complex, discrete, high-dimensional hardware artifacts (such as Abstract Syntax Trees, Control-Data Flow Graphs, place-and-route netlists, and memory trace logs) into continuous or structured latent space representations. Evaluating how different AI paradigms construct, navigate, and decode these latent spaces determines their resolving power and failure modes (Table B.2).
Four paradigms organize this territory: Token & Code Embeddings, Graph & Topological Embeddings, Continuous Surrogate & DSE Spaces, and Policy & Reinforcement State Spaces. Whatever the paradigm, a candidate latent point earns trust only through an independent physical grounding path, and each paradigm fails in its own way when its predictions diverge from physical hardware behavior.
| Latent Space Paradigm | Underlying Representation | Search & Inference Mechanism | Physical Grounding & Decoupling | Primary Latent Failure Mode |
|---|---|---|---|---|
| Token & Code Embeddings | High-dimensional dense vectors derived from Large Language Model (LLM) Transformer activations over Verilog, SystemC, or Triton DSL code | Autoregressive token sampling, temperature decoding, and beam search | Executable compilation via Verilator or Yosys and functional testbenches | Hallucinated Syntax & Vacuous Syntax: Generated code looks syntactically plausible but violates ABI, bit-width, or structural invariants. |
| Graph & Topological Embeddings | Node and edge embeddings (Graph Neural Networks / GNNs, Hypergraphs) capturing spatial connectivity, CDFGs, or netlist floorplans | Node classification, edge prediction, and spatial clustering | Physical place-and-route tools via OpenROAD or Synopsys Innovus and static timing analyzers via OpenSTA | Non-Routable Clustering: Surrogates cluster macros optimally in graph space, but extracted physical layouts collapse under severe metal layer congestion. |
| Continuous Surrogate & DSE Spaces | Low-dimensional continuous manifolds mapping discrete architecture configurations (cache size, pipeline depth, bus width) to scalar PPA estimates | Bayesian Optimization (BO), Gaussian Processes, and active learning acquisition functions | Cycle-accurate simulators like SCALE-Sim or gem5 and gate-level signoff via Ansys RedHawk-SC | Out-of-Distribution Exploitation (Optimizer’s Curse): Optimizers select extreme latent points whose predicted gains are inflated by estimation error rather than by real PPA improvements (Smith and Winkler 2006). |
| Policy & Reinforcement State Spaces | Markov Decision Process (MDP) state-action vectors representing placement steps, tile schedules, or circuit transformations | Deep Q-Networks (DQN), Proximal Policy Optimization (PPO), and Monte Carlo Tree Search (MCTS) | Downstream physical DRC/LVS signoff and formal property checkers via Cadence JasperGold | Reward Hacking: The policy maximizes proxy reward functions (e.g., estimated wirelength) by injecting false timing paths or unfeasible constraints. |
Mapping AI methods to their underlying latent space paradigms clarifies the evidence required to validate a candidate design. A model operating in token space establishes code syntax; validating its hardware claim requires decoding that token sequence into RTL and evaluating it through physical synthesis and static timing signoff.
These four latent paradigms (token vectors, topological graphs, continuous manifolds, and policy MDP state-action pairs) meet physical reality through one structural decoupling, latent candidate generation above and physical silicon signoff below (Figure B.1). To prevent latent failure modes (vacuous syntax, non-routable metal congestion, optimizer exploitation, and reward hacking) from corrupting the design loop, candidates must pass through an independent, evaluator-owned physical grounding funnel. This funnel forces candidate proposals through deterministic simulation, formal property verification, place-and-route netlists, and static timing signoff, ensuring that only physically grounded candidates receive human commitment authority approval before tapeout freeze.
B.2 Candidates, Not Decisions
In our framework, these model outputs are always candidates, never final decisions. An autoscheduler’s proposed schedule supports a performance claim only after we measure its execution on the target hardware. A proposed placement requires downstream place-and-route, timing, power, and congestion checks. Generated RTL requires functional and implementation checks. We in our accountable organization retain acceptance responsibility, while our verification and implementation owners retain signoff for their respective domains.
Candidates can mislead us through false confidence or hidden total costs. Generated assertions can pass vacuously while checking nothing that actually matters, so their apparent success is not independent evidence (Beer et al. 2001; Clarke et al. 2018) (Chapter 7). When we assess macro-placement methods such as AlphaChip, a reinforcement learning macro placement tool, a fair total-cost comparison must include the pretraining and fine-tuning runs actually used for the reported design, together with their compute (C.-K. Cheng et al. 2026). Neither apparent verification success nor a favorable cost comparison replaces our required acceptance and signoff.
B.3 Survey of Existing AI-Assisted Systems
When we survey the public examples available through July 2026, we see individual capabilities rather than a complete end-to-end answer. We can better understand their strongest claims by making the checks behind each result explicit. For each system, we must ask what artifact it produced, what test could reject it, how much of the broader architecture problem that test actually observes, and what we can inspect from the outside. Following those checks reveals both our progress and the remaining gaps, without mistakenly treating fundamentally different systems as steps in a single ranking.
Exact or inexpensive checks let us support strong claims over a narrow task. For example, AlphaTensor found a 4 by 4 matrix-multiplication algorithm for a two-element domain that uses 47 scalar multiplications rather than Strassen’s 49 (Fawzi et al. 2022). Because every candidate admitted an exact algebraic check, the system could confidently accept or reject solutions. Similarly, AutoTVM evaluates many tensor-program schedules on real hardware; we can measure the result directly, and most failures stay contained inside the tuning run (T. Chen et al. 2018). While these reliable checks make search practical, neither result gives us a complete system architecture.
When we rely on proxy and simulator feedback, we can support broader exploration, though we adopt the limits of our checking models. We see AlphaChip use wirelength and congestion proxies to guide macro placement (Mirhoseini et al. 2021). Meanwhile, ArchGym demonstrated that no single search algorithm dominates across our design spaces when we hold simulators and sample budgets fixed (Krishnan et al. 2023). To reduce costly target evaluations, Apollo transfers knowledge across related accelerator design spaces, whereas BOOM-Explorer pays hours per sample to execute a documented 7 nm flow (Yazdanbakhsh et al. 2021; Bai et al. 2021). We find each result meaningful within its chosen feedback source, yet we require stronger evidence before any of them can support a wider physical or system claim.
Functional tests, post-synthesis metrics, and fabricated silicon establish vastly different levels of hardware progress. Since functional success alone cannot guarantee hardware design quality, we look to systems like VerilogEval to check functional behavior (Liu, Pinckney, et al. 2023; Pinckney et al. 2024), while RTLLM layers on post-synthesis design-quality measures, though still stopping short of physical signoff (Lu et al. 2024). Pushing further, Chip-Chat reached tapeout for a small processor through extensive human-guided revision, and Enlightenment-1 produced a fabricated RISC-V core by expanding Boolean-function representations from input-output examples, an approach its authors frame as eliminating the manual verify-and-debug loop (Blocklove et al. 2023; S. Cheng et al. 2024). We view these as implementation achievements, yet neither system manages to deliver the full multi-tool system-architecture capability our moonshot demands.
We find human ratings and proprietary deployment reports much harder to evaluate from the outside. For instance, ChipNeMo reports task-specific internal gains, ChatEDA checks tool execution alongside human-rated request fulfillment, and DSO.ai announces 100 commercial tapeouts without a matched methodology (Liu, Ene, et al. 2023; He et al. 2024; Synopsys 2023). While these reports show our community moving learned methods into real workflows, they cannot single-handedly establish independent functional correctness, guarantee complete physical signoff, or prove a net benefit over a strong alternative.
Together, these examples demonstrate useful pieces of a broader design capability. We can use learned search and measured autotuning to explore our choices; we can leverage placement and RTL generation to produce physical artifacts; we can build tool-using systems to invoke real flows; we can rely on domain adaptation to support selected engineering tasks; and we can push generated designs all the way to silicon under tightly bounded conditions. Our moonshot aims to connect these demonstrated capabilities through current project states and appropriate design tools, all while retaining independent checks robust enough to reject an unsound result. We recognize that no single example has established that complete system yet.
Across these systems, we see that any given result only supports the specific claim its check can inspect. When we step back, we realize that check cost and fidelity, task scope, baseline quality, workflow coverage, and access to supporting material all limit what we as architects can conclude (Table B.3).
| System | What it establishes | The telltale limit |
|---|---|---|
| AlphaTensor (Fawzi et al. 2022) | Learned search improved a fifty-year-old matrix-multiplication count for 4 by 4 matrices modulo two | The algebraic construction admits an exact mathematical check, and a single scalar scores it |
| AutoTVM (T. Chen et al. 2018) | Measured search can improve schedules when many candidates run quickly on real hardware | The result covers tensor-program schedules, where failures usually remain safely contained within the tuning run |
| AlphaChip (Mirhoseini et al. 2021; C.-K. Cheng et al. 2026) | A learned policy produces macro placements a production flow accepts | The reward relies on proxy wirelength and congestion, and the matched baseline remains disputed |
| ArchGym (Krishnan et al. 2023) | At equal sample budgets no search algorithm dominates, so our chosen harness and budget ultimately shape the result | Because every candidate is graded by a simulator, the result inherently adopts its fidelity limits |
| Apollo and BOOM-Explorer (Yazdanbakhsh et al. 2021; Bai et al. 2021) | Learned design-space exploration can successfully exploit domain-specific evidence | Apollo transfers knowledge across related accelerator spaces to reduce costly target evaluations; BOOM-Explorer uses an open-source core but depends on commercial tools and pays hours per sample |
| VerilogEval and RTLLM (Liu, Pinckney, et al. 2023; Lu et al. 2024) | We can measure RTL generation on shared tasks | VerilogEval emphasizes functional simulation; RTLLM adds post-synthesis quality metrics; neither actually reaches physical signoff |
| Chip-Chat and Enlightenment-1 (Blocklove et al. 2023; S. Cheng et al. 2024) | Generated logic has reached silicon, including a core that successfully boots Linux | One relies on extensive human-guided revision; the other synthesizes a processor from input-output examples with a provable accuracy bound, rather than the full multi-tool system-architecture capability our moonshot poses |
| ChatEDA (He et al. 2024) | An agent can plan and invoke a real tool flow directly from stated intent | The benchmark checks tool execution and human-rated request fulfillment on 50 ChatEDA-Bench tasks using a simplified OpenROAD wrapper, lacking independent functional correctness or complete signoff |
| ChipNeMo (Liu, Ene, et al. 2023) | Domain adaptation can improve selected internal engineering tasks | The gains remain task-specific, general models stay stronger on certain subtasks, and outsiders cannot reproduce the proprietary evaluation |
| DSO.ai (Synopsys 2023) | Learned flow-parameter search has reached 100 vendor-reported commercial tapeouts | The evidence standard remains a press release, lacking any public methodology or matched baseline |
We present this table as a set of scoped claims, not as a definitive ranking of systems. When we embrace shared tasks, we make it easier to inspect exactly where each claim stops.