Replaces the PLL-fed 54 MHz `capture` domain, which oversampled the GC's
27 MHz EXI clock 2x and so put BIT-level timing across a CDC boundary: the
engine's view of the clock lagged the pin by 2 FFSynchronizer stages plus a
register (~55 ns) against a 37 ns bit time, so MISO came out ~2 bits late and
the GC read 0x17 as 05 C0. No amount of oversampling fixes that -- 54 MHz
gives only 2 ticks per bit and the part cannot close the 81 MHz that 3x needs.
The engine is now clocked by the pin itself (pin 44 = global buffer input net
6, no board change), making MISO clock-to-Q. ExiCapture creates four domains:
exiclk (posedge, samples MOSI), exiclk_n (negedge, drives MISO), both
async-reset by CS, plus reset-less exififo_w/exififo_r for the byte FIFO sides
-- reset-less because resetting one side of an AsyncFIFO desynchronises its
gray pointers, and posedge because AsyncFIFO has a posedge-only reset CDC
internally and cannot host a negedge side.
Also removes the SPRAM response FIFO. The DMA read was one byte late because
the round trip did not fit the protocol's turnaround byte; the arbiter already
exposed valid/ready, so the FIFO bought a cycle of latency and nothing else.
The response is handled outside the FSM (the reply lands in RHDR_PAD, not
SPRAM_STREAM) with a one-entry hold for when tx_fifo is momentarily full.
The PLL was left instantiated but unused after the rewrite; removing it frees
the hard macro and pin 35 (which stays unconnected only because the board is
already built that way). This is what lifted the pass rate:
domain target before after
clk (sync) 24 MHz 28.1-30.2 26.4-32.2 8/8
capture_clk 54 MHz 2 of 8 PASS (gone)
EXI pin domain 27 MHz -- 45.6-64.4 8/8
Best seed 3: clk 32.18 MHz, EXI 55.86 MHz. The binding constraint has FLIPPED
-- `clk` (1.10-1.34x) is now tighter than the EXI domain (1.69-2.39x) -- so
synth.py ranks seeds by worst RELATIVE margin, not by the EXI number.
synth.py could not have scored this design at all: it required the vanished
capture_clk, and its regex '(\w+)' cannot match nextpnr's exi_clk_$glb_clk
(no $ in \w). add_clock_constraint was also landing on the wrong net -- under
EXI_J4 the clock is the AND of two pads, not either pad -- so nextpnr silently
fell back to a 12 MHz default and under-optimised the whole EXI domain.
Testbenches:
- spi_mode3_slave had lost its testbench entirely in the rewrite. Restored
with a strict Mode 3 master (changes MOSI on the falling edge, samples MISO
in the clock-low phase) and MUTATION-TESTED: flipping either clock edge in
the RTL makes it fail. Both of those bugs previously reached silicon
against a lax master that parked MOSI well before the edge.
- exi_j4 T2/T3 returned [0,4,2,2]. Real bug: the engine latches the FIFO head
at each byte boundary, so a 2-byte command header leaves only ONE drain
slot. DEVID streamed zeros until CS and left two stale bytes -- one too
many -- so the NEXT enumeration came back a slot late. DEVID now pushes
exactly four bytes and stops. Register-space reads may still over-push:
their 4-byte header gives three drain slots.
- Dead ports removed from SPIMode3Slave (hdr_bytes, frame_start, cs_active,
byte_idx) and the mode2 parameter is gone -- there is one correct edge
convention and it is now enforced by tests.
All 14 module suites pass, plus bba_top at EXI_HALF=1/2/8.
CLAUDE.md: rewrote the clocking, CDC inventory and module tables; marked the
2026-09-30 capture_clk measurements historical; and corrected the line in
"Critical Protocol Notes" that still stated the INVERTED edge convention
("MOSI sampled on falling, MISO driven on rising" is Mode 2) -- the original
implementation followed that doc error.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bba_top wired ClockSignal("sync") to ClockSignal("exi"), so the two "domains"
were always the same physical clock net. Everything between them -- six
AsyncFIFOs and three PulseSynchronizers -- was pure latency and logic for a
crossing that did not exist.
* the six AsyncFIFOs become plain SyncFIFOs
* the three PulseSynchronizers become wires
* BBARegisterFile and ExiCapture move from m.d.exi to m.d.sync
* the exi ClockDomain is gone; HFOSC drives sync directly
The SPRAM request write port is also combinational now. A registered w_en
costs a 24 MHz cycle, and the protocol's turnaround byte (~296 ns at 27 MHz)
has no cycles to spare.
Passing: bba_register_file, spram_arbiter, rx_frame_assembler, tx_frame_drain,
w5100_parallel_master, uart_shell, status_panel. bba_top at EXI_HALF=1
(27 MHz, the hardware rate) passes device ID, PAR read/write, NWAYS, RWP and
the 34-byte TX frame.
STILL OPEN: the SPRAM/DMA read is one byte late. Removing the CDC was not
enough -- the remaining round trip is the rx crossing (exiclk->sync, a REAL
CDC, ~125 ns) plus FSM decode plus the spram_req FIFO, arbiter, SPRAM access
and spram_rsp FIFO, which still exceeds the turnaround byte. Next step: now
that it is all one domain, drop the two SPRAM FIFOs entirely and give the
register file a direct request/grant port on the arbiter -- that should take
the round trip to ~2-3 cycles and fit.
exi_capture and exi_j4 testbenches still assert removed behaviour (the CS-fall
flush and the old MISO slot timing) and need rewriting for the clocked engine.
Still WIP -- do not flash.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The TX failure was a TESTBENCH artifact, not a design bug. Between
transactions the bench raised CS for one HP -- 18.5 ns at EXI_HALF=1 -- but
cs_active reaches the exi domain through a 2-stage FFSynchronizer at 24 MHz,
so the register file never saw one transaction end and swallowed the next
one's header as write data. A real host leaves microseconds between
exi_deselect() and the next exi_select(). With a realistic gap the 34-byte TX
frame now matches byte-for-byte at the hardware rate.
At EXI_HALF=1 (27 MHz) bba_top now passes device ID, PAR read/write, NWAYS,
RWP and TX. The one remaining failure is the SPRAM/DMA stream, offset by
exactly one byte.
Root cause of that offset, and it is not architectural: bba_top.py:171 does
m.d.comb += ClockSignal("sync").eq(ClockSignal("exi"))
so exi and sync are LITERALLY THE SAME CLOCK NET. Every AsyncFIFO between
them is pure overhead. The SPRAM round trip pays two needless CDC crossings
(~6 cycles, ~250 ns) on top of the arbiter and SPRAM access, giving ~375 ns
against the ~170 ns the protocol's turnaround byte actually leaves once the rx
crossing is subtracted. Register reads are unaffected because their response
is immediate; only SPRAM is late.
Fix direction: merge the two domains and replace the exi<->sync AsyncFIFOs and
PulseSynchronizers with plain SyncFIFOs/signals. That removes the latency,
drops a lot of logic, and cannot change behaviour because the clocks are
already identical.
Known failing, both testing removed behaviour rather than new bugs:
* exi_capture's own testbench asserts the CS-fall flush and the old MISO
slot timing; the flush no longer exists (header pops drain the FIFO).
* exi_j4's T3 re-enumerate is off by a byte.
Still WIP -- do not flash.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Replaces 54 MHz oversampling with a slave clocked by EXI CLK itself:
exiclk posedge sample MOSI (Mode 3 samples on edge 2)
exiclk_n negedge drive MISO (must settle between the master's samples)
CS_N async reset for both
EXI CLK (pin 44) is at die (6,0) = global buffer net 6 on the 5k-sg48, so it
can drive a real clock network with no board change.
This removes the capture domain entirely. Bit-level timing no longer
crosses a clock boundary -- MISO is clock-to-Q instead of 3 ticks of a foreign
clock -- and the only crossings left are the byte FIFOs, which have a whole
byte-time (~296 ns) of slack rather than a fraction of a bit.
AsyncFIFO needs a posedge clock for its internal reset CDC, so the FIFO sides
use reset-less POSEDGE domains on the same pin; the engine pops on the posedge
and hands the byte to the negedge output stage through a register. The FIFOs
must not see CS: resetting one side of an AsyncFIFO desynchronises its gray
pointers.
Two bugs found and fixed along the way:
* one pop per byte boundary is all that is needed -- pops during the header
drain whatever the previous transaction left (replacing the CS-fall flush)
and the turnaround-byte push lands in data slot 0. No slot-threshold or
header-length logic at all.
* rx_byte/rx_valid had to become COMBINATIONAL. Registered, they need one
more clock edge, and after a transaction's final bit the clock stops and
CS rises -- so the last byte of every transaction was lost (a 4-byte write
landed as DE AD BE 00, a 34-byte TX as 15 bytes).
At the HARDWARE rate (EXI_HALF=1, 27 MHz) the device ID, NWAYS, PAR
read/write and the W5100->SPRAM RX path now all pass -- none of which has ever
worked at 27 MHz before. Testbenches now drive the SPI clock with real
delays, since there is no capture domain to count ticks against.
STILL BROKEN: the SPRAM/DMA stream is offset by one byte (its round trip
exceeds the single turnaround byte), and TX lands 15 of 34 bytes. Do not
flash this yet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Hardware speed sweep after the Mode 3 fix: ok=[1,1,1,0,0,0] -- register reads
are CORRECT up to 4 MHz and fail from 8 MHz. The MOSI edge fix works and the
gateware is functionally correct; what remains is a fixed MISO output delay of
~3 capture ticks (~55 ns: 2 stages of input FFSynchronizer plus 1 tick to
register the shift). At 27 MHz that is ~2 bits, which is exactly the observed
NWAYS read of 05 C0 = 0x17 >> 2, and the 250ns-pass / 125ns-fail threshold
brackets the delay at 60-125 ns.
Also records that lowering the EXI clock is not available: Swiss hardcodes
EXI_SPEED_32MHZ in exi_select().
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The docs call this 'Mode 3 (CPOL=1, CPHA=1)' and then describe sampling MOSI
on the FALLING edge. Idle-high plus sample-on-falling is Mode 2. Real Mode 3
samples on the second edge of each cycle, which with an idle-high clock is the
RISING one, and that is what the GameCube does.
Sampling on the same edge the GC drives MOSI latched the PREVIOUS bit, so
every byte arrived one bit late in both directions, at every clock speed:
the 0x80 register-space header byte was read as 0x00, which decodes as a
command-space device-ID query -- so NWAYS reads returned the device ID and the
speed sweep failed at every index. Hardware raw dump, first transaction after
an FPGA reset:
00 00 02 01 01 00 00 00 02 01 01 00 = 04 02 02 00 >> 1
The Pi probe never caught it because that script was written to match this
device, and every simulation testbench drives MOSI many capture ticks before
toggling the clock, so MOSI is stable at BOTH edges and the convention cannot
be distinguished. The bba_top master now models a true Mode 3 master (drive
on falling, sample on rising) so the suite can tell the difference.
SPIMode3Slave(mode2=True) restores the old behaviour for the Pi/J4 probe.
Known remaining issue: at EXI_HALF=1 (27 MHz, 2x oversampling) reads are still
shifted, because the 2-stage input FFSynchronizer costs 2 capture ticks which
at 27 MHz is a whole bit. That is a separate fault and only bites at 2x.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reading one byte and getting 0x00 cannot distinguish 'decode is wrong' from
'reply is late' -- a one-byte window has nowhere for a late answer to show up.
These two probes clock EIGHT data bytes and print every slot, so the position
of 0x17 (NWAYS) or 0x04 (device ID) gives the latency directly, the same way
bit-shift analysis turned 00 00 00 10 into 'correct, 22 bits late'.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
'highest good = 0' meant both 'only index 0 works' and 'nothing works', which
are opposite diagnoses -- the first says oversampling, the second rules it
out. Now reports the per-index map and says NONE explicitly.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bba_top derived its EXI clock from HALF, defaulting to 3.4 MHz against the
real GC's ~27 MHz. At that rate the whole CDC response latency fits inside
one bit time, so the suite passed green on a design that failed on console --
this is how both the wrong-header-format and the TX-pop-threshold bugs
reached hardware with everything green.
HALF is now EXI_HALF-configurable (default 8 for fast regression). At the
real rate, EXI_HALF=1, every read comes back shifted right by ONE BIT:
04 02 02 00 -> 02 01 01 00, NWAYS 0x17 -> 0x0B. That is a bit-level sampling
misalignment, not the byte-level latency chased earlier: at 54 MHz capture
there are only 2 ticks per EXI bit and the 2-stage FFSynchronizer on EXI CLK
costs 2 ticks, a whole bit.
Recorded as an open bug in CLAUDE.md with the measurements.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tx_fifo.r_en popped from txld_cnt >= 2, hard-coded for the old invented
2-byte header where the data phase began at slot 2. The real protocol's
register space uses a 4-byte header, so data starts at slot 4 -- two bytes
were being consumed before the GC clocked any data, and every register read
came back wrong. On hardware: HIPR and NWAYS both read 0x00, and the device
ID returned 01 80 c0 c0 (stale bytes, including our own header command bytes
0x80/0xC0 echoing back out of the FIFO).
The threshold is now derived from byte 0 bit 7, which is exactly what selects
the header form: register space -> 4 slots, command space -> 2 slots.
Also removes the pad-slot filler byte the register file was pushing. That was
compensating for this bug rather than fixing it -- it made the simulation pass
while hardware still failed, which is how it slipped through. With the pop
threshold correct the filler is wrong, and both the unit and integration
testbenches agree without it.
All suites pass: bba_register_file, bba_top, exi_capture, exi_j4,
spi_mode3_slave, tx_frame_drain, spram_arbiter, rx_frame_assembler,
w5100_parallel_master.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Replaces the invented 2-byte header (addr split across both bytes, 2-bit
length field) with the protocol libogc and Swiss actually speak:
command (bit7=0, 6-bit reg) [reg, 00, 00, data] one 4-byte transfer
register (bit7=1, 16-bit reg) [0x80|w<<6, ah, al, 00] + data until CS
This was not an optimisation: the old decoder read Swiss's NWAYS read
(80 00 31 00) as 'write 0x31 to NCRA', and bit 0 of 0x31 is RESET, so every
register read would have reset the device.
Changes:
* 16-bit address; no length field -- register reads and writes now stream
until CS, like the SPRAM path already did
* RHDR_LO starts the SPRAM fetch as soon as the address completes, using
the trailing header byte as the prefetch window the protocol provides
* command space serves EXI regs 0x02/0x03 (interrupt mask/status), the only
two Swiss uses
* EXI_GetID gets its own path: it offers just ONE header byte of warning, so
the first ID byte is pushed the instant byte 0 identifies the query
Two timing subtleties, both found by simulation and commented in place:
* MISO is driven LIVE from the tx FIFO head, so a byte pushed while the pad
byte is on the wire appears in the pad slot. A filler byte is parked
there (MISO is don't-care through the header) so the first real response
lands in data slot 0.
* the prefetch must be one-shot; re-firing while waiting for the pad byte
consumed the register stream early and shifted reads by a byte.
All testbenches updated to the real format and passing: bba_register_file
(7), bba_top (8 incl. the full W5100->SPRAM->GC loop and TX), exi_j4,
exi_capture, spi_mode3_slave, tx_frame_drain, spram_arbiter,
rx_frame_assembler, w5100_parallel_master. gc_bba_test rebuilt against the
new protocol.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Read from the two drivers that will actually talk to this device: libogc
(libdb/uIP/bba.c) and Swiss (cube/patches/bba/bba.c). The implemented 2-byte
header with a 2-bit length field does not match either.
The real protocol has two address spaces selected by bit 7 of byte 0, and no
length field at all -- the data phase runs until CS:
COMMAND (6-bit reg) one 4-byte readwrite; response in byte 3
REGISTER (16-bit reg) [0x80|w<<6, reg>>8, reg&0xFF, 0x00] + data phase
NCRA, IR, NWAYS, RWP, RRP and PAR all live in the register space. The
mismatch is destructive rather than merely non-functional: Swiss reading
NWAYS sends 80 00 31 00, which the current decoder reads as 'write 0x31 to
NCRA' -- and bit 0 of 0x31 is RESET. Every register read would reset the
device. The device-ID query is the one case where the two formats coincide,
which is exactly why enumeration worked on hardware and nothing else would
have.
Also explains the 22-bit response latency measured on console: the trailing
0x00 byte in the real header is the device's prefetch window, and the current
format spends those bits on the length field, leaving zero slack. Adopting
the real format is required for compatibility anyway and recovers ~296 ns of
the ~815 ns deficit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
First on-console run: the Identity suite failed with the device ID reading
00 00 00 10 instead of 04 02 02 00. Bit analysis shows that is an EXACT
match for the correct stream delayed by 22 bits -- the device answers
correctly, just too late for a 32-clock window to catch more than its first
set bit. Not corruption, and not a broken link: response latency.
At EXI index 5 (~27 MHz) 22 bit-times is ~815 ns, which is about what the CDC
chain costs (rx AsyncFIFO capture->exi, register-file decode, tx AsyncFIFO
exi->capture, SPI engine) at a 24 MHz exi clock. The design expects the GC to
hold the clock idle between the header write and the data read so the register
file can prefetch the response; libogc's inter-call overhead alone is not
enough at full speed.
Adds bba_gap_us (default 16 us, busy-waited with CS asserted since we hold the
EXI lock) and a Gap sweep test that reports the minimum clean gap at the
current speed -- which measures the latency rather than guessing at it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sets the PC to 10.0.0.50/24 so the GC test suite's RX test can pass: its TX
test ARPs for that address and the kernel answers ARP for an address it
actually holds, so no listener process is needed. Without it RX fails
legitimately for lack of traffic.
Handles the NetworkManager trap -- NM silently strips a hand-added address
within seconds, so the device is set unmanaged first and handed back on
'down'. Warns that this drops any existing connection on that NIC.
up / down / status / watch, with wired-interface auto-detection (prefers one
with a carrier) and a status readout that flags no-carrier along with the
likely cause: the W5100S rail is gated off GC_ON, so it is dead whenever the
console is off.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
libogc's EXI functions return '1 on success, <=0 on error', but every call
site tested '== 0'. A -1 error return therefore read as success, so a failed
EXI_Lock or EXI_Select would fall through and the subsequent transfer would
produce garbage reported as a misleading test failure rather than an EXI
error. All six call sites now test <= 0.
Also retries EXI_Lock for ~100 ms: it fails outright rather than blocking when
another subsystem holds the channel, and Swiss or a libogc driver may hold it
briefly -- without the retry a transient collision surfaces as a test failure.
Builds clean with devkitPPC 16.1.0 / GCC 16, no warnings: 172 KB .dol.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gc_bba_test/ builds a .dol that drives the adapter over raw EXI from the
console and reports pass/fail per test on the TV, navigable with the pad.
Uses libogc's EXI API against EXI0:2 (Serial Port 1) rather than its bba
network driver: driving the register file directly gives each check its own
verdict, so a failure points at a specific register instead of at
'networking'. Six suites - identity, registers, reset/control, EXI link
integrity (including an EXI clock-index sweep), ethernet TX/RX, SPRAM/DMA
streaming.
Encodes the hardware lessons from bring-up so the app cannot mislead:
* the device ID is a one-shot cleared by the first NCRA reset, so it is
reported SKIP on a re-run rather than FAIL
* TI means the frame reached the W5100, NOT the wire - the TX test says so
* register reads clock exactly the requested length (over-clocking
desynchronises the next transaction)
* TXDATA is written one byte per transaction (eff_addr auto-increments)
.devcontainer/Dockerfile gains the devkitPro gamecube-dev group. devkitPro
publishes no .deb on GitHub, so this uses their installer script against
apt.devkitpro.org -- which is 403 from inside the running container's egress
but reachable from a host-side docker build. Rebuild the container to get it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Regenerating the production files for the V2.1 eFuse rework surfaced two
steps that neither the skill nor CPL_ROTATIONS.md documented, both caught
only by diffing against the previously-shipped CPL:
- --exclude-dnp does not drop 'in_bom no' parts, so J4 and TP1-TP5 landed in
the raw export although the shipped CPL excluded them. Filter to
designators that have a BOM line; the two sets should end up equal.
- kicad-cli emits signed rotations while the correction step's % 360 only
normalises corrected parts. Mixing the two made the diff show 34 phantom
rotation changes (270.0 vs -90.0 is the same angle), burying the 2 real
ones.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The TPS25961's exposed pad is GND and the datasheet requires it be connected
to the GND plane (Table 5-1; package note 3 adds a mechanical requirement).
REVIEW.md claimed this was honoured because the footprint is the _ThermalVias
variant -- but the variant alone connects nothing. hardware/TPS25961.kicad_sym
defined pins 1-6 only, with no pin for the exposed pad, so KiCad had nothing to
map onto footprint pad 7 and left it netless: an isolated copper island under
the chip with its thermal vias going nowhere.
Adds pin 7 (GND, power_in, hidden, stacked on pin 4) to the symbol library, the
cached symbol in exi.kicad_sch, and the U13 instance.
PCB updated and verified: U13 pad 7 carries GND on all four elements (both SMD
rects and both thermal vias), R48 placed, EFUSE_OVLO routed, R49 gone. DRC
reports 0 violations, 0 unconnected pads and 0 schematic parity issues -- the
0-unconnected result is what confirms pad 7 is tied into the GND network rather
than merely labelled. The 4 DRC errors previously dismissed as zone-fill
phantoms on this pad are gone, though zones were refilled in the same pass so
that is not proof of cause either way.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
13 resistors carried Tolerance=5% while their MPN is a UNI-ROYAL 0402WG*F*
part -- F is the EIA code for +/-1% (J is 5%), and LCSC confirms the 1% rating.
The parts are 1%; only the metadata was wrong.
Worth fixing rather than leaving: the same part number appearing with two
different tolerances splits into two BOM lines under any grouping that
includes the field, and it misleads anyone sizing a divider. R48 in the eFuse
ladder was one of these (fixed in a9052c6) and there it was load-bearing --
at a genuine 5% the OVLO worst case reaches 17.05 V, over U3's 17 V limit,
versus 14.42-15.83 V at the correct 1%.
Metadata only; no circuit or part number changes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Redraws the eFuse area with proper wires instead of labels-on-pins, and
simplifies the divider that 228ff03 added.
The first draft split R3 into 12 k + 2.2 k to hit 14.2 k, purely to preserve
the original ~8.9 V UVLO. That bought a fourth resistor and a named junction
net (EFUSE_R3MID) that nothing else touched. The ~9 V UVLO turned out to be
an assumption carried over from the original design rather than a requirement:
U3's minimum input is 4.5 V, so relaxing it to 6.78 V costs nothing and is in
fact less likely to chatter if the GC rail sags.
R46 620 k -> 100 k (C25741) R1: 12V_RAW -> EN/UVLO
R47 100 k -> 12.4 k (C11692) R2: EN/UVLO -> OVLO
R48 NEW 10 k (C25744) R3: OVLO -> GND
R49 removed
R45 100 k -> 33 k (C25779) ILIM 0.52 A -> 1.52 A
OVLO is unchanged at 15.18 V typ (14.47-15.78 worst case) against U3's 17 V
limit, so the simplification costs nothing on the parameter that matters.
Verified: 12V_RAW(R46.2) / EFUSE_EN(R46.1,R47.1,U13.5) / EFUSE_OVLO(R47.2,
R48.1,U13.2) / GND(R48.2,R45.2,U13.4); 152 -> 151 components with only R49
removed; ERC 0 violations.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Implements the values worked out in 6ce7657.
R45 100k -> 33k ILIM 0.52 A -> 1.52 A (clears the 621 mA inrush)
R46 620k -> 150k ladder R1: 12V_RAW -> EN/UVLO
R47 100k -> 10k ladder R2: EN/UVLO -> OVLO
R48 NEW 12k \ ladder R3 = 14.2k: OVLO -> GND
R49 NEW 2.2k /
U13 pin 2 (OVLO) taken off GND and onto the new EFUSE_OVLO net
Verified: netlist shows 12V_RAW(R46.1) / EFUSE_EN(R46.2,R47.1,U13.5) /
EFUSE_OVLO(R47.2,R48.1,U13.2) / EFUSE_R3MID(R48.2,R49.1) / GND(R49.2,R45.2,
U13.4); 150 -> 152 components with none dropped (the malformed-property trap
from the kicad-bom-edit skill); ERC 0 violations.
PCB placement and routing still to do.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Works the TPS25961 fix out from the datasheet rather than from memory, and
re-solves it against resistors already on the BOM.
OVLO: TI's 3-resistor ladder (eq 7/8) -> R46 620k->150k, R47 100k->10k, new
R48 12k + R49 2.2k (=14.2k). UVLO 8.93 V typ, unchanged from today; OVLO
15.21 V typ, 15.81 V worst case. The OVLO ceiling is set by U3 (TPS562201,
4.5-17 V input), not by the eFuse -- that rules out a tempting 3-resistor
solution tripping at 17.24 V.
ILIM: R45 100k -> 33k. 0.516 A sat BELOW the board's own 621 mA inrush, so
the part entered current limiting on every power-on (-> thermal shutdown ->
retries -> latch-off). Inrush control comes from the fixed 5.17 V/ms slew
rate, not ILIM, so raising ILIM costs no inrush protection; it is pure fault
protection at ~27x the measured 56 mA load.
Every value is already stocked and 620k loses its only user: one FEWER unique
part, +2 placements.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The PC's replies are unicast to our own MAC, which it could only learn from
our requests, so the loop is closed independently of any packet capture.
Records the four W5100 fixes it took and the caveat that TI does not mean the
chip transmitted.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
RX_RSR_CHK returned to IDLE when RSR==0 without clearing Sn_IR. SEND_OK
(bit 4) fires after every successful transmit and the RX path only ever
cleared RECV (bit 2), so INT_N stayed asserted; because IDLE tests
~w5100_int_n BEFORE tx_valid, the FSM span IDLE->RX_CHECK->RX_RSR_CHK->IDLE
and TX was starved permanently. Observed on hardware as the first frame
transmitting and every later one never setting TI while RX kept working.
Now clears every Sn_IR bit except RECV, so a frame arriving between the RSR
read and the write still raises INT_N and is served next pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
w5100_rst_n was declared and never driven anywhere -- the pin sat at its init
value of 1 forever. The only reset the chip ever got was the MR software
reset, which arrives over the very bus a wedged chip has stopped answering, so
a wedged W5100 could not be recovered at all: not by NCRA reset, not by
reflashing, not even by reconfiguring the FPGA (RSTn just floats to its R36
pull-up while unconfigured). Only a 12 V power cycle worked.
Init now pulses RSTn low (1 ms, datasheet minimum is ~2 us) and waits the full
post-reset settle before touching the bus. RSTn low time is clamped to
reset_cycles so the testbenches' small values stay reachable by wait_ctr.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The init does MR=0x80 (software reset) then waits reset_cycles before writing
NETLCKR/SHAR/SIPR/socket registers. That wait was 24_000 cycles = 1 ms at
24 MHz, but the W5100S needs the datasheet's 60.3 ms -- our own bus self-test
needed ~85 ms before the chip answered at all.
1 ms is marginal rather than simply wrong, which is why this presented as
intermittent: an NCRA reset sometimes left the chip still resetting while the
init writes landed on it and were silently dropped, leaving it misconfigured
and the bus master blocked. Symptom was a W5100 that wedged after an NCRA
reset -- TX never completing and the UART shell's own 'udp unicast' hanging --
recoverable only by a 12 V power cycle. Note RST_N is never asserted by the
gateware; only the software reset is used, so this wait is the only settle
time the chip gets.
Default is now 2_000_000 = 83 ms. Testbenches pass small values explicitly and
are unaffected.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TX: the TWD fix lands a full 60-byte ARP on the wire, byte-for-byte correct
(previously truncated at 16). TI sets.
RX: a real 342-byte DHCP broadcast from the PC was received in MACRAW mode,
assembled into the SPRAM ring and DMA-read back over EXI. The descriptor
length 0x015A cross-checks exactly against the frame's own IP total-length
field plus the ethernet header, so the assembler's length is confirmed, not
merely plausible.
Also replaces the full-path probe's 'is 08 and 06 somewhere in the buffer'
guess with a real descriptor decode -- it called a DHCP frame an ARP reply.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TXFrameDrain sat in IDLE until it had a length, and the length only reached
tx_ctrl when the NCRA ST bits were written -- after the GC had streamed the
whole frame. So the entire frame had to fit in the 16-deep tx_bytes FIFO, and
BBARegisterFile silently drops bytes when w_rdy is low (SPI cannot
back-pressure). On hardware this truncated frames at exactly 16 bytes: a
captured ARP had 16 correct bytes followed by the frame restarting over itself.
The length is now handed to the drain one cycle after the TWD_HI (0x35) write,
which the GC issues BEFORE streaming data. The drain starts early and blocks
on tx_bytes_r_rdy, consuming bytes as they arrive, so tx_bytes becomes a
rate-matching buffer instead of whole-frame storage. The ST write remains a
fallback trigger for software that skips TWD, guarded by tx_queued so one frame
is never queued twice.
Adds BBATop T8: streams a 34-byte frame (> the 16-deep FIFO) over EXI and
checks the W5100 model received it byte-for-byte. Verified to FAIL without the
fix with exactly the hardware symptom -- 16/34 bytes, first bad byte at index
16. The gap that let this ship: TXFrameDrain's own tests drive the FIFO
signals directly, and the BBATop test only covered the RX loop.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A captured frame proves the full EXI->FPGA->W5100->wire path works: the first
16 bytes are byte-perfect (broadcast dst, PAR0-5 source MAC, ARP ethertype).
It truncates at exactly 16 = the tx_bytes FIFO depth, because TXFrameDrain
waits for a length that only arrives at the ST trigger, after the whole frame
has been streamed.
Supersedes the previous note, which concluded it was NOT depth-related; that
came from a clean-reset run whose result was invalid because the W5100 was
already wedged, so nothing transmitted regardless of length.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The whole GC init sequence now runs over EXI on the real board: device ID,
NCRA reset self-clear, PAR0-5, MAR, ANALOG, NWAYC, IMR, NCRA SR, NWAYS 0x17.
GC->wire TX does not complete. Not an EXI fault and not tx_bytes depth --
8-byte frames fail too, and the UART shell's own UDP send hangs the same way,
so the W5100 bus master is stuck and TXFrameDrain is waiting on it.
Also records that id_phase is a one-shot cleared by the first NCRA reset, so
a re-run probe reads 00 00 00 00 for the device ID and looks broken.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
First silicon proof of the EXI capture path. A Pi bit-banging EXI into J4
reads the device ID 04 02 02 00 21/21, NWAYS 0x17, HIPR 0x01, writes and reads
back PAR0-3, writes IMR, and sees NCRA's reset bit self-clear.
Fixes two host-side bugs found getting there:
- exi_devid_rpi.py sampled MISO just after the rising edge, racing the slave's
own update and landing one bit early (04 came back as 08). Sample in the
CLK-low phase, as the simulation does.
- pi-exi-wirecheck.py's bridge scan drove HIGH against pull-downs, but the
FPGA's SB_IO pull-up out-pulls the Pi's internal pull-down, so every pin
reported as bridged. The aggressor now drives LOW against pull-ups.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Verifies the harness before attempting a real EXI transfer. Keyed on the
EXI_J4 build's SB_IO pull-ups: an FPGA input with PULLUP=1 reads HIGH when
connected, follows the Pi's pull when open, and reads a hard 0 only when
shorted -- so all three cases are distinguishable from the Pi alone.
Includes a T0 control on known-unwired pins; without it a broken pull
mechanism would turn every 'connected' verdict into a false pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Factors the EXI_J4 pad merge out of synth.py so the synthesis path and the
test exercise the same code. Verifies the device ID (04 02 02 00) enumerates
over SP1 with J4 idle, over J4 with SP1 idle, and over SP1 again afterwards,
plus a register read via J4 and the full cs_n truth table.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4/8 seeds pass capture, best seed 8 = 63.09 MHz (+17% margin) — same pass
rate as the default build, so the AND-merge costs no measurable timing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Lets a bench host drive EXI without the SP1 edge connector, for bring-up.
Merges a second set of EXI pads onto the existing ones rather than repinning,
so the SP1 connector stays live and the default build is untouched. The three
inputs are AND-merged, which is correct because every EXI input is inactive
HIGH (CPOL=1 clk, active-low cs_n, mosi only matters while cs_n is low): the
unplugged side idles at 1 through its SB_IO PULLUP and passes the other side
through, so no select signal is needed. Outputs drive both pads.
All five J4 pads are on the same bottom die edge as the EXI pads (x=13..18 vs
x=5..9), so the capture domain keeps its anchor. It still adds 3 LUTs ahead of
the input synchronisers, so EXI_J4 builds must sweep seeds.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Anode-side pad at 3V3, cathode at 0V, LED dark — the full rail standing
across it means no current and no drop across R42, so Q2 and R42 are both
doing their job. Probe pressure on the anode pad lights it at full
brightness: the terminal is sitting on the pad unwetted. Reflow fixes it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The W5100S ethernet back-end now works end-to-end on real hardware: a complete,
correctly-checksummed UDP datagram (10.0.0.99:40000 -> 10.0.0.50:6464, 32-byte
payload) was transmitted by the FPGA-driven W5100S and captured on a PC, after a
full bidirectional ARP handshake.
Records the three W5100S-specific findings in CLAUDE.md (NETLCKR unlock, the
15-bit IDM address space putting the buffers at 0x4000/0x6000, and the 60.3 ms
reset-to-ready time), and notes that UDP unicast is the reliable bring-up path
while a 255.255.255.255 send sets SEND_OK without appearing on the wire.
w5100_udptest.py is the self-contained configure+send+readback probe that
isolated all of this.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reverts the 0x8000/0xC000 change from 162dbf7, which was WRONG and actively
broke transmission. The W5100S datasheet pseudo-code quotes 0x8000 (TX) /
0xC000 (RX) for the memory blocks, but the PARALLEL/indirect (IDM) interface
only decodes a 15-bit offset. Bench-proven with an address-aliasing probe:
writing distinct values to each candidate base and reading them back showed
0xC000 and 0x4000 are the SAME cell (0xC000 & 0x7FFF == 0x4000) while 0x6000
holds its own value.
Consequence of the bad base: every payload byte written to 0x9800+i aliased
down onto 0x0000+i, landing on SHAR (0x09-0x0E) and SIPR (0x0F-0x12) and
overwriting them with the payload. The chip then transmitted frames with a
garbage source MAC/IP, which the peer NIC drops without counting -- the
"SEND_OK but rx_packets=0" symptom, and the bogus SIPR0 readback (0x50 was
literally payload byte 15, 'P').
The NETLCKR unlock from 9c4bc7a is a genuine W5100S requirement and stays.
Also:
- w5100_udptest.py: self-contained configure+send+readback probe (and the
address-aliasing probe that found this), reports over UART.
- scripts/build-flash.sh: sweep N seeds and flash the best (capture timing is
seed-dependent, so the sweep is mandatory).
- scripts/uart-console.py: interactive UART console, plus --send/--read
one-shot modes for scripting.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reads socket-3 / status registers over the indirect bus and streams them on the
UART, without resetting the chip, to inspect what a UDP send left behind. First
hardware run was inconclusive (socket regs read 0x00 but SIPR/PHYSR didn't match
either "state persisted" or "clean reset") -- the FPGA reflash appears to glitch
RST_N, so a self-contained configure+send+readback is the reliable next step.
Committed as a starting point for that.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Second W5100S-vs-W5100 gotcha found at bring-up: the W5100S has a Network Lock
Register (NETLCKR, 0x0071) the original W5100 lacks. It defaults to 0x00 (locked),
and while locked, ALL writes to GWR/SUBR/SHAR/SIPR are silently dropped -- so the
chip has no source IP/MAC and the UDP/MACRAW send builds nothing (chip reports
SEND_OK but transmits nothing; socket registers aren't locked, which is why an
indirect write/readback of Sn_PORT succeeded). Fix: write the unlock value 0x3A
to NETLCKR right after MR enables indirect mode, before the network-config writes.
On the bench this flipped the board from silent to actually keying frames onto
the wire (magjack activity LED now blinks).
Also:
- bba_top.py test model: RX buffer base 0x6000 -> 0xC000 to match the W5100S
buffer-base fix (the model hardcoded the old W5100 address).
- w5100_selftest.py: added an indirect-mode (IDM) write/readback probe of a
socket register + IND= field in the UART report, to isolate direct-vs-indirect
access (confirmed indirect works on the real chip).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
From the physical V2 bring-up session (2026-09-20):
- exi_bba/w5100_selftest.py (NEW): standalone FPGA<->W5100 bus diagnostic.
Clock-independent data-bus walk (direct-mode GAR0 read-back, all 8 lines) +
MR software-reset self-clear (needs the 25 MHz crystal). Reports 4 verdicts on
D6/D7 LEDs AND over UART (115200): GOOD / data-line-N / clock-dead / no-response.
Boot wait is 85 ms (> the W5100S 60.3 ms init). On this board: GOOD -- bus +
all 8 data lines + 25 MHz clock all verified (unlike V1's broken D3).
- REVIEW.md / TODO.md: eFuse U13 OVLO is tied to GND, which on the TPS25961
selects the internal FIXED ~6 V overvoltage cutoff -- so it blocks the 12 V
rail entirely (bench-confirmed: 12V_EXI=0, GC_ON=0, W5100 unpowered). FAB-
BLOCKER for V2.1: fix with an OVLO divider (~1.1M/100k -> trip ~15 V). Bench
workaround: lift U13 pin 2 (OVLO) off GND. Also closed the eFuse-placement,
GND-via/3V3-zone, and CC-ESD TODO items.
- hardware/re-bba-rb/exi_devid_spi.py (NEW): Pi hardware-SPI (~25 MHz) EXI
device-ID host, companion to the bit-bang exi_devid_rpi.py.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The W5100ParallelMaster used the original W5100's TX (0x4000) / RX (0x6000)
memory-block base addresses. This board's chip is a W5100S, whose TX/RX memory
blocks live at 0x8000 / 0xC000 (datasheet: TX 0x8000-0xBFFF, RX 0xC000-0xFFFF).
Consequence found at hardware bring-up (2026-09-20): every frame was written to
dead address space, so SEND transmitted the (empty) real TX buffer -- the chip
reported "sent" but nothing valid reached the wire (peer rx_packets stayed 0,
link up). The sim bus-model used these same constants, so it never caught it --
exactly the "register addresses are datasheet-from-memory, confirm at bring-up"
risk. All socket register offsets were verified correct against the W5100S
datasheet; only the two memory bases were wrong. Fixes both the socket-N UDP
test and the socket-0 MACRAW (GC) path.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Roflin