Chapter 1 — The Machine in Your Pocket

“In a phone, every transistor is a negotiation with the battery.” — a mobile-silicon design adage

“Thus far shall you come, and no farther, and here shall your proud waves be stayed” — Job 38:11 (ESV)

Why This Matters

You have taken a computer architecture course before. You know what a pipeline is, you can draw a five-stage datapath from memory, and you have almost certainly been graded on a question that reduced to how do we make this go faster. Hold on to all of it. This course keeps every mechanism you learned and changes the question you ask about it.

A server architect has historically been allowed to buy performance with power: more clock, more voltage, more cores, a fan, a heatsink the size of a paperback. The design question is one-dimensional — how fast can it go? A mobile architect has never had that option. The device is sealed and has no fan, runs on a battery a user expects to last a day, and is held in a human hand, so its surface temperature ceiling is set by human skin rather than by anything the silicon cares about. And it is never really off — the radios listen, the sensors count steps, the microphone waits for a wake word, all night, on the same battery.

So the mobile architect asks four questions at once, and every one of them can veto the others:

1. Performance — how fast can it execute this?
2. Energy — how much of the battery does that cost?
3. Thermals — can it sustain that, or is it a ninety-second number?
4. Placement — which processor should be doing this work at all?

Those are The Four Questions, and they are the spine of this book. Every strange, asymmetric, specialized thing about a modern system-on-chip — the fact that the cores are not all the same, that most of the silicon is not CPU at all, that the GPU renders in tiles, that there is a whole separate processor whose job is to stay awake so the big ones can sleep — is an answer to those four being asked simultaneously. Learn to answer only the first and you have learned desktop architecture in a smaller package, and you will misread every block diagram you are handed.

AI enters this course in two registers. It is the defining new mobile workload, and the reason the accelerator fleet grew: a neural processing unit exists on a phone die because running a model on a general-purpose core costs more joules than the platform has to give, and the memory traffic costs more than the arithmetic does. We return to that in Chapter 3, build on it in Chapter 4, and pay for it thermally in Chapter 5.

It is also a bad source and a good tutor, and this course grades you on the difference. Ask a language model for the L2 cache size of a specific 2025 mobile part and it will very often give you a confident, precisely-formatted, entirely invented number, and it will not hedge. That is not a bug you can prompt your way around; it is the shape of the tool. So the rule in this book, which Appendix D states formally, is: use it to explain, never to source. Let it teach you what a translation lookaside buffer is. Never let it tell you how big one is. Every figure in every document you submit carries a primary-source citation or it scores zero, and a fabricated figure fails the integrity line outright.

Underneath all of it sits this week’s harder question, which the epigraph from Job puts in uncomfortable terms: what does it mean to build well inside limits you did not choose? You did not pick the battery chemistry, the thermal conductivity of aluminum, or the temperature at which a human hand says ow. Every interesting decision in this course happens inside a frame handed to you. As §1.9 argues, that is not a footnote to the engineering.

1.1 — Five Constraints, and the Four Questions

Start with the constraints. There are five, and they are not drawbacks — they are the design brief.

One: the battery is a fixed, small energy budget. Not a power limit — an energy limit, in joules, and when it is gone the device is a brick. A server drawing 300 W and a phone drawing 3 W are not the same design at different scales; the server optimizes a rate and the phone optimizes a total. That is why the correct efficiency metric on a phone, for a fixed task, is joules per task rather than watts or instructions per second.

Two: there is no fan. Heat leaves by conduction into the chassis, then convection and radiation off the surface. No forced air, no heat pipe, no headroom you can buy with a bigger cooler. Worse, the ceiling is not what the silicon can survive — junction temperatures a processor tolerates would burn a hand. The real ceiling is a skin-temperature limit set by human comfort, well below what the transistors would allow, which puts sustained dissipation for a phone-class device on the order of a few watts against tens to hundreds for a plugged-in machine. That sentence explains more mobile design decisions than any other in this book.

Three: physical volume is fixed and mostly spoken for. Battery and display take most of the interior; what remains holds the board, cameras, antennas, speakers, haptics, shielding. Silicon area is expensive, board area scarcer, z-height scarcest — which is why DRAM is frequently packaged directly on top of the SoC rather than sitting in slots, a decision with real consequences for both bandwidth and heat.

Four: the device is always on. Not “on” as in a lit screen — on as in a soft-off machine with a collection of things that must respond within milliseconds of an event that could happen at any moment: a call, a notification, a tap, a wake word, a step. Idle is not free, and idle is where most of the day goes. This is why leakage — power burned by transistors that are not switching at all — became a first-class problem, and why so much engineering goes into gating clocks and cutting power to blocks not in use right now.

Five: the radios and sensors never fully stop. The modem maintains a relationship with a network, Wi-Fi and Bluetooth scan, the accelerometer counts. Each is a subsystem with its own processor and firmware, on its own schedule, and none answers to your application’s scheduler. The architectural consequence: radio energy is dominated by time spent awake, not by bytes moved — which is why batching network traffic saves more energy than compressing it, a result Chapter 6 makes quantitative.

Now map the constraints onto the questions, because the mapping is the method:

Coach’s Note — Get in the habit this week of asking all four out loud, in order, about every mechanism you meet. Branch prediction: fast (performance), expensive when wrong (energy), warm (thermals), CPU-only (placement). Tile-based rendering: same or better (performance), dramatically cheaper (energy), cooler (thermals), GPU (placement). It feels mechanical for about two chapters and then it becomes the way you think. In Chapter 8 I hand you a specification table and grade you on holding all four at once, and students who have been asking them since Week 1 find that exam easy.

1.2 — What a System-on-Chip Actually Is

Say the phrase carefully: system on a chip. Not “a CPU with peripherals attached.” What is on that die is a substantial fraction of an entire computer — a dozen or more independent processors, several fully programmable, several running their own operating systems, most able to issue memory transactions on their own behalf.

They were integrated for the usual reasons: shorter wires cost less energy per bit, one package is smaller than five, one memory system is cheaper than five. That last reason is the one that matters, because integration is not merely packaging. Integration means sharing, and sharing means contention. Every block on the die shares four things.

One memory system — one controller, one physical DRAM, usually one system-level cache in front of it; the GPU streaming textures, the CPU walking a linked list, and the NPU pulling model weights are all in the same queue. One power delivery network and one battery — every milliwatt any block spends is a milliwatt no other block gets. One thermal budget — the die has one temperature, more or less, so a GPU running hot throttles the CPU next to it whether or not the CPU is doing anything wrong. One interconnect — every transaction crosses the same fabric, which must arbitrate between a display controller that cannot be late and a background file copy that can wait all day.

So a block diagram looks like a parts list and is not. It is a map of who competes with whom for those four shared resources.

Read that last column again and notice what nearly every row says: bandwidth. Take that one prediction out of this chapter. When something on a phone is slower than you expected and the CPU is not obviously pinned, your first hypothesis is that something is queued behind the memory controller. Chapter 3 makes you prove it.

How much of this chip is not the CPU?

The chapter ships a small synthetic dataset so you can study the shape of a floorplan without pretending to know a real one. Open code/soc-blocks.csv and run the budget tool:

python3 code/block_budget.py

You get an ASCII bar chart of die-area share by block, a rollup by category, and the number this section is named after: on the illustrative floorplan, the CPU — all three core types plus the shared L3 and DSU — is roughly 22% of the area, and roughly 97% of the die sits behind the one memory controller.

Read the header of that CSV before the data. Its first line says, in capitals, that it is synthetic teaching data — modeled on published behavior, not a measurement of any specific product. That is not boilerplate. Real floorplans vary enormously by tier, by generation, and by what is on-die at all; a device with a discrete modem loses the largest single non-CPU block on that list. The dataset teaches the shape — a CPU that is a minority of the silicon, a large graphics block, a modem that is its own computer, and a memory subsystem everything else queues behind. You may cite the shape. You may not cite the numbers. Week 8 grades you on telling measured data from modeled data.

Coach’s Note — That 78% is the whole course in one number. Three-quarters or more of the silicon in your pocket exists to do work the CPU is too expensive in joules to do. That is what “the era of specialization” actually means, and it is why this course spends more time on accelerators, memory and heat than on instruction sets. We start with the ISA because you cannot read the rest without it — not because it is where the performance lives.

1.3 — AArch64: The Contract Between Software and Silicon

An instruction set architecture is a contract: here is the state a program may see, here are the operations it may request, here is what they mean. Everything below that line — pipeline depth, issue width, cache sizes, whether there is a reorder buffer at all — is microarchitecture, invisible to the contract, and where vendors differentiate. Keep that boundary crisp. In Chapter 2 it becomes load-bearing: the prime core and the efficiency core in a phone are wildly different microarchitectures implementing the identical ISA, which is exactly what lets a thread migrate between them mid-execution.

AArch64, the 64-bit execution state of the Arm architecture, is what essentially every 64-bit phone, tablet and Arm laptop runs. Four properties define it here.

Thirty-one general-purpose registers, X0–X30, each 64 bits, each also addressable as a 32-bit view W0–W30. W4 is not a separate register from X4; it is the low half of the same one, and a 32-bit write zeroes the upper half. The stack pointer (SP) and program counter (PC) are handled separately and are not among the thirty-one. X30 is the link register — BL writes the return address into it, which is why a function that calls another must save it and a leaf function need not. There is also a zero register, XZR/WZR, which reads as zero and discards writes.

Fixed-width 32-bit instruction encoding. Every instruction is exactly four bytes. Not “usually.” Always.

Load/store architecture. Arithmetic operates on registers; memory is touched only by explicit loads and stores. There is no “add the contents of this memory location to this register.”

Four exception levels, EL0 through EL3, higher numbers carrying more privilege: EL0 for applications, EL1 for the OS kernel, EL2 for a hypervisor, EL3 for the secure monitor and firmware. A system call is a controlled transition from EL0 to EL1; a virtualized guest kernel still runs at EL1 with the hypervisor above it at EL2. EL3 arbitrates between the Secure and Non-secure worlds of TrustZone — which, and this is what people get wrong, is not just a CPU mode. The Non-secure bit propagates onto the interconnect, so memory and peripherals can be partitioned too. TrustZone is a system partition. Chapter 7 spends a week there.

Read the machine

Here is a leaf function in AArch64 — the full commented version is in code/regwalk.s, a reading exercise this course never compiles. Sum an array of 32-bit integers into a 64-bit accumulator:

// int64_t sum_i32(const int32_t *data, int64_t n);
//   x0 = data, x1 = n, returns in x0
sum_i32:
        mov     x2, #0                  // x2 = accumulator = 0
        mov     x3, #0                  // x3 = i = 0
        cmp     x1, #0
        b.le    .Ldone                  // n <= 0 ? nothing to do
.Lloop:
        ldr     w4, [x0, x3, lsl #2]    // w4 = data[i]
        sxtw    x4, w4                  // sign-extend 32 -> 64
        add     x2, x2, x4              // acc += data[i]
        add     x3, x3, #1              // i++
        cmp     x3, x1
        b.lt    .Lloop                  // signed compare, so a negative n is safe
.Ldone:
        mov     x0, x2                  // return value in x0
        ret                             // branch to the address in x30

The two movs set up an accumulator and an index in caller-saved scratch registers, so this function saves nothing and builds no stack frame — that is what “leaf function” buys you.

ldr w4, [x0, x3, lsl #2] is the only instruction in the loop that touches memory: the load/store architecture, visible. The addressing mode computes base + (index << 2) for free, because a 32-bit element is four bytes wide — a scaled-index addressing mode being one of several places where “reduced instruction set” is a misleading name. sxtw x4, w4 then sign-extends the loaded value into the full 64-bit register; get that wrong and negative values become large positive ones.

add x2, x2, x4 is the accumulate, and it matters for a reason that has nothing to do with the ISA. It is a dependency chain. This iteration’s add cannot begin until the previous one finished, so a wide superscalar core sitting under this loop has issue slots it physically cannot use. Hold that until §1.6.

ret branches to whatever is in x30 — which is why the non-leaf function in regwalk.s opens with stp x29, x30, [sp, #-48]!, pushing frame pointer and link register together while opening a 48-byte frame. Read that second function too: a return address spending time in memory on the stack is precisely the exposure Chapter 7’s pointer authentication closes.

Coach’s Note — Do not skim code/regwalk.s because “you know assembly.” Read every comment. The graded core of this week’s project is a bottleneck prediction, and a bottleneck prediction is an argument about what the machine is actually doing between two instructions. If you cannot say confidently which of these twelve instructions touches DRAM in the worst case and which cannot possibly, you are guessing — and Week 8 catches guessing.

1.4 — RISC and CISC, Honestly

Now take a slogan apart, because you will hear it from people who should know better: RISC is more power-efficient than CISC, which is why phones use Arm.

What is genuinely true: Arm and RISC-V are load/store architectures with fixed-width encodings and large, regular register files, and that combination genuinely simplifies instruction decode. When every instruction is four bytes, the front end knows where the next one starts without decoding the current one, so it can decode several in parallel from known offsets with simple logic. A variable-length encoding must determine each instruction’s length before it can find the next, which historically pushed x86 toward complex length-decode logic and decoded-instruction caches. Decode complexity is real, it costs area and power at the front end, and it mattered enormously when the entire budget was around one watt — front-end power is paid on every instruction, forever.

What is not true anymore. The back ends look alike: a modern high-performance x86 core decodes complex instructions into internal micro-operations and executes those out of order with speculation, renaming, and a large reorder buffer, and a modern high-performance Arm core does the same to its instructions. Past the decoders they are far more similar than the ISA argument suggests, because both solve the same problem with the same known solutions. The ISA is not destiny: x86 ships in fanless laptops and Arm ships in data-center servers; if the instruction set determined the power point, neither would exist. What determines it is the microarchitecture, the process node, the operating points offered, and — most of all — how much of the die went to things that are not the CPU. And the category names have decayed: AArch64 has scaled-index addressing, pair load/store, and a cryptographic extension whose instructions perform an AES round. None of that is “reduced” in the 1980s sense.

So here is the honest summary, deliverable in one breath in an interview:

The instruction set is a real but second-order effect. Decode simplicity is worth genuine power and area at the front end. But the first-order determinants of a mobile system’s performance and efficiency are the memory hierarchy, the accelerator fleet, and the power and thermal budget — and none of those three is an ISA property.

To feel the size of that second-order effect, build and run code/isa_compare.cpp:

g++ -O2 -std=c++17 -o isa_compare code/isa_compare.cpp && ./isa_compare

It writes the same dot product three ways — plain scalar, unrolled four ways with independent accumulators, and a portable “lane block” version shaped the way a fixed-width vector register forces you to write — and reports the median of five timed runs for each after a discarded warm-up. On most machines the spread between the slowest and fastest spelling of identical arithmetic on identical data is roughly two to four times. That is the measurable floor of the ISA-and-microarchitecture discussion; remember its size, because in Chapter 3 a far larger one opens up from nothing but where the data was sitting. (The program also prints three answers differing in their last digits, and explains why: floating-point addition is not associative. Reassociation is a real cost of vectorizing, and you have to decide out loud whether your workload can absorb it.)

1.5 — Three Ecosystems, Not Three Instruction Sets

Students compare Arm, x86, and RISC-V as instruction sets. Practitioners compare them as business models, because that is what determines what ships.

Arm sells intellectual property, not chips. A vendor can license a completed core design and drop it in, or hold an architecture license and build its own core implementing the same architecture — which is why two phones can both run AArch64 binaries while containing microarchitectures that share almost nothing. That is why the mobile SoC market looks the way it does: many vendors, deeply differentiated silicon, one binary-compatible software ecosystem. The ISA is the commons; the microarchitecture and the accelerator fleet are the product. If you are comparing two Arm SoCs and find yourself comparing their instruction sets, you have compared the part that is identical. Armv9-A, announced in 2021, is the current architectural generation; it makes SVE2 a baseline (§1.7) and introduces the Confidential Compute Architecture with the Realm Management Extension, adding a Realm world alongside Secure and Non-secure. Adoption is gradual — new features appear in new cores, and the installed base takes years to turn over.

x86 is a two-vendor ecosystem whose moat is binary compatibility with three decades of software — enormously valuable, and also a design constraint, since every core must keep executing code compiled for machines that no longer exist. x86 is not absent from low power; it is in fanless laptops and handheld gaming devices. But it did not win the phone, and the reasons are as much about licensing and integration as about watts: a phone vendor wants a modem, an ISP, an NPU and a security subsystem of its own choosing on one die, and Arm’s model is built to allow that.

RISC-V is an open, royalty-free instruction set. The base integer ISAs are RV32I and RV64I; the common application-class bundle is RV64GC (G = IMAFD plus Zicsr and Zifencei; C = compressed 16-bit instructions). Privilege is M (machine), S (supervisor), U (user) with an optional hypervisor extension — compare with Arm’s EL3/EL1/EL0, but do not equate them. Two facts show where the ISA is aimed: the “V” Vector Extension version 1.0 was ratified in November 2021, vector-length agnostic in the same spirit as SVE (§1.7), and the RVA23 application-processor profile, ratified in 2024, makes it mandatory for compliant application processors. That matters more than any individual instruction: a feature only some implementations have is one your shipped binary cannot use without runtime dispatch, which means writing and testing the code twice. A profile converts “you might have vectors” into “you have vectors.”

Now the deployment reality, stated carefully, because this is where enthusiasm outruns evidence. As of 2026, RISC-V ships in volume in embedded and accelerator roles — including as control cores inside SoCs that are otherwise Arm, where nobody sees them and no binary compatibility is required. That is a real and growing business. It is not the claim that “RISC-V is displacing Arm in flagship phones,” and you should not make that one: the application-processor ecosystem — compilers, runtimes, OS support, the library of shipped binaries — is the hard part, and it is not done.

1.6 — Pipelines, Speculation, and the Joules You Spend Being Wrong

You know the mechanisms. Re-derive them under the four questions, because the answers change.

The classic teaching pipeline is five stages: fetch, decode, execute, memory, write-back. Overlap them and you finish one instruction per cycle instead of one every five. Superscalar issues more than one instruction per cycle when it can find more than one that is ready. Out-of-order execution lets instructions execute as their operands become ready rather than in program order, retiring them in program order so architectural state stays coherent. And because none of that helps if the front end runs dry at every branch, branch prediction guesses which way a conditional will go and speculatively executes down the predicted path long before the branch resolves.

On a desktop that is the end of the story: it makes things faster, so do more of it. On a phone, ask question two.

A mispredicted branch costs the pipeline depth in wasted work. On a deep out-of-order core the penalty is typically on the order of ten to twenty cycles, though it depends entirely on the microarchitecture. Everything speculatively fetched, decoded, renamed, issued and executed on the wrong path is discarded. Now notice: those instructions ran. They toggled real transistors, charged real capacitance, read real cache lines. The energy was spent and there is no result to show for it. A misprediction is not merely a latency event. It is a pure energy loss.

That reframing explains a design decision you meet properly next week. Efficiency cores are shallower and narrower than performance cores — historically in-order or only lightly out-of-order, though more recent ones are modestly out-of-order — and not because their designers could not afford the transistors. Speculation is expensive in joules, and a core whose purpose is running background work at the lowest energy per instruction should not be gambling.

Run each mechanism through all four questions and the shape of the answer is a table:

Look at the last row: the only one with no cost, and a software change. Breaking one dependency chain into four independent ones adds no transistor and no joule of hardware, and it lets a superscalar core use the issue width it already paid for. Rep 7 makes you measure it; Rep 8 makes you go the other way and feed a core a branch it cannot predict.

Coach’s Note — “It ran and we threw it away” is the single most useful sentence in mobile architecture, and it applies to far more than branches. It is also the shape of a speculative prefetch that fetched the wrong line, a frame rendered and then composited over, a sensor sample taken and discarded, a network wake with nothing to send. When you go looking for energy in a real system, look first for work that was performed correctly and then thrown away. It is almost always there, and almost always larger than you guessed.

1.7 — SIMD, and the Idea That Matters More Than Width

Single-instruction-multiple-data is the cheapest parallelism there is. One instruction, one decode, one issue slot, N results. Decode and issue energy is amortized across all N lanes, which makes SIMD one of the few mechanisms that improves performance and energy per unit of work at once — rare in this book, and the reason SIMD is everywhere in mobile signal processing, imaging and machine learning.

NEON — Advanced SIMD — is the baseline on essentially all 64-bit Arm application processors. Thirty-two vector registers V0–V31, each fixed at 128 bits: four 32-bit floats, eight 16-bit values, sixteen bytes. The width is part of the architecture, so it becomes part of your source code. To write a NEON loop over n elements at four floats per iteration you must (1) write the main loop over n - (n % 4) elements, (2) write a scalar tail for the leftover one to three, (3) write the horizontal reduction that collapses four lanes to one value, and (4) rewrite all of it if you ever want the full width of a wider machine.

Step 4 is the one people underestimate. The 4 is baked into the binary. Give that binary to a machine with 512-bit vectors and it runs correctly at one quarter of the available width, forever, until somebody recompiles. Look at dot_lanes in code/isa_compare.cpp — the constexpr std::size_t L = 4; and the scalar tail under it are exactly this problem, in portable C++.

SVE and SVE2 solve it, and the solution is the most important ISA idea in this chapter. SVE is vector-length agnostic: the hardware vector length is an implementation choice from 128 to 2048 bits, in 128-bit increments, and the same binary runs correctly at any of them. Not recompiled — the same bytes. It works because the loop is written not against a width but against a predicate and an increment instruction:

    i = 0
    predicate = "which lanes, starting at i, are still inside the array?"
    while any lane in predicate is active:
        load the active lanes
        do the arithmetic on the active lanes
        i += (however many elements this hardware does per vector)
        predicate = recompute for the new i

The hardware answers “how many elements per vector” at runtime, and the final partial iteration is handled by the predicate masking off lanes that ran past the end of the array — so there is no scalar tail at all. Steps 1, 2 and 4 above do not exist. RISC-V reaches the same place by a different route: vsetvli requests an element count and the hardware returns how many it will actually do this pass, in a register you use to advance your pointer. VLEN is implementation-defined. Same property, same payoff.

Now the four questions, applied to the difference. On performance and energy, a 128-bit SVE implementation and NEON do very similar work. The gain is not in the instructions — it is in deployment. On a platform where you cannot recompile for every device your binary will land on (the situation of every shipped mobile application, framework and system library), vector-length agnosticism converts “target the narrowest device and leave performance on the table” into “use whatever width we find.” That is not a microarchitecture win. It is an ecosystem win, and it is why SVE2 as an Armv9 baseline and vectors-mandatory in RVA23 are the two facts here that will still matter in ten years.

Coach’s Note — This is the first place in the course where the right answer is not the faster one. NEON and SVE on a 128-bit machine perform about the same; grade them on question one alone and you call it a tie and move on. The VLA advantage becomes visible only when you ask what happens across an entire fleet of devices you do not control, over a product lifetime, with a binary you cannot recompile. Architecture decisions are almost always like this. The question you ask determines the answer you get, which is why you ask four.

1.8 — Interactive Lab: The SoC Block Explorer

Below this chapter on the website you will find The SoC Block Explorer. It is part of the chapter, not an extra — do it now, before the reps.

The first panel is a clickable SoC floorplan. Select any block and it tells you what that block is for, which of The Four Questions it answers, what it shares with the rest of the die, and what contends with it. Go through every block once. Then go through a second time and, before you click, say out loud what you expect the “contends with” line to say. The gap between your prediction and the panel is exactly the material you have not internalized from §1.2 — cheaper to find here than in the project.

The second panel gives you a workload — record 4K video, run an on-device chat model, scroll a feed, navigate with the screen off — and asks which blocks light up. Commit before you submit; the widget scores you and explains every miss. It catches you two ways. Blocks you forgot are involved: recording 4K video is not “the camera,” it is the ISP and the video encoder and the display engine driving the preview and the storage path and the memory controller carrying all of it at once. Blocks you selected that should stay asleep: navigating with the screen off should not light up the GPU or the big cores, and a selection that wakes the application processors for a task the sensor hub and modem can handle describes a device with terrible battery life.

What it teaches is the habit the whole book depends on: a block diagram is a contention map, not a parts list. By the end you should be able to look at any workload and name, without hesitating, which blocks execute it, which shared resource they will fight over, and which of the four questions is binding. That is what this week’s project grades.

A short Check Your Reps quiz is embedded on this page below the lab. It is an ungraded self-check — the point is to catch what you skimmed while the chapter is still fresh. Then sit this week’s graded knowledge check in Canvas — worth 1.5%, same material, larger pool, randomized draw, so retaking it is real practice rather than memorization. The two are not the same item; Appendix D has the full contract.

1.9 — Thus Far and No Farther

The Book of Job contains the longest and strangest speech in the Hebrew Bible: God answers Job’s demand for a hearing not with an explanation but with a tour of creation — wild goats, storehouses of snow, the ordinances of heaven. In the middle of it comes the line at the head of this chapter, spoken to the sea: “Thus far shall you come, and no farther, and here shall your proud waves be stayed” (Job 38:11, ESV).

It is a verse about a limit, and in its own context the limit is not a punishment. It is what makes a shoreline exist. Water without a boundary is not more powerful; it is merely undifferentiated. The boundary is what makes the sea the sea — a thing with a shape, a place, a name, and a relationship to the land it meets.

Make the argument carefully, though, because the cheap version — “constraints are good for creativity” — is often false. Sometimes constraints are just poverty, and a design starved of resources is a worse design whose author has learned to describe it generously. The strong version is different: the mobile architect’s constraints are not negotiable, and that is precisely what makes them generative. You cannot lobby physics for another watt, or argue the thermal conductivity of aluminum up ten percent because the schedule is tight, or ship a device whose surface burns a hand and call it a tradeoff. The frame is given — handed to you, prior to you, not up for discussion — and every interesting thing in this course was invented by someone who accepted that and started working.

Look at what came out of it. Heterogeneous multicore exists because you cannot build one core that is both the fastest and the cheapest, and someone stopped trying and built both. Tile-based rendering exists because external memory traffic is the dominant energy cost in graphics, and someone rearranged the algorithm to touch it less. The neural processing unit exists because moving a word costs orders of magnitude more energy than the arithmetic performed on it — Horowitz’s numbers, in Chapter 3 — and someone designed a dataflow whose entire purpose is not moving data. The sensor hub exists because “always on” and “always awake” turned out to be separable. Not one of those is an invention a designer with unlimited watts would have had reason to make. The desktop had unlimited watts for thirty years and did not make them.

And then — this is the part that should stay with you — the limit came for everyone. When single-thread scaling slowed and power density became the binding constraint in every market, the whole industry had to learn what mobile designers had known for a decade: you buy performance with specialization when you can no longer buy it with watts. The proud waves were stayed for the server too, in the end.

There is a doctrine of vocation underneath this, and the Lutheran tradition states it bluntly: your calling is not a frame you select, it is a station you are placed in, and faithfulness is what you do there. You did not choose the century, the body, the economy, the physics. The question was never whether the frame is the one you would have picked; it is whether you will do good work inside it. A craftsman who resents the grain of the wood produces less than one who reads it and cuts accordingly — and the second is not resigned, he is skilled, and skill is a form of respect for what is actually there. The engineer’s version, and the sentence to carry into the project: an architect who accepts a constraint honestly can optimize inside it; one who resents it keeps proposing designs that require the constraint to be different, and those never ship.

One caution, because a section that only praised limits would be dishonest. Some constraints are physics — the battery chemistry, the skin-temperature limit, the energy cost of driving a wire — and those you accept and design against. Some are decisions somebody made and could unmake: a bus width, a package choice, a thermal design, a schedule. Those you may push on, and pushing on exactly those is the Hard tier of this week’s project. Confusing a decision for a law makes you passive; confusing a law for a decision makes you ridiculous. Job’s sea is told thus far and no farther by the One who set the boundary. Your job is to know which of your boundaries were set by physics and which by a product manager, and to argue with only the second kind.

1.10 — Common Pitfalls

Pitfall: Reading a block diagram as a parts list instead of a contention map. Example: A teardown lists “GPU, NPU, ISP, modem” with a sentence on each, and predicts no bottleneck anywhere, because nothing in the list is individually slow. Fix: For every block, write down the three shared resources it touches — memory bandwidth, power budget, thermal budget — and who else is touching the same one at the same time. The bottleneck is never in a block. It is in a shared resource under simultaneous demand.

Pitfall: Assuming performance lives in the CPU, because that is where your last course spent its time. Example: An architecture review with four pages on core counts and pipeline depth and one paragraph on memory. Fix: Run code/block_budget.py and look at the number. On a floorplan shaped like code/soc-blocks.csv, roughly three-quarters of the silicon is not CPU, and nearly all of it queues behind one memory controller. Weight your analysis the way the die is weighted.

Pitfall: Repeating “RISC is more power-efficient” as if it were a complete explanation. Example: “Phones use Arm because RISC uses less power” — offered as the answer, with nothing behind it. Fix: Say the precise version: fixed-width encoding makes decode cheaper, decode power is paid on every instruction, and that mattered most when the whole budget was about a watt. Then the honest second half: the ISA is second-order, the ecosystem and licensing model did most of the work, and the first-order effects are memory, accelerators, and the power budget.

Pitfall: Accepting a specification number from a language model. Example: You ask for a part’s L2 cache size and memory bus width. You get a clean, confident, well-formatted answer with plausible numbers. You put it in a table. One of the two does not correspond to anything that exists. Fix: Use it to explain, never to source. Every number in every submitted document traces to a primary source — a vendor specification page, an architecture reference manual, a standards document, or your own measurement — with a retrieval date. Ask the model what a figure means all day long. Never let it tell you what the figure is. This is a rubric line, not a suggestion.

Pitfall: Writing SIMD against a fixed vector width and calling it portable. Example: A kernel written for four 32-bit lanes with a hand-rolled scalar tail. It compiles everywhere, runs everywhere, and leaves three-quarters of a wider machine’s vector units idle forever. Fix: Know which you are writing. A fixed-width intrinsic kernel is a specific optimization for a specific width and should be labeled as such in the source. If the binary must span device generations you do not control, that is what vector-length-agnostic models — SVE2, RVV — were designed for.

1.11 — Reps

Open the exercises and do all of them. This week’s reps build the four reflexes the project grades: asking the four questions in order unprompted, reading a block diagram as a contention map, reading AArch64 well enough to say what the machine is actually doing, and verifying every number against a primary source before you write it down.

This week’s AI policy. Use an AI assistant to explain anything in this chapter — what an exception level is, why a dependency chain limits issue width, what predication means. Do not use it as a source for any figure, part number, configuration, or specification. Every number that lands in a rep write-up or in your project carries a citation to a primary source with a retrieval date. Rep 11 sends you looking for that failure mode deliberately, so you have seen it before it costs you a grade. Appendix D has the formal policy and the AI-usage note you attach to every deliverable.

A preview:

• Rep 2 — Build the die-area budget from the synthetic block dataset and answer how much of the chip is not the CPU.
• Rep 4 — Walk regwalk.s instruction by instruction and name every register’s job.
• Rep 7 — Measure the ISA’s floor with isa_compare.cpp — three spellings of one kernel, one median each.
• Rep 8 — Make the branch predictor fail, and price the misprediction in joules as well as cycles.
• Rep 11 — Catch the assistant inventing a number, then verify the real one against a primary source.

1.12 — This Week’s Project

You are ready for Project 1 — The SoC Teardown, in Project 1.

You will pick one real, currently-shipping system-on-chip — or, on the browser workbench with no device and no admin rights, work from a vendor’s published specification page, a fully supported path that costs you nothing on the rubric. From it you produce soc-architecture-review.docx: the block inventory, what each block is for, the CPU cluster and memory configurations, and — the graded core — a bottleneck prediction for two named workloads, with reasoning. Not “it might be memory-bound.” Which shared resource, under which simultaneous demand, and why. Alongside it go report.docx, carrying a primary-source citation for every number you state, and ai-usage.txt.

That review is not a one-week artifact. It is the beginning of the SoC Architecture Review, the running document you carry through all eight weeks and finish in the capstone in Chapter 8. Students who write a real document in Week 1 have a capstone that is half done.

Medium tier adds a second SoC from a different vendor on the same axes — a comparison of architectural choices and their consequences, never a ranking of one vendor’s silicon against another’s. Hard tier is the judgment piece: a one-page memo arguing what you would change about the part you studied and what that change would cost. That memo is the thing no tool writes for you.

Set up your workbench with Appendix A before you start, read Appendix B on reading a block diagram, and read the grading contract in Appendix D once, all the way through, this week.

1.13 — Coach’s Final Word

Here is what you have that you did not have on Monday.

You can name the five constraints that make this a different discipline, and the four questions that follow — performance, energy, thermals, placement. You can read a block diagram as a map of contention over four shared resources rather than as a parts list, and you have seen, in a dataset shaped like a real floorplan, that roughly three-quarters of the silicon is not CPU and nearly all of it queues behind one memory controller. You can read AArch64: thirty-one general-purpose registers, a link register that matters, a zero register, fixed-width encoding, load/store, four exception levels. You can take the RISC-versus-CISC slogan apart and say which part is true and what it is worth. You can explain why vector-length agnosticism is a bigger idea than vector width, and why a mispredicted branch is an energy event and not just a latency event. You have also met this course’s discipline about numbers: there is a language model on your desk that will hand you an invented cache size in a beautifully formatted table and never once tell you it is guessing. Use it to explain. Never let it source.

Thus far shall you come, and no farther. The sea gets a shoreline and becomes a sea. You did not choose the battery, the physics of heat, or the temperature at which a human hand objects — and it is exactly inside that unchosen frame that heterogeneous cores, tile-based rendering, neural accelerators and always-on sensor hubs were invented, by people who stopped arguing with the boundary and started working against it. That is not a consolation for having limits. It is the reason this field is interesting.

Next week we take the first block on the diagram and break it open. The CPU is not one thing. It is not even one kind of thing. And the reason why is going to make more sense to you than it would have on Monday.

See you next week.

Up next: Read the exercises and complete every rep — that is the conditioning, and the project assumes you did it. Then open Project 1 and start The SoC Teardown. Set up your workbench with Appendix A, learn to read a block diagram with Appendix B, read the measurement standard in Appendix C and the grading contract in Appendix D, and keep Appendix E open — the vocabulary comes fast this week. After that, Chapter 2 — not all cores are equal, and the reason why is a design decision, not an accident.