My IIsi has a 50 MHz RD68884 FPU!

[Melkhior]

Disclaimer: a lot of the work described below was done with the help of AI. None of this message was.
Disclaimer 2: first posted on 68kMLA, but I figure it might be of interest on TD as well

After playing with Claude Code to finish recreating old 68k-based Suns (Sun-2 w/ MC68010, Sun-3 w/ MC68020, described on TD as it's not on-topic for 68kMLA), I had an issue: NetBSD/sun3 expects a FPU (unlike SunOS 4.1.1 which can live without). So I needed one, looked at github for all those recreation of MC68881 or MC68882 (well, two of them), and realize they absolutely wouldn't do - not only did Claude find many issues when I asked for a documentation-driven audit, but both of them ended up not fitting (for one by "an order of magnitude"!) in an Artix-7 100T.

So I had to recreate my own MC68881-compatible FPU, the RD68884, with one goal: be small! it needed to fit in the 50T of my IIsiA7 Mini, and even perhaps the 35T in the original IIsiFPGA, and also in a 100T alongside my RD68021 CPU and all the devices in a Sun-3. I wasn't sure if Claude was good enough to do it given the size of the existing implementations, and that I went for the full-fat MC68881 with all the transcendental functions! no cheating by doing the '040 subset and using the FPSP (which was plan B).

Turns out, yes, it works. Claude ultimately (with a bit of help) delivered a design that takes less than 14% of the slices of the A50T... no need to say, I wasn't going for a high-performance FPU It originally was tested in a Wukong A100T as part of my Sun-3 design, where it was happy to start NetBSD and run hard-float "whetstone" and other FP-testing codes just fine.

I eventually got around to put the RD68884 in the IIsiA7 Mini (standalone, without any other devices yet), and it works! Clocked at 50 MHz, Speedometer 4.02 sees it as roughly the same performance as the 20MHz MC68882 on the PDS adapter... as I said, not fast! But then, a large part of the problem is the overhead of the coprocessor interface anyway.

As far as I know, it's the first "fpga-proven" FPU design to be tested against a real MC68030

 

[bakkus]

As usual, your projects are REALLY cool!
It's an exciting time where we now have access to tooling which can accelerate the complete reverse-engineering of custom- or now hard-to-find chips.

 

[Kai Robinson]

Awesome! How come you went with the '881 instead of the '882?

 

[Melkhior]

Awesome! How come you went with the '881 instead of the '882?

Size and simplicity. I was really worried a full FPU wouldn't fit from looking at existing designs. Turn out, those other cores were probably written by an AI doing it the same they would do an integrated FPU in a modern RISC core (which is likely what they have in their training data), and doing an hyperbolic arc-cosine in one or a few cycles takes a lot of area I explicitly asked for a minimalist micro-coded replica of the '881 whose only goals where 50+MHz and size. I expected a week or two of work, but Claude figured out it could just pilfer the FPSP and various soft-float libraries to "help" with the micro-code... took a couple of days to go from original prompt to first check on the IIsi, with the Sun-3 tested before the IIsi!

Of course now that I know the size of the RD68884, I have claude working on a variant, the RD68885 (that's original...), that will look and feel like the '882 with more overlap, and hopefully bit a bit faster for sequence of simple FPU instructions.

It's an exciting time where we now have access to tooling which can accelerate the complete reverse-engineering of custom- or now hard-to-find chips.

Some types of reverese-engineering, yes, for other it still an open question (for me). I tried reverse-engineering an Apple chip made with a gate array from an ultra-high resolution (over 50k*50k pixels) die shot. It's basically computer vision to figure out how the metal layers are connecting the transistors. But even knowing where the grid of transistors is and the list of possible gates and how they are wired from the documentation, I couldn't get it to finish the job - whenever I tried to get claude to fix something, it would break elsewhere. But then I know nothing about computer vision... and AI doesn't do well when the user is clueless.

EDIT: also, the RD68884 passes timings and work in the IIsi at 66.66 MHz, but that's only improve performance by a small amount, the coprocessor dialog is the bottleneck for simple operations.