CI runs for the first time, and the wrapper had drifted off the core

I sat down to write this project up for the site and read my own last commit. It said D and W over the LAN were returning 0x44. I remembered it working. Turned out I’d done the fix on the other machine and never pushed, so I pulled six commits from 2026-08-09 and one of them was a verification workflow that had never run. Pushing it ran it. Red.

First failure was mine. The core repo’s FuseSoC generator finds GHDL through a GHDL environment variable and falls back to ~/oss-cad-suite/bin/ghdl. My Makefile set that variable and never exported it, so it only ever worked on machines where the fallback path existed. One export GHDL line.

Second failure was the real one. make convert builds the netlist from the core repo at HEAD, and the core repo moved on 2026-08-08. Commit c05c7c7 purged the EXTERNAL_RAM generic, the ram_ext_* bus and the 3-bit int_vector from b8008_top. My wrapper still declared all three. Nine port errors. It had worked locally for a month because the netlist on disk was built in August and nothing regenerated it.

I went down a hole first. The bring-up commit says the DHCP lease needed liteeth at master 276c9e3, and this machine had it at the 2026.04 tag, so I tried pinning it forward. liteeth 28b4493 from June uses litex master’s new CSR aliases, CSR.wr_stb, which litex 2026.04 doesn’t have. Elaboration dies in the MAC SRAM. Back to the tag. There’s a make liteeth-pin LITEETH_REV=… knob now for a bench session, and make litex-env never moves a checkout on its own.

Then I pinned CI to the last core commit that still had the old ports, 70c7498, and cancelled the run when I realized that was freezing the wrapper on an August core. The core’s fine. The wrapper needed to follow it.

The change is smaller than it sounds. EXTERNAL_RAM=false already instantiated ram_sync inside b8008_top. The external mode just routed the same latched_address, data, rw_n and cs_n out to the bus, where my Migen side fed a 16 KB Memory. ram_sync.vhdl and address_decoder.vhdl are byte-identical across the purge. The old jam byte was "00" & int_vector & "101" with vector 000, which is 0x05. The new int_instruction default is 00000101, also 0x05. ROM interface untouched. So the wrapper drops its ram_* ports and the vector latch, the Migen side drops its RAM, and both boot testbenches drop their RAM models. The Verilator bench was also still wiring ctl_* and sts_* ports I’d deleted in August. S-CORE-3 got a dated amendment re-freezing the port list.

Convert now stamps the netlist with core 342f8cd. The GHDL sim prints the banner through “8008 Mon”, the Verilator sim through “8008 “, and make test is green, 4 C binaries, 105 host and 48 SoC tests.

Then three more red runs, all one bug. On the runner, litex_setup.py clones the vendored trees under .venv/. On this Mac they’re at the repo root from July. liteeth-pin, the C test include path and the fork-drift test all assumed root. They accept either now.

Run 34549971806 went green at 2026-09-11 01:21 UTC. Five and a half minutes end to end on a fresh runner, of which the seven SoC elaborations take three. Convert takes 4 s. That’s the first green run this repo has had, and every failure on the way was something that only shows up on a machine that isn’t mine.

What I have not done is put this on the board. The logic is the same but the 16 KB RAM used to be a Migen Memory and is now inferred by yosys from the GHDL netlist. That’s a different path to block RAM. make check-synth counts DP16KD for exactly this reason, and the core repo’s own monitor build infers this same ram_sync fine, but a green test suite is not a working machine. Next is a bitstream, make selftest, and D and W by hand.