Trace a rail from its source to its load, from both ends
On the workbench a chip isn't being powered: the rail it needs isn't present at its pin. The novice reflex: say 'the chip is dead' and replace it. The master reflex: 'where does this rail come from?' Because if a rail is missing at a chip, the cause is usually not that chip — it's most often the rail's source, or the path between the source and the chip. The only way to find that is to trace the rail — but not by chasing a wire with your eyes. You saw it yesterday too: seeing a net only as a wire (skipping the same-name = connected rule) was the most common trap. An Apple schematic is multi-page, and nets are connected by name (same name = connected, off-page connectors + cross-references). Today we put that knowledge into action. You'll burn two rules into your mind: (1) follow the net NAME, not the wire — because a rail doesn't 'end' at the page edge; it continues on another page under its name. (2) Verify a rail from both ends — find its source (where it's driven/generated) and its load (where it's consumed). Because the fault is almost always between these two: either the source isn't producing, or the path is broken. This skill — source↔load tracing — is the very heart of board-level diagnosis; everything that follows rests on it.
What does it mean to trace a rail — and what are source and load?
A net (rail/signal) is an electrical path, and every net has two kinds of ends:
- Source: Where the net is driven/generated. For a power rail, the source is the regulator/PMIC output that produces it (e.g., the source of
PP_VDD_MAINis a converter). For a signal, the source is the output pin of the chip that drives it. - Load: Where the net is consumed. For a power rail, the load is the chips it feeds. For a signal, the load is the input pin of the chip that receives it.
Rail tracing = following a net from one end to the other: from source to load, or from load to source. Why is this so important?
Today's question: If a rail is 'missing' at a chip, is the fault in that chip, in the rail's source, or in the path between? The answer can't be given without tracing the rail from both ends.
Because a 'not arriving' fault has three possible locations: (1) the source isn't producing, (2) the path between source and load is broken, (3) the load itself is faulty (rarest). Blaming the load (the chip) directly, without tracing the rail, is the most common and most expensive mistake. Today we learn to trace a rail correctly — by name and from both ends.
Why do we follow the net NAME, not the wire?
Recall from yesterday: an Apple schematic is multi-page, and nets are mostly connected by name, not by wire (same name = connected). This has a direct consequence for tracing: you can't keep chasing a wire with your eyes, because the wire enters an off-page connector at the page edge and 'disappears' — but the net continues under its name on another page.
The correct method is to follow the name:
- In boardview/schematic software: You click a net, and the software highlights every point (across all pages) carrying that name. With one click you see the net's entire world.
- In PDF/by hand: You search for the net name and jump page to page by following the off-page connector + cross-reference page number at the edge.
Apple example: While tracing the PP_VDD_MAIN rail, you see it on one page, find the 'goes to sheet 40' arrow at the edge, jump to that page, and find the net continuing under the same name. Even though the wire looks cut off, the net continues.
Reading tip — the golden rule: Don't think 'the rail ended on this page.' Note the net name, follow the off-page arrows and cross-reference page numbers. Follow the name, not the wire. This is the only reliable way to trace without getting lost in a multi-page schematic.
What happens when a path passes through series elements — and why does the net name change?
A single net (same name) is a single electrical node. But a real power/signal path often passes through series elements, and each side of a series element is a different net (usually with a different name). Series elements commonly found along a path:
- 0Ω jumper resistor: a bridge that closes/opens/splits the path.
- Ferrite bead / inductor (L): a series element that filters noise.
- Sense resistor: a small resistor that samples current/voltage.
- Load switch / converter: a switch that passes the rail under a separate name beyond a point.
- Connector (J): a transition between boards/flexes.
Tracing a path end to end = jumping net to net across these series elements. The net name changes often:
- Apple example 1:
PP_VDD_MAIN→ a divider resistor (R5901 1.3M / R5902 100K) →PP_VDD_MAIN_VMON(monitor line). The name changed because it passed through a series element (the divider). - Apple example 2:
PP_VBUS1_E75_RVP→ series 0Ω (R5903) →PP_HYDRA_ACC1. Same power, new name.
Why it's critical: These series elements are where the path can break (go open circuit) — and they're exactly the points where you'll measure. If a ferrite bead goes open, the source produces the rail but it never reaches the load.
Reading tip: When tracing a path, mark the series elements (0Ω/ferrite/sense/connector). Don't let the name change stop you — it's the continuation of the same path. These points answer both 'where does it break' and 'where do I measure.'
How do you verify a rail from both ends?
A chip isn't being powered (its rail is missing at the pin). Verify the rail from both ends:
Step 1 — Find the net name: Read the net name at the chip's unpowered pin (e.g., PP_xxx). From now on you'll follow this name, not a 'wire.'
Step 2 — Find the source: Trace the net backward by name (click in boardview / follow off-page in PDF). Who produces this rail? Which regulator/PMIC output, on which page? Identify the source.
Step 3 — Map the path: What series elements are on the path from source to load (the chip) — 0Ω/ferrite/sense/connector? List them by following the name changes.
Step 4 — Measure from both ends: Is the rail present at the source? Is it present at the load (the chip pin)?
- Missing at the source → the fault is on the source/regulator side (not producing).
- Present at the source, missing at the load → the fault is in the path between; probe the series elements (ferrite/0Ω/connector) one by one and find the open one.
- Present at both, but the chip still doesn't work → now the load (the chip) can be a candidate (last).
Step 5 — Conclusion: Locate the fault as source / path / load. Blame the chip last; most 'not powered' cases are the source or the path.
Trace a rail from source to load and identify the measurement points
A chip has no supply at its `PP_RAIL_X` pin. Assume this path: `regulator output (sheet 20) → ferrite bead L → 0Ω jumper R → connector J → chip (sheet 35)`. Questions: (a) To trace the rail, do you follow the wire or the name, and why? (b) Which two ends do you measure? (c) If it's present at the source but missing at the chip, which elements do you probe, in what order?
(a) I follow the NAME (`PP_RAIL_X`): the rail enters an off-page connector at the page edge and disappears but continues under its name; chasing a wire misleads in a multi-page schematic. I follow the sheet 20→35 cross-reference. (b) The two ends: source = regulator output (sheet 20) and load = chip pin (sheet 35). I measure the rail's presence at both. (c) Present at source / missing at chip → the fault is in the path; I probe the series elements in order: ferrite bead (open?), 0Ω jumper (open?), connector (seated/corrosion?). I find the open one; I consider the chip last. The answer should show the 'follow the name' + 'from both ends' + 'probe the series elements' logic.
Compare your answer with Sections 2-4: confirm 'follow the name, not the wire' in (a), the source+load two ends in (b), and in (c) that you probe the series elements (ferrite/0Ω/connector) in order and leave the chip for last.
Looking at the rail from one end only and blaming the chip (the load) directly
A chip wasn't being powered; the technician said 'the chip is gone,' removed and replaced it — the rail was still missing. Because the fault wasn't in the chip: the rail's source (a load switch on another page) wasn't producing an output. They had seen the rail only as a 'wire' next to the chip, without tracing it backward by name to check the source. The master followed the net name, found the source two pages away at the load switch: the switch wasn't receiving enable. The real fault was at the source; the removed chip was wasted and time was lost.
Most 'not powered' faults are not in the load (the chip) but at the source or in the path. Seeing the rail from one end only (just next to the chip) and not tracing it backward by name makes the source and the path's series elements a blind spot. Replacing the chip blindly is both costly and misleading: the real fault (source/path) stays in place and the new chip won't be powered either.
- Trace the net backward by name: find the source first, then the path, consider the load last.
- Always verify from both ends: present at the source, present at the load?
- Present at source / missing at load → probe the series elements (ferrite/0Ω/connector); blame the chip last.
What is today at a glance?
Today's essence — rail tracing:
- Every net has two ends: source (driven/generated) and load (consumed). Rail tracing = following from one end to the other.
- Follow the NAME, not the wire: in a multi-page schematic the rail 'ends' at the edge but continues under its name; click-highlight in boardview, follow off-page + cross-reference in PDF.
- The path passes through series elements: 0Ω/ferrite/sense/connector; each has a different net on its two sides (the name changes). These points are both 'where it breaks' and 'where I measure.'
- Verify from both ends: present at source / present at load? No source→regulator; source present, load missing→path (series element); both present→chip (last).
Now you can work out where a rail comes from, where it goes, and where it breaks. Tomorrow we scale this skill: not a single rail, but reading an entire power tree — battery → PMIC → buck/LDO → rails → loads. Finding a rail's source begins with knowing where it sits in that tree.
- GUIDESparkFun ElectronicsHow to Read a Schematic — the net/node concept and the basis of net names/labels (same name = connected); the universal net logic that rail tracing rests on↗#src_sparkfun_schematic
- BOARDVIEWApple Inc.iPhoneX Intel Edition MLB schematic — rail tracing examples: PP_VDD_MAIN → divider (R5901 1.3M/R5902 100K) → PP_VDD_MAIN_VMON; PP_VBUS1_E75_RVP → series 0Ω (R5903) → PP_HYDRA_ACC1; source↔load tracing across pages via off-page connector + cross-reference · power input + general#src_iphone_schematic
- BOOKUSTA AkademiUSTA field knowledge base (Ilham Hüseynov) — the source↔load two-ended tracing reflex in 'not powered' faults, the order of probing series elements (ferrite/0Ω/connector), and the field rationale for blaming the chip last#src_usta_field
What did you gain today?
What you learned today
- Every net has two ends: source (driven/generated) and load (consumed); rail tracing is done from one end to the other.
- Follow the NAME, not the wire: in a multi-page schematic the rail 'ends' at the edge but continues under its name (boardview click-highlight / PDF off-page + cross-reference).
- The path passes through series elements (0Ω/ferrite/sense/connector); each has a different net on its two sides (the name changes) — these points are 'where it breaks' and 'where I measure.'
- Verify from both ends: no source→regulator; source present, load missing→path (series element); both present→chip (last). Don't blame the chip blindly.
A moment from the field
A chip wasn't being powered; the technician said 'the chip is gone' and replaced it — the rail was still missing. The fault wasn't in the chip but in a load switch at the rail's source (it wasn't receiving enable). They had seen the rail only as a 'wire' next to the chip, without tracing it backward by name to check the source. The master followed the net name, found the source two pages away, and solved the real fault (the switch enable). The removed chip was wasted — because the rail had been read from one end only.
What will you learn tomorrow?
You learned to trace a single rail from both ends. Tomorrow we scale it: not a single rail, but **an entire power tree** — battery → PMIC → buck/LDO → rails → loads. Finding a rail's source is completed by seeing where it sits in that tree; we'll build the 'which rail comes from where, and in what order is it verified' reflex.
Yesterday you learned the language of the schematic (same name = connected, off-page); today you put that language into action and traced a rail from its source to its load. The 'follow the name, not the wire' + 'verify from both ends' reflex is the heart of board-level diagnosis — in the iPhone phase you'll solve every block (NAND/camera/baseband) with exactly this method. The skill you built today is the foundation of the 'measure from both ends' moment there.
FREE READING
Keep going — don't lose your place.
You read this lesson without signing up. Checkpoints, progress tracking and the lesson assistant are tied to your account; a free account opens all three and picks up where you left off.
- Checkpoint questions
- Progress tracking
- Lesson assistant
No card required. The free tier stays open with no time limit.
AkademiUsta · CONSOLE.TR · TR1_D03