Case study · PCB design review
We reviewed a CERN board with Probe, then graded it against CERN’s own tracker.
Probe read the board’s ODB++ export — netlist joined with per-pin device function, datasheets and BOM — and returned 62 findings, each traced to a specific net or pin, with a verdict. We then checked its electrical findings against the defects CERN had already found and published.
1,050 components • 6,251 pins • 62 findings, each traced to a net or pin • graded against CERN’s public issue tracker
About Probe
Probe is E-Sharp’s PCB design-review tool. It reads the parts on your designs — netlist, per-pin device function, datasheets and BOM — and turns review findings into cited facts anyone can check. This case is one board, put through exactly that.
The board
A serious board, with a public defect history
The DI/OT Zynq UltraScale+ System Board is the crate controller at the heart of CERN’s Distributed I/O Tier platform — a CompactPCI Serial board that runs a DI/OT crate and talks to up to eight peripheral boards over White Rabbit, Gigabit Ethernet or fieldbus. It is published through the Open Hardware Repository, and it is real production hardware: five revisions since 2019, the latest built in a run of 30 units in 2026.
It is also dense — a Xilinx Zynq UltraScale+ MPSoC with 8 GB of ECC DDR4, 1,050 components and 1,157 nets across 14 copper layers, and twelve supply rails from 0.6 V to 12 V. Two things make it a fair test of a review tool. It is genuinely hard — the kind of board where intent defects hide in plain sight. And its defects are independently recorded: CERN tracks issues per revision in a public tracker, so a reviewer’s claims can be graded against ground truth rather than opinion.
What Probe reads
Netlist joined with per-pin device function, datasheets and BOM — not just copper and geometry. A netlist check confirms the board matches what the designer drew; Probe reads the datasheets to check the drawing does what the designer intended.
Geometric and DFM checks are left to the tools built for them. Probe targets the intent and behaviour defects those tools can’t see.
What Probe returned
62 findings, each traced to the board
Probe concluded every applicable rule — 37 deterministic checks and 955 guided instances — and reported 62 findings, 55 of them open electrical findings that gate the board’s Green verdict. Each finding names its subjects: the exact nets and pins it rests on, and the evidence behind it. The output isn’t a score; it’s a verdict a design owner can act on.
The 62 span 10 major findings — several serious enough to force a respin — and a tail of minor notes and confirmations, and every electrical finding is corroborated against the netlist and BOM, evidence you can open, not an alert to triage. That is the difference from a checker that buries one real fault under a screen of false positives.
The verdict was clear: the board is not clean, and not to be presented as releasable until the findings are resolved. Probe concluded every applicable rule across the board and reported 10 major findings — several serious enough to force a respin. And where a check couldn’t be settled from the design alone, it didn’t guess: it set the question aside and recorded exactly what evidence would answer it.
Six real defects that ERC and DRC pass
A sample of what Probe found. The copper matches the schematic on every one — a rule check sees nothing wrong. They are wrong at the level of intent, the level Probe reaches by joining the netlist to the parts’ own datasheets. Each would have shipped on a clean ERC and DRC pass.
Ethernet cannot transmit
The RGMII transmit clock lands on the PHY’s TX_CLK output (pin 59); the pin it belongs on, GTX_CLK (33), is left unconnected. Probe read what pins 59 and 33 actually are on the PHY — the interface cannot send a packet.
Two I²C buses swapped
The monitoring bus has SCL and SDA on each other’s processor MIO pins, so the controller can’t drive it; the backplane service bus is crossed at the mux.
A BOM code that means 12 V
Three resistors carry a part code for 210 Ω against a value of 210 kΩ. Built by part code, one would drive a 5 V regulator to about 12 V.
Thermal shutdown that won’t latch
The over-temperature outputs disable the regulator that powers the temperature sensors themselves — so the board power-cycles instead of latching off.
USB resets the processor
With USB connected, a push-pull translator output drives PS_SRST_B through a 0 Ω resistor, against the open-drain supervisor and the reset button.
DDR4 rails out of order
VPP comes up after VDD/VDDQ, by the designer’s own sequencing note and the enable chain — where Micron requires VPP first or together.
Graded against CERN’s public tracker
To grade Probe honestly, we set its findings against CERN’s own list — not our own judgement. Of the 13 electrical defects CERN found on this revision and fixed in the next:
Where the review stops
Four that a file-based review can’t reach
Four of the 13 sit outside what a review of the design files can see — a requirement stated nowhere on the board, a bench measurement, a layout-domain tuning, and a feature request. Probe didn’t raise them, and doesn’t claim to. Naming that boundary is part of trusting the tool.
The four, and what they are
- A system-level requirement — a PHY that had to sit on a specific interface for timestamping. No document on the board states it, so nothing on the board could reveal it.
- A start-up inrush — a regulator tripping over-current on power-up, found on the bench (0.84 A against 0.72 A). An inrush check Probe doesn’t yet run.
- A signal-integrity tweak — SD-card clock termination, tuned against particular card brands.
- A feature request — a power-cycle trigger CERN wanted, not a wiring fault.
Why that matters
- A boundary, not an oversight. A requirement no schematic encodes, a bench-measured transient, a layout-domain tuning and a wish-list item — none is a connectivity or datasheet fact the design files carry.
- No invented answers. Where Probe has no grounding it stays silent, or sets the question aside and records what would settle it — it does not fill the gap with a guess.
- Verifiable end to end. Because CERN’s tracker is public, every claim here — what Probe raised and what it left — can be checked against their issue numbers.
How it works
Reads the parts, not just the rules
Grounded in real design data
Every finding links to specific nets and components. Probe joins the netlist with per-pin device function, the datasheets and the BOM — so it reviews what the parts actually are, not just how the copper is drawn.
A verdict, and an honest ledger
Findings carry severity and state, and gate a clear release verdict. Where the facts don’t yet exist — questions that only the built board can answer — Probe records them as a bring-up checklist, not as a pass.
Pre-layout to post-layout
Probe can review from schematic and BOM alone, before layout — so each revision is re-checked against the datasheets as the design changes, not only at the end.
Self-hosted, searchable across designs
Runs on your own infrastructure. Findings are stored against the parts and inherited by every board that carries them, so what you learn on one design carries to the next.
Learn more: Probe — PCB design review with evidence → Why ERC and DRC are not enough →
Board and revision history: CERN Open Hardware Repository — DI/OT Zynq UltraScale System Board wiki. Findings graded against CERN’s public issue tracker.
The tool behind this review
See how Probe reads a board
Probe reviews the schematic and BOM against intent — the defects ERC and DRC don’t see — and traces every finding to the net, pin or datasheet behind it.
