Lesson 4: Power and Expansion Planning Lab

A parts list is not a system design.

You can buy a compatible CPU, enough RAM, a fast GPU, and a good monitor and still build a machine with the wrong PSU connectors, poor airflow, no room for the expansion card, or a display path that cannot deliver the mode you selected.

Today you prove the paths before the machine is assembled.

The scenario

Design a school media or esports workstation with:

• motherboard and CPU compatible with the Week 2 platform;
• 32 GB RAM;
• one NVMe system drive;
• one SATA storage drive;
• discrete GPU;
• wired Ethernet;
• USB capture device or internal capture card;
• digital monitor connection;
• cooling appropriate for the CPU and GPU workload.

The goal is not to build the most expensive PC.

The goal is to make every required path defensible.

Path 1: power

Start with the components that need power and trace each requirement.

System process animation

Power delivery from wall to silicon

Follow energy conversion and regulation instead of treating every no-power symptom as a failed PSU.

RestartPreviousPlay sequenceNext

1. 1Wall ACThe outlet supplies correct alternating-current voltage.
2. 2PSUThe supply converts AC into regulated DC rails.
3. 3DC railsCables carry power to the board and devices.
4. 4MotherboardBoard planes distribute rails to subsystems.
5. 5VRMRegulators create precise processor voltages.
6. 6LoadsCPU, GPU, memory, storage, and fans consume power.

Technician question: Where does a known-good voltage stop?

For the proposed configuration, verify:

• PSU capacity;
• required motherboard and CPU connectors;
• GPU power connectors;
• SATA power;
• PSU form factor and case fit;
• approved modular cables when relevant;
• one efficiency or power-loss consideration.

Then ask the more important question:

What symptom would appear if each power path failed?

Missing SATA power may make one drive disappear while the rest of the system works.

Missing CPU power may prevent POST while fans still spin.

Those are different failures because the dependencies are different.

Path 2: heat

Now trace how heat leaves the system.

CPU / GPU
   ↓
coolers
   ↓
case airflow
   ↓
room

Record:

• CPU cooler type;
• GPU cooling assumption;
• intake locations;
• exhaust locations;
• one airflow obstruction risk;
• one sign that cooling is failing under load.

Do not write "three fans" as the cooling plan.

Explain the direction of airflow and which heat sources depend on it.

Path 3: expansion

List every expansion requirement.

A discrete GPU or internal capture card may need:

• a specific PCIe slot size;
• available electrical lanes;
• physical clearance;
• enough spacing from another card;
• enough PSU capacity;
• cooling space.

If the capture device is USB instead, the internal PCIe requirement changes but the external USB capability becomes important.

Architecture changes when the implementation changes.

Path 4: display

Trace the complete signal path:

GPU
 ↓
output port
 ↓
cable
 ↓
monitor input
 ↓
requested resolution / refresh mode

Verify that the chosen GPU output, cable or interface, and monitor input can support the display mode you are claiming.

A monitor advertising a high refresh rate does not prove the full path can deliver it.

Worked design decision: internal versus USB capture

Suppose both options meet the basic capture requirement.

Internal capture card

Adds:

• PCIe slot and lane requirement;
• internal physical space;
• possible airflow impact.

USB capture device

Adds:

• external USB bandwidth and capability requirement;
• cable and port dependency;
• less internal expansion pressure.

Neither answer is automatically better.

Choose based on the rest of the system.

This is what tradeoff reasoning looks like.

Inject one failure into the design

After the clean design is complete, introduce one hidden change:

• CPU power disconnected;
• GPU power disconnected;
• display cable moved to the wrong output;
• monitor set to the wrong input;
• CPU fan disconnected;
• expansion card not fully seated.

The person diagnosing the system receives only the symptom and a few observations.

Use the paths you already built.

Do not abandon the model because something failed. The model is what makes the failure interpretable.

Keep the diagnosis controlled

Record:

1. symptom;
2. known-good evidence;
3. path you believe contains the failure;
4. strongest theory;
5. one competing theory;
6. smallest useful test;
7. result;
8. correction if justified;
9. verification.

If you change three things at once, the result is much harder to explain.

One controlled change gives you better evidence.

What the finished design should prove

Another technician should be able to inspect your record and answer:

• How does every major component receive power?
• How does heat leave the system?
• Which expansion resources are consumed?
• How does the display signal reach the monitor?
• Which failure would break each path?
• What verification would prove the system works afterward?

If the document is only a shopping list, it is not done.

Next, we use the same paths against a set of machines and displays that all look broken for different reasons.