Compute Carrier Board Architecture

You own the compute carrier board: the board the Jetson Thor module plugs into. It powers and sequences the module, connects every sensor and actuator, and keeps the robot safe if the module misbehaves. In the month before schematics, a system architect closes three loops on paper:

1. Interfaces: every sensor, actuator and peripheral lands on a real module resource with bandwidth and margin, with no pin-mux conflicts.
2. Power: every rail has a source, a current and thermal budget, and a place in the sequence.
3. Workload: the AI workload fits the module's fixed memory bandwidth and power envelope.

The outputs of that month: an interface control document, a pin-budget spreadsheet, a power tree with sequencing and budget, a stack-up and SI plan, a thermal budget, a safety concept, a boot and bring-up plan, and a BOM risk list (long-lead and single-source parts).

Say it this wayBefore I draw a schematic I close three loops: does every interface land on a real pin with margin, does every rail have a sequenced source with current and thermal headroom, and does the workload fit the module's fixed memory bandwidth. If any of those fail, the schematic is fiction.

The carrier is where three timescales meet:

• Reflexes at the edge: current loops at 10–40 kHz in each joint drive, slip detection in the hand MCUs.
• Coordinated control: joint-level control at 1–4 kHz over EtherCAT, owned by a real-time MCU so the inference workload cannot disturb it.
• Policy: the vision-language-action model on Thor at roughly 5–50 Hz, consuming camera frames and a summarized contact and joint state.

Every arrow on this map is an impedance, sequencing, EMC and failure-mode decision on your board.

Say it this wayReflexes stay at the edge, joint control runs on a dedicated real-time MCU at 1–4 kHz, and the policy runs on Thor at tens of hertz. The carrier's job is to connect those three without letting the slow one disturb the fast ones.

Module: NVIDIA Jetson T5000. 14-core Arm Neoverse-V3AE CPU at up to 2.6 GHz, 2,560-core Blackwell GPU, 2,070 TFLOPS FP4 (sparse), 128 GB 256-bit LPDDR5X at 273 GB/s, 40–130 W configurable, 100 × 87 mm with an integrated thermal transfer plate, and a 699-pin board-to-board connector.

You design to the module connector, not the SoC balls. The memory is on the module, so the hardest classic carrier task, DDR routing and byte-lane matching, is gone. Your high-speed burden is PCIe Gen5, 25GbE, CSI-2 and USB.

I/O available: PCIe Gen5 up to 8 lanes across controllers C1 (x1, root port), C2 (x1), C3 (x2, root port), C4 (x8) and C5 (x4); 4 × 25GbE; 16 lanes of MIPI CSI-2 (C-PHY 2.1 or D-PHY 2.1), up to 32 cameras with virtual channels; 3 × USB 3.2 and 4 × USB 2.0; HDMI 2.1 and DisplayPort 1.4a.

Build the budget as a spreadsheet: one row per connector pin (pin, module function, net name, voltage domain, carrier device). Then check two things: every function has enough lanes, and no two functions need the same shared lane. High-speed lanes (PCIe, USB 3.2, 25GbE) come from shared UPHY lanes, so confirm the pin-mux configuration supports your exact combination before committing.

Say it this wayThe memory's on the module, so I don't route DDR. My pin budget is about PCIe Gen5, 25GbE, CSI and USB, and the first pass is a lane-conflict check because those share UPHY lanes. I confirm the mux supports my combination on paper before layout.

Where each rail comes from

• Input protection: TVS for load-dump-like transients from the actuator bus, reverse-polarity protection, and a hot-swap controller or eFuse to limit inrush into the bulk capacitance. Size the MOSFET for safe operating area during inrush.
• 48 → 12 V: a fixed-ratio bus converter (4:1) at about 97%. High voltage on the harness, high current only where it is needed.
• SYS_VIN_HV (12 V): the main module input, behind a sequenced load switch. NVIDIA's guidance is to size it to the datasheet's absolute-maximum current with margin; at the 130 W mode it draws about 11 A at 12 V.
• SYS_VIN_SV (3.3 V): always-on, comes up first. Also feeds the safety and real-time MCUs and supervisors.
• SYS_VIN_MV (5 V): module input, enabled after HV.
• Carrier rails: enabled by CARRIER_POWER_ON from the module, so peripherals never back-power the module's I/O.
• Cameras: 12 V power-over-coax through per-camera filters and current limits.

Power budget

Master interface map, highest bandwidth first

The real engineering effort concentrates at the top of this table: PCIe Gen5 and 25GbE. Everything below 1 Gb/s is ordinary good practice.

Say it this wayThe 48 V bus comes in through protection to a 4:1 bus converter. 12 V feeds the module through a sequenced switch, 3.3 V is always-on and comes up first, 5 V follows, and the carrier rails wait for the module's CARRIER_POWER_ON. Whole board is about 200 W from 48 V, so about 4 A on the harness.

1. 48 V arrives; protection and the bus converter bring up the 12 V bus.
2. SYS_VIN_SV (3.3 V) comes up first. Safety and RT MCUs start booting.
3. SYS_VIN_HV (12 V) is switched on to the module.
4. SYS_VIN_MV (5 V) follows.
5. MODULE_POWER_ON asserts (an RC delay of more than 50 ms after 5 V in the published bring-up).
6. The module's internal sequencer runs, then it asserts CARRIER_POWER_ON.
7. Carrier regulators turn on; their power-goods combine.
8. The carrier releases SYS_RESET_N (about 19 ms later in the published bring-up).
9. PERIPHERAL_RESET_N releases carrier peripherals last.

Signals you must handle

• VDDIN_PWR_BAD_N: tells the module the input is good. Drive it from a supervisor on the input rail.
• MODULE_SHDN_N, POWER_BTN_N, MODULE_SLEEP_N: shutdown, power button and sleep control.
• SYSTEM_OC_N, THERM_ALERT_N: over-current and thermal alerts into the module.
• Shutdown: reverse order. On input loss, assert power-bad, let the module shut down, and hold carrier rails long enough with holdup capacitance for the NVMe to flush.

The order and delays above come from a published T5000 carrier bring-up discussion on NVIDIA's forum. Treat them as illustrative and confirm against the Jetson Thor Series Modules Design Guide (DG-12084) before design.

Say it this wayAlways-on 3.3 V first, then 12 V, then 5 V, then MODULE_POWER_ON. The module runs its own sequencer and hands me CARRIER_POWER_ON; only then do my peripheral rails come up, and I release SYS_RESET_N on their power-goods. Peripherals never get ahead of the module.

Step 1 · Sensor ingest is not the bottleneck

Ingest per stream = bytes per sample × samples per second. Cameras dominate.

0.72 GB/s ÷ 273 GB/s ≈ 0.26%. Even if each frame is written once and read three to five times by ISP, encoder and GPU, that is about 3–4 GB/s, under 1.5% of the memory bandwidth. Sensors do not size the memory system.

Step 2 · Where 273 GB/s comes from

• Bus width: 256 bits ÷ 8 = 32 bytes per transfer.
• Data rate: LPDDR5X-8,533 MT/s. The write clock (WCK) runs at about 4,266 MHz and data moves on both edges: 2 × 4,266 ≈ 8,533 transfers per second per pin.
• Bandwidth = 32 B × 8,533 × 10⁶ /s = 273 GB/s.

Check: 32 B × 4,266 MT/s would give only 136 GB/s, so the transfer rate must be 8,533 MT/s.

Step 3 · Where 9 GB of weights comes from

Ten billion parameters is an assumption for a large vision-language-action policy. Ask for the real model size and precision; the rest of the math follows.

Step 4 · Why it is memory-bound, not compute-bound

• At batch size 1 (one robot, one observation), each weight is used for about 2 floating-point operations: one multiply, one add.
• At FP4 each weight is 0.5 B, so arithmetic intensity is 2 FLOP ÷ 0.5 B = 4 FLOP per byte.
• The machine can do about 2,070 TFLOPS (FP4, sparse) but only fetch 273 GB/s: its balance point is 2,070 × 10¹² ÷ 273 × 10⁹ ≈ 7,600 FLOP per byte (about 3,800 dense).
• The workload's 4 FLOP/B is roughly a thousand times below that. The GPU sits idle waiting for weights. Attainable throughput ≈ 273 GB/s × 4 FLOP/B ≈ 1.1 TFLOPS.

Step 5 · The naive rate does not fit, and what does

• Every inference step must read essentially all 9 GB from DRAM. On-chip caches hold tens of megabytes, so "keeping the weights resident" in DRAM does not reduce this traffic.
• At 50 inferences per second: 9 GB × 50 = 450 GB/s, about 1.65 × the 273 GB/s available. It does not fit.
• Upper bound: 273 ÷ 9 ≈ 30 inferences per second at 100% efficiency; about 21 per second at a realistic 70%.

Fixes, all above the board level:

• Run the big model less often. Action chunking: each inference outputs a chunk of future actions (for example 10–50 steps), so the VLA runs at 5–10 Hz while control runs at 50 Hz or faster. At 10 Hz, 9 GB × 10 = 90 GB/s, about a third of the bandwidth.
• Split slow and fast. A large vision-language backbone at a few hertz plus a small action head (tens to hundreds of MB) at high rate.
• Fewer bytes per weight: FP4 throughout where accuracy allows.
• Fewer weights per step: a smaller or distilled model, or a mixture-of-experts model that reads only active experts.
• Leave headroom: the cameras, ISP, encoder and CPU share the same 273 GB/s.

If it still does not fit, the answer is a different module or a smaller model. No carrier-board change creates memory bandwidth.

Say it this waySensors are about a quarter of a percent of memory bandwidth, so the model sizes the memory system. 273 is 32 bytes times 8,533 MT/s. A 10-billion-parameter policy at mostly FP4 is about 9 GB, and at batch one it's about 4 FLOP per byte against a machine balance near 7,600, so it's memory-bound. Fifty inferences a second needs 450 GB/s and doesn't fit. Action chunking at 10 Hz needs 90 GB/s and does. If that's not enough, it's a module or model decision, not a board fix.

• 14 layers to give every high-speed layer an adjacent solid ground, keep power planes paired with ground, and leave room for the 699-pin connector breakout.
• Material: low-loss laminate (Df around 0.002–0.004 at 10 GHz) at least on the PCIe Gen5 and 25GbE layers; a hybrid stack can use standard FR-4 elsewhere to save cost.
• Impedance: 85 Ω differential for PCIe, 100 Ω for Ethernet, CSI and GMSL breakout, 90 Ω for USB, 50 Ω single-ended.
• Copper: 2 oz on the 12 V plane for about 11–15 A with low drop; 0.5–1 oz on signal layers.
• Vias: backdrill PCIe Gen5 and 25GbE through-hole vias to keep stubs short; ground-stitch every layer transition; via-in-pad where the connector escape needs it.
• Thickness: about 1.6–2.0 mm, chosen with the connector and mechanical team.

Say it this wayFourteen layers so every high-speed layer has a solid adjacent ground and power planes sit against ground. Low-loss laminate on the Gen5 and 25G layers, backdrilled vias, 85 Ω for PCIe and 100 Ω for Ethernet and CSI, and 2-ounce copper on the 12 V plane.

• PCIe Gen5: budget the channel first: module connector, carrier traces, vias, AC caps, M.2 connector, SSD. If simulated loss exceeds the end-to-end budget, add a retimer. AC caps near the transmitter. Stripline on L3. Intra-pair skew within a few mils, no plane splits underneath.
• 25GbE: same discipline; verify with channel operating margin. Keep to one or two via transitions.
• CSI-2: deserializers placed close to the module connector so the CSI runs are short. Match data lanes to the clock lane.
• GMSL: 50 Ω coax launch at the camera connectors; power-over-coax inductors sized for the camera current and not saturating; place deserializers so coax connectors sit on the board edge.
• Return paths: every high-speed layer change has ground vias next to the signal vias.
• Partitioning: 48 V input and converters in one corner, away from cameras and the CSI area; EtherCAT ports and magnetics at the edge facing the joints.
• Reference clocks: PCIe 100 MHz HCSL from the module or a clock buffer, routed as a protected differential pair.

Say it this wayI budget the PCIe Gen5 channel before layout and add a retimer only if simulation says the loss exceeds budget. Deserializers sit next to the module connector so CSI stays short, coax connectors on the edge, and the 48 V converter is in its own corner away from the cameras.

• Module: up to 130 W through its integrated thermal transfer plate into a heat sink or a cold plate tied to the robot chassis. In a sealed robot body without airflow, conduction to the chassis is the main path.
• Carrier hot spots: bus converter losses (~3% of 200 W ≈ 6 W), downstream bucks (2–3 W), NVMe Gen5 (up to ~12 W, needs its own thermal pad and will throttle if hot), deserializers (~1.5 W each), 25G PHY.
• Design: place hot parts where the chassis path is shortest, use thermal vias and copper pours, and give the NVMe a pad to the enclosure.
• Monitoring: thermistors near the converter, SSD and module read by the RT or safety MCU; THERM_ALERT_N into the module; a power-mode policy that drops the module to a lower power mode before throttling hits control.

Say it this wayModule heat goes through its transfer plate into the chassis. On the carrier, the converter, SSD and deserializers are the hot spots; each gets a short path to the enclosure and a thermistor, and the power-mode policy steps the module down before anything throttles.

• Independent safety MCU (lockstep cores) on the always-on 3.3 V rail with its own supervisor and watchdog.
• It owns Safe Torque Off to every drive, through FSoE or hardwired STO lines, and reads the E-stop chain.
• It watches heartbeats from Thor and the RT MCU. A missed heartbeat or out-of-range rail trips STO and engages brakes.
• Freedom from interference: separate power, clock and reset from the module, so no failure of the AI compute can stop the safety function.
• Target: the safety level set by the machinery risk assessment, typically ISO 13849 PL d, category 3 for a human-adjacent industrial robot.

Say it this wayThor is never in the safety path. A lockstep MCU on the always-on rail owns STO and the E-stop, watches heartbeats from Thor and the real-time MCU, and trips the drives if either goes quiet. It has its own power, clock and reset.

• Release to motion: the safety MCU holds STO until Thor's stack and the RT MCU both report healthy and EtherCAT reaches Operational.
• Recovery: the USB-C port plus a force-recovery strap lets you reflash the module.
• Bring-up order: power the carrier with no module and a dummy load; verify every rail, power-good and sequence; then install the module and boot to the console; then bring up each interface (PCIe link training, cameras with PRBS or pattern, Ethernet loopback, EtherCAT scan).
• Design for test: test points on every rail and power-good, a console UART header, current-sense on major rails, and boundary scan on carrier devices where available.
• Production test: flash, PCIe link speed and width check, camera bit-error test, Ethernet and EtherCAT loopback, thermal soak, power-cycle and brown-out tests.

Questions to ask them: Which module and power mode are you targeting? What model size, precision and inference rate does the ML team plan? How many joints and cameras, and what control rate? Is EtherCAT the joint bus? What safety level came out of the risk assessment? What's the enclosure and cooling path?

Say it this wayI'd spend the first month closing interfaces, power and workload on paper, retire the top risks with the ML, mechanical and controls teams, and only then start schematics.

• NVIDIA Jetson Thor module datasheet (T5000/T4000)
• Jetson Thor Series Modules Design Guide (DG-12084, NVIDIA developer login)
• NVIDIA forum: Thor board design power-on (sequencing discussion)
• NVIDIA forum: T5000 SYS_VIN_HV current sizing
• EtherCAT Primer (this folder)