Project 6 — The Integration Map

“joined and held together by every joint with which it is equipped, when each part is working properly” — Ephesians 4:16 (ESV)

Chapter: 6 — Wiring the System Together Due: End of Week 6 Weight: 7% of the course grade (one of the six weekly labs; see Appendix D) Deliverables: report.docx, measurements.xlsx, ai-usage.txt Workbench: Normal tier is completable on Workbench B — a browser dev environment, no install, no admin rights, no phone. Workbench L is more comfortable. Workbench D (a physical Android device) is optional everywhere in this project and appears only in clearly-marked “go further” steps. See Appendix A. Allowed tools: Python 3 and a C++17 compiler; this chapter’s code/ directory; vendor specification pages, architecture reference manuals and standards documents for citation; the textbook. AI policy — explain, never source. You may use a language model to explain any mechanism in this chapter. You may not take a number, an interface name, a protocol capability, or a product claim from it. Every external figure in your report carries a primary-source citation. An uncited figure scores zero on its line; a fabricated one fails the integrity line outright. ai-usage.txt is required whether or not you used a model.

The Setup

A relief agency runs a small fleet of ruggedized tablets for its field clinicians. The device does four things at once, all day, in places with bad coverage and no mains power: it records video documentation of a site visit, it navigates between sites on cellular, it runs an on-device model that transcribes and redacts the clinician’s spoken notes so nothing sensitive leaves the device, and it keeps its screen on in daylight the whole time.

The current generation does all four. Badly. The camera preview stutters during navigation. The transcription that takes two seconds in the office takes fifteen in the field. Battery does not last a shift. Every vendor the agency has asked has offered the same answer: buy the newer chip.

You have been brought in because you suspect that is the wrong answer. Not because the newer chip is bad, but because nothing in the symptom list is a compute problem. A stuttering preview while navigating is a bus master losing an arbitration. A model that is slow only in the field is a model competing with a radio and a camera for the same path to memory. A battery that does not last a shift, on a device whose CPU is mostly idle, is a wake-up problem, not a throughput problem.

Your job is to produce the document the agency’s engineering partner never wrote: an integration map. Every significant bus master, what it needs, when it needs it, what it shares, and — the part that earns the grade — the two most likely integration failures for the named use case, with the measurement that would confirm each. You are not going to fix the device this week. You are going to make it possible for someone to fix it, by naming the seam.

Setup (the starter)

Everything you need ships with this chapter and runs on all three workbenches:

• code/bus-traffic.csv — a synthetic traffic table for seven masters. Its first line says so. You will use it as the shape of an integration map and replace or extend its rows with figures you can cite or derive.
• code/qos_arbiter.py — the arbitration simulator. Fixed-priority and weighted-fair, with an optional best-effort floor.
• code/radio_energy.py — the radio-energy model: unbatched, compressed and batched, with the tail.
• code/irq_vs_poll.cpp — the interrupt-versus-polling crossover model (used in the Medium tier).

Run each of them once before you write a word. Then read Appendix B on how to read a block diagram, and Appendix C on what a measurement log must contain.

One rule about the dataset, and it is graded. code/bus-traffic.csv is synthetic teaching data modeled on published behavior. It is not a measurement of any product. Your report must say so, in your own words, at the point where you first use it — and must be explicit about which of your numbers are derived from stated assumptions, which are cited to a primary source, and which are synthetic. Week 8 grades you on that distinction. This week you start practicing it.

Learning Targets

By completing this project you will demonstrate that you can:

• Read a device as a set of bus masters competing for a shared path, rather than as a list of blocks.
• Derive a master’s bandwidth requirement as arithmetic from stated assumptions, and say plainly when you cannot derive it and what you would need.
• Classify traffic by latency class and deadline, and defend why a given client is hard-real-time, soft, or best-effort.
• Predict, and then simulate, who is starved under a given arbitration policy — and defend the choice of victim.
• Reason about radio energy in terms of awake time, and show why batching dominates compression.
• Name a specific integration failure with a mechanism and a user-visible symptom, and design a measurement that could refute it.
• Distinguish measured, derived, cited and synthetic figures, and disclose AI assistance honestly.

Normal Tier

Goal: an integration map for one device class and one named use case, with a contention analysis and two defended failure predictions, in report.docx, backed by measurements.xlsx.

Pick one device class and say which in your first line: a flagship phone, a field/rugged tablet (the scenario’s device), a wearable, or an XR headset. Then pick the use case; the default, and the one the scenario is about, is “record 4K video while navigating on cellular, screen on, with on-device transcription running.” You may substitute another use case if it exercises at least four simultaneous masters, but say why.

Required deliverables

1. The integration map. A table in report.docx with one row per significant bus master. Minimum six rows; the scenario’s device has more. Columns:

   Master	Interface it arrives on	Direction	Peak / average demand	Latency class	Deadline	Shares with	Source of the figure

   Source of the figure is one of: derived (show the arithmetic), cited (name the document), or synthetic (from the shipped dataset). Every row must have one. “Estimated” is not a category — if you estimated, you derived it from assumptions, so state the assumptions.

2. The bandwidth arithmetic. For at least three masters, show the derivation the way §6.2 does — inputs, multiplication, result, and the assumption you made. The display and the camera are the obvious two; pick a third. If a master’s demand cannot be derived or cited (a modem’s DRAM traffic is a good example), say so explicitly and state what you would need to measure it. An honest “I could not determine this, and here is how I would” scores full marks on that line. An invented number scores zero.

3. The contention analysis. Run code/qos_arbiter.py under both policies at a total bandwidth you choose and justify in one sentence. Report which masters are in trouble under each. Then answer, in prose: under fixed priority, who did the policy sacrifice, and was that the right sacrifice for this device and this use case? One paragraph, and it must commit to an answer.

4. The radio analysis. Run code/radio_energy.py at least three times with different parameters — at minimum the default, one with a different tail, and one with a different transfer interval. Report joules for unbatched, compressed and batched in each, plus the ratio. Then connect it to the scenario in two sentences: the device’s navigation and its telemetry both use the radio; which of them is the expensive one, and why is it not the one that moves the most bytes?

5. The two most likely integration failures. This is the graded core. For each of two failures:

   • The mechanism. Which master starves which, at which seam, under what condition. “Bandwidth contention” is not a mechanism. “The camera’s CSI-2 receiver and the NPU’s weight streaming both target the same port into the system-level cache; under fixed priority the camera wins and the NPU’s grant collapses below its sustained need” is a mechanism.
   • The user-visible symptom. What the clinician actually experiences, in one sentence.
   • The confirming measurement. One concrete measurement — a counter, a trace, a timing, an A/B condition — that would confirm it.
   • The refuting result. What result would tell you that you were wrong. A prediction with no refutation condition is not an analysis, and this line is graded on its own.

6. measurements.xlsx. Every run of every program: what you ran, the exact arguments, the workbench, the date, the repetition count, and the result. Medians and dispersion where you ran anything more than once. Format per Appendix C. The simulations are deterministic, so this week’s log is mostly a provenance record rather than a statistical one — say that in the log’s header, because knowing which of your numbers needed statistics is itself the skill.

7. ai-usage.txt. One honest paragraph in the format Appendix D defines: which model and version, what you used it for, what you verified, and — if it happened — what it got wrong. “I did not use AI” is a complete and acceptable answer if it is true.

Normal-tier rubric (out of 100)

Medium Tier (+up to 25% extra credit)

M1. The always-on budget

The field tablet must survive a shift. Produce, as a section of report.docx, an always-on budget: what is permitted to be awake while the screen is off, and what wakes what.

• Enumerate every candidate always-on job for your device class — sensor fusion, step or motion detection, wake-word detection, location for a geofence, a background sync, a health poll, notification delivery.
• For each, state which processor it runs on (the sensor hub or an application core), what wakes it, and how often.
• For at least three of them, apply §6.7’s batching argument or §6.9’s tail argument to propose a concrete change that reduces the wake count without removing the feature.
• Use code/irq_vs_poll.cpp to make one of those arguments arithmetic: pick a job with a plausible event rate, run the model at that rate, and report whether an interrupt-driven or polled service is cheaper for it — and what would move the answer.
• Close with the ranking the agency actually needs: given a fixed idle-power target you cannot meet, which job do you cut first, and what evidence justifies the cut?

State plainly which parts of this budget are structural reasoning and which would need measurement. Do not invent milliwatt figures. A budget expressed in wake-counts and ownership, with the measurements named, is worth full marks; a budget full of uncitable power numbers is worth none.

M2. Extend the dataset honestly (optional within Medium)

Add two rows to a copy of code/bus-traffic.csv for masters your device class has and the shipped file does not — a second camera, a video encoder, a display-stream compression block, an XR tracking sensor set. Keep the synthetic-data header line. Derive each new row’s figures from stated assumptions, show the arithmetic, and re-run the arbiter. Report what changed and whether any master’s verdict flipped.

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

H1. The interface memo

Write, as the final section of report.docx, a memo of half a page to a page addressed to the agency’s engineering partner. Name one interface on your integration map that you would change, and defend the change. Choose a real change with a real cost — for example:

• give the display controller a reserved system-level-cache allocation, or a private port;
• move the on-device model’s weights behind a dedicated buffer so its streaming does not compete with the camera;
• move a discrete part on-die, or a integrated part off-die, and take the opposite set of costs;
• add a best-effort floor at a specific percentage, and say which master funds it;
• move a job from an application core to the sensor hub, and name what capability that job loses.

The memo must contain all four of these, and the rubric weight is in the last two:

1. The change, stated in one sentence, precisely enough that an engineer could act on it.
2. What it buys, in bandwidth, latency or energy, argued from your own map and your own runs.
3. What it costs. Area, power, complexity, schedule, risk, or a master that now suffers. Every change on a fixed budget takes from someone. Name them.
4. The condition under which you would withdraw the recommendation. One sentence: “if measurement showed X, I would not do this.”

A memo that says “use a faster interconnect” fails. A memo that says “reserve 15% of the system-level cache for the display controller, which removes the 0.3 ms burst overrun we predicted; it costs the NPU roughly a sixth of its effective cache and will lengthen first-token latency; I would withdraw it if a trace showed the display’s misses were caused by composition layer count rather than fetch bandwidth” is the work. This is the judgment an AI cannot make for you, because it requires committing to a loser.

Submission

Submit the three deliverable documents together:

1. report.docx — the integration map, the arithmetic, the contention analysis, the radio analysis, the two failures, plus the Medium and Hard sections if you attempted them.
2. measurements.xlsx — the run log, per Appendix C.
3. ai-usage.txt — the honest disclosure, per Appendix D.

Open report.docx with this header block, filled in:

Project 6 — The Integration Map
Tier targeted:        Normal / Medium / Hard
Device class:         (phone / rugged tablet / wearable / XR headset)
Use case analyzed:    (one sentence)
Masters mapped:       (count)
Interconnect total used in the simulation, and why:  (one sentence)
Failure 1 (one line): ______   confirmed by: ______   refuted by: ______
Failure 2 (one line): ______   confirmed by: ______   refuted by: ______
Provenance summary:   derived: __ figures | cited: __ figures | synthetic: __ figures
Workbench:            L / B / D

Hints (Read Before You Begin)

• Start from the use case, not from the block diagram. List what the device is doing in that one moment, then ask what hardware each activity touches. You will find masters you would never have listed by walking a block diagram — the video encoder, the composition path, the storage writes that the recording produces.
• A master you forgot is worth more than a master you described well. The most common failure of this assignment is a beautiful table with five rows and no storage controller, or no video encoder, or no second camera. Recording produces writes.
• Do the display and camera arithmetic first. They are the two you can derive from first principles in three lines each, and they anchor the scale of everything else. §6.2 shows the shape.
• “Shares with” is where the analysis lives. Two masters that never overlap in time do not contend, no matter how large their numbers. Say when each master is active during the use case, and you will find your two failures almost by inspection.
• Justify your interconnect total out loud. There is no correct value and the graders know it. What is graded is whether you said what your total represents (a theoretical peak? an achievable sustained figure? a fraction allocated to this path?) and why you chose it.
• The refutation line is the one students skip. Write it first if you have to. If you cannot name a result that would prove you wrong, your failure prediction is not falsifiable, and an unfalsifiable prediction is not engineering.
• Do not go looking for a vendor’s interconnect bandwidth. For most parts it is not published, and this is the exact place a language model will hand you a confident invention. If you cannot cite it, model it — a modeled number you labeled as modeled is honest; a sourced-looking number you cannot source is the one thing this course fails you for.
• (Workbench D, optional.) If you have an Android device with developer options, capture a system trace while running the use case and use it to check one claim on your map. This is a bonus observation for any tier, never a requirement — say plainly in report.docx that it was optional and what it changed, if anything.

What Mastery Looks Like (Beyond the Rubric)

A great Project 6 reads like the document a platform architect hands to a partner three weeks before tape-out. The map is complete enough that you can see the omissions were considered. Every number says where it came from, and at least one line says “I could not determine this” in a way that makes the reader trust all the others more. The contention analysis does not hedge: it names the master that gets sacrificed and it says whether that was right, in a sentence a program manager could act on. And the two failure predictions are specific enough to be wrong — each has a mechanism you could argue with and a measurement that would settle the argument.

The tell of a weak submission is the opposite in every particular: a table of blocks rather than masters, round numbers with no derivation, “there may be contention” instead of “the camera starves the NPU during the burst,” and a failure prediction that could not possibly be refuted by anything.

Coach’s Note — The agency’s vendors all said “buy the newer chip,” and one of them may even be right. But notice what a new chip does not fix: a policy that starves the wrong master, an app that wakes a radio every thirty seconds, a composition path that wakes the GPU for a frame the display controller could have assembled itself. Those are seam problems, and seam problems follow you onto the new silicon. When someone answers a systems question with a component, that is the moment to ask for the integration map. Usually nobody has one. That is your opening, and it is most of what a systems architect is actually paid for.

When You’re Done

1. Re-read your map and ask: is every row a master (something that issues transactions) rather than a block? Delete anything that is only a block.
2. Check every figure for a provenance label. Any number without one is either derived — so show the arithmetic — or it does not belong in the document.
3. Read your two failures aloud. Does each name a mechanism, a symptom, a confirming measurement, and a refuting result? If any of the four is missing, it is not finished.
4. Confirm your report says, in your own words, that code/bus-traffic.csv is synthetic and what that limits.
5. (Hard) Re-read the memo and find the sentence that names the loser. If there isn’t one, you have not made a recommendation — you have made a wish.
6. Submit report.docx, measurements.xlsx and ai-usage.txt together.
7. Then read Chapter 7. The modem you just mapped — a computer running its own operating system, with a path into your memory system — is about to become a threat model.

A theological footnote. Paul describes a body “joined and held together by every joint with which it is equipped, when each part is working properly” (Ephesians 4:16, ESV). The passage does not say the body is held together by its members; it says it is held together by its joints, and that each part works properly in its place, in relation to what it is joined to. This week’s work is an unusually literal application of that. You spent it not on components but on the connections between them — and you will have noticed that nobody gets a launch slide for a seam. The integration engineer’s excellence is legible only as absence: the frame that did not tear, the battery that lasted the shift, the reboot that did not happen. That is the ordinary shape of vocation, which is measured by the neighbor served and not by the recognition attracted. The clinician in the field will never know your name. She will know that the device recorded the visit. Write the contract down, instrument the seam, and let that be enough.

See you next week.