Project 1 — The SoC Teardown

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

Chapter: 1 — The Machine in Your Pocket Due: End of Week 1 Weight: 7% of your course grade — one of the six weekly labs, all weighted equally. Submit: A link to a public repository containing soc-architecture-review.docx, report.docx, and ai-usage.txt. Set up your workbench first with Appendix A; read Appendix B on reading a block diagram before you start; the grading contract, the tier system and the AI-usage note are all defined in Appendix D. Allowed tools: Any workbench from Appendix A. Vendor specification pages, architecture reference manuals, standards documents, published technical documentation. The chapter’s code/block_budget.py and code/soc-blocks.csv. A physical device is optional and unnecessary — every point on the Normal rubric is earnable from a browser and a vendor’s published page. AI policy — explain, never source. Use an assistant to explain any concept, term, or diagram convention you meet. Do not use it as a source for any figure, part number, cache size, clock, bus width, or configuration. Every number in your submission traces to a primary source with a retrieval date. An uncited or unverifiable figure scores zero on its rubric line. A fabricated figure fails the integrity line outright — that is not a deduction, it is a failure, and it is the one rule in this course with no partial credit.

How This Course Works

Read this once. It will not be repeated.

This is a graduate course and it carries roughly 12 to 15 hours per week, including the reading, the reps, and the lab. That is the honest number. The reading is dense on purpose, the reps are conditioning rather than busywork, and the lab is where the grade actually lives. Budget accordingly.

Everything in the eight weeks hangs off one frame, introduced in §1.1 and applied every week after: The Four Questions. Performance — how fast can it execute this? Energy — how much of the battery does that cost? Thermals — can it sustain that, or is it a ninety-second number? Placement — which processor should be doing this work at all? A student who can only answer the first has learned desktop architecture. By Week 8 you will be handed a specification table and graded on holding all four at once.

This project starts the document that carries you there. soc-architecture-review.docx is the SoC Architecture Review — a running artifact you open this week, extend in Weeks 2 through 7 as each chapter teaches you a new block, and finish in the capstone. Write it as a document you will still respect in Week 8.

Set your environment up with Appendix A. Read the grading contract in Appendix D once, all the way through, this week — it defines the weights, the tier system, and the AI-usage note, and this project will not restate them.

The Setup

A Lutheran relief agency runs field teams in six countries. Their case workers currently carry whatever handset they happened to own, and the results are exactly what you would expect: some devices hold a charge through a twelve-hour day of GPS logging and photo documentation, some are dead by two in the afternoon; some record usable video of a damaged water system, some overheat and stop recording after four minutes; some upload the day’s case files over a marginal cellular link, some spend an hour trying.

The agency has decided to standardize on one device, and they have asked you — the one person in the building who reads specification sheets for a living — to tell them what to look for. They do not need a product recommendation this week. They need something harder and more useful: an architect’s reading of one real system-on-chip, so that when a vendor’s sales engineer says “eight cores at three gigahertz” they can ask the question that actually matters.

Because here is what the field teams’ day is: a phone in a hot vehicle, off-grid, recording video, running photo processing, holding a cellular connection, logging position with the screen off for hours at a time. Not one of those is a benchmark. Every one of them is a bottleneck waiting in a shared resource.

Your job this week is to take one shipping SoC apart on paper — every block, what it is for, what it shares, what it contends with — and then predict, with reasons, where two of those workloads will actually break down.

Setup (the starter)

You need one thing to begin: a real, currently-shipping mobile system-on-chip, and a primary source about it.

Pick from a vendor that publishes: Qualcomm, Apple, MediaTek, Samsung, or Google. A primary source means the vendor’s own product page, newsroom post, developer documentation, or an architecture reference manual — plus standards documents (a JEDEC LPDDR specification, an Arm architecture reference manual) for the parts a vendor does not detail. A review site is not a primary source. A wiki is not a primary source. A language model is emphatically not a primary source.

The chapter’s starter files support the analysis:

• code/soc-blocks.csv — the synthetic floorplan model. Use it as the template for your block inventory, not as a source of numbers. Its first line tells you why.
• code/block_budget.py — run it to remind yourself of the shape you are looking for: a CPU that is a minority of the silicon, everything else queuing behind one memory controller.
• code/regwalk.s and code/isa_compare.cpp — background for the bottleneck reasoning, and the basis of the reps in the exercises. Do the reps first; this project assumes them.

Workbench B students, read this. You need no device, no compiler, and no admin rights to earn 100 on the Normal tier. Every required item is a reading, a citation, and a written argument. That is not a consolation path — it is the primary path, because architecture review is a reading and reasoning discipline before it is a measurement discipline. Measurement starts in Week 2.

Learning Targets

By completing this project you will demonstrate that you can:

• Read a real system-on-chip block diagram as a map of contention over shared resources, not as a parts list.
• Name every significant block on a mobile SoC and state, for each, what it is for, what it shares, and what it contends with.
• Report a CPU cluster configuration and a memory configuration accurately, from primary sources, and say honestly what the vendor does not publish.
• Predict where a named, realistic workload will bottleneck, and defend the prediction by naming the specific shared resource and the simultaneous demand on it.
• Apply The Four Questions to an architectural choice, rather than answering only the performance one.
• Distinguish a sourced figure from an unsourced one, a primary source from a secondary one, and modeled data from measured data — and disclose your use of AI honestly.

Normal Tier

Goal: One real SoC, taken apart on paper, with two defended bottleneck predictions and a citation behind every number.

Required features

1. Declare your subject and your path. At the top of soc-architecture-review.docx, name the SoC you chose and which workbench you used (L, B, or D). One line each.

2. The block inventory. A table with one row per block. Use the block vocabulary from §1.2 — CPU clusters, GPU, NPU, DSP, ISP, display and video engines, modem, memory controller, shared caches, secure subsystem, sensor hub, interconnect. For every row:

The Confirmed? column is not optional and it is worth points. Mark each block confirmed (this vendor’s primary source says this block exists on this part), or inferred (you are reasoning from the general shape of a mobile SoC because the vendor does not say). Both are acceptable answers. Pretending an inference is a confirmation is not.

3. The CPU cluster configuration. How many cores, of how many kinds, in what arrangement. Cite it. If the vendor publishes core names and counts but not cache sizes, say so — “cache sizes not published” is a correct, creditable line, and it is a far better answer than a plausible number you could not source.

4. The memory configuration. DRAM generation, and the memory interface width if you can source it. If you have both a data rate and a bus width, show the bandwidth arithmetic explicitly:

bytes/s = data rate (MT/s) × bus width (bytes)

Show your work, label the inputs with their sources, and state the result as theoretical peak — because that is what it is. If you cannot source the width, say “width not published” and explain in one sentence why the width, not the DRAM generation, is what actually buys bandwidth.

5. Two bottleneck predictions — the graded core. Pick two workloads from the agency’s day:

• Recording 4K video with the preview on screen, in a hot vehicle.
• Running an on-device model to transcribe or classify a case note.
• Uploading a day’s photos over a marginal cellular link.
• Logging position for eight hours with the screen off.

They must be materially different — two workloads that bottleneck in the same place on the same resource count as one. For each, write:

• Which blocks are running. All of them. Recording video is not “the camera.”
• Which single shared resource becomes the constraint — memory bandwidth, the power budget, the thermal budget, or the interconnect — and why that one and not the others.
• Which of The Four Questions binds first, and what a user would actually observe when it does. A dropped frame? A recording that stops? A phone that is dead at 2 p.m.?
• What would have to be true for you to be wrong, and what you would measure to find out.

6. The Four Questions, applied. Somewhere in the review, take at least three blocks and run all four questions on each explicitly, in the §1.6 style. Not four adjectives — four sentences with content.

7. report.docx — the citation record. A table of every external figure you stated, its value, its primary-source URL, and the date you retrieved it. Plus a short section named “What I could not find” listing every figure you wanted and could not source, and what kind of source would have it. That section is worth real points. Architects who write it are trusted; architects who quietly fill the gap with a plausible number are not.

8. ai-usage.txt. One honest paragraph: which model and version you used, what you used it for, and — specifically — anything it told you that you had to verify or discard. If you used no AI, say that. See Appendix D.

Example shape of a bottleneck prediction

WORKLOAD:   4K video capture with on-screen preview, ambient ~40 C, unplugged.
BLOCKS:     ISP (per-frame pipeline) + video encoder (fixed-function) + display
            engine (preview at panel refresh) + storage write path + memory
            controller carrying all of it + CPU orchestrating.
CONSTRAINT: The memory controller, then the thermal budget. Every one of those
            blocks streams to and from DRAM concurrently, and the display engine
            cannot be deprioritized without a visible glitch.
BINDS FIRST: Thermals. Bandwidth contention shows up as a dropped frame under
            load, but the vehicle is hot and there is no fan; sustained capture
            drives the skin-temperature limit and the platform sheds work.
OBSERVED:   Recording continues for a while, then frame rate falls or capture
            stops with a temperature warning.
I'D BE WRONG IF: the encoder and ISP are efficient enough that the modem, not
            capture, dominates the thermal budget. To find out I would need a
            sustained capture run with device thermal status logged over time.

Normal-tier rubric (out of 100)

The integrity line. Any figure that is fabricated — stated as fact, cited to nothing or to a source that does not contain it — fails the project regardless of the rest of the rubric. This is the only rule in the course with that consequence, and it exists because in Week 8 you will be asked to distinguish what you measured from what somebody modeled, and a habit of confident sourcelessness makes that impossible.

Medium Tier (+up to 25% extra credit)

M1. A second SoC, from a different vendor, on the same axes

Repeat the block inventory, the cluster configuration, and the memory configuration for a second currently-shipping SoC from a different vendor, with the same citation discipline. Then write a comparison — and read the next paragraph twice before you do.

You are comparing architectural choices and their consequences. You are not ranking silicon. No sentence in this course says one named vendor’s part is faster or better than another’s. The interesting comparisons are structural: one part integrates the modem on-die and the other does not — what does that buy and what does it cost in thermal budget and in die area? One publishes its cache hierarchy and the other does not — what can you conclude, and what can you only infer? One uses a wider memory interface — what workload does that width serve, and what does it cost in package and power?

Write at least three such comparisons. Each one is: this choice, that consequence, under which of The Four Questions.

M2. The die-area argument, applied

Run code/block_budget.py and quote its shape — not its numbers — in a short section of report.docx. Then argue, from your own two inventories, whether the parts you studied appear to follow the same pattern the model describes: a CPU that is a minority of the silicon, and a long tail of specialized blocks. Be honest about what you cannot see. You do not have die photographs and you should not pretend the model’s percentages apply to your parts. What you can do is count blocks, note which functions got dedicated silicon, and say what that tells you about what the architect expected the device to spend its day doing. That last sentence is the whole exercise.

Hard Tier (+up to 25% additional extra credit)

H1. The architecture memo

One page, no more. Addressed to a design lead. Title it: What I would change about this part, and what it would cost.

Pick one change to the SoC you studied in the Normal tier — one, not a wish list. A wider memory interface. A larger system-level cache. A discrete rather than integrated modem, or the reverse. A different balance between prime and efficiency cores. More NPU, less GPU. Then answer, in order:

1. What the change is, stated precisely enough that an engineer could cost it.
2. Which of The Four Questions it improves, and for which named workload. “It would be faster” fails. “It would raise sustained capture time for the video workload in section 3, because the constraint there is bandwidth contention at the memory controller” passes.
3. What it costs. Every change costs something, and naming it is the entire assignment. Die area is the obvious currency; so are package size, power, thermal budget, memory latency, yield, board area, and the generality you gave up when you spent transistors on a fixed-function block. If your change appears to cost nothing, you have not understood it yet.
4. What breaks or gets worse. Somebody else’s workload. Name it.
5. The evidence you do not have. State plainly which figure would confirm or kill your proposal, and what kind of measurement or source would produce it.
6. The distinction that earns this tier. Say explicitly whether the thing you are proposing to change is a law — physics, the skin-temperature limit, the energy cost of driving a wire — or a decision somebody made and could unmake. You are only allowed to argue with the second kind. §1.9 is why.

A memo that lists five improvements without costing any of them scores nothing. A memo that proposes one change, prices it honestly, names who loses, and admits what it cannot prove is the work of an architect, and it is precisely the judgment no tool produces for you.

Submission

Submit one URL: a public repository.

What it must contain

1. soc-architecture-review.docx — the block inventory, configurations, The Four Questions applied, and the two bottleneck predictions. This is the document you carry all eight weeks; give it a structure you can extend.
2. report.docx — the citation table, the “What I could not find” section, the M2 die-area argument if you did it, and the H1 memo if you did it.
3. ai-usage.txt — the honest disclosure.
4. A README.txt naming the SoC(s), the workbench you used, and the tier you targeted.

Use exactly those filenames. They are fixed across the whole course, and the Week 8 capstone expects to find soc-architecture-review.docx where you left it.

# Project 1 — The SoC Teardown

**Tier targeted:**   Normal / Medium / Hard
**SoC studied:**     (name)
**Second SoC (Medium):** (name, or n/a)
**Workbench:**       L / B / D
**Workload 1 bottleneck:**  (one line: which resource, which question binds)
**Workload 2 bottleneck:**  (one line)
**Figures I could not source:** (count, and the most important one)
**What I learned:**  (one paragraph)
**AI usage:**  Model(s) + version(s): ____. Used for: ____.
               Verified or discarded: ____.  Signed: <your name>

Hints (Read Before You Begin)

• Start from the workload, not the chip. Pick your two workloads first, then go looking for the blocks they touch. Students who start from the spec sheet write inventories; students who start from the workload write predictions, and predictions are what the rubric pays for.
• The interconnect and the memory controller are never on the marketing diagram. They are also where your bottleneck lives. Put them in your inventory as inferred and reason about them anyway. Leaving them out because the vendor did not draw them is the single most common way to lose points on this project.
• “Not published” is a real answer and it earns credit. Vendors publish what helps them sell. Cache sizes, interface widths, sustained power envelopes and thermal design targets are frequently absent. Writing “not published, and here is why it matters” demonstrates exactly the judgment being graded. Writing a plausible number instead demonstrates the opposite.
• Two workloads that bottleneck the same way count as one. If both of your predictions end in “memory bandwidth,” pick a different second workload. The screen-off navigation case is deliberately included because it bottlenecks somewhere else entirely — and if you find yourself concluding that it does not really bottleneck at all, that is an interesting finding and you should say so.
• Show the bandwidth arithmetic, do not assert it. data rate × bus width is arithmetic, not a claim, so you may compute it freely from two sourced inputs. What you may not do is quote a bandwidth figure you did not compute and cannot source.
• Use the AI on the concepts, never on the chip. “Explain what a system-level cache does and why it sits in front of the memory controller” is a great question to ask a model. “How big is the system-level cache on part X” is the question that will cost you the project. The line is exactly that sharp.
• Write report.docx as you go, not at the end. Every time you write a number, write the URL and the date in the same motion. Reconstructing citations afterward is miserable, and it is how honest people end up with unsourced figures.

What Mastery Looks Like (Beyond the Rubric)

A great Project 1 does not read like a specification sheet with commentary. It reads like an engineer explaining a machine to a colleague.

The inventory is complete including the unglamorous blocks nobody advertises, and every inference is labelled as one. The configurations are sourced, and the gaps are stated plainly rather than papered over. And then the bottleneck predictions do the thing the whole course is about: they name a specific shared resource, they explain what else is demanding it at the same moment, they say which of The Four Questions binds first, they describe what a human being would actually observe, and they end by naming the measurement that would prove the author wrong.

That last move — here is what would falsify this — is the difference between an analysis and an opinion. A prediction that cannot be wrong is not a prediction. In Week 8 you will be asked to defend an investigation to a skeptical audience, and the students who do well are the ones who have been writing falsifiable claims since Week 1.

Coach’s Note — The agency does not need you to tell them which phone is fastest. Any review site will tell them that, using a number measured on a cold device in a climate-controlled room, which is a true number about a false situation. What they need — and what nobody sells them — is somebody who can look at a block diagram and say this device will be fine for the photos and it will overheat on the video, and here is the shared resource that explains both. That is the whole job. It is also, not incidentally, why this profession is worth doing: the value is not in knowing the specification, it is in knowing what the specification implies for a real person on a real day.

When You’re Done

1. Open report.docx and check that every number in soc-architecture-review.docx appears in the citation table with a URL and a date. Any number that does not: either source it now, or delete it. There is no third option.
2. Click through your own citations. A dead link, or a page that does not actually contain the figure you attributed to it, is the same failure as no citation at all.
3. Re-read your two bottleneck predictions. Does each one name a shared resource rather than a block? “The GPU is the bottleneck” is almost always wrong; “the GPU and the display engine are both saturating the memory controller” is the shape of a right answer.
4. Check that your two predictions are genuinely different from each other. If they are not, replace one.
5. Confirm every inferred row really is marked inferred. Read the table one more time specifically looking for a confident claim you cannot back.
6. (Hard) Re-read the memo and ask: did I name what my change costs, and did I name who loses? Strip any sentence that improves something for free.
7. Commit, push, submit the URL. Then read Chapter 2 — we open the first block on your diagram, and you find out why the cores inside it are not the same as each other.

A theological footnote. “Thus far shall you come, and no farther, and here shall your proud waves be stayed” (Job 38:11, ESV). The verse is spoken to the sea, and the limit it sets is not a punishment — it is what makes a shoreline, and therefore what makes the sea a thing with a shape and a name. This week you spent your hours on a machine defined entirely by boundaries its designers did not choose: a battery that holds what it holds, an aluminum shell that carries heat as fast as aluminum carries heat, a skin-temperature ceiling set by human hands rather than by silicon. Every specialized block you inventoried — the tile-based GPU, the fixed-function encoder, the sensor hub awake so the big cores can sleep — was invented by somebody who stopped arguing with those boundaries and started working inside them. There is a vocation in that. You do not choose your station; you choose whether to do good work in it. And there is a discipline in it too, which this project graded: knowing which of your limits are laws and which are merely decisions, accepting the first honestly, and reserving your argument for the second.

See you next week.