Public-reference architecture memo

AI/GPU Server Platform Integration Dossier

A portfolio-grade system study for an 8-GPU node or rack-slice boundary. It translates board, power, SI/PI, and bring-up experience into platform ownership language without copying any proprietary vendor design.

Public-reference study

This dossier demonstrates a target AI/GPU server reasoning boundary. It is not a record of Pengcheng's employer platform, customer deployment, or shipped hyperscale ownership. Verified career experience is listed separately on the Resume page.

Scope Architecture Power SI/PI BMC Validation Debug cases

Scope

Boundary: one AI accelerator node or rack slice.

The dossier is scoped around a practical platform integration boundary: host complex, accelerator bay, high-speed fabric, rack/server power input, BMC telemetry, cooling assumptions, validation coverage, and field debug hooks.

The point is not a vendor replica. The point is to show the system interfaces a hardware integration engineer must reason about when a platform moves from schematic and layout review into bring-up, validation, factory readiness, and customer-visible issue closure.

Target job-language mapping

Best-fit titles	Hardware System Integration, Platform SI/PI, Rack/Server Power, Hardware Systems Application, Board/Product NPI
Primary proof	Architecture trade-off, bring-up sequencing, interconnect margin, telemetry, validation matrix, debug closure
Resume grounding	5+ years of complex hardware platform work spanning FPGA/SoC, 10 Gbps+ SerDes, power sequencing, SmartVID/PMBus, bring-up, validation, RCA/ECO, and NPI
Excluded claim	Hyperscale shipped ownership, proprietary NVLink/TPU/GPU board design, confidential customer deployment data

Public-reference AI server platform architecture diagram with data, control, power, and validation planes

System Architecture

Separate the data plane, control plane, debug plane, and fault domains.

Platform interviews often test whether the candidate can reason across interfaces rather than list components. This map is the narrative spine: what carries workload traffic, what manages the platform, what helps root-cause failures, and what can fail independently.

Host complex CPU, memory, BIOS/UEFI, boot device, root ports, base clock/reset dependencies.

Fabric PCIe/CXL-ready topology, switches, retimers, connectors, cables, refclk, link logs.

Accelerator bay GPU/accelerator modules, high-current rails, local sensors, serviceable mechanical interfaces.

Management BMC, PMBus, I2C/SMBus, fault codes, sensor timeline, FRU inventory, event log.

Validation EVT/DVT/PVT gates, factory tests, fault injection, stress, soak, compliance, RMA/FA hooks.

Data plane

Workload traffic and bandwidth-critical paths.

Host-to-accelerator links, accelerator-to-accelerator fabric assumptions, NIC/DPU paths, storage and boot boundaries.

Control plane

Platform management and recovery paths.

BMC ownership, power sequence control, telemetry sampling, firmware handoff, logs, FRU data, field service signals.

Power Delivery

The power tree is also a debug architecture.

A platform power plan should explain how rails turn on, how faults propagate, how telemetry is sampled, and how a field engineer can distinguish transient droop, protection trip, thermal derating, and firmware policy issues.

Input

Rack feed to board power entry.

48/54V or 12V assumption, power shelf boundary, hot-swap, eFuse, redundancy, surge/inrush, and input telemetry.

Conversion

High-current accelerator rails.

VRM phase planning, load-step target, SOA, loop stability, bulk/decap strategy, OCP/OVP/OTP policy.

Observation

PMBus as a platform witness.

Voltage/current/temperature samples, fault latches, sampling period, timestamp correlation, and BMC event severity.

Interview claim to support: not just "I can tune compensation," but "I can explain how rail behavior affects link training, thermal throttling, firmware logs, protection thresholds, and field diagnosis."

SI/PI

High-speed margin must connect simulation, layout, lab, and logs.

Area	Platform question	Evidence to produce
Channel budget	Can a link close after board loss, connector loss, cable loss, via transitions, and retimer placement?	Loss budget, retimer decision, equalization assumptions, compliance measurement plan.
Reference clock	Could jitter, spread spectrum, clock muxing, or reset timing explain intermittent training?	Clock tree, jitter budget, reset dependency map, oscilloscope capture plan.
PI coupling	Can rail noise or PDN impedance convert a power event into a fabric symptom?	PDN target, load transient correlation, rail noise capture during link training.
Lab correlation	Does the lab evidence match AER logs, BMC event timeline, and thermal state?	Timestamped bring-up log, BER/compliance data, environmental notes, failure matrix.

BMC / Firmware Interface

Telemetry is the bridge between hardware events and platform operations.

The BMC plan is deliberately hardware-facing: rail-good dependencies, power sequence state, sensor placement, fault code ownership, log schema, and the minimum metadata needed for factory test, field support, and failure analysis.

Telemetry schema skeleton

rail_id	Stable rail name matching schematic, PMBus device, and validation checklist.
state	off, ramping, power_good, degraded, fault_latched, recovery_attempted.
correlation_id	Shared ID across BMC event, host log, link training attempt, and lab capture.
service_action	Retry, collect capture, inspect connector, replace module, escalate to FA.

Validation Matrix

Make first boot only the beginning of the proof.

Phase	Exit signal	Failure injection	Factory / field hook
Pre-board	Schematic review, layout constraints, power/SI risk register, test point map.	Review missing rail telemetry, missing reset observability, weak channel margin.	ICT/FCT strategy seeded before layout freeze.
Power-up	All rails sequence correctly, PMBus IDs match, fault latches clear, inrush within target.	Inject undervoltage, delayed power-good, sensor missing, fan/pump warning.	Factory rail test and BMC inventory snapshot.
Host boot	BIOS/UEFI reaches OS, BMC logs align with host timestamps, FRU data is complete.	Reset timing perturbation, boot device missing, BMC handoff delay.	Golden log bundle for comparison.
Fabric bring-up	Expected enumeration, link speed/width, BER/compliance pass, no unexplained AER storm.	Retimer config mismatch, lane reversal error, marginal connector, rail noise stress.	Link-training capture script and RMA triage checklist.
Stress / soak	Thermal equilibrium, no derating surprises, stable rails, no recurring correctable errors.	Load step, inlet temp rise, fan/pump fault assumption, workload transition stress.	Field telemetry thresholds and service action policy.

Debug Closure

Three public-reference scenarios explore the system lens.

Case 01

PCIe Gen5 link training intermittency

Retimer, refclk, connector loss, polarity, and rail noise fault tree.

Open case

Case 02

GPU load-step brownout

VRM stability, decap, OCP blanking, PMBus sampling, and protection response.

Open case

Case 03

Thermal/BMC sensor mismatch

Sensor placement, cold-plate contact, VRM hotspot, derating policy, and validation gate.

Open case

The proof demo converts this debug narrative into a small executable artifact: open the telemetry/debug timeline parser report.