Architecture 2.0
Principles of AI-Native System and Chip Design
Preface
v0.2.9When we look across science and engineering, artificial intelligence has begun to do real work. It searches design spaces too vast to enumerate by hand, learns predictive models where first principles cannot easily reach, and proposes candidate solutions no one thought to try. But can AI also transform how we design computing systems and silicon chips?
Computer architecture is an unusually demanding domain to test that question. An architectural decision begins with high-level workload intent and propagates through software runtimes, ISAs, microarchitectures, RTL, and physical silicon signoff. Our measurements are expensive and inherently partial. A simulator, compiler, formal model, synthesis report, and post-layout analysis each reveal a different slice of the system under different operating assumptions. Verification must prove far more than whether a candidate design looks plausible, and a logic bug discovered after tapeout carries catastrophic financial and schedule costs compared to a software patch.
Yet that very difficulty is why the opportunity is so compelling. The ambition of this book is larger than accelerating isolated CAD tasks. An AI-native system and chip design methodology rebuilds the design workflow itself, so that learned methods, conventional simulators, and physical signoff tools operate as one system, on one shared representation of the project, with hardware and software designed together. The danger arrives with the opportunity. Generators can already produce candidate designs far faster than any team can responsibly evaluate them, and generating options faster helps only when the engineering process can determine what those options mean.
This question is not new to me. Not long after ChatGPT appeared, I began carrying an early version of the design request this book calls the Lighthouse prompt, a few sentences asking for a low-power XR compute subsystem, into talks and hallway conversations, asking what it would take for a machine to do real architecture work against it. Most colleagues thought the question was premature at best. Three years later, the capabilities have moved faster than almost anyone expected, and the question is no longer whether to take the possibility seriously. It is how to do the work with discipline.
I wrote this book to make that possibility concrete without assuming its success. The ambition is deliberately larger than generating RTL from a prompt or training a standalone performance predictor. It asks whether a complete, closed-loop approach can produce superior architectures, reduce the total cost of reaching a comparable result, or achieve both. It does not assume that this moonshot is solved; it establishes the foundational principles and tool harnesses required to pursue it rigorously without confusing local progress with full-system success.
The architecture problem always comes first. Depending on the design problem, the right approach may combine generation, prediction, optimization, conventional analysis, or no AI at all. Architecture 2.0 is not a claim that every design task requires machine learning; it is a framework to determine where AI earns its place and what evidence its use must produce.
On the Title of This Book
The title of this book, Architecture 2.0: Principles of AI-Native System and Chip Design, is a compact statement of its scope, and each of its terms is deliberate.
Architecture 2.0 names a paradigm shift1 that this book argues for rather than assumes, away from manual point-design sweeps toward autonomous, closed-loop exploration across the hardware-software stack. The book teaches Principles because its substance is the decision rules, evidence standards, and design trade-offs that architects face every day.
1 Author’s note: I do not use the term paradigm shift lightly. In the classic formulation of Kuhn (1962), a paradigm shift occurs when a discipline’s established methods encounter physical and operational limits that incremental improvements can no longer resolve. I argue that computer architecture has reached that condition, and this book supplies the evidence standard by which the claim should be judged. Independent use and later evidence will determine the verdict.
AI-native carries a precise engineering meaning here. A point-assistance workflow retrofits a copilot onto individual CAD tasks and leaves the surrounding process untouched. An AI-native methodology instead builds the exploration workflow, the machine-usable state representation contracts, and the verification harnesses around closed-loop search and multi-tool orchestration from the start. Finally, System and Chip Design reflects the physical reality that a silicon chip cannot be designed in isolation from the software compilers, memory hierarchies, interconnects, and physical signoff engines that surround it.
What This Book Teaches
This book follows an architecture question through the engineering work required to answer it. As architects, we formulate the question and represent the design state, then select the methods and run the tools required to evaluate candidate solutions. What the tools return must be interpreted, compared against credible baselines, and turned into a technical recommendation that a human authority will own. This sequence keeps the focus on what architects must judge and execute rather than on any ephemeral model or tool.
When we evaluate whether adopting an automated workflow improves a design program, the object of study is the complete human-and-tool workflow. Candidate quality, final architecture performance, and the specific contribution of an AI model require separate, rigorous tests. A powerful model can sit inside a broken design loop, whereas a modest learned method can yield immense value if it eliminates the exact bottleneck constraining our decisions. The book condenses that discipline into two tests it applies throughout. Did the complete approach improve the work? And should anyone commit to the result? The first question is technical. The second one never is.
This book prepares an architect to carry out the following core work:
- Formulate architecture questions and clarify the specific decisions they support.
- Diagnose limiting bottlenecks in a workflow before selecting an AI or conventional method.
- Represent design state, cross-layer dependencies, permitted modification spaces, and unrepresented unknowns.
- Select appropriate methods among conventional analysis, unassisted design, candidate generation, performance prediction, design space optimization, or targeted hybrids.
- Interface methods to executable tools, reconstruct execution trajectories, and qualify which tool outputs constitute valid physical measurements.
- Evaluate outcomes fairly, isolating the architecture result and the contribution of AI against matched baselines at equal evaluation budgets.
- Defend technical recommendations, explicitly stating evidence limits while identifying who holds commitment authority and who retains ultimate technical responsibility.
To keep these principles concrete, this book uses a recurring Lighthouse case study featuring a real-time mobile extended reality compute subsystem under strict power and physical constraints. Nothing in that subsystem can be solved in isolation. The power envelope limits the accelerator, the accelerator reshapes memory traffic, and the memory hierarchy shifts thermal density across the die. The book returns to the Lighthouse at the points where the case exposes a fundamental principle, grounding the methods in executable reality rather than abstract claims.
This book sits at the convergence of three established technical disciplines, as shown in Figure 1.
Computer architecture and machine learning intersect in ML for systems, where learned models predict performance and explore design spaces. Computer architecture and EDA intersect in chip design, where microarchitectural choices become RTL and physical floorplans. Machine learning and EDA intersect in ML for CAD, which accelerates placement, routing, and logic verification. Architecture 2.0 operates where all three meet.
This intersection matters because each discipline enforces distinct evidence standards. Simulation benchmarks validate work between architecture and machine learning; physical signoff and silicon validate work between architecture and EDA; post-route metrics validate work between machine learning and EDA. Architecture 2.0 demands that we satisfy all three standards simultaneously. A generated hardware block that ignores workload characteristics is not an architecture result; a learned estimate that fails physical signoff is not a physical result; and a successful tool run without a matched baseline comparison does not prove that AI improved the design.
This book is not a catalog of current neural networks, a prompt-to-chip automation script, or a defense of using AI indiscriminately. It does not replace architectural judgment, compiler engineering, or formal verification with black-box models. Physical checks remain paramount, and named human architects remain answerable for the choices made and the silicon committed.
Who This Book Is For
The primary audience is the practicing computer architect and systems researcher. This book assumes familiarity with performance, power, energy, area, and hardware-software interfaces, as well as the ability to evaluate architecture papers, simulator logs, and synthesis reports. It does not assume prior background in machine learning; it introduces all necessary ML concepts through concrete architecture problems and physical constraints.
Four technical communities meet at this intersection, and this book is structured to serve each of them:
- Computer architects seeking to integrate AI generation and search into rigorous design space exploration without losing control of physical constraints.
- EDA and CAD engineers looking to connect synthesis, placement, and verification tools to high-level architectural decision loops.
- Machine learning and ML-systems researchers entering hardware design who need to understand how physical signoff, evaluation costs, and formal verification redefine the criteria for a valid result.
- Graduate students and systems engineers spanning hardware and software who want a shared vocabulary and rigorous framework for AI-native systems engineering.
The common test across all four communities is whether the reasoning carries to architecture problems beyond the Lighthouse case, and whether it makes clear when an AI-native design loop earns its place and when conventional engineering remains the better answer.
Book Structure
This book develops its engineering argument across four sequential movements:
- Part I: System Intent and Design Lifecycles defines what a complete Architecture 2.0 capability must achieve and why generating candidates faster is worthless without matching evaluation capacity. It shows how a compact product request expands into a full cross-stack architecture problem, and how a staged lifecycle keeps that work organized.
- Part II: Technical Building Blocks traces an architecture question through the four technical layers every AI-native design system needs: represented design state, learned and conventional methods, tool-connected environments, and verification feedback. The through-line is preserving physical meaning during automated search.
- Part III: Closed-Loop Execution and Ownership runs complete design loops end to end, asks what transfers when the workload, tools, or objectives change, and shows how to evaluate the whole workflow against credible baselines. It ends with the question of ownership, and the answer keeps commitment authority with named human architects.
- Part IV: Open Infrastructure and Ecosystems changes altitude from one team to the discipline. It separates the shared infrastructure that comparable claims require, such as open process data and neutral benchmark governance, from the practices any team can adopt tomorrow.
Together, these four movements carry the argument from high-level vision to executable methods an architect can evaluate, apply, and transfer to other system design problems, and then to the shared foundations the discipline still needs.
How to Read This Book
Read this book sequentially the first time through. The engineering argument is cumulative. Method selection depends on state representation, measurement validity depends on tool execution discipline, and technical recommendations depend on evidence limits. The Lighthouse mobile XR case study provides narrative continuity throughout, serving as a concrete reference rather than a rigid design template.
Test these principles against a live design problem while reading. Ask what decision truly matters, what hidden constraints must be exposed, which baseline comparison is fair, what the tools actually measured, and what risks remain unverified. The measure of this book is whether its principles carry to design problems it never mentions.
Specific AI models, benchmark scores, and CAD tool interfaces will keep changing. The core reasoning in this book is built to outlast them. When we ground the work in problem formulation, state representation, tool discipline, rigorous evaluation, and human commitment authority, we can swap out every model and tool named here without losing the underlying architectural framework.
I expect AI to reshape how we design systems and chips, and I have tried to write the book that takes that possibility seriously without taking it on faith. Candidate generation alone will not drive the change. The future of our discipline belongs to design systems that connect high-level intent to verifiable physical evidence, and to architects with the judgment to govern them. Architecture 2.0 is the disciplined foundation for deciding where AI belongs, where it does not, and what the evidence proves.