Hi HN,

I was supposed to be on vacation right now, but my visa got delayed. Stuck at home with a Heijin AX301 dev board (Altera/Intel Cyclone IV EP4CE6), I decided to kill some time by porting Linux to a softcore on it—a lingering goal from my college days that took about 4 days.(GitHub Repo: https://github.com/14sea/see_neorv32_run_linux)

(Btw: plus tpu version: https://github.com/14sea/neorv32_tpu)

Shortly after, I saw someone offering a bounty (a skewer meal) to port firmware to an open-source Lattice iCE40. I didn't have an iCE40, but I figured: why not just make the board I already have "open-source" instead? Add the fact that I had a $100 Claude API credit ready to be used, and the EP4CE6 essentially became the victim of circumstances.

I know there's a lot of fatigue and skepticism around "AI slop" right now. I’ll be completely honest: Claude wrote the vast majority of the code for this project. I basically acted as the high-level architect—setting up the "Pair-Diff" methodology, reviewing the results, and steering the LLM while clicking "Next" (even this article is written by Gemini). But I don't mind the stigma, because the end result isn't just a toy script; it’s a fully functional, automated black-box fuzzing pipeline that outputs working bitstreams.

Here is what "one guy, one laptop, one board, and an LLM" managed to map out in a single weekend:

Complete CRAM Address Model: 22 columns × 18 rows × 16 LEs = 376/376 positions fully verified (100%).

Logic Configuration (~95% decoded): LUT truth tables use XOR-linear encoding (any 16-bit mask = XOR of single-bit patterns). FF and arithmetic modes are mapped.

Zero-Noise Fuzzing: By compiling a primitive LUT with mask=0x0000 vs mask=0xFFFF at the exact same coordinate, I could isolate the CRAM bits with literally zero routing noise.

End-to-End Hardware Verification: The Python bitstream codec we built can now read/write LUT truth tables. I generated an .rbf directly via the codec (without Quartus), flashed it with openFPGALoader, and the logic gates behaved perfectly on the physical hardware.

The Routing Matrix Deep Water

We are currently in Phase 3: the routing matrix. We’ve mapped out C4 (I=0) switches with a universal formula across 22 LAB columns (63 wires, 0 false predictions), and about 35% of R4 switches.

It’s terrifying to realize that what used to take an open-source community months of collaborative effort can now be largely brute-forced by a single developer directing an LLM in a matter of days. As I wrote in my journal: the tech is here, and if I didn't do it, someone else would have anyway.

If anyone here has experience with FPGA routing matrices (specifically C16 and R24 long-distance wires), I’d love your insights.

GitHub Repo: https://github.com/14sea/Cyclone_CRAM_Mapper

Happy to answer any questions about the fuzzing pipeline, the XOR-linear modeling, or what it’s like to use Claude Code for hardcore hardware reverse engineering!

Show HN: Reverse-engineered the FPGA bitstream using Claude Code