8 Running the Lighthouse Loop
“In theory, there is no difference between theory and practice. But, in practice, there is.”
— Jan L. A. van de Snepscheut, Caltech Lecture (1993)
Author’s Note: Van de Snepscheut’s quip names this chapter’s design. The forward turn is a constructed loop in which a stronger estimate is deliberately assigned costs that overturn a proxy winner; the companion SCALE-Sim lab returns a different outcome, which is the point of keeping an illustrative trace separate from empirical evidence.
The crux
How does an AI-assisted loop convert the lighthouse prompt into one bounded, rejectable turn rather than a one-shot design answer?
The previous chapters defined the parts of a credible loop, but a list of parts is not a running engine. This chapter turns the crank. It takes the lighthouse prompt, bounds it to a task small enough to run, and walks the loop through candidate instantiation, prediction, escalation, rejection, and commitment. The chapter contains two demonstrations with different evidence status. The forward lighthouse turn uses code-generated values assigned to produce a proxy reversal. Those values are pedagogical, not measurements from XRBench, SCALE-Sim, another named simulator, or silicon, and they support only the loop mechanics shown here. The companion SCALE-Sim lab is a separate executable path and returns a different result; it neither validates nor replaces this constructed turn. Chapter 9 supplies a measured deployment-facing case. The closing demonstration then fills the same twelve card fields retrospectively from the contested AlphaChip public record, using no invented values.
Read the chapter as a calibration exercise for the whole book. Earlier chapters named the card fields one at a time. This chapter asks whether those names change how a reader handles a plausible AI answer. The test is whether the reader can watch a candidate win a cheap proxy, lose under a constructed stronger-evidence stage, and still see progress because the loop preserved the reason for rejection.
Bounding the task comes first. “Design a low-power XR compute subsystem” is not a loop; it is a wish. This chapter narrows the task to one XRBench-class1 workload slice. The loop chooses among three compute organizations under a 3 W power envelope and an 8 ms per-frame deadline.2 The 8 ms deadline is the slice’s per-frame display budget. The loop then returns the surviving candidate with its evidence and rejected alternatives. The candidates are a vector CPU extension, an accelerator deliberately left loosely coupled as a stress case, and a shared-memory SoC block. The loose accelerator is not the only accelerator realization allowed by the prompt; it is included so interface and data-movement costs have somewhere to show up. PIM (Processing-in-Memory), which moves compute inside memory chips to reduce interface taxes, is the natural low-data-movement contender and is deferred to a later turn. That is enough to make the loop turn. The worked example is therefore not a DSE recipe; it is a trace of what an AI-assisted architecture loop may propose, what feedback it may trust, and what residue it must leave for an accountable owner.
1 This chapter uses “XRBench-class” to mean a workload slice modeled on the XRBench benchmark family (Kwon et al. 2023), not measured XRBench results, which is why every number in the worked turn is illustrative rather than a benchmark score.
2 Commercial XR displays refresh at 72–120 Hz; at 120 Hz the per-frame budget is 8.3 ms, which this slice rounds to 8 ms (Kwon et al. 2023).
Kwon, Hyoukjun et al. 2023. “XRBench: An Extended Reality (XR) Machine Learning Benchmark Suite for the Metaverse.” Proceedings of Machine Learning and Systems.
Field note: Let the evidence choose the lesson
The companion SCALE-Sim lab, a runnable systolic-array exercise in the project repository, does not reproduce this chapter’s constructed energy reversal. Its tool-produced result instead exposes proxy overstatement and a multiobjective tradeoff among latency, utilization, and hardware budget. There the operation-count proxy overstates the largest array’s speedup because it assumes a utilization the simulated mapping never reaches. That contrast is useful. A real loop must report the lesson its evidence supports rather than choose values that force a predetermined rejection.
The active slice of the lighthouse prompt grounds this trace (Table 8.1). Everything outside the slice is not ignored; it is explicitly deferred to the next evidence stage.
| Loop field | Active slice in this chapter |
|---|---|
| Workload | One XRBench-class mobile-XR slice with a real-time frame deadline; a real loop would also record workload ID, input schema, scenario labels, coverage limits, distribution assumptions, provenance, and validity checks. |
| Baseline | A bounded comparison among three compute organizations, not a full product baseline. |
| ISA/software assumption | All candidates must preserve the existing 64-bit RISC-V software ecosystem to avoid rewriting the full stack from scratch; full compiler/runtime feasibility is deferred to a later stage. |
| Design space | Vector CPU extension, intentionally separated accelerator stress case, or shared-memory SoC block; no cache, chiplet, voltage, compiler-policy search, or full tightly coupled accelerator, CGRA (Coarse-Grained Reconfigurable Architecture), or PIM search yet. |
| Legal actions | Instantiate the three candidate organization records with prompt, generator/search version, candidate IDs, invalid-action records, and selection rule; run the proxy screen, escalate all candidates to the simulation-stage estimate because the proxy has no final rejection authority, reject only on declared deadline/power gates, and advance a survivor only to RTL-level study; changing workload scope or claiming implementation readiness is outside this turn. |
| Physical envelope | 3 W power envelope and 8 ms per-frame deadline; process and thermal assumptions are placeholders for the next stage. |
| Excluded evidence | No RTL, timing, area, thermal, physical-design, deployment, silicon, carbon-footprint, or memory-consistency/coherence evidence. |
What this chapter gives you
After this chapter you can turn a broad prompt into one bounded, rejectable AI-assisted loop turn and read the record it leaves. That means you can:
- Instantiate and run an AI design-loop card on a concrete prompt, not merely fill it in;
- Recognize proxy mismatch when the loop’s cheapest winner fails at higher fidelity;
- Apply the commitment rule to stop the AI loop at an honest evidence level;
- Explain a ranking change through a mechanism hypothesis, directional prediction, and discriminating test without treating illustrative values as confirmation;
- Read the residue an AI-assisted loop leaves: supporting evidence, rejected alternatives, and the next check the accountable decision process needs;
- Fill the card backward from a public record and read which missing fields predict where a dispute breaks out.
This chapter uses three related artifacts with distinct jobs. The design-loop card is the compact summary and index for one turn. Supporting evidence carries the observations, limits, and reasons that justify the card entries; Table 8.3 is one structured form. A runnable receipt binds actual inputs, configurations, commands, logs, and outputs so another team can attempt the declared replay. Because no external tool produced the constructed lighthouse values, this demonstration can supply a card and illustrative supporting evidence, but not a runnable receipt. The AlphaChip exercise can audit what its public record contains; it cannot reconstruct artifacts that never entered that record.
8.1 Round One: Generate and Screen on a Proxy
The four rounds that follow are not four turns. As illustrated in Figure 8.1, they make up one complete design-loop turn realizing its five beats; generation and proxy screening share the first round. First, a generative method3 or heuristic search explores the allowed action space to propose candidate designs. Second, these candidates are quickly screened against a low-fidelity proxy, giving the loop its first observation of the design’s state. Third, because the proxy’s authority is limited, surviving candidates must escalate to stronger architecture-feedback tools, such as calibrated simulation and later synthesis checks, that test declared constraints with higher fidelity. Fourth, any options that violate these hard constraints are pruned and rejected, leaving a trail of failed-run and rejected-alternative records. Finally, the human architect reviews the gathered evidence and makes a bounded, documented commitment.
3 Here the generative role is operational, not definitional. It seeds the three candidate organization records that the proxy screen can test, reject, or escalate.
The loop begins cheaply. A generative model or search method proposes the three organizations in a bounded candidate schema, and an analytic proxy estimates latency and energy per frame in milliseconds and millijoules. The proxy is an operation-count or datapath-only estimate; it counts arithmetic, not the traffic needed to feed it. It is fast and ignores most data movement, input-distribution variation, locality, runtime behavior, and coverage labels, so it flatters designs that keep arithmetic local. At this fidelity the loosely coupled accelerator looks best. It posts the lowest energy and latency because the proxy never charges it for moving data in and out.
This turn seeds the three candidate records directly rather than demonstrating a full generative search; a real run would store the prompt, generator version, candidate IDs, invalid candidates, and selection rule as part of the supporting record. Regardless of how candidates are generated, a proxy result is low-fidelity feedback that becomes evidence only for the narrow action of deciding what to escalate. The AI-assisted loop records the proxy ranking and escalates.
Architect’s checkpoint: The Escalation Gate
The automation’s role: Rank candidates using the cheap proxy to prioritize the search space. The human architect’s role: Verify that proxy results only guide escalation and are not trusted as implementation commitments.
8.2 Round Two: Escalate to a Simulation-Stage Estimate
To advance beyond the proxy’s blind spots, a constructed simulation-stage estimate assigns the first memory-traffic charge. This stage represents a stronger environment contract. It prices data movement, returns latency, energy, and power observations with provenance and cost, and has authority to overturn proxy rankings before commitment. Its power column is frame energy divided by the candidate’s active compute time, a simple active-window power screen against the 3 W budget. It is a screen, not a signoff TDP verdict. Peak and transient power (such as di/dt current spikes and IR voltage drops) and sustained thermal behavior are deferred to later stages. Slower and scarcer than the proxy, the stage stands in for a stronger model class: dataflow analysis (e.g., Timeloop) (Parashar et al. 2019), calibrated pre-RTL estimation coupled to a full-system model (e.g., Aladdin) (Shao et al. 2014, 2016), cycle-level simulation (e.g., gem5) (Binkert et al. 2011), and FPGA-accelerated simulation (e.g., FireSim) (Karandikar et al. 2018).
Parashar, Angshuman, Priyanka Raina, Yakun Sophia Shao, et al. 2019. “Timeloop: A Systematic Approach to DNN Accelerator Evaluation.” 2019 IEEE International Symposium on Performance Analysis of Systems and Software, ISPASS, 304–15. https://doi.org/10.1109/ISPASS.2019.00042.
Shao, Yakun Sophia, Brandon Reagen, Gu-Yeon Wei, and David Brooks. 2014. “Aladdin: A Pre-RTL, Power-Performance Accelerator Simulator for Rapid Design Space Exploration.” Proceedings of the 41st Annual International Symposium on Computer Architecture (ISCA). https://doi.org/10.1109/ISCA.2014.6853196.
Shao, Yakun Sophia, Sam Likun Xi, Vijayalakshmi Srinivasan, Gu-Yeon Wei, and David Brooks. 2016. “Co-Designing Accelerators and SoC Interfaces Using Gem5-Aladdin.” International Symposium on Microarchitecture (MICRO).
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.
All three candidates are escalated because proxy feedback has no final rejection authority. In the budget terms of Chapter 7, each of those checks is assigned a cost orders of magnitude above a proxy evaluation, an illustrative ratio, so the turn’s feedback budget is dominated by its three escalations rather than its three proxy calls. The result is the chapter’s central mechanics demonstration. The assigned values make the candidate that wins the cheap screen fail at the stronger stage (Table 8.2).
| Candidate | Proxy lat / energy | Sim lat / energy | Avg power | Verdict |
|---|---|---|---|---|
| Vector CPU extension | 7.6 ms / 22 mJ | 9.5 ms / 24 mJ | 2.5 W | rejected: misses 8 ms deadline |
| Loosely coupled accelerator | 4.5 ms / 12 mJ | 8.8 ms / 28 mJ | 3.2 W | rejected: misses 8 ms deadline; over 3 W envelope |
| Shared-memory SoC block | 6.0 ms / 16 mJ | 6.5 ms / 18 mJ | 2.8 W | survives to RTL study |
Plotted as paired estimates, the same computed numbers show the reversal as crossing lines (Figure 8.2). The loosely coupled accelerator starts lowest and ends highest once the stronger stage charges data movement, while the shared-memory SoC block barely moves.
In this illustrative three-candidate slice, the intentionally separated accelerator stress case that won on the proxy fails under the constructed simulation-stage estimate. The assigned values model a case where data movement across the system interconnect raises its energy above every alternative and removes most of its latency lead. The interconnect might be a Network-on-Chip fabric or a bus built on a standard protocol such as AXI (Advanced eXtensible Interface). This constructed example does not assume a specific transport. A real study would have to model the topology, protocol, and implementation because those choices affect latency and energy. The shared-memory SoC block is assigned a smaller penalty to represent traffic that stays inside the tightly coupled on-chip hierarchy it shares with the CPU. These assignments model the mismatch without claiming the ranking was measured. The vector extension, which also keeps data local, fails instead on raw throughput against the deadline. This is proxy mismatch made concrete (Figure 8.2), a problem that Roofline analysis can sometimes expose when a proxy rewards compute throughput but the binding mechanism is bandwidth or data movement (Williams et al. 2009). The loop was optimizing the measurement it could see (arithmetic), not the objective it cared about (end-to-end latency and energy). The stronger simulation-stage rejection gate prices communication. The failed candidate is not deleted. It is recorded as a rejected alternative, with the fidelity level at which the proxy win disappeared, so a later loop does not rediscover it.
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.
To document this shift in ranking, the loop adds a structured entry to its supporting evidence (Table 8.3). The exact schema of the candidate record depends on the environment, but it should be structured enough for scripted checks and human review, such as JSON or YAML. A YAML entry might look like this:
candidate_id: xr_accel_loose_v4_2
status: REJECTED
rejection_gate: power_screen # also misses the 8 ms deadline
provenance:
git_hash: "a4c9f1b"
generator_version: "1.2.0"
proxy_estimates:
energy_mJ: 12
latency_ms: 4.5
simulation_estimates:
energy_mJ: 28
latency_ms: 8.8
avg_active_power_W: 3.2 # conservative screen, not a signoff TDP
failure_reason: "interconnect/DMA traffic pushes the average-power screen to 3.2 W (over the 3 W budget) and latency to 8.8 ms (over the 8 ms deadline)"Read the first two rows of Table 8.3 as feedback stages and the third as the record those stages leave. The columns organize the feedback source, its fidelity and budget, what it supported, the condition it could reject on, its provenance limit, and the next evidence required. This supporting evidence record is what makes the toy loop auditable rather than merely ranked.
| Stage | Feedback source | Fidelity and budget | Support | Rejection gate | Provenance / limit | Next evidence |
|---|---|---|---|---|---|---|
| Proxy screen | Operation-count or datapath-only estimate. | Three cheap evaluations; ignores most data movement. | Ranks the accelerator first on proxy energy. | No final rejection; only warnings. | Illustrative constants in this chapter. | Escalate all candidates to stronger feedback. |
| Simulation-stage estimate | Illustrative memory-aware estimate plus simple power check. | Three scarce illustrative checks; still no RTL or physical feedback. | Shared-memory SoC block clears both gates. | 8 ms deadline and 3 W envelope. | Hard-coded values; not XRBench, gem5, synthesis, silicon data, workload trace IDs, scenario coverage labels, or input-distribution records. | Tool-produced interface-traffic and stall counts, a declared traffic sensitivity or ablation, then RTL, timing, area, thermal, and compiler/runtime checks. |
| Rejected alternatives | Recorded failed candidates. | Two rejected candidates. | Failure reasons are preserved. | 8 ms deadline and 3 W envelope; proxy mismatch is recorded as diagnostic context. | Candidate IDs and reasons only; no logs attached, and no evidence that another workload distribution would preserve the same rejection. | Prevent rediscovery and guide the next search. |
8.3 Round Three: Reject on the Envelope
Beyond simply reordering candidates, the constructed simulation-stage estimate also exposes harder physical gates. The loosely coupled accelerator does not merely lose on energy; in this constructed setting, its symptoms point to one possible cause the next evidence stage would have to verify. Reaching the accelerator means moving data across an interface to off-chip or distant memory, and that traffic is expensive on every axis at once. In this illustrative off-chip or distant-memory assumption, a 100–160 pJ/byte movement cost applied to roughly 100 MB per frame lands in the 10–16 mJ range, arithmetically consistent with the assigned 16 mJ increase. The scale is consistent with the order-of-magnitude data-movement costs discussed in Section 2.7. The assigned latency and energy values also push its active-window power screen across the 3 W budget. That is enough to reject the candidate at this illustrative stage and to flag it for the sustained-thermal and peak-power signoff the loop has not yet run. These are hard constraints, not just soft metrics, so no local proxy advantage rescues it. The rejection is the commitment rule from Chapter 7 doing its work. A candidate advances only if it is valid, its evidence clears the threshold for the stage, and its residual physical risk is acceptable.
The assigned reversal makes a mechanism hypothesis visible, but it does not verify one. The stronger-stage values already include a data-movement penalty, so treating the resulting reversal as independent confirmation would be circular. A real study would need a contrast that could distinguish the proposed cause from competing explanations.
Engineer move: Test the Data-Movement Account
The rejection check establishes whether the candidate clears this constructed envelope. It does not establish why the ranking changed. Record the mechanism account as five linked statements.
- Hypothesis: Interface traffic omitted by the proxy, rather than arithmetic work, causes the loosely coupled accelerator’s energy and latency reversal.
- Directional prediction: Holding the workload and compute mapping fixed, reducing bytes that cross the interface should reduce latency and energy and narrow the gap. Increasing those bytes should widen it. If latency remains above the deadline after traffic falls, another mechanism is still limiting.
- Discriminating contrast: Sweep the external-traffic term in the diagnostic model. In a real tool path, vary a realizable factor such as buffer placement or tiling while preserving the kernel, arithmetic work, frequency, and model version, then record interface bytes and stall cycles.
- Observation status: Roughly 100 MB per frame at 100–160 pJ/byte contributes 10–16 mJ, which is arithmetically consistent with the assigned 16 mJ increase. No simulator or measurement produced this observation.
- Validity boundary: This chapter establishes internal consistency and a test protocol, not an empirical cause. A tested explanation requires tool-produced traffic, stall, latency, and energy observations under the declared contrast across relevant workload slices.
This constructed turn can demonstrate the protocol and name the next experiment, but it cannot supply that observation; the companion SCALE-Sim lab does not implement this specific contrast and must report the conclusions its own results support.
Lighthouse prompt: Price the interface before believing the proxy
Context. The rejection gate forces us to confront the true integration cost of a proposed design, tying back to the constraints in the lighthouse prompt. This worked AI-assisted loop deliberately includes a loosely coupled accelerator as a stressed integration variant, even though the full prompt also allows a tighter accelerator path.
In the Lighthouse prompt. The “64-bit RISC-V-based” software path (which anchors the architecture to a vast, existing software investment), the “XRBench-class real-time mobile XR workload” slice, the 8 ms frame deadline the slice fixes, and the “3 W TDP target” are fixed. The AI loop varies the “vector-capable CPU, accelerator, or SoC block” choice and its interface cost.
Deferred evidence. Compiler and runtime, RTL, thermal, physical-design, and verification and reliability evidence are deferred to the next stage.
Takeaway. In this constructed Lighthouse turn, a proposed accelerator is not a faster box attached to the side; it is an interface, memory-system, software-path, and power claim. Once data movement across that interface misses the deadline and crosses the envelope, the local arithmetic win the automation found no longer matters.
8.4 Round Four: Commit at an Honest Level
With the rejection gates applied, one candidate survives the deadline and the envelope. It is tempting to call that a final result. It is not. The evidence behind it is a simulation-stage architectural estimate standing in for cycle-level and power feedback. This supports an experimental commitment, not an implementation or a tapeout (Figure 8.3). The architect’s decision is therefore bounded. Advance the surviving organization to an RTL study where physical design steps like logic synthesis, place-and-route, exact timing closure, and a stronger physical power estimate can confirm or reject it. Because the survivor is a shared-memory block, it also owes formal obligations this toy loop did not discharge. Its coherence protocol would need explicit-state model checking, following the same environment-contract logic used for SLICC-style cache-coherence interfaces in Chapter 5. Its consistency model would need litmus tests (small, concurrent test programs) escalated to formal memory-model verification (Chapter 7), since litmus tests show the presence of ordering bugs, not their absence. It won partly by keeping traffic on-chip, trading the interface data-movement cost that sank the accelerator for on-chip coherence traffic the proxy never charged, so both gates stay open beyond this turn. The other two candidates remain recorded as rejected alternatives.
Stopping at this honest boundary is the difference between an answer and a defensible AI-assisted loop turn. The result is a reviewable loop-turn record: the surviving state, the evidence that supports it, the actions and alternatives rejected, the commitment level, and the next evidence an accountable owner requires.
Architect’s checkpoint: The Commitment Gate
The automation’s role: Provide the surviving candidate alongside a filled card, supporting evidence, and rejected-alternative records. The human architect’s role: Accept the evidence boundary and authorize advancing the surviving candidate to RTL study, or demand stronger evidence before committing.
The cost of skipping that gate is not hypothetical, and it is not unique to hardware. A software deployment incident makes the same commitment-gate habit visible, but it is an analogy for the gate, not evidence about this hardware estimate.
Field note: Four hundred forty million in forty-five minutes
On August 1, 2012, a trading firm deployed new order-routing code, but the update reached only seven of its eight servers. The eighth still ran repurposed logic that a reused flag switched back on, and it began firing orders into the market with no position limit and nothing to halt it. No automated check verified that the right code, and only the right code, was live everywhere. In about forty-five minutes the firm lost roughly four hundred forty million dollars and nearly collapsed (U.S. Securities and Exchange Commission 2013; Knight Capital Group 2012).
Lesson. The architecture lesson is narrower. Before a loop turns an output into a commitment, it needs a check that can verify the artifact, reject it, and stop escalation or roll back. That halt is what keeps an AI generator from extrapolating past its authorized evidence boundary.
Knight Capital Group. 2012. Knight Capital Group Provides Update Regarding August 1st Disruption to Routing in NYSE-Listed Securities. Press release (Form 8-K), August 2, 2012.
U.S. Securities and Exchange Commission. 2013. In the Matter of Knight Capital Americas LLC. Release No. 34-70694. SEC.
Design principle: Stop at an honest evidence level
An AI-assisted loop should report what its evidence supports, what it rejected, and what would overturn the decision, then stop there. The honest commitment level, not the most optimistic one a generative model might claim, is the result.
That commitment residue becomes a filled design-loop card (Table 8.4). The entries are intentionally terse and point outward to supporting artifacts. A real project would attach logs, scripts, trace identifiers, and power-model records, but the first test is whether the loop can state what it did and what would reject it.
| Card field | Lighthouse loop entry |
|---|---|
| Intent | Explore a low-power mobile-XR compute organization that can meet a real-time deadline under a 3 W envelope. |
| Task | Compare three bounded compute organizations for one XRBench-class workload slice. |
| Design space | Choose among vector CPU extension, intentionally separated accelerator stress case, and shared-memory SoC block; leave cache, voltage, chiplet, compiler-policy, full tightly coupled accelerator search, and RTL edits outside this turn. |
| Representation | Candidate ID, candidate record, legal action taken, workload slice ID/coverage label, proxy and simulation observations, uncertainty/provenance limits, deadline, power envelope, and verdict. |
| Environment | Analytic proxy followed by an illustrative simulation-stage estimate standing in for cycle-level feedback and a simple power-envelope check. |
| Method role | Seed candidates, predict cheap proxy scores, escalate all candidates because the proxy has no final rejection authority, and critique proxy wins against stronger feedback. |
| Feedback budget | Three cheap proxy evaluations and three illustrative simulation/power checks, each assigned a per-evaluation cost orders of magnitude above the proxy, so the budget is dominated by the escalations; no RTL, timing, thermal, or silicon evidence yet. |
| Evidence | The shared-memory SoC block is the only candidate that clears the 8 ms deadline and 3 W envelope in the illustrative run. This supports the illustrative gate result; it does not empirically establish the proposed data-movement mechanism. |
| Failed runs / rejected alternatives | Rejected-alternative records show that the vector CPU extension misses the latency deadline and the loosely coupled accelerator misses the deadline and exceeds the power envelope after the constructed estimate assigns a data-movement penalty. |
| Rejection checks and authority | Deadline check, power-envelope check, and the stronger estimate that can overturn the proxy ranking. |
| Evidence-supported claim boundary | Advance only to RTL-level study; implementation commitment would require synthesis, timing, area, thermal, compiler/runtime, memory-consistency/coherence, and stronger power evidence. |
| Accountable decision | Advance the shared-memory SoC block to RTL-level study and retain the other two candidates with their rejection reasons. |
The filled card passes that first test; its fields state what the turn did, at what evidence level, and what would reject it. A real execution would bind those summaries to runnable material. The runnable receipt can respect proprietary boundaries while still stating what was run, what failed, what is redacted, what remains non-public, and what can be independently tested. Table 8.5 gives a minimum directory shape.
| Receipt item | Example contents for this loop |
|---|---|
README.md |
Task slice, claim boundary, non-goals, and accountable decision authority. |
inputs/ |
Workload IDs, benchmark version, scenario metadata, input-distribution summary, coverage labels, trace provenance, workload-level rejection conditions, and redaction notes. |
prompts/ |
Prompt slice, model/tool versions, role assignments if multiple models act, generator/search configuration, untrusted-input notes, invalid proposals, selection rule, and human overrides or approvals. |
candidates/ |
Candidate IDs, configuration records, invalid-action records, and rejected alternatives. |
runs/proxy/ |
Proxy model version, constants, scripts, logs, and cheap-screen results. |
runs/sim/ |
Simulator or stronger-feedback configuration, seeds, logs, metrics, warnings, and failures. |
evidence/ |
Supporting evidence records, fidelity labels, uncertainty, baseline, integrity checks, disclosure boundary, and sensitivity notes. |
decisions/ |
Architect review note, escalation rule, reopening condition, commitment level, and next evidence required. |
A winning claim cannot travel alone. It travels as one bundle, sketched in Figure 8.4, whose artifacts record what evidence supported the claim, what alternatives failed, and what accountable decisions govern its next stage.
Here the directory bundle is a target structure; the filled card and supporting evidence record still expose the task boundary, evidence level, rejection reasons, decision limit, and next evidence owner. A real execution would populate the receipt so another architect could replay the turn as declared and inspect why the survivor advanced.
For advanced loops, the receipt also says what would reopen the decision. A later workload shift, dependency change, field-telemetry incident, stronger physical check, or integrity failure should be able to point back to the exact entry whose authority has expired.
8.5 Running the Card Backward on AlphaChip
The worked turn above ran the loop forward on numbers this chapter invented. The card supports a second test that needs no simulator and no invented values. The forward run tests whether the card can organize one bounded decision; the backward run tests whether the same fields can diagnose where a public claim became difficult to adjudicate. Take the book’s recurring war story and fill the same twelve fields backward, using only what the public record around AlphaChip carried when the claim was made and what it carries now, including the independent reassessment and the authors’ response (Cheng, Kahng, Kundu, et al. 2023; Goldie, Mirhoseini, Yazdanbakhsh, et al. 2024). The exhibit asks one question. Do the card’s fields localize where the dispute actually broke out?
Cheng, Chung-Kuan, Andrew B. Kahng, Sayak Kundu, Yucheng Wang, and Zhiang Wang. 2023. “Assessment of Reinforcement Learning for Macro Placement.” Proceedings of the 2023 International Symposium on Physical Design (ISPD). https://doi.org/10.1145/3569052.3578926.
Read Table 8.6 as an audit of the record, not of the work. A field marked absent does not mean the original team lacked it internally; a production chip-design flow plainly had baselines, gates, and owners. Absent means the public record did not carry the field, and a claim can be adjudicated in public only on the record that travels with it.
| Card field | Public record, 2021 | Public record after the 2024 addendum |
|---|---|---|
| Intent | Present. Compress TPU-block macro placement from weeks of expert work to hours at comparable or better quality on key power, performance, and area metrics (Mirhoseini et al. 2021). | Unchanged, restated with the AlphaChip name and a deployment claim across TPU generations (Goldie, Mirhoseini, Yazgan, et al. 2024; Google DeepMind 2024). |
| Task | Present. Macro placement on production netlists, a bounded physical-design task. Never disputed. | Unchanged. |
| Design space | Partial. The placement action space is described; which blocks, constraints, and flow settings defined legality stayed internal. | Open test cases exist, but from the reassessment’s flow, not the original’s (Cheng, Kahng, and others 2023). |
| Representation | Present. The netlist-as-graph encoding is described in the paper. | Inspectable in the released code (Google DeepMind 2024). |
| Environment | Absent. No runnable environment, tool contract, or test cases traveled with the claim. | Partially closed. Code and a pretrained checkpoint are public; the production flow and blocks remain internal (Google DeepMind 2024). |
| Method role | Present. A reinforcement-learning policy generates placements inside a larger flow. Never disputed. | Unchanged. |
| Feedback budget | Absent. Pretraining corpus, compute, and convergence criteria were not stated as a budget another team could match. | The dispute’s center. The rebuttal is a feedback-budget argument that the critics skipped pretraining, under-trained, and used far less compute (Goldie, Mirhoseini, Yazdanbakhsh, et al. 2024). |
| Evidence | Disputed. Comparisons were anchored to proprietary blocks and to a proxy cost later reported to correlate weakly with post-route metrics (Cheng, Kahng, and others 2023). | The reassessment added open evidence on its own cases; the strongest original evidence is still not publicly replayable. |
| Failed runs / rejected alternatives | Absent. No failed or rejected placements, seeds, or excluded cases were published. | Still absent, on both sides. |
| Rejection checks and authority | Absent as a shared gate. Both sides held strong private gates (synthesis, timing, layout rules, expert review); none was common to both (Chapter 9). | Emerging third-party gauges such as end-to-end placement benchmarks postdate the dispute (Wang et al. 2025). |
| Evidence-supported claim boundary | Absent. The strongest claim shipped with no stated evidence that would overturn it. | The addendum closed the journal’s process; no public statement of an overturning condition exists (Goldie, Mirhoseini, Yazgan, et al. 2024). |
| Accountable decision | Partial. Deployment decisions were plainly owned inside Google; the public record does not name the review that accepted them. | Unchanged. |
Mirhoseini, Azalia, Anna Goldie, Mustafa Yazgan, et al. 2021. “A Graph Placement Methodology for Fast Chip Design.” Nature 594 (7862): 207–12. https://doi.org/10.1038/s41586-021-03544-w.
Wang, Zhihai et al. 2025. “Benchmarking End-to-End Performance of AI-Based Chip Placement Algorithms.” Advances in Neural Information Processing Systems (NeurIPS). https://arxiv.org/abs/2407.15026.
The pattern in the table is the chapter’s forward lesson replayed on a real case. The generation-side fields, intent, task, representation, and method role, were present in 2021 and were never the argument. The dispute broke out precisely in the fields the record left empty (Figure 8.5). Read against Chapter 2, that pattern is the scissors gap in public form, generation outrunning the shared capacity to reject and commit. The reassessment and the rebuttal disagreed about the environment and the feedback budget, whether the method was run as published, pretrained, converged, and given comparable compute (Cheng, Kahng, and others 2023; Goldie, Mirhoseini, Yazdanbakhsh, et al. 2024). Those are two rows of this card. A shared card would not have decided who was right, but it would have made the mismatch visible as a mismatch, a different loop run under a different budget, before it hardened into a public argument. And as the war story in Chapter 9 shows, both sides held strong rejection gates privately; what no card field could point to was a rejection authority both sides accepted.
One row of that grid can also be read as measurement. The evidence row cites a proxy cost later reported to correlate weakly with post-route metrics; the reassessment’s artifact record publishes the pairs behind that report, fifteen strong placements from Circuit Training, the open-source release of the AlphaChip method, on one open test case, each scored by the proxy the loop optimized and by the post-route metrics a signoff flow reads (Cheng, Kahng, and others 2023). Plotted against each other, the proxy barely orders the outcomes (Figure 8.6). The forward turn earlier in this chapter constructed a proxy reversal to teach the mechanism; this is the same mechanism in the measured record of the case the card audits.
In the structural-conformance terms of Appendix B, the 2021 public record can populate a Level 0 card. It also contains fragments of fields required at Level 1, but conformance is not fractional.
The code and the pretrained checkpoint released with the 2024 addendum add replay-relevant artifacts for the method (Google DeepMind 2024), but they do not make the strongest proprietary-block claim publicly auditable. Structural conformance, replay status, and public support for that claim remain separate judgments, and the public record still lacks a shared production environment contract, comparable feedback budget, and rejected-alternative summaries (Cheng, Kahng, and others 2023; Goldie, Mirhoseini, Yazdanbakhsh, et al. 2024; Goldie, Mirhoseini, Yazgan, et al. 2024; Google DeepMind 2024).
Google DeepMind. 2024. How AlphaChip Transformed Computer Chip Design. Https://deepmind.google/discover/blog/how-alphachip-transformed-computer-chip-design/.
Cheng, Chung-Kuan, Andrew B. Kahng, et al. 2023. “Assessment of Reinforcement Learning for Macro Placement.” Proceedings of the 2023 International Symposium on Physical Design (ISPD). https://doi.org/10.1145/3569052.3578926.
Goldie, Anna, Azalia Mirhoseini, Amir Yazdanbakhsh, and Jeff Dean. 2024. “That Chip Has Sailed: A Critique of Unfounded Skepticism Around AI for Chip Design.” arXiv Preprint arXiv:2411.10053.
Goldie, Anna, Azalia Mirhoseini, Mustafa Yazgan, et al. 2024. “Addendum: A Graph Placement Methodology for Fast Chip Design.” Nature 634: E10–11. https://doi.org/10.1038/s41586-024-08032-5.
Nothing in that conclusion requires releasing proprietary data. The Level 0 redacted pattern in Chapter 10 shows what bounded public context could have traveled with the claim. It could have stated the claim and non-claim, disclosure boundary, authorized reviewer roles, and confidential inputs without claiming audit or replay. A redacted Level 1 card could have supported deeper inspection only if every Level 1 field were populated and the supporting evidence were available to the stated reviewers. The journal published the addendum in 2024. Public adjudication still lacked a shared record. This retroactive card is the book’s discipline fired once on the case that motivated it, and the residue it leaves is the same as the worked turn’s, a record another architect can inspect and continue.
8.6 Open Research Questions
The instantiation of the lighthouse loop demonstrates a bounded, rejectable turn. The research questions here ask what must be built before that kind of turn can scale beyond a worked example without losing its evidence discipline.
How can architectural intent become one bounded loop turn? The worked example succeeds because the broad prompt is sliced into a task small enough to act on, evaluate, reject, and record. A strong research contribution would define methods for lowering architectural intent into a legal action space, workload slice, feedback budget, evidence target, and commitment level. The evaluation should ask whether different architects can derive comparable loop turns from the same broad intent and whether those turns avoid unsupported claims.
What signals should trigger escalation in one loop turn? The worked example statically allocates feedback across proxy and simulation stages. A stronger paper would define policies that recommend when to escalate, reject, or request stronger checks during a single turn. The evaluation should center on evidence cost, false commitments, and whether the policy stops at the honest evidence level rather than merely finding higher-scoring candidates. Using Table 8.3 and Table 8.5 as evidence objects, the evaluation should show what would cause the turn to stop, escalate, or continue.
How can proxy workloads expose data-movement mirages? The worked escalation showed that cheap analytical proxies can miss interface taxes, data movement, and other system effects. A paper-quality contribution would build a proxy-audit benchmark with known blind spots and methods that flag when a proxy is likely misleading. The result should be measured by earlier detection of proxy mismatch, fewer wasted high-fidelity runs, and a stated bound on the claims the proxy can support.
What receipt metadata makes rejected candidates reusable? A runnable receipt is useful only if it records enough context for another architect to understand why a candidate failed. A concrete research artifact would define receipt fields for rejected candidates, including workload scope, configuration, invalid action records, evidence level, failure reason, redaction boundary, and conditions for reuse. The evaluation should test whether later loops can interpret the failure and reuse the negative evidence without erasing the evidence level that produced it.
When should a recorded rejection be reopened? A rejected candidate becomes a failure record, but treating every such record as permanent can wrongly shrink the future search space. A strong paper would model rejection validity as a function of workload, process node, software stack, tool version, and evidence level, then test when an optimizer should safely reconsider an old failure. The evaluation should distinguish localized failures from genuinely invalid designs and show that revival does not reopen known failure modes.
8.7 Conclusion
This chapter asked how an AI-assisted loop converts the lighthouse prompt into one bounded, rejectable turn rather than a one-shot design answer. The move is to shrink the prompt to a task small enough that a candidate can actually be rejected, then walk it through generation and proxy screening, escalation to a stronger estimate, rejection on the power envelope, and commitment at a level the evidence can honestly support. The numbers were illustrative. The shape was the lesson. The data-movement account therefore supplied a mechanism hypothesis and a discriminating next test, not a verified explanation. A loop is not a single answer but a sequence of bounded, checkable transitions. Running the card backward over the AlphaChip record made the same point without a single invented number. The fields the public record carried were never disputed; the argument lived in the fields the record left empty.
What the turn leaves behind matters as much as the candidate that survives it. This constructed example leaves a filled design-loop card and illustrative supporting evidence record. A real execution would add a runnable receipt. That residue lets a second architect reconstruct why the surviving candidate advanced, why the others did not, and what would overturn the decision. A win with no reviewable residue is a claim no one else can check.
The discipline the turn enforces is to stop at an honest evidence level. When a cheap proxy and a stronger check disagree, the loop follows the rejection authority declared for that claim and commits only as far as its evidence reaches, refusing to dress a proxy result as silicon-grade proof. Read this way, the worked turn becomes a template a reader can reuse on a real project, naming the loop, judging whether its evidence matches its commitment level, and saying what remains an accountable decision. One loop turn stays small, bounded, and reviewable, which is exactly what makes it worth trusting.
What to carry forward
- Carry forward: One honest loop turn stops at a declared commitment level and leaves a reviewable record of the surviving candidate, its evidence, and why the alternatives were rejected; a real execution should also bind its executable artifacts in a runnable receipt.
- Reader test: Could another architect reconstruct why the surviving candidate advanced and what would overturn it?
- Up next: Chapter 9 asks how this reviewable-record discipline changes across workload, software, DSE, domain-specific architecture and code generation, co-design, fleet, and RTL/physical loops with different feedback budgets and rollback costs, and when trusted disposition rather than generation becomes the limit.