Been working on this monstrosity of a motherboard for the 8088, still somehow not done lol (send help)
Gonna have to pivot to software, funding for hardware is hard frankly with all the backlog the reviewers have, so this will stick to strictly verilog simulation until I get the funding for building this myself. For now, I’ve only written the address decoder.
Next comes the fake ram simulation of a sdram, complete with chip select, bank select, row address strobe and column address strobe, bank precharge, data mask, along with row cycle time (tRC), RAS to CAS delay (tRCD), precharge command period (tRP), boot rom etc. We’ll see how stuff goes.
What is this? What am I making?
The Grip is an open-source x86-32 motherboard project built around a real AMD Am486DX4 or Am5x86 processor and an FPGA-based chipset.
The project will begin as a modular prototype using separate CPU, FPGA/memory, display, storage, audio, and controller boards connected through a backplane (read: jank setup of breadboard). Once the architecture is proven, these modules will be integrated into a final laptop motherboard and a 3d printed custom case.
The FPGA will replace the traditional northbridge and southbridge logic. It will handle CPU bus transactions, memory control, BIOS mapping, interrupts, timers, DMA, ISA, storage, display blah blah blah.
The planned final system includes 128 MB or more of SDRAM, SD based storage (no compactflash thank you), VGA graphics, LCD output, mouse/keeb support on PS/2, audio, floppy. OS Support will be first FreeDOS, then Linux Win95 and Win98.
The first major milestone is simple: release the processor from reset, detect its request for the reset vector, return valid instruction bytes, and complete the bus cycle. Simple, but if it works, we build on top of it.
spent roughly eight hours researching the 486 bus, drawing a timing diagram, and implementing the first version of the CPU bus frontend.
allat to send 4 x86 NOP instructions. crazy? i was crazy once.
(well i am still now)
Works simulated, lets see how it works with a proper full fledged simulated i486. i’ll borrow one from github to see if this works.
YOU WANT A DEVLOG, YOU WANT ONE, HUH????? HERES A DEVLOG FOR YOU:
net_name: “spi_sck”
dont_route: true
FUCK YOU RENESAS FUCK YOU FUCKING PIECE OF SHIT FUCK YOU!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! YOUR PLACE AND ROUTE TOOL IS UTTER GARBAGE!!!!!!!!!!!!!!!!!!!!!!!!! WHY ARE YOU IGNORING USER NETS!!!!!!!!!!!!!!!!!!!!!!! STOP. OPTIMISING. THE. USER. CODE.
Edit: I figured what’s up
Aparently Renesas bought dialog semiconductor which bought silego, which made their greenpak line of fpgas, which was essentially scratch/Lego mindstorms for fpgas, and not meant to handle actual verilog, which when renesas made their forgefpga line they just reused greenpak
hence the mind boggling bugs
its like trying to run c in scratch
fuck my chud life
Devlog #2: Building the NTT Core
Last time I ended on “okay, I’ll build a tiny NTT accelerator for Kyber on the Shrike Lite.” So that’s what I’ve been doing. No LEDs blinking yet since this whole devlog is me in a simulator, fighting my own garbage code.
But it’s progress, and it’s the kind of progress where I learned something every single time it broke.
Quick recap of the target: Kyber’s math runs mod q = 3329, and the whole NTT is 7 layers of 128 butterflies each (256 coefficients, standard Cooley-Tukey). On a chip with 1120 LUT5s and 32kb of BRAM, getting this to fit is a real damn sisyphean task. This sh*t is like tech from the 2000’s.
Started at the bottom: a 16-bit Han-Carlson adder, because I refuse to put ripple-carry anywhere near a critical path (We’re civilized men, writing civilized code, not animals).
Could I have done just a simple carry-look ahead? Yes, yes I could have. No, I don’t think I will. Fan out is getting crazy already, may as well use a PPA atp.
Built it as a proper parallel-prefix tree using 2D wire arrays in Verilog instead of copy-pasting carry logic by hand.
Found one non-bug worth noting for later: the top half of the adder (bits 8–15) isn’t a true prefix tree, it just ripples off the bit-7 carry. Works fine functionally, just means the top half is roughly double the gate depth of the bottom half. But, really, who cares. Not me. CBA.
The Montgomery reducer (a.k.a. the finite state machine from hell):
This is where it got ugly. Montgomery reduction is how you do modular multiplication without a hardware divider:
- multiply,
- then reduce using a precomputed constant instead of dividing by q every time.
I wrote it, simulated it, ran it cycle by cycle in EDA Playground because Icarus was being uncooperative (yeah, when does Icarus help anyways??? may as well switch to Quartus at this point), and found: add_a/add_b were registers, so they only update after the clock edge, but result <= add_sum was reading the sum from the previous cycle’s stale operands.
Every state that tried to compute-and-latch in one cycle was quietly latching garbage. Bit 0 of t_low was getting dropped somewhere in there too. Phenomenal. Simply beautiful.
Fixed it by making the adder operands purely combinational (mux on state), so add_sum always reflects the current state’s actual intent.
I thought that fixed it.
No, why would it fully fix it? Of course it would not. There was still a state-transition bug lurking. Very fun to debug.
The butterfly
This is the unit that actually does the NTT math: read two coefficients + a twiddle factor, multiply, reduce, add/subtract, write back. Spent a good chunk of time chasing what looked like a hang here, that turned out to be nothing but a testbench race condition - sampling signals in the same cycle they change, not an actual DUT problem. Frick me.
Bonus: figured out how BRAM actually gets wired
Dug through some existing Renesas example projects (shoutout to whoever wrote the FIFO-on-BRAM one, you saved my life)
Where it stands
Working (in simulation, against reference vectors):
Han-Carlson adder
Montgomery reducer
Modular ALU
Serial multiplier (shoutout to whoever made the Kyber spec sheet; you saved my ass because most of the time all I have to do is bit shift to “multiply”)
NTT butterfly
Address generator
Full 256-point forward NTT, top to bottom
Still to build:
- the inverse NTT (GS-DIF, reusing everything above),
- the pointwise multiplication step for after both polynomials are transformed,
- and the actual RP2040-FPGA SPI link tying it all to real hardware instead of a testbench.
atleast man the sim works, thats pretty damn good. im happy this works. next is getting it on the hardware and doing some actual cryptography with it.
I was 15 minutes into a CTF crypto challenge, watching my CPU crawl through a polynomial multiplication, when it hit me: This is embarrassingly parallel. Why isn’t there hardware for this?
That night I fell down the FPGA rabbit hole. The idea was pretty great, a chip you can rewire into literally anything, like a custom RISC-V CPU, a cryptography accelerator. Where does that second idea take me? A method to execute a side-channel attack on cryptographic protocols using the FPGA, and all on a chip smaller than a credit card.
So I bought an FPGA on impulse, without researching properly. You can’t blame me, I was very excited.
I bought a Sipeed Tang Primer 20K core board. What I didn’t know: it’s just the RAM stick. The actual brains need a baseboard with power switches, reset buttons, and USB. Aaaaaaand I had none of that.
ba dum tss
What I did have: a Vicharak Shrike Lite (the green board in the photo). 1120 LUTs. An RP2040.
The Tang Primer has a JST debug connector. The Shrike Lite has JTAG pins. In theory, this was simple: connect the wires, run openFPGALoader, and go.
In practice:
The pinout I found online was confusing
The BL702 debug chip locks up after programming unless you power cycle the JST connector.
My multimeter showed 0V on TX, and no amount of head scratching made it work.
A week of “should just work” turned into a desk covered in jumper wires, a growing collection of frustrated terminal logs, and the Shrike Lite blinking an LED like it was mocking me.
I couldn’t get the Tang Primer running. But the Shrike Lite was working perfectly.
So I asked myself: what’s the smallest possible cryptography accelerator I could build on 1120 LUTs?
The answer: an NTT (Number Theoretic Transform) core for ML-KEM (Kyber). Why? Why not. Post-quantum cryptography is a hot topic of research. I figured I’d take a crack at it, see what makes it so hot.
Surely, after all of this, I have some lessons to take home, right? Those are:
FPGAs are not plug-and-play. The ecosystem assumes you bought the right baseboard.
1120 LUTs is tiny but not useless. You can’t fit full Kyber, but an NTT core fits comfortably. (I hope)
Documentation is scattered.
A working demo on cheap hardware beats a simulation on the PC. Much more satisfying to see a simple LED light up than stare at another waveform in GTKWave.
So what do I do next?
A working NTT accelerator on the Shrike Lite that processes Kyber polynomials with the RP2040 to FPGA and back bridge sending coefficients and getting transformed results.
The Bottom Line
I bought the wrong board. I didn’t have the right programmer. Nothing worked for weeks.
But I learned more from breaking things than I ever would from following a tutorial.
