Hypothesis

Re-ran the R0 JTAG/service-port analysis on R1 (ODB++ SH100008192_R1.0 0407.1700 + BOM SH100008193_R1.0; ingested as netlist R1, id 16). The JTAG signal chain is byte-identical to R0 — the TDO open-drain root cause (E-038) was NOT addressed in R1. Expect the same ~1 MHz ceiling on R1 hardware unless reworked.

R0 → R1 diff (JTAG/service-port)

Net: R1's service-port changes are about auto power-up (moving to the always-on P3V3_STBY domain so the manual switch can be removed), not JTAG speed. The TDO path is untouched.

Answer 1 — open-drain affects XJTAG too (verified)

U9 sits on the common TDO node JTAG_TDO_3V3 = U48.4, upstream of the FTDI/XJTAG mux split (U48.3→FTDI, U48.2→XJTAG). Both hosts read TDO through U9 + R139. SN3257 is a passive pass-FET (no re-buffer), so XJTAG can be worse — the 10 K pull-up must also charge the cable + pod capacitance through the switch. Not FTDI-specific; same fix needed for either host.

Answer 2 — I/O voltage chain is consistent (verified)

Two clean islands: 1.8 V FPGA side (P1V8_VCCO) ↔ 3.3 V host side (P3V3_STBY). U8 bridges TCK/TMS/TDI (VCCB pin16=1.8, VCCA pin1=3.3). U48 mux + FT4232H VCCIO (U10 pins 20/31/42/50/56) = 3.3 V (the P1V8_USB pins are the FTDI internal core/PHY, not I/O). No stray rail, no contention.

• The TDO open-drain IS the 1.8→3.3 level-shift: U9 VCC = 1.8 V (JTAG_BUFFER_VCC_Q ← PQ1 ← R137 ← P1V8_VCCO); its open-drain output is pulled to 3.3 V by R139. Legal (AUP1G07 open-drain rated to 3.6 V, no VCC clamp) — but this is exactly why it's RC-slow.
• ⚠ Earlier E-038 fix "swap to push-pull AUP1G17" is WRONG (voltage-naive): a single-rail buffer at 1.8 V outputs only 1.8 V (too low for 3.3 V FTDI input); at 3.3 V it can't read the FPGA's 1.8 V TDO (VIH≈2.15 V).
• ✅ Correct fix: a dual-supply directional translator for TDO, e.g. SN74AXC1T45 (VCCB=1.8 / VCCA=3.3, DIR=B→A) — same family as U8, push-pull both sides, 100s of MHz. R139→~470 Ω is only a partial bench mitigation.
• Checks: J20 (XJTAG header) has no VTREF pin (pod must be hard-set to 3.3 V); U9 VCC is gated by PQ1/JTAG_FTDI_EN_N — confirm U9 is powered when XJTAG is the active path.

Next step

1. R1 board: if at-speed JTAG still needed, rework TDO — replace U9 (SN74AUP1G07) with a dual-rail translator (SN74AXC1T45-class). Bench triage: R139 10K→470Ω, scope TDO rise.
2. Raise with Synopsys (Martin Wang / Erik) for the next spin — the open-drain TDO is the wrong topology for at-speed and was carried over unchanged from R0.
3. Re-test 6/12/20 MHz on reworked R1; compare to R0.

Source: R1 netlist (project 46, id 16) vs R0 netlist (project 43, id 15). Predecessor analysis: R0 concept E-038, notice E-039. Related: [[microhaps-project]].

Defect: JTAG works only at ~1 MHz and fails ≥6 MHz on the FTDI service-port path. Root cause = the TDO return buffer U9 (SN74AUP1G07), an open-drain part powered at 1.8 V whose output is pulled up to 3.3 V by R139 (10 K). The open-drain rise is RC-limited (τ ≈ 10K × ~20 pF ≈ 200 ns → ~440 ns edge), so TDO read-back cannot settle within the TCK period above ~1 MHz. Target is ≥12 MHz, ideally 20 MHz.

Scope of impact:

• Affects both FTDI and XJTAG — U9 sits on the common TDO node JTAG_TDO_3V3 (U48.4), upstream of the FTDI/XJTAG mux split. Neither host escapes it; XJTAG can be worse (pull-up also charges cable+pod through the passive SN3257).
• Present in R0 and carried over unchanged into R1 (verified against both netlists: R0 id 15 proj 43, R1 id 16 proj 46). R1's only service-port change was the move to the P3V3_STBY/AWO domain (auto power-up), not the TDO path.

Required fix for R2:

• Replace U9 with a dual-supply directional level translator for TDO — e.g. SN74AXC1T45 (VCCB = 1.8 V from P1V8_VCCO, VCCA = 3.3 V, DIR set B→A), push-pull both sides, hundreds of MHz. Same family as U8.
• ❌ Do not substitute a single-rail push-pull buffer (e.g. AUP1G17): at 1.8 V it can't reach the 3.3 V host input; at 3.3 V it can't read the 1.8 V FPGA TDO (VIH ≈ 2.15 V). The open-drain exists because it doubles as the 1.8→3.3 V level-shift, so the replacement must also translate.
• Confirm the new translator's enable/power is asserted for both FTDI and XJTAG paths (current U9 VCC is gated by PQ1/JTAG_FTDI_EN_N — verify it isn't FTDI-only).

Also for R2 (related, lower severity):

• Add a VTREF pin on the XJTAG header J20 (currently none) so the XJLink pod can sense target I/O voltage instead of being hard-set to 3.3 V.
• C10–C13 (10 nF JTAG line caps) are NM/"disable" — keep depopulated or correct footprint value to ≤47 pF if any filtering is ever wanted.

Acceptance criteria (R2 bring-up):

• Clean JTAG enumeration + boundary scan at ≥12 MHz (target 20 MHz) on the FTDI service-port path; verify on XJTAG path too.
• Scope TDO rising edge at the U48/host side: ≤ ~10 ns (vs ~440 ns today).

Interim (R0/R1 boards in hand): bench rework — R139 10 K → ~470 Ω (partial), or piggyback an SN74AXC1T45 on the TDO net; scope TDO before/after.

Root-cause analysis: R0 concept E-038 (proj 43), R1 diff E-001 (proj 46); mount-status check E-039 (proj 43). Netlists: R0 id 15, R1 id 16. Related: [[microhaps-project]]. Raise with Synopsys (Martin Wang / Erik Ingemarsson) for the R2 spin.

From the R1 I2C walkthrough (see E-003). Potential carried-over/relocated version of the R0 issue [project 43 / E-045].

What changed R0→R1: Per DesignLog R1.0-007/008, the reversed CLKA passFETs (Q22/Q23) were removed and the Si5340 clock generator (U6) I2C was moved onto the FPGA_I2C segment (U6 pins 13/14 → FPGA_I2C_SDA0/SCL0). Good — the broken FET translator is gone.

The concern: FPGA_I2C is the B-side of buffer U5 with VCCB = P3V3_VCCO (3.3 V), so that segment idles at 3.3 V. But the Si5340 supply/strap configuration in R1 is unchanged from R0: all its digital control straps still pull to P1V8_CLK (1.8 V) — CLKA_I2C_SEL (R114), CLKA_IN_SEL0/1, CLKA_LOS#/LOL#/INTR#/RST# — strongly implying the Si5340 digital VDD / I2C I/O is 1.8 V. If so, its SDA/SCL (pins 13/14) are now connected directly, with no translator, to a 3.3 V bus → the same over-voltage class as E-045, just relocated from the CLKA branch to FPGA_I2C.

Why it may still be a problem: R0's E-045 was a 1.8 V device pulled to 3.3 V via a wrong-rail / reversed FET. R1 removes the FET but, if the Si5340 I2C is 1.8 V, places it directly on a 3.3 V segment shared with the FPGA (bank K9/K10, VCCO = P3V3_VCCO) — over-voltage on the Si5340 I2C pins, and the FPGA driving 3.3 V into them.

To confirm (same open question as E-045): the Si5340A digital VDD / I2C I/O voltage per datasheet. U6 supply pins in R1: 8/9 → P3V3_CLK (3.3 V, likely VDDA); 21/26/32/39/40 → P1V8_CLK (1.8 V); 18/23/29/34 → P2V5_CLK_A. If the I2C-referencing VDD is the 1.8 V group, this is a real defect; if the Si5340 VDD was set to 3.3 V (so its I2C is 3.3 V), then moving it to FPGA_I2C is correct and this resolves clean. A scope of FPGA_I2C SDA/SCL idle high (3.3 V expected) and confirmation of the Si5340 VDD strap settle it.

Action: confirm with Synopsys (Martin Wang) whether the Si5340 digital supply is 1.8 V or 3.3 V in R1. If 1.8 V, a level translator (or moving the Si5340 to a 1.8 V I2C segment) is needed.

R1 mirror of the R0 design-flaw notice (project 43, E-053). Raised while debugging the R0 LTC2980 command-NACK; on R0 it's latent (U5 NM, FPGA stranded — confirmed by Daniel on DUT H883774). On R1 it may be live and must be verified.

The flaw

Static-offset I2C repeaters (TCA980x / PCA9517 family) cannot share a bus segment. Each buffer's driven low sits at its ~0.5 V static offset; a second repeater on the same net reads that offset-low as a real bus low and re-drives → the two latch each other low (bus stuck), or at best their offsets stack and destroy V_OL margin for downstream slaves (e.g. the LTC2980, the R0 symptom). Safe sharing requires enable orchestration so exactly one buffer drives at a time.

Why R1 is exposed

R1 fits both TCA9803 buffers that R0 left NM:

• U60 (FTDI I2C buffer) — fitted, EN = FTDI_I2C_EN (R1.0-002).
• U5 (FPGA↔main bridge) — fitted & enabled, EN pull-up R55 4.64k (R1.0-008).

If their B-sides land on the same management-bus segment and both can be enabled simultaneously, R1 reproduces the prohibited two-repeater topology.

Action — verify against R1 netlist (id 16, this project)

1. Trace U60 B-side and U5 B-side nets — do they connect to the same segment?
2. Check the EN logic — can both be asserted at once, or is access mutually exclusive?
3. If shared + concurrently enabled → design issue, likely blocking: gate the enables (one active per access) or remove/relocate one buffer.

Severity is warning pending verification; escalate to blocking if the shared-segment topology is confirmed. Source: project-43 E-053 / E-052; related project-46 E-004 (V_OL/V_IL margin).

I2C walkthrough of MicroHAPS R1 (project 46), same method as R0 (project 43, walkthrough E-042). Evidence: microhaps_r1_netlist.json (full board), r1/SH100008193_R1.0_MicroHAPS_BOM.csv (Reference/Part/Special=DNI), schematic r1/SH100008193_R1.0_MicroHAPS_Schematic.pdf (sheets 4 + 7), and the SH100008193_R1.0 DesignLog. No live R1 bus scan available.

Architecture (R1) — two buses, now properly buffered

• Bus A — management (I2C_SCL0/SDA0), the central hub. FTDI buffered in via NEW U60 (TCA9803, VCCA/VCCB = P3V3_STBY, EN = FTDI_I2C_EN). FPGA + Si5340 buffered off via U5 (TCA9803, A-side=main bus @P3V3_STBY, B-side=FPGA_I2C@P3V3_VCCO). Direct on the bus: LTC2980 U15, EEPROM/IDPROM U4, TMP441 U3, fan U55, PMIC PU8, and the new debug header J22.
• Bus B — FPGA mux trunk (MUX_I2C, FPGA J10/J11) → PCA9547 U47 (0x70) → 8 channels (HT3_0..3, QSFP_0/1, MGB_0/1). MGB channels now translate 3.3↔1.8 V via U54/U50 = TCA9803 (was PCA9306).

R0 → R1 diff (verified against DesignLog)

Four checks (R1)

1. Pull-ups — main bus: dedicated pull-up → P3V3_STBY (U60 B-side) ✅ (fixes E-044); FTDI seg → P3V3_STBY ✅; mux trunk → R571/R572 1k ✅ (R0 gap fixed); 8 mux channels 4.7k → P3V3_VCCO ✅. MGB 1.8V OUT pull-ups R430/R429 = DNI (TCA9803 removes pull-ups on one side per R1.0-016 — confirm the 1.8V side is pulled by the module/IN segment). FPGA_I2C segment pull-up not located in the reduced netlist — confirm on schematic.

2. Voltage domains — main bus / FTDI / mux trunk = 3.3V; MGB low side = 1.8V via TCA9803 U54/U50 (dual-rail VCCA 3.3 / VCCB 1.8 ✅). ⚠️ See linked finding: Si5340 now sits on the 3.3V FPGA_I2C segment with no translator, but its control straps still pull to P1V8_CLK (1.8V) ⇒ its I2C I/O is likely 1.8V → possible relocated E-045 over-voltage.

3. SCL/SDA orientation — SCL↔SCL / SDA↔SDA consistent through U60/U5/U54/U50/U47 and all channels. FTDI now uses FTDI_I2C_SDA0 (U10.27+U10.28 tied, MPSSE) into U60. ✅

4. Addresses — Bus A: PU8 0x31 (was 0x30 — conflict fixed), EEPROM/IDPROM 0x50 (AT24MAC402, + hidden 0x30 WP now clear of PU8), TMP441 0x4C, LTC2980 0x5B base (dies 0x5C–0x64), fan 0x57, Si5340 0x74 (now on FPGA_I2C). Bus B: mux 0x70, MCP3424 0x68, MGB clock 0x60. 0x30 conflict resolved ✅. (R0's unexplained 0x58 scan responder can't be checked without an R1 scan.)

Net result

R1 fixes the R0 I2C findings: E-043 (FPGA now bridged via fitted U5), E-044 (main bus now has a dedicated P3V3_STBY pull-up + proper buffering), 0x30 conflict (PU8→0x31), and removes the reversed CLKA passFETs. One concern carried/relocated: the Si5340 1.8V I2C on the 3.3V FPGA_I2C segment — see linked finding. Netlist stored as R1-I2C (project 46).

R1 swapped U50/U54 (the MGB I2C level translators) from PCA9306 to TCA9803, but their TCA9803 VCCA (A-side supply, pin 1) and EN (pin 5) remain on the old PCA9306 VREF bias network — P3V3_VCCO through series R522/R542 plus a cap, not tied to a rail. Is the A-side of these repeaters adequately supplied, or must the VREF network be replaced with a direct VCCA-to-rail connection (R522/R542 → 0 Ω / removed)? Raising as gating because it affects both MGB management-bus translators and the A-side I2C may not come up.

Receipts: ["observation:5", "net:PCA9306_VREF2_MGB2A_2", "net:PCA9306_VREF2_MGB2A_1", "component:R522", "component:R542", "component:U5", "datasheet:TCA9803DGKT"]

— odb board 2, concern CON-001

Design-log corroboration (R0.0→R1.0 log, tab 'R0.0 --> R1.0', severity-3 entry): the U50/U54 PCA9306→TCA9803 swap was a deliberate space-saving change — quote: "PCA9306 package is 3x4mm and requires external resistors on both sides. TCA9803 package is 3x3mm and remove the pull-ups on one side. Will replace U50 and U54 with TCA9803." The SAME entry records an OPEN action item: "Will investigate full footprint impact that this might have." CON-001 / OBS-5 is the concrete answer to that open item: the TCA9803 VCCA (pin1) + EN (pin5) were left on the old PCA9306 VREF series-R node (3V3 via R522/R542 + cap), not on a rail — precisely the "full footprint impact" the designer flagged but did not close. The footprint-impact investigation should explicitly cover the VCCA/EN supply: tie VCCA directly to the A-side rail and set R522/R542 to 0Ω / remove them.

Subject: CON-001

— odb board 2 (comment)

Design-log context (R0.0→R1.0, severity-2 entry) for the FPGA_I2C nets flagged as 'pull-up missing': quote — "There was no filter on this bus in R0.0. Will scope the signals. The FPGA_I2C_SCL/SDA0 are functioning as intended, but there is some ringing on the falling edge. This ringing is not present on MUX_I2C_SCL/SDA, so will add the same filter to FPGA_I2C_SCL/SDA0." This explains the FPGA_I2C_SCL0_R / SDA0_R 'R' nets that I2cPullupMissing flags — they are the deliberately-added RC falling-edge filter nodes (series R), not missing pull-ups. OBS-6's on-board pull-up question still stands for the management trunk, but the FPGA_I2C*_R flags are a by-design filter, not a defect.

Subject: observation:6

— odb board 2 (comment)

Design-log R0.0→R1.0 digest (substantive entries from SH100008193_R1.0_KU5P_Generic_Tester_DesignLog.xlsx, tab 'R0.0 --> R1.0'): (1) sev3 — U50/U54 PCA9306→TCA9803 swap for size + to drop one side's pull-ups; flagged "investigate full footprint impact" [→ CON-001 / OBS-5, VCCA/EN on the stale VREF node]. (2) sev2 — add an RC falling-edge filter to FPGA_I2C_SCL/SDA0 (ringing seen in R0), matching MUX_I2C; this creates the _R nets [→ OBS-6]. (3) sev4 — replace a PMOS with the intended NMOS (change R1.0-017). (4) sev1 — regenerate missing teardrops on some lines. (5) sev3 — add plane obstruct/keepout and connect with traces as needed. The remaining ~28 R0→R1 log rows are severity/date stubs with no description text in the sheet. Source path: C:\tmp\claude\testdevelopment-snps-microhaps\docs\main_pcba\SH100008193_R1.0_KU5P_Generic_Tester_DesignLog.xlsx

— odb board 2 (comment)

Trace cross-check: OBS-7 independently rediscovers the existing BLOCKING R2 item E-002 ("Replace open-drain TDO buffer U9"). E-002 carries the full RCA — SN74AUP1G07 open-drain @1.8V + R139 10K→3.3V, RC τ ≈ 10K×~20pF → ~440 ns edge, so JTAG TDO read-back fails above ~1 MHz (target ≥12 MHz); R2 fix = SN74AXC1T45 dual-rail translator. So OBS-7's "verify edge rate at full TCK" is CONFIRMED: it DOES fail at full TCK — this is blocking, not merely a verify-item. IMPORTANT counter-example to FR-007 (downgrade open-drain-with-pull-up to warning): the pull-up IS present here (R139) yet the part is blocking — a weak 10K pull-up does not rescue the edge rate. FR-007 must gate on the RC edge budget vs the bus clock, NOT on pull-up presence alone.

Subject: observation:7

— odb board 2 (comment)

Trace cross-check: CON-001 EXTENDS the prior R1 I2C walkthrough E-003, which recorded the MGB translator swap as "PCA9306 → TCA9803 (VCCA=VREF2 3.3V, VCCB=P1V8_VCCO 1.8V)" and treated VCCA=3.3V as acceptable. CON-001 / OBS-5 is the deeper catch: that VCCA "VREF2" node is 3V3 through series R522/R542 (the old PCA9306 bias network) plus a cap — not a direct rail. The prior walkthrough saw the voltage but not the series resistance, so it didn't flag that the active buffer's VCCA is not a low-impedance supply. Recommend folding this into E-003's MGB-translator row and the design-log open item "investigate full footprint impact".

Subject: CON-001

— odb board 2 (comment)

CORRECTION — OBS-7 refuted. JTAG TDO must be driven push-pull (point-to-point, single driver); an open-drain buffer cannot be used on it. U9 (SN74AUP1G07, open-drain) on JTAG_TDO_3V3 is therefore a real drive-type ERROR regardless of the R139 pull-up — the pull-up only yields a slow RC high, not a valid push-pull high. The deterministic OpenDrainBusContention ERROR was right; OBS-7's "deliberate level-shift, verify-item only" was an over-reconciliation (optimistic dismissal). Authoritative record: engine ERROR + Trace E-002 (blocking, R2 → push-pull dual-rail translator SN74AXC1T45). My FR-007/FR-008 (which tried to soften the open-drain error using pull-up presence / edge budget) are withdrawn for push-pull buses; see FR-009.

Subject: observation:7

— odb board 2 (comment)

Enrichment result (Si5340A datasheet, cached — answers E-004's open question). The Si5340 serial-interface I/O voltage (SDA pin13 / SCL pin14, plus all control/strap pins) is NOT fixed by a supply pin: it is set by the IO_VDD_SEL register bit, selectable as V_DDIO = VDD (1.8V) or VDDA (3.3V) [Si5340A Pin Descriptions + Table 5.14, note "V_DDIO is determined by the IO_VDD_SEL bit, selectable as V_DDA or V_DD"]. The digital-pin abs-max input voltage is referenced to V_DDIO. So "is the Si5340 I2C 1.8 or 3.3V?" resolves to: it depends on the programmed IO_VDD_SEL — a firmware/NVM setting, NOT determinable from connectivity. Board tell: U6's control straps pull to P1V8_CLK (1.8V); for correct operation the strap rail should match V_DDIO, which leans toward IO_VDD_SEL = VDD = 1.8V. IF 1.8V: R1 placing the Si5340 directly on the 3.3V FPGA_I2C segment over-voltages its I2C pins (rated ~V_DDIO+0.3 ≈ 2.1V, driven to 3.3V) → E-004 is a real defect; and R0's reversed Q22/Q23 passFETs (project-43 E-045) forward-bias their NMOS body diodes from the 3.3V main bus into the 1.8V pins (~2.7V) → same over-voltage class. DEFINITIVE CLOSE needs the Si5340 IO_VDD_SEL value from the device config (.slabtimeproj / NVM) — confirm with Synopsys (Martin Wang). If IO_VDD_SEL = VDDA (3.3V), both E-004 and the Q22/Q23 concern resolve clean.

Subject: E-004

— odb board 2 (comment)

PU10 (P1V8_MGTVCCAUX LDO) feedback node P1V8_MGTAVCCAUX_FB — a high-impedance ~0.8 V reference node — is routed off the regulator on sheet 13 across to the LTC2980 power-manager region on sheet 10, where it dead-ends at the margining/servo resistors R304 (15k), R307 (6k04) and R308 (24k9). All three are DNI (not installed), so the LTC2980 closed-loop margining on this rail is unpopulated and PU10 runs open-loop at its fixed R560/R561 = 1.82 V setpoint. The concern: an unterminated high-Z FB copper stub running to a distant sheet/region acts as a noise-pickup antenna on the regulator's most sensitive node. Confirm the as-routed FB trace length is acceptable for stability/noise; and flag that if anyone ever populates R304/R307/R308 to enable LTC2980 margining of this rail, the FB routing and divider interaction must be re-reviewed.

Receipts: ["component:PU10", "net:P1V8_MGTAVCCAUX_FB", "pin:PU10.3", "schematic:PU10", "component:R560", "component:R561", "component:R304", "component:R307", "component:R308", "datasheet:TPS7A8101DRBT", "principle:high-impedance-feedback-routing"]

— odb board 6, concern CON-001

All four HT3 DUT-interface I2C channels (HT3_0..3) place an RC low-pass on the PCA9547 mux's DOWNSTREAM open-drain channel pins: a series 32 ohm (RN73R1ETTP32R0F50) toward the Samtec connector plus a 100 pF shunt to GND (KGM05AR71E101KH) sitting directly on the mux/pull-up node, with a 4.7 k pull-up (CRCW04024K70FKED). Refs: HT3_0 R43/R44+C26/C27 (J16); HT3_1 R49/R50+C29/C30 (J18); HT3_2 R52(+)+C34 (J17); HT3_3 R53(+)+C36 (J19). Because I2C HIGH is made passively by the pull-up, no driver strength helps the rising edge, so the 100 pF on the bus node gives t_r approximately 0.854.7k100pF = ~400 ns from the cap ALONE - already exceeding the 300 ns Fast-mode (400 kHz) budget before any connector/cable/DUT capacitance is added. Bring-up firmware (crps.py) states the I2C controller uses a 400 kHz bus, so these filters preclude reliable 400 kHz operation on the DUT channels and even consume ~40% of the 1 us budget at 100 kHz. Note the cap is on the WEAK mux side; the upstream FPGA<->mux segment (MUX_I2C, R486/C710, 1 k pull-up R572) uses the opposite, correct arrangement - cap at the FPGA pin, series-R toward the load - so the better pattern was clearly available and was not applied downstream. Recommended resolution: remove the shunt caps (or cut to a few pF), and/or strengthen the pull-ups, or formally confirm the DUT I2C is intended to run <=100 kHz. Decide before HT4 adapter bring-up.

Receipts: ["net:HT3_0_I2C_SDA_R", "net:HT3_0_I2C_SCL_R", "net:HT3_1_I2C_SDA_R", "net:HT3_1_I2C_SCL_R", "net:HT3_2_I2C_SDA_R", "net:HT3_3_I2C_SDA_R", "component:U47", "component:R43", "component:C27", "component:R465", "net:MUX_I2C_SDA_R", "component:R572", "component:C710", "principle:i2c-rise-time-budget"]

— odb board 6, concern CON-002

U47 (PCA9547BS) uses an I2C-PROGRAMMED 8-channel I2C mux to fan the host bus (MUX_I2C, mastered by FPGA U1 and shared with the MCP3424 ADC U16) out to HT3_0..3 DUT channels plus QSFP_0/1 and MGB_0/1. Two architectural costs make this a poor fit for a test fixture: (1) Firmware complexity — every downstream access needs a mux channel-select write first, plus channel-state bookkeeping, and the mux itself must be reached over I2C to talk to any I2C device (bootstrapping). (2) Poor fault isolation — all channels share the single upstream segment, so any downstream device that hangs holding SDA or SCL low (a DUT not yet powered/booted, or in an error state — the normal case for a tester) wedges the ENTIRE upstream bus, including unrelated ADC (U16) monitoring. The master cannot deselect the stuck channel, because deselecting requires an I2C write on the now-wedged bus. The only recovery is asserting MUX_I2C_RST_N (U47.24, driven by FPGA GPIO U1.F13 via 0R R474, 1k pull-up R471). That reset is on a dedicated GPIO so escape IS possible, but it is a global hammer: it drops all 8 channels at once and disturbs every other in-flight transaction, badly complicating error-handling/retry logic. On the high-pin-count XCKU5P, repurposing lower-priority FPGA I/O as dedicated per-channel I2C (or per-channel buses) would have given per-DUT fault isolation, removed the mux as a shared single point of failure, and eliminated the select-before-access overhead entirely. Recommend evaluating dedicated per-channel I2C for the next spin and for the HT4 adapter program.

Receipts: ["component:U47", "net:MUX_I2C_SDA", "net:MUX_I2C_SCL", "net:MUX_I2C_RST_N", "pin:U47.24", "pin:U1.F13", "component:U16", "component:U1", "component:R471", "component:R474", "net:HT3_0_I2C_SDA_R"]

— odb board 6, concern CON-003

P1V8_MGTVCCAUX is always-on: PU10 (TPS7A8101 LDO) is sourced from P3V3_G (3.3V STANDBY at PJ1), so the FPGA's GT transceiver-auxiliary supply is energized whenever standby power is present — while VCCINT (P0V85) and the GT analog supplies MGTAVCC (P0V9) / MGTAVTT (P1V2), all off the switched P12V, are at 0V. Is this acceptable for the XCKU5P? Concerns: (1) it is out of the recommended UltraScale+ power-on order (core -> VCCAUX -> GT supplies together); (2) applying 1.8V to MGTVCCAUX while VCCINT=0 drives continuous leakage through the device's internal ESD/clamp structures (24/7 standby power + long-term reliability); (3) the MGTVCCAUX-vs-MGTAVCC/MGTAVTT voltage difference in this state (1.8V vs 0V) must be checked against the DS922 absolute-max inter-rail delta-V. Recommend gating MGTVCCAUX with the rest of the FPGA supplies (move PU10 to the switched domain, or have the LTC2980 hold it off in standby) unless DS922 confirms always-on-while-others-off is tolerated.

Receipts: ["power_tree (board 6): P1V8_MGTVCCAUX <- VFLTR_P3V3_MGTVCCAUX <- P3V3_G via L10, produced by PU10 (TPS7A8101) — role_layer; P3V3_G enters at connector PJ1 as a standby rail.", "VCCINT (P0V85_VCCINT) + P1V2_MGTAVTT via PU7, P0V9_MGTAVCC via PU6 — all sourced from P12V (switched/main), so 0V in standby.", "PU10 enable net P1V8_MGTVCCAUX_EN connects to R367/R368 -> P1V8_MGTVCCAUX_EN_R (LTC2980 manager U15) — sequencing intent present but overridden by the standby source.", "Subjects: net P1V8_MGTVCCAUX; U1 (XCKU5P-1FFVB676E); PU10 (TPS7A8101DRBT).", "Verify: Xilinx DS922 (Kintex UltraScale+ power-on/off sequencing + abs-max inter-rail delta-V) and UG580 (UltraScale PCB design)."]

— odb board 6, concern CON-004

JTAG is DISABLED by default and the external XJTAG port is not independent. JTAG_FTDI_EN_N idles HIGH (R133 10k→P3V3_STBY; the GND pull-down R134 is DNP) → U8 (SN74AXC4T245) OE deasserted AND PQ1 off (U9 TDO buffer unpowered) → both the forward path (TCK/TMS/TDI via U8) and the TDO return (via U9) are off until the FT4232 is enumerated and drives EN_N low (U10.30). Separately, JTAG source selection (XJTAG_SELN, U48.1) is driven ONLY by the external dongle (J20.11 + R502 1k pull-up) with no FT4232 connection. So selection (dongle-only) and enable (FT4232-only) do not compose into arbitration: a plugged XJTAG dongle always wins selection but still needs the onboard FT4232 powered/enumerated/firmware-configured to enable the buffers. Is this intended, or should the buffers default-enabled (populate R134 / EN_N default low) and/or the XJTAG dongle self-enable (also assert EN_N) so the external boundary-scan port works independently and the FPGA is JTAG-accessible before USB host configuration? = R1 carries this beyond E-002/E-005; proposed R2 fix in obs#47.

Receipts: ["obs#47 (JTAG bus full walk)", "JTAG_FTDI_EN_N: R133=10k to P3V3_STBY (pull-up), R134 (GND pull-down) = DNP in populated BOM", "U8 SN74AXC4T245 OE on pins 14/15 = JTAG_FTDI_EN_N", "PQ1 SSM3J328R: gate=JTAG_FTDI_EN_N, drain=JTAG_BUFFER_VCC_Q=U9 VCC (power-gates the TDO buffer)", "XJTAG_SELN=U48.1 driven by J20.11 (HTST-110 dongle) + R502 1k pull-up; no FT4232 net on it", "U10.30 (FT4232 ch-D) is the only driver of JTAG_FTDI_EN_N", "SN74AUP1G07 datasheet: Ioff/partial-power-down (U9 power-down legal)", "Trace E-002 / R0 E-038 (open-drain TDO U9)"]

— odb board 6, concern CON-005

D2 (BAV99 dual-diode rail clamp) is tapped on the CONNECTOR side of the series resistor, so instead of protecting the fan PWM line it becomes a fault-injection path into the standby rail. Topology: U55 (MAX31760) PWM out -> FAN_PWM (R510 pull-up) -> R511 (series) -> FAN_PWM_OUT -> J21.4 (fan header), with D2.3=FAN_PWM_OUT, D2.2=P3V3_STBY, D2.1=GND. Because D2's tap sits on the bare J21.4 node with R511 on the far (internal) side, there is NO series impedance between the connector and the clamp. At J21, P12V (pin2) is one position from FAN_PWM_OUT (pin4); a P12V->PWM short (bent pin / debris / cable fault) puts ~12V on FAN_PWM_OUT, which forward-biases D2's pin3->pin2 diode straight onto P3V3_STBY, current-limited only by the diode. That drags the entire standby domain (I2C buffers U5/U60, the MAX31760, monitoring, EEPROM, etc.) toward 12V and destroys it before D2 fails open. The same board does the TACH channel CORRECTLY: D3 (BAV99) clamps FAN_TACH_1, which is BEHIND series R513 (J21.3 FAN_TACH_IN -> R513 -> FAN_TACH_1 -> D3), so a connector fault is current-limited by R513 before reaching the clamp. Fix: move D2's center tap to the FAN_PWM node (between R510 and R511) so R511 current-limits any connector fault into the clamp -- i.e. make PWM match the TACH topology already correct on this board. (Note: BAV99 is also a switching-diode rail clamp, not an IEC-61000-4-2 ESD device.)

Receipts: ["component:D2 (BAV99)", "pin:D2.3=FAN_PWM_OUT", "pin:D2.2=P3V3_STBY", "pin:D2.1=GND", "net:FAN_PWM_OUT (pins: D2.3, J21.4, R511.2)", "component:R511 (series, FAN_PWM<->FAN_PWM_OUT)", "component:R510 (pull-up on FAN_PWM)", "component:U55 MAX31760 (FAN_PWM driver, U55.6)", "pin:J21.4=FAN_PWM_OUT", "pin:J21.2=P12V (adjacent connector pin)", "CONTRAST correct pattern: component:D3 (BAV99) on net:FAN_TACH_1 behind component:R513 (J21.3 FAN_TACH_IN -> R513 -> FAN_TACH_1 -> D3)"]

— odb board 6, concern CON-006

The fan header's +12V (J21.2) connects directly to the main board P12V rail with no fan-dedicated current limit / eFuse / fuse. P12V is the raw board rail: it is the INPUT of every buck regulator (PU4 MPM54504, PU5 MPM3630, PU6 MPM3683, PU7 MPM3690, PU8 MPM3695), the INPUT of the board's two TPS259540 eFuses (UP1/UP5, pins 3/4), and arrives from the input power connectors PJ1/PJ2 -- all the same net as J21.2. The TPS259540 eFuses do NOT protect the fan: they protect only the mezzanine outputs (UP1.5=P12V_OUT_MGB2A_2, UP5.5=P12V_OUT_MGB2A_1). So a fault at the fan connector -- a fan stall/overcurrent, or a P12V short to an adjacent J21 pin (GND, or FAN_PWM_OUT via the D2 path into P3V3_STBY) -- is dumped onto the unprotected main 12V rail and collapses/faults the entire board 12V domain, with no isolation. The protective pattern (eFuse) is clearly available and applied elsewhere on this very board (mezzanine 12V), but was not applied to the off-board fan tap. Should the fan +12V be given its own current limit (eFuse / polyfuse / fused tap) like the mezzanine outputs, so a fan/cable fault cannot take down the system rail?

Receipts: ["pin:J21.2=P12V", "net:P12V (raw main 12V rail)", "component:UP1 TPS259540 (IN P12V pins 3/4 -> OUT P12V_OUT_MGB2A_2 pin 5)", "component:UP5 TPS259540 (IN P12V pins 3/4 -> OUT P12V_OUT_MGB2A_1 pin 5)", "regulator inputs on P12V: PU4 MPM54504, PU5 MPM3630, PU6 MPM3683, PU7 MPM3690, PU8 MPM3695", "input connectors on P12V: PJ1 (pins 10/11), PJ2 (pins 5/6/7/8)", "related: D2 path (P12V->FAN_PWM_OUT short forward-biases D2 into P3V3_STBY) -- see companion concern"]

— odb board 6, concern CON-007

U4 (M24C02-FMC6TG fitted in layout / AT24MAC402 in BOM — identity UNRESOLVED), the central-bus ID-EEPROM at 0x50 (on I2C_SDA0/SCL0, P3V3_STBY domain), has its write-protect pin (pin 7) left FLOATING. Net N6775165 has exactly two connections: U4.7 and R48 — and R48 is dnp_absent (not installed). R48 would pull WP up to P3V3_STBY (= U4's own VCC, pin 8): i.e. the designed-in strap to ASSERT write-protect. With R48 unpopulated, WP floats. Per the AT24MAC402 datasheet (now on file) section 2.5 + Table 2-2: WP at VCC -> the FULL array is write-inhibited; WP at GND -> normal write operations; if left floating the WP pin is internally pulled down to GND, BUT 'due to capacitive coupling that may appear in customer applications, Microchip recommends always connecting the WP pin to a known state,' and when using a pull-up it must be <=10 kohm. A separate pin note states the internal pull-down 'disengages once biased above ~0.5 x VCC.' So as built: (a) the standard array defaults write-ENABLED, and (b) the protect line is left floating against the manufacturer's explicit guidance, so a coupled transient could push WP through the trip point and make the write-protect state non-deterministic on the ID-EEPROM. Note: the factory EUI-48 and 128-bit serial live in a separate, permanently write-protected extended block, so the unique MAC/serial is safe; only the soft ID content in the standard 256-byte array is exposed. Questions: (1) Is the ID-EEPROM intended to be field-writable, or should R48 be populated as a <=10 kohm pull-up to VCC to assert full-array protection? If it must stay writable for provisioning, should WP be driven by a GPIO rather than left floating? (2) Resolve M24C02 (layout) vs AT24MAC402 (BOM) first — their WP semantics differ and only the AT24MAC402 datasheet is on file.

Receipts: ["component:U4 (M24C02-FMC6TG fitted / AT24MAC402 in BOM - identity unresolved)", "pin:U4.7 = WP -> net:N6775165", "net:N6775165 = U4.7 + R48 only", "component:R48 population=dnp_absent (R48.1=P3V3_STBY pull-up to U4 VCC; R48.2=N6775165)", "datasheet:AT24MAC402-MAHM-T sec2.5 + Table 2-2 (VCC=full array protected; GND=normal writes; floating->internal pull-down to GND; 'always connect WP to a known state'; pull-up <=10k)", "datasheet:AT24MAC402 note - internal pull-down disengages above ~0.5xVCC", "datasheet:AT24MAC402 - EUI-48 + 128-bit serial in separate, permanently write-protected block", "context: U4 = central-bus ID-EEPROM at 0x50 (I2C_SDA0/SCL0, P3V3_STBY)", "related: M24C02 (fitted) datasheet NOT on file - BUG-027 / part-identity item"]

— odb board 6, concern CON-008

U54 and U50 (TCA9803DGKT active I2C bus buffers) have their A-side supply VCCA (pin 1) fed ONLY through a 200k resistor from P3V3_VCCO, which cannot power an active buffer: U54 VCCA(pin1)+EN(pin5) sit on net PCA9306_VREF2_MGB2A_1, whose only DC path is R542 (CRCW0402200KFKED, 200k) from P3V3_VCCO plus a 100nF decap (C985); U50 is identical on PCA9306_VREF2_MGB2A_2 via R522 (200k) + C970. The TCA9803 datasheet rates supply current at 3.3 mA (family: 9800=0.54, 9801=1.1, 9802=2.2, 9803=3.3 mA), but 200k from 3.3V can deliver at most 3.3V/200k = 16.5 uA - ~200x short - so VCCA collapses to near ground under the part's own draw and the A-side buffer is effectively unpowered. EN is tied to the same starved node, so the device may not even enable. The A-side I2C bus (MGB_0_I2C_SCL/SDA, pulled up to VCCA) would be dead. Root-cause hypothesis: the net name PCA9306_VREF2 indicates a PCA9306 origin (a PASSIVE FET translator whose VREF2 reference pin IS correctly biased through 200k); a swap to the TCA9803 active buffer kept the PCA9306 200k VREF2 bias instead of wiring VCCA to a real rail. Fix: feed VCCA directly from the intended A-side rail (1.8V/3.3V), not through R542/R522. Affects both MGB2 channels (MGB2A_1=U54, MGB2A_2=U50); the third TCA9803 U5 is NOT affected (its VCCA = P3V3_STBY, a regulated rail via PU9).

Receipts: ["U54 (TCA9803DGKT): VCCA pin1 + EN pin5 on net PCA9306_VREF2_MGB2A_1; net members = U54.1, U54.5, R542.2, C985.2 only. R542 = CRCW0402200KFKED (200k), other end P3V3_VCCO. C985 = 100nF to GND. VCCB pin8 = P1V8_VCCO.", "U50 (TCA9803DGKT): VCCA pin1 + EN pin5 on net PCA9306_VREF2_MGB2A_2; net members = U50.1, U50.5, R522.2, C970.2 only. R522 = CRCW0402200KFKED (200k), other end P3V3_VCCO. C970 = 100nF to GND. VCCB pin8 = P1V8_VCCO.", "TCA9803 datasheet (on file): device supply current 3.3 mA (TCA9800 0.54 / TCA9801 1.1 / TCA9802 2.2 / TCA9803 3.3 mA). Max current through 200k from 3.3V = 16.5 uA -> ~200x short of the 3.3 mA draw.", "Contrast - U5 (TCA9803DGKT) is NOT affected: VCCA pin1 = P3V3_STBY, a regulated standby rail (producer PU9), with full decoupling; EN pin5 = N16776794 (its own strap). Confirms the defect is specific to the MGB2 A-side buffers fed off the PCA9306_VREF2 fossil nets.", "Subjects: U54, U50 (TCA9803DGKT); R542, R522 (200k); nets PCA9306_VREF2_MGB2A_1/_2, P3V3_VCCO, P1V8_VCCO, MGB_0_I2C_SCL/SDA."]

— odb board 6, concern CON-009