1 The Architecture Moonshot

Author

Affiliation

Harvard John A. Paulson School of Engineering and Applied Sciences

Published

August 11, 2026

“The purpose of computing is insight, not numbers.”

— Richard Hamming, Numerical Methods for Scientists and Engineers (1962) (Hamming 1962)

Author’s Note. Richard Hamming, a pioneer in computer science, argued that computing should yield insight rather than raw data. The distinction matters here. AI-native architecture should help architects ask better questions, test alternatives, explain mechanisms, and defend decisions. Producing more candidates is useful only when it improves that work.

North-Star question

What would it take to build an AI-native design system that carries compact system intent through real system-and-chip design to a supported architecture result, rather than merely generating artifacts faster?

Computer architecture has repeatedly expanded what we can design by advancing our methods alongside our devices. Lasting advances do more than automate a local step; they give us better abstractions, repeatable paths to design artifacts, and checks that expose bad results. That history sets our standard for judging AI-native system design.

While learned methods can process unstructured information, propose alternatives, and coordinate tool actions, AI remains a capability rather than a guarantee. This standard defines an ambitious, testable moonshot that carries compact system intent through tools, measurements, and checks to support a verifiable architecture result. The added complexity and cost of AI are justified only if the complete system improves our architecture work.

To test whether AI capabilities transform architecture practice rather than merely accelerating a local task, we cannot evaluate methods in isolation. We require an industrial-grade engineering challenge that spans workloads, software, hardware, and physical signoff under strict real-world constraints.

Learning objectives

This chapter establishes the following learning objectives:

Define the Architecture 2.0 moonshot, point AI assistance, and AI-native design capabilities.
Decompose compact system intent into explicit cross-stack architecture requirements.
Distinguish generated artifacts from verifiable architecture results.
Evaluate architecture quality and design efficacy as independent tests.

1.1 Historical Context and Design Transitions

Every major era in computer architecture has advanced by redefining the boundary between human intent and automated tool execution. Rather than merely accelerating manual tasks, lasting design transformations introduce abstractions that expand expressible hardware complexity while establishing repeatable verification contracts. The Mead–Conway Very Large Scale Integration (VLSI) methodology¹ connected structured design rules with automated layout tools and scalable fabrication access (Mead and Conway 1980). When reduced-instruction-set computing arrived, it reshaped the hardware-software contract around quantitative principles that we could benchmark and test directly (Patterson and Ditzel 1980).

¹ VLSI complexity (origin): Early-1980s frontier microprocessors held about \(10^4\) to \(10^5\) transistors, and by 2021 frontier chips held tens of billions (Rupp 2022). Mead and Conway answered that outgrowth of transistor-level practice with higher-level abstractions, design rules, and fabrication access that a course could teach and a community could share.

Rupp, Karl. 2022. Microprocessor Trend Data. GitHub data repository. https://github.com/karlrupp/microprocessor-trend-data.

Mead, Carver, and Lynn Conway. 1980. Introduction to VLSI Systems. Addison-Wesley.

Patterson, David A., and David R. Ditzel. 1980. “The Case for the Reduced Instruction Set Computer.” ACM SIGARCH Computer Architecture News 8 (6): 25–33. https://doi.org/10.1145/641914.641917.

Veripool. 2026. Verilator User’s Guide. https://verilator.org/guide/latest/.

De Micheli, Giovanni. 1994. Synthesis and Optimization of Digital Circuits. McGraw-Hill.

Synopsys. 2023. Synopsys Formality Equivalence Checking. https://www.synopsys.com/implementation-and-signoff/signoff/formality.html.

Later, logic synthesis allowed us to transform register-transfer-level descriptions into gate-level implementations, while Verilator, an open-source C++ SystemVerilog simulator (Veripool 2026), alongside formal equivalence checking engines like Synopsys Formality, a commercial formal equivalence checker, detected design errors and exposed invalid outputs (De Micheli 1994; Synopsys 2023). In each of these eras, an idea became consequential because we could systematically apply, inspect, and improve the methodology built around it.

While we relied on different technical mechanisms for each of these transformations, they all expanded the fundamental unit of design we could express. Just as importantly, they made the resulting objects checkable against shared rules, tools, or measurements.

Each established design methodology connects an input abstraction to an expanded design object and a dependable verification infrastructure (Figure 1.1). Across the historical progression, Mead–Conway design rules connect transistor layouts to layout rule checkers; the RISC contract pairs instruction set architectures with quantitative benchmarks; logic synthesis maps RTL descriptions to gate-level formal equivalence engines; and hardware generators such as Chisel (an open-source hardware construction language in Scala) (Bachrach et al. 2012; Izraelevitz et al. 2017) pair parameterized code with compiled verification testbenches.

Bachrach, Jonathan, Huy Vo, Brian Richards, et al. 2012. “Chisel: Constructing Hardware in a Scala Embedded Language.” Proceedings of the 49th Design Automation Conference (DAC), 1216–25. https://doi.org/10.1145/2228360.2228584.

Izraelevitz, Adam, Jack Koenig, Patrick Li, et al. 2017. “Reusability Is FIRRTL Ground: Hardware Construction Languages, Compiler Frameworks, and Transformations.” IEEE/ACM International Conference on Computer-Aided Design (ICCAD), 209–16. https://doi.org/10.1109/ICCAD.2017.8203780.

Historical progression through Mead-Conway design rules and abstractions, the RISC hardware-software contract, RTL logic synthesis, and reusable hardware generators. Each established method connects an input abstraction to a design object and a dependable check or infrastructure. A separate prospective case shows an AI-native design system connecting system intent and current project state through existing tools and checks to a supported comparison or finding with stated alternatives and limits; the result may reject a candidate or retain the reference design. — Figure 1.1: **Design method advances expand system expressiveness and verification depth.** Established advances connect an input abstraction to a larger design object and to the checks or infrastructure that make the transformation dependable. AI-native system design appears separately as a prospective system for carrying system intent and current project state to a supported architecture result through existing tools and checks.

AI-native system design enters as a prospective methodology set apart from these established tiers (Figure 1.1): it explores whether compact system intent and current project state can carry to a supported architecture result through existing simulators and EDA toolchains. It does not replace established verification infrastructure; it remains dependable only if its generated outputs pass those same checks. We should view this not as an inevitable next step, nor as a fully automated prompt-to-chip pipeline, but as an open challenge.

1.2 Defining Architecture 2.0

When we measure our current AI capabilities against those historical transitions, we find that merely generating more code, RTL, or design proposals might be useful, but it does not by itself give us a new design method. Generative AI tools and foundation models can now produce candidate code blocks faster than human engineering teams can evaluate and verify them, a divergence we examine in Chapter 2. This widening “scissors gap” (the growing distance between rapid candidate generation velocity and slow physical signoff throughput) means that generating options faster helps only when our engineering process can determine what those options mean.

Our initial paper set out the broad Architecture 2.0 vision (Janapa Reddi and Yazdanbakhsh 2025). For the engineering argument in this book, we define Architecture 2.0 as follows:

Architecture 2.0. Architecture 2.0 is the discipline of building AI-native design systems that carry high-level system intent across the hardware-software boundary toward supported architecture results, and of holding those systems to an architecture-grade evidence standard. It shifts the architect’s primary role from manually crafting point microarchitectures to formulating multi-objective constraints, directing agentic exploration, and forming technical recommendations that a named commitment authority can review.

This shift frames computer architecture across three historical epochs, a periodization we construct for this book’s argument rather than an established community taxonomy (Table 1.1).

Table 1.1: Historical Epochs and the Emerging Architecture 2.0 Program. As design complexity expands, automation moves from unassisted CAD scripts through localized learned surrogates toward AI-native design systems. The final row states an emerging engineering program rather than a completed historical transition.

Epoch & Era	Fundamental Paradigm	AI & Automation Mechanism	Primary Human Role
Architecture 0.0 (Transistor Era)	Physical Construction	Manual schematics, layout design rules, & unassisted CAD scripts	Drafting polygons & wiring circuits
Architecture 1.0 (Mead–Conway / H&P Era)	Structured Abstraction	Pre-2016: Logic synthesis & branch perceptrons 2016–2021 (Deep Learning Era): Task-specific surrogates & point CAD optimization	Hand-crafting specifications & evaluating point designs
Architecture 2.0 (Emerging AI-Native Discipline)	Closed-Loop Architecture Work	Current capability: Foundation models, learned surrogates, and early multi-tool orchestration Program target: Closed-loop design systems that connect intent to checked architecture results	Formulating intent, setting bounds, forming recommendations, & retaining named commitment authority

To realize Architecture 2.0 in practice, we establish a formal distinction between localized tool acceleration and complete workflow transformation:

Point AI assistance: Deploying learned models, foundation tools, or generative heuristics to accelerate isolated point tasks within an established engineering workflow, such as drafting an RTL module, tuning a microarchitectural parameter, or predicting a local metric, without altering surrounding manual orchestration, data representations, or physical signoff boundaries.
AI-native system and chip design: Structuring the exploration workflow, machine-usable state representations, cross-layer contracts, rejectable evaluation loops, and verification harnesses around closed-loop search and multi-tool orchestration. The system may span hardware and software, but its result remains bounded by the tools, measurements, and checks that actually ran.
Architecture moonshot: Establishing that a complete AI-native design system can carry compact system intent through real toolchains and physical signoff to a defensible hardware-and-software result. This is the program-level ambition. The book does not assume it has been achieved.

Our discipline has long embraced learned mechanisms, ranging from perceptron branch predictors, later adopted in shipping silicon, to surrogate models used in design-space exploration (Jiménez and Lin 2001; Ipek et al. 2006). However, our focus throughout this monograph is not on adding neural components into silicon, but rather on using learned methods to elevate the engineering practice of architecture design itself.

Jiménez, Daniel A., and Calvin Lin. 2001. “Dynamic Branch Prediction with Perceptrons.” Proceedings of the Seventh International Symposium on High-Performance Computer Architecture (HPCA), 197–206. https://doi.org/10.1109/HPCA.2001.903263.

Ipek, Engin, Sally A. McKee, Rich Caruana, Bronis R. de Supinski, and Martin Schulz. 2006. “Efficiently Exploring Architectural Design Spaces via Predictive Modeling.” Proceedings of the 12th International Conference on Architectural Support for Programming Languages and Operating Systems, ASPLOS XII, 195–206. https://doi.org/10.1145/1168857.1168882.

1.3 Defining the Architecture Moonshot

We use the term moonshot to draw an explicit parallel to transformative engineering milestones such as the DARPA Grand Challenge for autonomous vehicles.² That challenge set a bold, public milestone to transform autonomous navigation from isolated laboratory algorithms into integrated systems capable of navigating complex physical environments under real constraints. In computer architecture, an architecture moonshot defines a similarly bold, testable target. It requires building a closed-loop design system that carries compact system intent through multi-objective exploration, real toolchains, and physical signoff to produce defensible hardware-and-software results.

² DARPA Grand Challenge (origin): The 2004–2007 Defense Advanced Research Projects Agency prize competitions transformed autonomous vehicle engineering from isolated laboratory algorithms into integrated systems capable of navigating complex physical environments under real-world operational constraints; the 2005 Grand Challenge and its winning vehicle are the documented anchor (Buehler et al. 2007; Thrun et al. 2006).

Buehler, Martin, Karl Iagnemma, and Sanjiv Singh, eds. 2007. The 2005 DARPA Grand Challenge: The Great Robot Race. Vol. 36. Springer Tracts in Advanced Robotics. Springer Science & Business Media.

Thrun, Sebastian, Mike Montemerlo, Hendrik Dahlkamp, et al. 2006. “Stanley: The Robot That Won the DARPA Grand Challenge.” Journal of Field Robotics 23 (9): 661–92. https://doi.org/10.1002/rob.20147.

Design principle: An architecture moonshot must expand expressible and checkable design

The principle: An architecture moonshot defines a systemic, verifiable advance in translating compact intent into physically realizable hardware-and-software results.

The rationale: Adding automation to an unconstrained or unverified design loop generates candidate artifacts faster without expanding what an architecture team can systematically prove or defend. An architecture moonshot succeeds only when it expands the scale of design intent we can express and binds that intent to repeatable, independent physical and software verification infrastructure.

For us to treat an architecture moonshot credibly, three core conditions must align.

The alignment spans three requirements, a grand architecture challenge, a substantial shift in design practice, and an enabling advance in AI, data, or tools (Figure 1.2). Any two of the three, without the third, is an incomplete engineering effort. Tackling a grand challenge without a new method leaves an unsolved problem; proposing a new design practice without an enabling advance remains mere aspiration; and demonstrating an enabling advance without a real architecture challenge yields a vacant capability demonstration.

Three-circle Venn diagram showing an architecture moonshot at the intersection of a grand architecture challenge, a substantial change in design practice, and an enabling advance in AI, data, or tools. — Figure 1.2: **Architecture moonshots become testable at the intersection of challenge, methodology, and tooling.** A major architecture challenge and a proposed change in design practice require a demonstrated advance in AI, data, or tools that makes meaningful progress practical.

Only at the central intersection of all three domains in Figure 1.2 does an architecture moonshot become testable. This central alignment ensures that we apply novel AI capabilities to meaningful hardware challenges under real design constraints, avoiding the pitfalls of unsolved problems, mere aspirations, or vacant capability demonstrations.

The takeaway for us is not that we should avoid ambitious targets. Instead, we must state what capability our target depends on and identify what results would challenge our assumptions. Placing AI within this historical continuum reveals that integrating learned methods into design automation extends established search, prediction, and generation capabilities without altering the verification contracts required for physical signoff.

1.4 The Architecture Moonshot Brief

Grounding our moonshot in historical precedent requires an industrial challenge that tests cross-stack decision-making rather than isolated code generation. We ground our investigation in a mobile extended reality (XR) system-on-chip (SoC) subsystem, a demanding target that couples a 3 W-class power envelope and millisecond frame deadlines with heterogeneous compute engines. This case study tests whether learned tools can navigate complex architectural trade-offs across software, microarchitecture, and silicon implementation.

1.4.1 The Mobile XR Subsystem Case Study

In industrial practice, architecture studies rarely start with formal, machine-executable specifications. Instead, they begin with a compact product request that compresses complex physical and computational expectations into a few sentences. Unpacking this high-level prompt reveals dependencies that span every layer of the hardware-software stack.

Lighthouse prompt: The Lighthouse prompt

Design a low-power, 64-bit RISC-V-based compute subsystem for an XRBench-class real-time mobile XR workload. Realize it as a vector-capable CPU, accelerator, or SoC block under a 3 W TDP target in a 3 nm-class LP mobile process, and return a design-space report with evidence and rejected alternatives.

To properly study this workflow, we must explicitly define architecture and architect. For us, architecture is far more than a novel microarchitecture, a high-level block diagram, or a physical chip artifact.

Architecture. Architecture is the hardware and software contract and system organization turning workload intent and technology constraints into a defensible system design. It includes the instruction set architecture (ISA), microarchitecture, memory, interconnects, accelerators, chiplets, compiler and runtime interfaces, and deployment model.

Architect. The architect is responsible for the architecture recommendation within the project’s decision structure. The architect frames the problem, chooses abstractions, sets the evidence standard, integrates cross-layer results, and forms the supported technical recommendation. Specialists qualify measurements and checks and own technical signoffs in their domains.

The architect recommends; someone must still decide, and that decision needs its own name. We define 100 percent In-Order Commit Authority (or Commitment Authority) as the strict organizational decision threshold wherein a designated human authority holds exclusive, non-delegable approval rights to advance an architectural recommendation across a consequential transition, ensuring that automated generators never commit silicon capital or modify baseline contracts out of order.

Conceptually, this threshold functions like an in-order instruction commit unit in a microprocessor pipeline. While out-of-order execution units (our generative models and search algorithms) speculate and propose candidate results in parallel, only the named commitment authority can retire decisions into permanent architectural state. The architect supplies the supported technical recommendation. One person may hold both roles, but the organization must assign each responsibility and approval right explicitly. Methods can contribute candidates and analysis without assuming either responsibility.

The Lighthouse prompt serves as a standardized, multi-constraint benchmark request that articulates compact system intent to guide AI-native design-space exploration across realistic hardware, software, and physical boundaries. We have chosen XRBench, an open-source mobile XR benchmark suite (Kwon et al. 2023), because it offers a well-known public suite of mobile XR workloads, rather than a rigid, proprietary product specification. When we operate at this scale, our prompt exposes the architectural work that a smaller, simpler generation task would obscure. It provides a long-term target for measuring our progress against the full design challenge.

Underneath this brief prompt lies a complete hardware-and-software SoC architecture, structured as three operational layers of a complete architecture study (Figure 1.3): the compact product prompt, the eight coupled architectural requirement domains it implies, and the execution and analysis pipeline that must run before any result.

Stacked diagram with the full Lighthouse prompt at the top, architecture requirements in the middle, and the execution and analysis requirements needed to support an answer at the bottom. — Figure 1.3: **Compact system prompts encapsulate multi-layer architecture studies.** The prompt implies architecture requirements and engineering work that must be completed before forming a supported result and technical recommendation.

Tool results continually force us to revisit and refine those requirements, a feedback path the stack makes explicit (Figure 1.3). Eight tightly coupled layers define the technical dependencies across our design space. The specific capacities, widths, and interface choices that follow are one illustrative decomposition of the prompt rather than resolved design commitments.

Workload layer: Real-time mobile XR workloads drawn from XRBench (Kwon et al. 2023), complemented by general compute traces from SPEC CPU2017, a standardized CPU benchmark suite (Standard Performance Evaluation Corporation 2017), and inference kernels from MLPerf, an industry-standard machine learning benchmark suite (Mattson et al. 2020).
ISA and ABI contract layer: A 64-bit RISC-V application processor core (RV64GCV) equipped with a 128-bit RVV 1.0 vector execution pipeline for data-parallel math, bound by a standardized Application Binary Interface (ABI).
Compute organization layer: A heterogeneous combination of a vector-capable CPU core, a dedicated Neural Processing Unit (NPU) matrix engine (a systolic tensor array optimized for spatial perception and neural rendering), and specialized SoC blocks.
Memory and data movement layer: A multi-level hierarchy comprising 32 KB L1 caches, a 512 KB private L2 cache, a 4 MB shared system-level L3 cache, and Tightly-Coupled Memory (TCM) scratchpads, linked over an AMBA Advanced eXtensible Interface (AXI5) interconnect with verified Network-on-Chip (NoC) bisection bandwidth and die-to-die interfaces such as UCIe (Universal Chiplet Interconnect Express, an open industry standard for die-to-die chiplet interconnects) to High-Bandwidth Low-Power Double Data Rate 5X (LPDDR5X) DRAM under strict DRAM timing parameters.
Power envelope layer: A 3 W sustained Thermal Design Power (TDP) target³ operating under passive optical frame cooling and skin-temperature ceilings (< 41 °C).
Compiler and runtime stack layer: Software execution paths transformed from Abstract Syntax Trees (ASTs) and Control-Data Flow Graphs (CDFGs) through intermediate representation (IR) compiler frameworks or specialized domain libraries with vector intrinsics running under a real-time OS to satisfy rigid 8.33 ms frame deadlines at 120 FPS (120 Hz) (Huzaifa et al. 2021).
Physical constraints layer: Implementation targets framed in 3 nm-class low-power mobile process nodes.
Reliability and verification layer: Signoff guarantees combining formal property verification for protocol compliance, low-power domain isolation intent, and static timing closure across process corners.

Kwon, Hyoukjun, Krishnakumar Nair, Jamin Seo, et al. 2023. “XRBench: An Extended Reality (XR) Machine Learning Benchmark Suite for the Metaverse.” Proceedings of Machine Learning and Systems 5: 1–20. https://proceedings.mlsys.org/paper_files/paper/2023/hash/07b7c2f8a6978e376f9656d69619bfbb-Abstract-mlsys2023.html.

³ Mobile XR and Smart Glasses Thermal Boundaries: Wearable spatial computing systems, ranging from ultra-lightweight smart glasses to high-performance spatial headsets such as the current Meta and Apple devices, face hard physical constraints in human skin-temperature safety limits (roughly 41 °C) and passive frame heat dissipation. In smart glasses and wearable spatial platforms, the total system power envelope must stay under roughly 2 W to 3 W TDP to prevent thermal throttling and skin discomfort against human temples. Achieving continuous spatial perception, eye-tracking, and neural rendering within such an envelope requires combining low-power mobile silicon nodes (such as TSMC N3E or N7) with energy-efficient on-chip AXI5 NoC interconnects, 2.5D/3D UCIe die stacking, and LPDDR5X memory interfaces.

Mobile XR is an ideal target because it forces us to simultaneously satisfy tight latency, thermal, and energy constraints alongside complex cross-layer behavior. We cannot optimize a single kernel or hardware block without accounting for the software pipeline, the memory system, or the rigid frame deadlines that users actually experience (Huzaifa et al. 2021). Early bringup of this software stack and ISA contract relies on tools like Spike, the canonical RISC-V ISA functional simulator, and Renode, an open-source multi-node system emulator, to verify compiler behavior before hardware implementation begins.

When we incorporate industrial integration, technical requirements become increasingly stringent. We know that an accelerator in a modern system-on-chip (SoC) is not an isolated, self-contained module; it must interface with pre-existing intellectual property through strict protocols like AMBA AXI (an Arm-defined on-chip interface protocol with separate channels and strict valid-ready handshake requirements (Arm Limited 2020)). If a candidate exhibits superior power, performance, and area (PPA) metrics yet violates an AXI handshake contract, we cannot integrate it into production silicon.

Arm Limited. 2020. AMBA AXI and ACE Protocol Specification. ARM IHI 0022H. Arm Limited. https://developer.arm.com/documentation/ihi0022/h/.

We use the word prompt advisedly; it is intentionally modest. A prompt expresses our high-level, compact intent. From there, we derive requirements that interpret the prompt’s obligations and highlight the choices we still need to make. A true specification goes further, locking down enough behavior, interfaces, workloads, software semantics, constraints, and acceptance criteria to make our implementation testable. We then craft a study plan that pins down the reference design, alternative options, tools, budgets, and stopping conditions for a specific comparison.

Right now, our Lighthouse prompt is not a specification. Terms like “XRBench-class,” “3 W,” “3 nm-class,” and the broad compute options we have allowed still demand concrete versioned workloads, process assumptions, and verification checks. As architects, we must explicitly expose and resolve these unstated parameters before this request can drive real engineering, deciding which interpretation makes it into the spec and what a successful result looks like.

This prompt does not represent a single model query or an isolated generation step. Answering it requires a memory trace gathered from a fixed XRBench workload and configuration, a compiler built to target our proposed organization, an accurate simulator, a synthesis run mapped to a low-power library, and expert reviewers who can verify that the results substantiate our recommendation. Throughout this book, we are studying that entire human-plus-technical workflow, rather than just grading the fluency of a single generated response.

When we apply these definitions to the Lighthouse, we are committing to a comprehensive hardware-and-software result, not just a standalone chip. Any specific investigation we run must still fix the workload version, the hard deadlines, the architecture and software paths, our reference design, process libraries, operating assumptions, toolchains, budget, stopping conditions, implementation constraints, verification duties, and exact measurements. If we change a fixed condition, we alter the challenge; when we finally resolve an open choice, we make the project executable. While these choices make our design comparisons possible, they are not the architecture itself. We must be ready to defend how those decisions support our comparison and our final technical recommendation.

1.4.2 Decomposing Intent into Executable Specifications

A compact product prompt conceals two distinct engineering phases. First, we must translate high-level intent into unambiguous architectural requirements. Second, we must construct a tool-connected evaluation pipeline that supports a defensible technical recommendation.

This multi-phase structure connects our compact product intent to eight coupled architectural requirement domains, spanning workload definition down to physical signoff, and grounds them in cycle-accurate simulators, EDA toolchains, and formal verification engines.

We start with the prompt itself. We must translate high-level intent into guiding questions and coupled design choices long before we ever see a generated chip artifact. The prompt asks us to compare several compute organizations for a real-time mobile XR workload, ensuring we respect a 3 W thermal design power (TDP) sustained thermal envelope that our declared form factor and cooling assumptions must remove, alongside the realities of an LP process. As we break it down, individual phrases bound different parts of our study.

For instance, when we read “64-bit RISC-V-based compute subsystem,” that fixes our word length and ISA family under the RV64GCV standard. Yet, in our study, we must still choose the exact ISA extensions (such as vector lengths or custom matrix instructions), ABI⁴, compiler runtime stack, and software contract. The phrase “XRBench-class real-time mobile XR workload” sets our target environment, which we evaluate alongside general CPU benchmarks and inference kernels. We also notice the “accelerator block” provision, which intentionally leaves several compute organizations open for comparison, ranging from scalar CPUs to decoupled vector pipelines and specialized systolic NPU engines.

⁴ ABI (application binary interface): The binary-level agreement on register usage, calling conventions, stack layout, and data alignment that lets separately compiled code interoperate. Adding a custom instruction changes the ISA, but shipping it means the compiler, libraries, and operating system have to agree on the ABI as well, which is why an ISA extension is a software project rather than a hardware edit.

RISC-V International. 2026. The RISC-V Instruction Set Manual, Volume II: Privileged Architecture. https://docs.riscv.org/reference/isa/_attachments/riscv-privileged.pdf.

The 3 W TDP target and physical constraints in advanced low-power mobile process nodes impose hard thermal, area, and security limits. Reported process characterizations indicate that scaling logic in leading-edge nodes does not yield equivalent memory area density gains, making large on-chip caches and scratchpads an explicit area and static leakage trade-off. Because mobile XR subsystems continuously ingest sensitive biometric eye-tracking and 3D spatial room streams, Layer 8 (Reliability & Verification) requires a declared threat model, physical-memory access controls, and separate defenses for the relevant side channels. RISC-V Physical Memory Protection (PMP) can enforce physical-memory access permissions, but it does not create an enclave or close timing, cache, or shared-resource channels by itself (RISC-V International 2026).

To hit a 3 W TDP in a mobile XR form factor, we have to explicitly state our cooling and skin-temperature assumptions, SRAM versus DRAM area trade-offs, packaging and signaling strategies, NoC bisection bandwidth, and energy allocation between the compute subsystem and off-chip memory access under realistic memory timing constraints.

Even though the prompt formally asks for a design-space report, our study might also produce software, models, RTL, layouts, prototypes, or even a physical chip, depending on how ambitious our claims are. When evaluating multi-objective design choices, we construct the Pareto frontier, defined as the set of objective outcomes of feasible designs for which no alternative is at least as good on every objective and strictly better on at least one (Deb 2001). Our final report weaves these artifacts, Pareto optimal sets, and measurements into the proposed design, explaining why we rejected the alternatives. To test our judgment, the prompt leaves the accelerator microarchitecture, memory system, software integration, and evaluation tools open for us to define. Turning these choices into a rigorous study requires us to formulate explicit constraints that our tools can actually ingest. We navigate requirement translation by combining profiling, analytical models, prior designs, design tools, and our own expert judgment. A simple product request like “we need a low-power AR headset” does not automatically supply a 3 W TDP, point us to a particular RISC-V extension, or specify the ideal L2 capacity. Instead, we must derive these study parameters ourselves, leaning on workload and system evidence.

Deb, Kalyanmoy. 2001. Multi-Objective Optimization Using Evolutionary Algorithms. John Wiley & Sons.

We can use learned methods to assist us here. They can extract candidate constraints from requirement documents, relate them to prior designs and public benchmarks, and flag ambiguities for us to resolve. For example, when a prompt vaguely asks for a “real-time” workload, a language model might push us to clarify whether we mean a strict 11 millisecond frame deadline at 90 Hz, a 20 millisecond motion-to-photon bound, or a 99th-percentile tail-latency target.

However, this AI assistance does not eliminate our formulation work. While it can slash the time we spend assembling candidate specifications, we still make the final call on whether the proposed bounds are complete and supported. Before we can even begin our search, we must represent our accepted constraints in a format our tools can actually use, like a parameterized generator configuration or a sweep specification. Prose alone cannot define a legal design space.

A single shift in our workload, software, hardware, or physical choices can alter the validity of all the others, changing the very checks that might disqualify an answer. We consider any answer incomplete if it fails to identify its workload slice, software contract, physical assumptions, supporting observations, and ultimately, the owner of the recommendation. Whenever we propose a commitment, we must explicitly identify the named authority standing behind it.

Examining these choices shows that the workload and process phrases demand more detail than the compact prompt initially provides. The XRBench suite provides a concrete workload anchor, rather than leaving us with a vague application label. End-to-end XR research demonstrates how tightly perception and display stages are coupled, making mobile XR a full system-level architecture target rather than just a single kernel for us to optimize (Huzaifa et al. 2021). Here again, we can use learned methods to analyze dataset distributions and uncover coverage gaps, complementing our traditional profiling, trace analysis, and expert workload judgment. For instance, an AI method could analyze a memory trace collected from a fixed XRBench workload and configuration, clustering access patterns to suggest specific cache hierarchies or local scratchpads for our simulations.

⁵ PDK (process design kit): The package for one manufacturing process that supplies device models, design rules, and related data used by implementation tools. The open SKY130 PDK demonstrates that a PDK can be published (SkyWater PDK Authors 2020), but it cannot supply the authorized project-specific information for a different process or commercial tool flow.

SkyWater PDK Authors. 2020. SkyWater SKY130 PDK Documentation. Project documentation. https://skywater-pdk.readthedocs.io/en/main/.

Apple. 2024a. Apple Debuts iPhone 16 Pro and iPhone 16 Pro Max. https://www.apple.com/newsroom/2024/09/apple-debuts-iphone-16-pro-and-iphone-16-pro-max/.

Apple. 2024b. Apple Introduces M4 Chip. https://www.apple.com/newsroom/2024/05/apple-introduces-m4-chip/.

We must ensure our selected benchmark represents our broader system claim. Likewise, the prompt states the process node as a broad class rather than pointing us to a named foundry process design kit (PDK)⁵. Even though we saw 2024 mobile SoCs publicly described in 3 nm-class technology (Apple 2024a, 2024b), our study must explicitly name the specific process, libraries, voltage assumptions, and signoff path. We cannot support a true physical-feasibility claim until each surviving candidate successfully navigates the relevant physical-design flow.

This concise prompt conceals substantial engineering depth. In our early studies, we might screen candidates against the 3 W TDP and 3 nm-class LP mobile process constraints using calibrated analytical models or partial implementations. However, any candidate we use to anchor a physical-feasibility claim must eventually navigate the relevant physical-design and verification flow, ensuring that performance, power, and area (PPA) gains do not violate baseline contracts.

When we compare the RISC-V vector (RV64GCV) and accelerator alternatives, we must also check the compiler runtime stack, domain libraries, generated code, and overall software portability. Software reliability and physical signoff require explicit verification checks to validate interconnect contracts, power-gating behavior, and static timing closure.

Often, we find the software stack acts as our limiting dependency. A novel spatial accelerator is dead silicon if we cannot co-adapt the compiler to target it. To meet these demanding workload and physical requirements, we must build a design system that keeps our knowledge, tools, and review loops tightly connected across all eight layers of the prompt stack.

1.5 AI Models vs. AI-Native Design Systems

Navigating these cross-layer dependencies requires a distinction between the tools we train and the design systems we operate. We must not confuse an isolated AI model with a complete AI-native design system. A foundation model or learned surrogate is a stateless tool component that proposes candidates or accelerates estimation; it holds no live project memory, cannot verify physical constraints, and cannot issue architectural commitments. In contrast, an AI-native design system represents the full technical capability, coupling learned components with version-controlled project state, deterministic simulators, EDA toolchains, and formal verification engines under human commitment authority.

To carry our Lighthouse question across the stack, we need far more than reusable model weights. Our technical system must actively maintain the live project state, weaving together learned models, compilers, full-system simulators, synthesis flows, and physical verification pipelines. Every candidate must return checkable evidence that holds up independently of the method that generated it.

We draw a sharp distinction between three core concepts.

Architecture foundation models: Pretrained learned components (Bommasani et al. 2021) that supply reusable prior knowledge across multiple tasks (e.g., workload classification or heuristic search guidance). They hold no live project state and cannot issue technical commitments.
AI-native design systems: The configured technical ensemble of learned models, conventional simulators, versioned artifacts, tool interfaces, feedback loops, and automated verification checks.
Version-controlled project state: The immutable source of record, maintaining machine-readable specifications, SystemVerilog RTL, C++ behavioral models, and physical layout scripts for conventional EDA toolchains.

Bommasani, Rishi, Drew A. Hudson, Ehsan Adeli, et al. 2021. “On the Opportunities and Risks of Foundation Models.” arXiv Preprint arXiv:2108.07258. https://arxiv.org/abs/2108.07258.

The complete AI-native design system organizes around a reusable knowledge substrate on one side and human authority on the other (Figure 1.4). The optional architecture foundation model ingests reusable domain knowledge to propose candidates or accelerate workload predictions. The version-controlled project record remains our authoritative source of truth for specifications, RTL sources, and EDA scripts, feeding conventional simulators, compilers, and physical signoff engines, which execute checks and return empirical evidence.

The design system also separates technical analysis from organizational authority (Figure 1.4). The human architect reviews tool evidence to formulate a supported technical recommendation, while a distinct Commitment Authority holds exclusive, non-delegable approval rights to advance, hold, or reject the design before committing silicon capital.

Reusable architecture knowledge feeds an optional architecture foundation model inside an AI-native design system. A separate version-controlled project record informs the active architecture tasks and conventional methods. Task outputs reach design tools and checks, which return evidence and update project state. A supported architecture result leaves the technical system for review by the architecture role, which forms a supported technical recommendation for a separate commitment authority. — Figure 1.4: **Foundation models function as optional components within the broader design system.** Reusable architecture knowledge can support a learned component adapted to workload analysis, prediction, generation, or diagnosis. The current project record, conventional methods, compilers, simulators, EDA and formal tools, and our independent checks remain part of the larger system. We supply our intent and constraints, review the supported result, and form a supported technical recommendation. A separate commitment authority decides whether our project advances, holds, or rejects that recommendation.

In the context of our Lighthouse challenge, a reusable model might help us analyze XR workloads, screen candidate organizations, draft software or RTL, or quickly diagnose a failed check. In contrast, our live project record supplies the authoritative context, including the current trace, our 3 W envelope, the specific candidate identity, and the exact tool and library versions we are running. These current inputs fundamentally determine what our simulators, implementation tools, and verification flows actually evaluate; no amount of reusable prior knowledge can substitute for them.

1.6 Evaluation Framework for Artifacts, Results, and Trade-Offs

Once we establish an AI-native design system that couples project state with downstream tools, transforming raw candidate proposals into verifiable architectural evidence requires a structured evaluation framework. Because generative models can produce candidate code far faster than conventional tools can simulate or physically implement them, architects must balance proxy estimation against high-fidelity verification. Integrating rejectable decision loops into our continuous design pipeline ensures that expensive downstream tools analyze only viable candidates.

1.6.1 Qualifying Artifacts into Verifiable Results

Architectural progress moves through a deliberate hierarchy, expanding high-level intent into specifications, candidate artifacts, empirical measurements, and verified comparative results. From there, we build a technical recommendation that drives a commitment decision. These stages must remain distinct. We define an artifact as anything produced during the work (such as code, RTL, a model, a layout, a report, or a testbench). A candidate is a proposed design or configuration we want to compare. A measurement (or observation) gives us information about a candidate under stated conditions. An architecture result is a supported comparison or finding where our assumptions, conditions, checks, alternatives, and limits are clear enough to inform our next action. A valid architecture result does not always mean a breakthrough; it can reject every candidate, support retaining our current design, narrow the scope of the question, or simply conclude that our available measurements cannot decide the issue.

These distinctions help us determine how to allocate our scarce evaluation feedback. As architects, we might begin with a memory-trace slice collected from a fixed XRBench workload and configuration, alongside its software pipeline. We might propose alternatives, such as varying vector widths, swapping CPUs, or adding accelerators, and screen them with a cheap proxy. We reserve our expensive compiler, simulator, RTL, and physical-design effort for candidates whose results could actually alter our next action or technical recommendation.

The distance between an artifact and a result is especially large in hardware. A generator might produce a mathematically elegant instruction extension that passes behavioral simulation, only to fail logic equivalence checking, design-rule checks, timing, power, or thermal limits during implementation. We can use a surrogate model (a cheaper proxy approximation of an expensive evaluation that lets us screen many candidates quickly (Forrester et al. 2008)) to screen candidates, but a design selected by the surrogate may still fail once a more faithful tool exposes properties the surrogate missed. In aerospace engineering, aerodynamicists rapidly screen candidate wing profiles using low-order computational fluid dynamics (CFD) approximations (Anderson 1995), yet physical wind-tunnel testing remains non-negotiable before flight certification. Similarly, in microarchitectural co-design, a surrogate model enables us to screen thousands of candidate floorplans or tile schedules in seconds, but we must still validate surviving designs in physical EDA signoff tools before committing capital to silicon fabrication. This gap represents the hardware realization of the sim-to-real transfer problem extensively studied in robotics and machine learning (Tobin et al. 2017).

Forrester, Alexander I. J., András Sóbester, and Andy J. Keane. 2008. Engineering Design via Surrogate Modelling: A Practical Guide. John Wiley & Sons. https://doi.org/10.1002/9780470770801.

Anderson, John D. 1995. Computational Fluid Dynamics: The Basics with Applications. McGraw-Hill Education.

Tobin, Josh, Rachel Fong, Alex Ray, Jonas Schneider, Wojciech Zaremba, and Pieter Abbeel. 2017. “Domain Randomization for Transferring Deep Neural Networks from Simulation to the Real World.” arXiv Preprint arXiv:1703.06907.

Once we have measured the affected workload fraction and stated our mapping assumptions, Amdahl’s law supplies an inexpensive theoretical speedup limit. For example, an accelerator that covers 60 percent of the XR pipeline’s cycles inherently caps our whole-system speedup at 2.5 times, no matter how infinitely fast we make the block itself (Amdahl 1967). When we profile memory traces and instruction counts on Spike, we can compute these bounds in seconds long before launching multi-hour microarchitectural simulations. This bound does not verify our profile, mapping, overlap, memory behavior, or implementation. We must also recompute the bound anytime a candidate changes the covered work or the underlying software path.

The roofline model supplies our second screening bound by relating operational intensity to peak compute and memory bandwidth (Williams et al. 2009). Much like the Amdahl calculation, this screen remains inexpensive only after we have measured or declared the specific inputs and assumptions that define the bound.

Williams, Samuel, Andrew Waterman, and David Patterson. 2009. “Roofline: An Insightful Visual Performance Model for Multicore Architectures.” Communications of the ACM 52 (4): 65–76. https://doi.org/10.1145/1498765.1498785.

The roofline bounds attainable performance once our study has a candidate-specific operational intensity and the platform’s peak compute and memory bandwidth, which set its machine balance. In the method vocabulary that Chapter 5 develops fully, generation can propose legal vector configurations, prediction can estimate their data-movement risks, and optimization can choose which configurations merit simulation. A candidate whose bound is already inadequate need not enter the simulator queue. Operational intensity must reflect the candidate’s mapping, declared memory boundary, and cache or scratchpad behavior. We recompute the bound when those properties change, and we still verify the mapping and resulting design for surviving candidates. Ultimately, the roofline can reject an implausible candidate cheaply; it cannot establish that the final design works.

Log-log line plot illustrating verification demand scaling. Unfiltered candidate verification demand scales linearly with proposal volume, exceeding a fixed project budget envelope at 100 candidates per day. Rejection-bound early screening filters prune non-viable candidates, constraining total verification compute within the project budget up to 100,000 candidates per day. — Figure 1.5: **Verification demand scaling across AI candidate proposal velocities.** As AI foundation models reduce proposal cost per candidate by two to three orders of magnitude, total verification compute demand scales linearly with candidate volume \(N\), which climbs exponentially as proposal velocity rises. Early rejection-bound filters (Amdahl caps, Roofline limits, SRAM bounds) tame this demand explosion, constraining total verification compute within a fixed project budget envelope. The cost coefficients and pass-through rate are constructed to make the relationship inspectable; they are not measurements of any tool flow, and the crossover point moves with a project’s own numbers.

Analytical bounds, proxy scores, simulator results, and EDA reports provide very different kinds of evidence, at sharply different costs. Without early rejection bounds, accelerating candidate generation moves the verification burden downstream rather than removing it (Figure 1.5). Unfiltered verification demand scales linearly with proposal rate, so brute-force signoff breaches a fixed project budget envelope beyond 100 candidates per day. Early rejection-bound filters, such as Amdahl caps, Roofline limits, and SRAM area bounds, prune non-viable candidates before they reach full signoff tools, holding total verification compute within the project budget even at proposal rates up to 100,000 candidates per day. This is a constructed analytical scaling model: the coefficients set where the crossover falls, not whether it exists.

We often see a proxy rank candidates one way, only for a simulator to reverse that ranking, while an EDA run might give us complex timing paths and congestion heatmaps rather than a convenient single score. For instance, BOOM-Explorer, an automated design-space exploration framework for RISC-V cores (Bai et al. 2021), highlights that some implementation evaluations can take hours to run. Cadence Joules and Synopsys PrimePower estimate time-based and gate-level power, identify power-critical activity windows, and produce power data that downstream power-integrity and thermal analyses can use (Cadence Design Systems 2026; Synopsys 2026). They do not themselves establish dynamic voltage-drop or thermal-hot-spot signoff. Iterative searches demand many trials before we can distinguish the best actions. When our evaluation capacity cannot cover those trials, brute-force approaches exceed our computational budget. Statistical overfitting⁶ provides a useful analogy here, though our specific failure mode is more acute. If we run a repeated search against a fast proxy, the search can exploit the proxy’s omissions or errors. This produces apparent design gains that disappear when surviving candidates undergo stronger evaluation for the property at issue.

Bai, Chen, Qi Sun, Jianwang Zhai, Yuzhe Ma, Bei Yu, and Martin D. F. Wong. 2021. “BOOM-Explorer: RISC-V BOOM Microarchitecture Design Space Exploration Framework.” 2021 IEEE/ACM International Conference on Computer-Aided Design (ICCAD), 1–9. https://doi.org/10.1109/ICCAD51958.2021.9643455.

Cadence Design Systems. 2026. Joules RTL Power Solution. Product datasheet. https://www.cadence.com/content/dam/cadence-www/global/en_US/documents/tools/digital-design-signoff/joules-rtl-power-solution-ds.pdf.

Synopsys. 2026. PrimePower: RTL to Signoff Power Analysis. Product documentation. https://www.synopsys.com/implementation-and-signoff/signoff/primepower.html.

⁶ Overfitting: The machine-learning failure of fitting the noise of a training sample so closely that performance does not generalize to new data (Hastie et al. 2009). Proxy exploitation is analogous but not identical; it can occur when search uses omissions or errors in an evaluator even without fitting a statistical model.

Hastie, Trevor, Robert Tibshirani, and Jerome Friedman. 2009. The Elements of Statistical Learning: Data Mining, Inference, and Prediction. 2nd ed. Springer Series in Statistics. Springer. https://doi.org/10.1007/978-0-387-84858-7.

Evaluation does not end when a candidate clears its current checks. Hardware commitments freeze key choices on a timeline that stretches far beyond the rapid evolution of workloads, compilers, libraries, and learned models. As optimizers, we cannot safely specialize a 3 nm-class accelerator to a single static trace without considering how the workload and its software stack might shift before deployment. We must balance aggressive specialization with enough baseline programmability to ensure our designs survive that interval.

Even after bounds, proxies, and search tools narrow down our work, their output alone never proves whether a compiler assumption holds, whether the measured behavior truly stems from our proposed mechanism, or whether the remaining trade-off supports the next consequential transition. Our studies should always record the candidates, assumptions, measurements, checks, and rejections that affect our core claims, without retaining every transient model trace. We must formulate a concise rationale that connects our proposals, tool results, rejected alternatives, and the final recommendation, keeping this rationale clearly distinct from the raw measurements. This practice helps reviewers spot missing assumptions, hidden contradictions, or conclusions that our checks do not support. We then rely on these recorded results and rationales to shape our technical recommendations or decide on the next phase of study.

A useful result must clear a much higher bar than a mere artifact. The measurements we take must support a fair comparison under explicitly stated conditions, and our checks must back up the final conclusion. We must record important alternatives and failures so that the result informs our next architecture action. Rejecting a candidate, choosing to retain our current architecture, or opting for a conventional method are all useful results in their own right.

These useful results do not need to resolve the entire Lighthouse challenge in a single step. We can make real progress by closing out one clearly defined piece without claiming an end-to-end answer. A full-scope result addresses the complete challenge, yet it might still conclude that no candidate actually works. Even then, that outcome does not automatically establish the contribution of any named component or guarantee the broader success of the Architecture 2.0 program. Achieving full Lighthouse success demands a supported design that satisfies our fixed conditions alongside the complete design-space report promised by the prompt. This includes delivering the software path, meeting physical constraints, documenting rejected alternatives, proving applicable reliability and security properties under our declared fault and threat models, completing all checks, and providing a recommendation that an independent architect can examine. A candidate, RTL block, report, or tool output is merely an unverified artifact until qualified by measurements and checks under stated conditions. Never treat a syntactically valid script or a successful local tool return as evidence that an architecture should change; a valid architecture result must explicitly identify the candidate, workload, measurement, check, and bounding conditions.

1.6.2 Multi-Metric Trade-Offs and Rejectable Evaluation Loops

Qualifying artifacts into verifiable results for our mobile XR subsystem requires balancing competing physical and computational constraints rather than optimizing a single scalar metric. A candidate that excels in peak compute throughput may fail to meet real-time frame deadlines, violate thermal envelopes, or overload off-chip memory interfaces. Supporting a system claim demands multi-metric evaluation loops capable of rejecting non-viable candidates early in the exploration process. Depending on workload behavior, software support, data movement, physical limits, verification effort, and deployment conditions, we might prefer completely different designs. A valid efficiency claim must capture the complete system cost within a defined total-cost boundary. Local improvements in compute throughput remain meaningless if they shift costs to memory bandwidth, violate thermal envelopes, or impose verification burdens that exceed the project budget.

The total-cost boundary establishes a comprehensive accounting perimeter that incorporates all direct and indirect expenditures (including compute throughput, memory bandwidth, thermal dissipation, EDA tool licenses, verification cycles, and human review overhead) required to achieve useful system work. Conceptually, the total-cost boundary functions like total cost of ownership (TCO) accounting in cloud infrastructure (Barroso et al. 2019). A specialized accelerator block that appears cheap on a raw compute benchmark becomes prohibitively expensive if it demands twice as many EDA licenses, saturates memory bus channels, or forces engineers to spend weeks debugging corner-case verification failures. A valid efficiency claim must evaluate metrics within this complete boundary rather than optimizing localized compute steps. A complete architecture result spans far more than efficiency alone. In quantitative computer architecture, we treat performance, cost, and power as first-class concerns (Hennessy and Patterson 2017). As Dennard scaling weakened, dark silicon emerged, and multicore scaling hit its limits, we had to rely increasingly on specialization (Dennard et al. 1974; Borkar and Chien 2011; Esmaeilzadeh et al. 2011; Jouppi et al. 2017; Chen et al. 2016; Hennessy and Patterson 2019). That shift toward specialized hardware also meant we could no longer ignore broader system effects.

Barroso, Luiz André, Urs Hölzle, and Parthasarathy Ranganathan. 2019. The Datacenter as a Computer: Designing Warehouse-Scale Machines, Third Edition. Synthesis Lectures on Computer Architecture. Springer International Publishing. https://doi.org/10.1007/978-3-031-01761-2.

Hennessy, John L., and David A. Patterson. 2017. Computer Architecture: A Quantitative Approach. 6th ed. Morgan Kaufmann.

Dennard, Robert H., Fritz H. Gaensslen, Hwa-Nien Yu, V. Leo Rideout, Ernest Bassous, and Andre R. LeBlanc. 1974. “Design of Ion-Implanted MOSFET’s with Very Small Physical Dimensions.” IEEE Journal of Solid-State Circuits 9 (5): 256–68. https://doi.org/10.1109/JSSC.1974.1050511.

Borkar, Shekhar, and Andrew A. Chien. 2011. “The Future of Microprocessors.” Communications of the ACM 54 (5): 67–77. https://doi.org/10.1145/1941487.1941507.

Esmaeilzadeh, Hadi, Emily Blem, Renee St. Amant, Karthikeyan Sankaralingam, and Doug Burger. 2011. “Dark Silicon and the End of Multicore Scaling.” Proceedings of the 38th Annual International Symposium on Computer Architecture, ISCA ’11, 365–76. https://doi.org/10.1145/2000064.2000108.

Jouppi, Norman P., Cliff Young, Nishant Patil, David Patterson, et al. 2017. “In-Datacenter Performance Analysis of a Tensor Processing Unit.” Proceedings of the 44th Annual International Symposium on Computer Architecture (ISCA), 1–12. https://doi.org/10.1145/3079856.3080246.

Chen, Yu-Hsin, Tushar Krishna, Joel S. Emer, and Vivienne Sze. 2016. “Eyeriss: An Energy-Efficient Reconfigurable Accelerator for Deep Convolutional Neural Networks.” 2016 IEEE International Solid-State Circuits Conference (ISSCC), 262–63. https://doi.org/10.1109/ISSCC.2016.7418007.

Hennessy, John L., and David A. Patterson. 2019. “A New Golden Age for Computer Architecture.” Communications of the ACM 62 (2): 48–60. https://doi.org/10.1145/3282307.

Horowitz, Mark. 2014. “1.1 Computing’s Energy Problem (and What We Can Do about It).” 2014 IEEE International Solid-State Circuits Conference Digest of Technical Papers, 10–14. https://doi.org/10.1109/ISSCC.2014.6757323.

Gupta, Udit, Young Geun Kim, Sylvia Lee, et al. 2021. “Chasing Carbon: The Elusive Environmental Footprint of Computing.” 2021 IEEE International Symposium on High-Performance Computer Architecture (HPCA), 854–67. https://doi.org/10.1109/HPCA51647.2021.00076.

Data movement illustrates why we need this broader comparison. In the cited 45 nm data, a 32-bit integer add costs about 0.1 pJ, while SRAM and DRAM accesses cost orders of magnitude more (Horowitz 2014). In our 3 nm-class Mobile XR SoC, where off-chip LPDDR5X DRAM accesses consume significant energy relative to on-chip NPU matrix multiplication, we expect data movement across the AMBA AXI5 interconnect to pressure the 3 W TDP envelope. We must evaluate an accelerator that adds memory traffic with a system energy comparison rather than a compute-only claim. Tools such as DRAMSim3 coupled with gem5 can estimate selected memory-system behavior and energy under declared models; they do not supply an unqualified system-energy result. When we scale up to the warehouse level, our boundary expands to include utilization, networking, power delivery, operations, and total cost of ownership (Barroso et al. 2019). If we look at operational and embodied carbon, we have to add assumptions about manufacturing, energy mix, utilization, geography, and system lifetime (Gupta et al. 2021). We should include only the dimensions relevant to our specific claim, and we must explicitly name the violations, such as design-rule-check (DRC) failures or thermal limits, that completely rule out a candidate.

A valid comparison must also account for our failed and rejected alternatives, not just our winning designs. When we preserve those negative results, we prevent future architects from wasting time reevaluating candidates that our earlier evidence already ruled out. Documenting our failures also shows which parts of the design space our claim covers.

Modern benchmark suites already report several of these dimensions at once. For example, MLPerf Inference, part of our community effort to make machine-learning performance claims reproducible across systems, includes deployment scenario, latency, throughput, and accuracy in its comparisons (Mattson et al. 2020; Reddi et al. 2020). We must always evaluate useful work against whatever resource is scarce in our stated setting, whether that happens to be latency, throughput, energy, power, area, cost, carbon, reliability, verification effort, engineering time, or project risk.

Reddi, Vijay Janapa, Christine Cheng, David Kanter, et al. 2020. “MLPerf Inference Benchmark.” 2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA), 446–59. https://doi.org/10.1109/ISCA45697.2020.00045.

The design, workload, scenario, and scarce resource together define what “efficient” really means. For our Lighthouse system, a candidate that improves average throughput might still be a terrible choice if it misses an XR frame deadline, exceeds our 3 W envelope under sustained load, or adds verification work that our project simply cannot absorb. If we change any of those conditions, we change our claim and the evidence we need to support it.

To structure this multi-metric evaluation, we separate five dimensions of system quality from the meta-cost of the engineering study itself.

Five dimensions describe the proposed physical system, performance, power and energy, reliability and correctness, scalability and cost, and sustainability, while a sixth tracks the study cost itself, the simulation cycles, EDA licenses, and engineering hours expended to reach a verdict (Table 1.2). An apparent efficiency gain in one dimension (such as peak compute throughput) is invalid if it silently inflates data movement energy, violates thermal envelopes, or incurs prohibitive study cost.

Table 1.2: A system result and the work needed to establish it require different measures. Five dimensions describe the proposed system, while evidence and engineering effort describe the study. A valid comparison must show when an apparent improvement shifts cost or changes the scope.

Dimension	Question	Why it complicates the comparison
Performance	How much useful work is delivered per unit time, latency budget, or service-level target?	The answer depends on workload selection, scenario, software stack, and whether the measured behavior matches the deployment claim.
Power and energy	How much useful work is delivered per watt, joule, thermal budget, or battery envelope?	A credible comparison must account for activity, data movement, voltage/frequency choices, thermal constraints, and fidelity gaps between estimates and signoff.
Reliability and correctness	Which required behaviors hold across faults, corner cases, nondeterminism, and the declared operating conditions?	A faster candidate is not acceptable if it spends its savings on fragility, security side-channels, debug burden, or invalid software and hardware assumptions.
Scalability and cost	How much useful work is delivered per dollar, rack, network hop, operator action, or unit of capacity?	Local wins can shift cost to memory, network, power delivery, utilization, operations, or total cost of ownership.
Sustainability	How much useful work is delivered per unit of operational and embodied environmental footprint?	Carbon depends on hardware lifetime, manufacturing, energy mix, utilization, and where and when computation runs.
Study cost: evidence and engineering effort	How much decision-relevant evidence is obtained per simulation, experiment, verification run, or engineer-hour?	Generating more candidates can still be inefficient if evaluation consumes scarce feedback, hides failures, or cannot reject weak outputs.

Because these dimensions interact, we cannot tune them in isolation. In the mobile XR setting anchored by XRBench and ILLIXR, an open-source modular extended reality system framework (Huzaifa et al. 2021), frame latency, energy, sustained power, and data movement are so tightly coupled that a gain in one area can violate a deadline or thermal limit in another. We might offset better simulated performance with verification work the project cannot absorb, or we might achieve lower energy only by relying on fragile software assumptions. A candidate that looks like a winner under a proxy might fail when we test it on a more faithful workload. Therefore, we must explicitly explain which trade-offs are acceptable for our stated constraints, defining the true scope of our system claim instead of relying solely on a single attractive artifact or metric.

Huzaifa, Muhammad, Rishi Desai, Samuel Grayson, et al. 2021. “ILLIXR: Enabling End-to-End Extended Reality Research.” 2021 IEEE International Symposium on Workload Characterization (IISWC), 24–38. https://doi.org/10.1109/IISWC53511.2021.00014.

Even with these coupled requirements, we do not need AI for every architecture project. We often prefer conventional architecture methods when our design question and permitted changes are narrow enough to evaluate directly, and when our required feedback remains cheap and dependable. We should always start by identifying what our familiar models, scripts, simulators, and expert reviews already handle well, before we dictate what we expect AI to improve. The real test is whether AI assistance leads us to a better system or a more reliable conclusion, rather than just helping us generate more artifacts.

When we look at measured RTL-generation benchmarks, we see substantial functional-test failures among generated candidates, making our independent checks essential (Liu, Pinckney, et al. 2023; Pinckney et al. 2024). The practical question is whether our complete approach, and all its required checks, actually improves the architecture result, lowers the total cost of reaching a result of comparable quality, or both, relative to competent conventional work. If every bad proposal forces us into a multi-hour synthesis run, our evaluation pipeline can consume more engineering time and computation than the AI method ever saved us.

Pinckney, Nathaniel, Christopher Batten, Mingjie Liu, Haoxing Ren, and Brucek Khailany. 2024. Revisiting VerilogEval: A Year of Improvements in Large-Language Models for Hardware Code Generation. https://doi.org/10.48550/arXiv.2408.11053.

Our Lighthouse prompt makes this friction concrete. The requested subsystem must support a specific workload class, meet a strict power envelope, fit our technology assumptions, interact correctly with our software stack, and produce reviewable evidence. When we make our final comparison, we must carefully weigh energy, latency, memory traffic, programmability, verification, and deployment risk. While a single scalar objective might help an automated search navigate this complex space, it can never substitute for our architectural judgment.

1.7 State of the Art and Benchmark Assessment

To see how current tools navigate these multi-metric trade-offs and evaluation bottlenecks, we must benchmark the existing state of the art in AI-assisted design automation. Recent advances span exact mathematical search, hardware autotuning, macro placement, and automated RTL generation. However, evaluating these techniques reveals a gap between rapid software assertion checking and the multi-hour physical signoff required for hardware realization. Mapping the state of the art highlights where learned methods accelerate design exploration and where verification bottlenecks persist.

1.7.1 Survey of AI-Assisted Design Systems

Existing AI-assisted design tools demonstrate strong point capabilities within specific evaluation regimes rather than a unified, end-to-end autonomous flow. Recent efforts span exact mathematical search, hardware autotuning, learned physical macro placement, proxy-guided design space exploration, and automated RTL generation. As mapped in the taxonomy in Appendix B, each system establishes progress within a specific evaluation domain, yet every result remains bounded by the fidelity and scope of its underlying verification checks.

These efforts demonstrate that learned methods can accelerate isolated steps in search, placement, and code generation. However, among the systems surveyed in that taxonomy as of this edition, no single framework carries high-level system intent through multi-tool execution, physical signoff, and formal verification to a supported architectural result without human intervention. To bridge this gap, our moonshot connects these demonstrated point capabilities through explicit machine-usable state representations, rejectable evaluation loops, and physical checks while preserving human commitment authority.

A useful contrast exists with software engineering evaluation frameworks such as SWE-bench (Jimenez et al. 2024). Software issue harnesses execute unit and integration tests rapidly, yielding immediate pass-fail feedback for candidate fixes. Hardware design evaluation operates under a different velocity regime. While early analytical or functional screens run quickly, full hardware signoff requires expensive physical synthesis, formal equivalence verification, static timing analysis, and thermal modeling. Fast proxies can prune infeasible designs, but only rigorous physical and formal checks can validate a candidate before hardware commitment.

Jimenez, Carlos E., John Yang, Alexander Wettig, et al. 2024. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” International Conference on Learning Representations (ICLR). https://doi.org/10.48550/arXiv.2310.06770.

Patterson, David A. 2012. “For Better or Worse, Benchmarks Shape a Field: Technical Perspective.” Communications of the ACM 55 (7): 104. https://doi.org/10.1145/2209249.2209271.

Standard Performance Evaluation Corporation. 2017. SPEC CPU 2017 Benchmark. https://www.spec.org/cpu2017/.

Binkert, Nathan, Bradford Beckmann, Gabriel Black, et al. 2011. “The gem5 Simulator.” ACM SIGARCH Computer Architecture News 39 (2): 1–7. https://doi.org/10.1145/2024716.2024718.

Karandikar, Sagar, Howard Mao, Donggyu Kim, et al. 2018. “FireSim: FPGA-Accelerated Cycle-Exact Scale-Out System Simulation in the Public Cloud.” 2018 ACM/IEEE 45th Annual International Symposium on Computer Architecture (ISCA), 29–42. https://doi.org/10.1109/ISCA.2018.00014.

Mattson, Peter, Vijay Janapa Reddi, Christine Cheng, et al. 2020. “MLPerf: An Industry Standard Benchmark Suite for Machine Learning Performance.” IEEE Micro 40 (2): 8–16. https://doi.org/10.1109/MM.2020.2974843.

Our discipline already has shared checks at individual layers. We have seen SPEC-style benchmarks make performance claims far more comparable through common workloads, strict run rules, and precise reporting standards (Patterson 2012; Standard Performance Evaluation Corporation 2017). We rely on cycle-accurate architectural simulators (such as gem5) and FPGA-accelerated hardware simulation (such as FireSim) to provide shared simulation platforms at different costs and fidelities (Binkert et al. 2011; Karandikar et al. 2018). MLPerf defines rigorous benchmark suites and submission rules for machine-learning systems (Mattson et al. 2020). These resources ensure that we as outside researchers can rerun, compare, and challenge any scoped result. However, they do not render our results automatically correct, nor do they connect all the diverse evidence we require for the Lighthouse. We must therefore view our current systems as establishing bounded progress toward our moonshot, rather than delivering a definitive, end-to-end verdict.

1.7.2 Data Scarcity, Verification Load, and Generators vs. Verifiers

A primary reason current systems achieve only bounded progress is that AI-assisted hardware design operates under severe data scarcity and asymmetric verification costs. Unlike software development, where vast open-source repositories supply training data and fast integration tests, hardware design depends on confidential process design kits, proprietary IP blocks, and multi-hour physical synthesis flows. As candidate proposal velocity increases, verification capacity becomes the dominant bottleneck.

The available public data changes sharply with the task. Open-source software corpora may contain hundreds of billions of tokens, while hardware collections count synthesizable modules, executed layouts, or validated architecture questions (Lozhkov et al. 2024; Wang et al. 2025; Prakash et al. 2025; Chai et al. 2022). Those units are not directly comparable, so they do not establish a single scarcity ratio or a causal explanation for model failures. They do show why an AI-native design system needs task-specific curation and machine-checkable evidence rather than assuming that broad software pretraining covers architecture work. Chapter 4 examines those collections in their native observation units.

Lozhkov, Anton, Raymond Li, Loubna Ben Allal, et al. 2024. “StarCoder 2 and The Stack v2: The Next Generation.” arXiv Preprint arXiv:2402.19173. https://arxiv.org/abs/2402.19173.

Prakash, Shvetank, Andrew Cheng, Jason Yik, et al. 2025. “QuArch: A Question-Answering Dataset for AI Agents in Computer Architecture.” IEEE Computer Architecture Letters 24 (1): 105–8. https://doi.org/10.1109/LCA.2025.3541961.

Chai, Zhuomin, Yuxiang Zhao, Yibo Lin, Wei Liu, Runsheng Wang, and Ru Huang. 2022. “CircuitNet: An Open-Source Dataset for Machine Learning Applications in Electronic Design Automation (EDA).” Science China Information Sciences 65 (12): 227401. https://doi.org/10.1007/s11432-022-3571-8.

Liu, Mingjie, Teodor-Dumitru Ene, Robert Kirby, et al. 2023. ChipNeMo: Domain-Adapted LLMs for Chip Design. arXiv preprint arXiv:2311.00176. https://arxiv.org/abs/2311.00176.

While public software repositories easily expose source changes, technical discussions, and testing frameworks, hardware is far more guarded (Liu, Ene, et al. 2023). If we lean solely on models trained on public text for our architecture studies, we might generate plausible-looking RTL that misses our specific interfaces, PDKs, memory subsystems, or signoff constraints. Open designs and open PDKs help, but they cannot replace the authorized PDK, IP blocks, and precise tool configurations required to actually evaluate our project’s physical claims.

Technical fit is not our only hurdle when using project data; our candidates must also survive legal and compliance scrutiny. If a model reproduces code from its training set in generated RTL without strict provenance tracking, we expose our designs to inbound IP contamination. Conversely, if we send proprietary specifications, constraints, or EDA tool reports out to an unauthorized model endpoint, we risk outbound disclosure. Without strict data isolation and clear provenance, our AI-generated architectures will not clear legal signoff, erasing whatever time candidate generation saved. We must manage source permissions, output provenance, project confidentiality, and outside-review access as distinct, non-negotiable requirements for how we handle data.

Training data is not the only way to fill these information gaps. As architects, we can actively supply specifications and analytical models, encode our own machine-checkable constraints, pull in live documentation, and use tool feedback to refine our candidates iteratively. Automated debugging frameworks (Tsai et al. 2024), open-source SoC design environments (Amid et al. 2020), and open digital physical design toolchains (Ajayi et al. 2019) illustrate how we can expose constraints and integrate tool feedback.

Tsai, Yun-Da, Mingjie Liu, and Haoxing Ren. 2024. “RTLFixer: Automatically Fixing RTL Syntax Errors with Large Language Models.” Proceedings of the 61st ACM/IEEE Design Automation Conference (DAC). https://doi.org/10.1145/3649329.3657353.

Amid, Alon, David Biancolin, Abraham Gonzalez, et al. 2020. “Chipyard: Integrated Design, Simulation, and Implementation Framework for Custom SoCs.” IEEE Micro 40 (4): 10–21. https://doi.org/10.1109/MM.2020.2996616.

Ajayi, Tutu, Vidya A. Chhabria, Mateus Fogaça, et al. 2019. “Toward an Open-Source Digital Flow: First Learnings from the OpenROAD Project.” Proceedings of the 56th Annual Design Automation Conference (DAC), 1–4. https://doi.org/10.1145/3316781.3326334.

In large-scale verification, we combine rapid C++ behavioral co-simulation with FPGA-accelerated cycle-exact verification under realistic trace inputs, gate-level static timing verification, formal equivalence checking, and Bounded Model Checking for property verification. While these platforms illustrate how we can expose constraints and integrate tool feedback, they cannot automatically recover the proprietary information that lies beyond their reach. We examine the mechanisms for building and representing this project knowledge in Chapter 4.

Even if we perfect candidate generation, verification remains the larger hurdle. A first-pass RTL candidate might look plausible while hiding subtle, fatal errors. In fact, industry surveys show that verification eats up roughly half of our total engineering effort, with our design engineers dedicating nearly half of their own time just to verification tasks (Foster 2022). We can certainly apply reusable UVM environments across multiple related candidates, but our stimulus, checkers, assertions, coverage models, and debug capacity must evolve to match the new behaviors our generated candidates introduce.⁷

Foster, Harry. 2022. Part 8: The 2022 Wilson Research Group Functional Verification Study. Verification Horizons, Siemens EDA. https://blogs.sw.siemens.com/verificationhorizons/2022/12/12/part-8-the-2022-wilson-research-group-functional-verification-study/.

⁷ Universal Verification Methodology (UVM): A standardized SystemVerilog library and class hierarchy for constructing modular, coverage-driven hardware verification testbenches (IEEE 2020).

IEEE. 2020. IEEE Standard for Universal Verification Methodology Language Reference Manual. IEEE Std 1800.2-2020. IEEE. https://doi.org/10.1109/IEEESTD.2020.9195920.

Liu, Mingjie, Nathaniel Pinckney, Brucek Khailany, and Haoxing Ren. 2023. “VerilogEval: Evaluating Large Language Models for Verilog Code Generation.” IEEE/ACM International Conference on Computer-Aided Design (ICCAD). https://arxiv.org/abs/2309.07544.

Lu, Yao, Shang Liu, Qijun Zhang, and Zhiyao Xie. 2024. “RTLLM: An Open-Source Benchmark for Design RTL Generation with Large Language Model.” Proceedings of the 29th Asia and South Pacific Design Automation Conference (ASP-DAC). https://arxiv.org/abs/2308.05345.

Wang, Jinghua, Lily Jiaxin Wan, Sanjana Pingali, et al. 2025. “OpenRTLSet: A Fully Open-Source Dataset for Large Language Model-Based Verilog Module Design.” 2025 IEEE International Conference on LLM-Aided Design (ICLAD), 212–18. https://doi.org/10.1109/ICLAD65226.2025.00038.

If candidate production speeds past our ability to test, the primary bottleneck shifts directly to verification. Published generation benchmarks report severe attrition at the parsing, interface-compliance, and functional-simulation stages (Liu, Pinckney, et al. 2023; Lu et al. 2024; Wang et al. 2025), and composing representative stage rates end to end, with timing closure and layout checks compounding further, shrinks thousands of generated candidates to a handful of survivors. We walk that composite attrition stage by stage in Chapter 7.

AI candidate proposal latency and hardware verification check time do not scale together (Figure 1.6). Across five design scales, proposal latency stays under one minute at every abstraction level, while verification check time expands by orders of magnitude as design scope grows, from milliseconds for tensor operators up to days or weeks for full SoC physical signoff and formal equivalence checking. This four-order-of-magnitude verification gap is why accelerating candidate creation yields diminishing returns unless we pair generation with equally fast early screening filters; these are constructed order-of-magnitude ranges, not measurements. Generating hardware faster matters only if we retain the ability to identify and reject bad candidates at that same accelerated pace.

Horizontal bar chart comparing AI candidate proposal latency against hardware verification check time across five design scales from tensor operators to full SoC signoff. Verification check time scales from milliseconds to days/weeks, while AI candidate generation remains under one minute. — Figure 1.6: **Proposing a candidate and checking one do not scale together.** Constructed order-of-magnitude ranges, not measurements; no per-candidate latency study is reported here. What transfers is the divergence. Proposal cost stays roughly flat as design scope grows, while the checks that could reject a candidate grow with it, so the two curves separate by orders of magnitude at full SoC signoff. A project’s own tool flow sets where the separation lands.

Verification must also push well beyond basic functional correctness, especially when our design’s threat model involves hardware security. As Spectre demonstrated, processors that are functionally flawless can still leak sensitive data through microarchitectural side channels (Kocher et al. 2019). If we use AI to generate security-relevant hardware, we are obligated to apply independent checks tailored to our specific design and threat models. This means we must verify isolation properties, run side-channel analyses, and detect malicious modifications. While our generation models can help us draft SystemVerilog assertions, outline security properties, and build testbenches, they cannot prove their own correctness.

Kocher, Paul, Jann Horn, Anders Fogh, et al. 2019. “Spectre Attacks: Exploiting Speculative Execution.” IEEE Symposium on Security and Privacy (s&p), 1–19.

Because we operate under scarce project information and costly verification, maintaining explicit state becomes a requirement for AI-native co-design. When we lower compact system intent through our prompt stack, candidate generation is only the opening step. To translate high-level intent into verified silicon, our prompt stack must connect directly to a continuous design workflow. In this workflow, candidate proposals, simulation runs, and verification checks iterate under clear architectural bounds, keeping machine-usable state inspectable by our human reviewers every step of the way.

1.8 From Architecture 1.0 to Architecture 2.0

Working within these data and verification limits defines the operational transition from Architecture 1.0 to Architecture 2.0, expanding the scope of automation without transferring decision authority (Janapa Reddi and Yazdanbakhsh 2025). Architecture 1.0 relies on analytical models, scripted parameter sweeps, and manual microarchitectural tuning. Architecture 2.0 incorporates learned generation, surrogate prediction, and agentic search across the hardware-software boundary. This transition shifts the architect’s primary role from crafting individual point designs to formulating system constraints, orchestrating automated tools, and forming supported technical recommendations for the named commitment authority.

Janapa Reddi, Vijay, and Amir Yazdanbakhsh. 2025. “Architecture 2.0: Foundations of Artificial Intelligence Agents for Modern Computer System Design.” Computer 58 (2): 116–24. https://doi.org/10.1109/MC.2024.3521641.

Five architectural responsibilities separate established Architecture 1.0 practice from AI-native Architecture 2.0 methodology, marking how our operational role as architects evolves (Table 1.3). Under Architecture 1.0, engineers manually script parameter sweeps and tune point microarchitectures. Under Architecture 2.0, learned surrogates and generative search automate candidate exploration and tool orchestration. Decision authority, though, remains unchanged: while AI components propose candidate designs and aggregate evidence, the human architect and Commitment Authority retain sole approval rights over baseline contracts and silicon signoff.

Table 1.3: AI participation broadens what may be delegated without changing the authority structure. Architecture 2.0 adds learned prediction, generation, optimization, retrieval, or tool coordination to established analytical and automated practice, while the architect and commitment authority retain their respective decision-making roles.

Feature	Established architecture practice (Architecture 1.0)	AI-native co-design practice (Architecture 2.0)
Problem framing	Architects define the question, abstractions, constraints, and tool tasks	Learned methods may help interpret broader intent or incomplete information and propose choices for architect review
Exploration	Architects use analytical models, scripts, parameterized generators, sweeps, and conventional optimization	Prediction, generation, and learned optimization may propose, screen, or select alternatives alongside established methods
Tool use	Architects and scripts invoke simulators and design tools, preserve results, and decide what to run next	Automated components may select later actions from tool returns, so state, cost, failures, and permitted actions must be usable by the component and inspectable by the reviewer
Result standard	Measurements and checks turn candidate artifacts into comparisons that can support the next architecture action	The same standard applies; broader automated participation does not make an unchecked artifact an architecture result
Recommendation and commitment	Architects integrate results and form the technical recommendation; a named commitment authority decides whether the architecture advances to the next consequential transition	Methods may organize analysis or prepare a draft recommendation, while the architect and commitment authority retain their respective responsibilities

Inviting AI into our process does not automatically generate explicit evidence or sound record-keeping. In conventional projects, we preserve requirements, artifact versions, tool databases, and verification reports across engineering repositories and expert intuition. When we introduce automated components, we face a new structural requirement. We must represent selected state and permitted tool actions for machine execution while keeping all artifacts inspectable by human reviewers.

Both execution paradigms retain the same review obligations; what changes is which state becomes machine-usable (Figure 1.7). In established Architecture 1.0 work, project knowledge remains distributed across specifications, source files, and expert practice, with human architects manually driving tools and review loops. AI-native Architecture 2.0 work instead structures machine-usable project state and action spaces for automated agents. Both retain explicit review points and iterative feedback paths, keeping machine-driven exploration transparent to human architects.

Two side-by-side diagrams compare established human-orchestrated and AI-native co-design studies. The left distributes project knowledge across engineering artifacts, records, and expert practice. The right also represents selected state and permitted actions for automated methods. Both panels retain explicit evidence, expert or architect review, and a feedback path without assigning organizational commitment to the review step. — Figure 1.7: **Automated participation introduces explicit machine-use representation requirements.** Our established architecture work can retain explicit evidence while our project knowledge remains distributed across specifications, source code, tool databases, verification artifacts, and expert practice. When we add automated components, we must also represent selected state and permitted actions for machine use while keeping them inspectable by our reviewers. Both panels retain a review point and a feedback path; neither assigns organizational commitment to that review step.

We must keep this machine-usable state strictly aligned with the artifacts and records our reviewers inspect. Meeting this requirement does not automatically validate the outputs, nor does it transfer our responsibility for the technical recommendation or our commitment authority.

We must deliberately coordinate our methods to keep every local action tied to our original design question. If we do not, a generator, surrogate, simulator, or implementation tool might succeed locally but inadvertently advance an infeasible candidate, or miss a system obligation.

To manage this, our design system keeps the architecture question and its obligations current alongside candidate, tool, and version state. From there, we assign prediction, generation, optimization, or conventional methods based on whatever work is currently limiting our progress. We use tool feedback and independent checks to constrain their outputs, while leaning on cost and clear stopping conditions to bound the overall effort.

We must keep candidate production separate enough from checking to expose failures. Even nominally independent implementations often fail on the exact same hard inputs (Knight and Leveson 1986), and multiple components can repeat the same flawed assumption if they share training data, a proxy, or an underlying model. In this book, we treat an independent check as a strict operational threshold. Under this threshold, the method that produces a candidate neither controls its check nor acts as the sole pass/fail authority. Likewise, the check cannot simply inherit its decisive assumptions and implementation straight from the generator. While achieving complete independence is rare, we know that a check only repeating its producer’s assumptions can never qualify our results.

Knight, John C., and Nancy G. Leveson. 1986. “An Experimental Evaluation of the Assumption of Independence in Multiversion Programming.” IEEE Transactions on Software Engineering 12 (1): 96–109. https://doi.org/10.1109/TSE.1986.6312924.

Even when we coordinate a study perfectly, it cannot establish whether our proposed architecture succeeds or if our complete approach actually improves the work. To make those final judgments, we need entirely separate tests.

1.9 Putting the Moonshot into Practice

Bridging the gap between prospective methodology and production reality requires rigorous evaluation criteria and explicit operational safeguards. Two questions have to stay apart, because they can come back with different answers and only one of them is technical.

We evaluate our moonshot against two independent tests. The first asks whether the work got better. The second asks whether anyone should commit to it. Passing the first does not settle the second, and no amount of evidence collapses them into one question.

Our first test asks whether the complete AI-native design system improved the work. A proposed design must satisfy the fixed Lighthouse conditions under the required workload, software, implementation, physical, and verification checks. It must then beat a credible alternative, which means the strongest practical conventional workflow run under identical constraints for budget, tool access, and stopping conditions. A generated artifact demonstrates architectural progress only when it improves the final result, reduces the total engineering cost of reaching a comparable result, or does both. The test carries its own envelope. It is answered for the workloads, tools, and conditions actually assessed, and it says nothing outside them. It can come back three ways. The new design is better, the original reference should stand, or nothing available meets the conditions. All three are results.

Our second test asks a different question that no measurement answers. Given what the evidence supports, the trade-offs, the limits of the result, and the risk that remains unmeasured, should this organization commit? That decision belongs to a named commitment authority within an accountable organization, not to a passing check and not to the system that produced the candidate. The architect’s supported recommendation is an input to that decision. Reviewability makes both tests possible and substitutes for neither. We develop this second test fully in Chapter 11, which is also where we return to the Lighthouse and report what our own results settled.

Keeping the tests apart drives several consequences for how we measure success. A brilliant design does not prove that our workflow improved the engineering process, and an inexpensive process never justifies an inferior architecture. If a conventional workflow produces a sound result, that counts as a success for the architecture question even when our complete approach fails to beat it. A random search gives us a useful performance floor, but we cannot assume it represents the strongest practical conventional baseline. Most consequentially, a study can pass the first test and still end without a commitment, and an organization can decline to commit a design that the evidence fully supports. Neither outcome is a contradiction.

Neither of these comparisons isolates the contribution of a specific foundation model, generator, surrogate, or individual software component. If we want to make that narrower claim, we must perform a controlled replacement or ablation study within an otherwise identical system. When we call these tests “independent,” we simply mean they answer fundamentally different questions. We do not imply that their measurements are statistically independent.

Assessing a broader program does not add a third test. It aggregates the first one across studies, and the second still falls to whoever owns each commitment. We aggregate repeated comparisons of our complete approach across various tasks, design stages, and conditions. To claim program-level success, our complete approach must consistently improve architecture results, reduce the cost of achieving comparable quality, or both across our entire declared scope. Based on the public evidence we reviewed for this edition, we cannot yet settle that final verdict.

A single successful Lighthouse study gives us an existence proof. It does not provide broad validation for a new design method. To achieve that, our same two tests must hold up across all our declared tasks and conditions. Independent teams must be able to reproduce our relevant measurements and supported results using our preserved inputs, tools, and checks. Finally, those outside teams must have the ability to inspect the engineering basis behind any technical recommendation we make.

1.10 Common Pitfalls

As engineering teams put these evaluation tests into practice, deploying an AI-native design system introduces subtle operational failure modes where unverified assumptions or misaligned metrics distort architectural decision-making. Identifying these common pitfalls helps engineering teams enforce signoff boundaries while avoiding both dogmatic skepticism and uncritical trust in generated artifacts.

Dismissal without measurement: Rejecting an assisted approach on the strength of an early hallucinated artifact, or adopting one on the strength of an impressive demonstration, without running either against a credible alternative at matched budget. Both moves settle the question by disposition rather than evidence. The two evaluation tests exist precisely so that a refusal and an adoption are held to the same standard.
Confusing draft artifacts with checked architectural decisions: Mistaking a syntactically valid block of generated RTL, a compiler patch, or a candidate script for a checked architecture decision. In a moonshot context, an unverified candidate remains an uncommitted hypothesis until it passes complete physical, software, and workload checks and is retired by the human commitment authority.⁸
Ignoring cross-layer system boundaries in intent translation: Optimizing an isolated subsystem like a compute array without accounting for global data movement, memory bandwidth caps, power delivery, or strict interface protocols such as AXI handshakes. Translating compact intent requires preserving global system contracts rather than maximizing local component throughput.
Exploiting proxy evaluators: Over-optimizing candidates against fast surrogate models or high-level estimators that omit physical implementation constraints. When optimization loops exploit proxy blind spots, apparent architectural gains disappear as soon as downstream physical EDA synthesis and formal verification run; the calibration discipline that keeps screening proxies honest belongs to method selection and feedback qualification (Chapter 5).⁹
Conflating generation velocity with architectural progress: Celebrating a rapid AI generation step without asking where its output sits on the artifact-to-result hierarchy this chapter defined. A faster route to an unqualified artifact is not progress, and Chapter 2 develops the capacity arithmetic behind this trap.¹⁰
The believer’s surrender (bypassing signoff checks): Uncritically trusting generative AI outputs or surrogate recommendations without executing rigorous physical EDA timing, formal SystemVerilog Assertion checks, and workload simulations. Relinquishing commitment authority to learned models invites silent bugs and silicon re-spins.

⁸ Purpose of computing: Hamming (1962) famously established that “the purpose of computing is insight, not numbers.” In AI-native hardware engineering, emitting syntactically plausible RTL or compiler patches merely produces candidate data; an architectural decision requires verified physical and workload insight established under human commitment authority.

Hamming, Richard W. 1962. Numerical Methods for Scientists and Engineers. McGraw-Hill.

⁹ Goodhart’s Law in EDA surrogates: Strathern (1997) distilled Goodhart’s observation into its familiar form, that when a measure becomes a target, it ceases to be a good measure (Goodhart 1975). Automated optimization loops that target fast surrogate metrics exploit omissions in high-level cost models, causing proxy-optimized ranks to decouple completely from physical timing and power signoff.

Strathern, Marilyn. 1997. “‘Improving Ratings’: Audit in the British University System.” European Review 5 (3): 305–21.

Goodhart, Charles A. E. 1975. “Problems of Monetary Management: The UK Experience.” In Papers in Monetary Economics, vol. 1. Reserve Bank of Australia.

¹⁰ Amdahl’s Law of design pipelines: Amdahl (1967) established that overall speedup is strictly bounded by the un-accelerated sequential fraction of a workload. In AI-native design, accelerating draft proposal generation by \(100\times\) yields minimal total throughput improvement if downstream formal verification, timing closure, and human signoff remain un-accelerated bottlenecks.

Amdahl, Gene M. 1967. “Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities.” Proceedings of the April 18–20, 1967, Spring Joint Computer Conference, AFIPS ’67 (spring), 483–85. https://doi.org/10.1145/1465482.1465560.

1.11 Open Questions

Navigating these operational pitfalls and evaluation limits brings us directly to the research frontier of AI-native architecture. The transition from generating isolated artifacts to establishing a verifiable, AI-native design capability marks an expansion in what our discipline can reliably build. The frontier of this chapter lies precisely at the gap between compact system intent and rigorous cross-stack validation, a space where current design automation breaks down. Resolving how we capture unstructured requirements, enforce physical constraints, and prevent proxy exploitation across the full hardware-software contract requires more than incremental tool updates. These foundational challenges define the larger Architecture 2.0 effort, setting the stage for the open questions that conclude every subsequent chapter.

Intent Translation and Human Decision Ownership: Architecture 2.0 expands automated orchestration across multi-layer stack constraints while preserving strict human governance.

How can compact system intent become an executable architecture specification without losing system obligations or diluting human commitment authority? A compact request leaves workload behavior, software contracts, interfaces, physical limits, and acceptance conditions implicit. An AI-native design system must expose these missing obligations and orchestrate cross-stack exploration without replacing human intent with system-generated assumptions or bypassing human commitment authority.

Foundation Models Versus Project State: Learned prior knowledge must accelerate design exploration without corrupting authoritative project records.

What architectural knowledge can transfer across project generations via foundation models, and how can a design system detect when prior assumptions fail under new technology constraints? Prior design data can save repeated effort, yet learned models may silently apply stale assumptions when technology nodes, process design kits, or compiler pipelines change. Our discipline must develop detection mechanisms that expose invalid knowledge transfer before reused patterns yield unsupported architecture results.

Total-Cost Boundary and Artifact Qualification: Qualifying generated candidates demands comprehensive accounting of evaluation feedback and verification load.

Where does an AI-native design system create net architectural value after accounting for the complete total-cost boundary? Accelerating a local generation step does not reduce total engineering effort if data preparation, simulation, verification, failed runs, and human review inflate overall costs. As architects, we must establish when AI-native co-design improves final architecture results or lowers the net cost of achieving them, rather than shifting engineering burdens elsewhere.
How do we construct multi-metric verification boundaries that prevent proxy exploitation during learned search? Learned optimizers and surrogate models can exploit omissions in fast evaluators, producing apparent gains that vanish during physical synthesis or gate-level power analysis. We must design rejectable evaluation loops that pair cheap surrogate screening with high-fidelity physical and formal checks before candidates reach design commitment.

Discipline-Wide Benchmark and Evidence Disclosure Standards: Rigorous comparison requires open benchmarks and reproducible evidence boundaries.

What standard benchmark suites and evaluation protocols must our discipline establish to measure Architecture 2.0 capabilities against strong conventional baselines? Validating AI-native design systems requires shared, multi-constraint targets comparable to how SPEC, MLPerf, and gem5 transformed conventional practice. We must define open system briefs, like the Lighthouse mobile XR subsystem, that test complete cross-stack orchestration across realistic hardware, software, and physical constraints.
What minimum evidence standard should accompany claimed Architecture 2.0 advances while protecting restricted physical PDKs and proprietary IP? Architecture results often depend on confidential foundry design kits, proprietary EDA toolchains, and internal chip data. As architects, we must establish disclosure standards that protect restricted IP while providing sufficient technical evidence for independent reviewers to evaluate and reproduce claimed methodology advances.

1.12 Summary

In this opening chapter, we established the Architecture 2.0 moonshot around our industrial Lighthouse case study. A compact prompt is never a specification; it conceals eight tightly coupled layers spanning workloads, contracts, compute organizations, memory hierarchies, power envelopes, compilers, physical constraints, and signoff checks. Before treating any request as an executable target, we must explicitly define those underlying system obligations, legal alternatives, physical limits, and acceptance checks. While provisional assumptions allow early exploration, they cannot support architectural commitment. An isolated candidate may falsely appear superior if a comparison omits a critical dependency; we must ensure every reported measurement traces to a verified evidence path before committing to a design. When we integrate AI-native co-design into our workflows, we must distinguish between unverified draft artifacts and fully qualified architecture results that can withstand independent review.

Our analysis demonstrates that AI participation broadens what we can automate without altering our fundamental decision authority. When we evaluate this foundational phase of Architecture 2.0, four core takeaways govern our work.

Key Takeaways: From Compact Intent to a Supported Result

Explicit specification over compact intent. A high-level prompt must expand into explicit workload traces, ABI contracts, memory hierarchies, physical constraints, and verification checks before any candidate can drive executable engineering.
Artifact qualification standard. Syntactically valid code or successful local tool runs are merely candidate artifacts until qualified by rigorous measurements and checks under declared operating conditions.
Two independent evaluation tests. Architecture 2.0 requires evaluating the architectural design quality against reference baselines separately from measuring the net productivity and engineering cost reductions of the AI-native workflow itself.
Non-delegable commitment authority. Automated generators and learned surrogates propose candidate designs, while a named human commitment authority retains non-delegable approval rights over silicon capital commitments and baseline specification updates.

The Architecture 2.0 moonshot matters only because modern computer architecture has hit structural complexity limits. The compounding physical, software, and evaluation pressures behind those limits, and why they now exceed what conventional design practice can absorb, are where we turn next (Chapter 2).