Implementing Memory Cache in FPGA

[@m1geo]

Marking the bootloader as dirty and having the cache controller handle it was genius! :)

[@CompuSAR]

THANK YOU! I was _so_ proud of this trick, and it got absolutely zero reaction.

[@m1geo]

@@CompuSAR nah, I was watching like "oh, how's he getting out of this one." and then you pulled this off, and I was like "woah, magic!" 🤣 genuinely excellent! Excited for more! Keep up the series, please! 😍

[@vincentvoillot6365]

Very interesting idea, very crafty. An other solution is to read the EEPROM thoughts SPI, it must have at least few MB available to be map as read only.

[@CompuSAR]

@vincentvoillot6365 There's no shortage of space on the flash. Getting it to the CPU is another matter. That would require dedicated hardware that runs counter to what we're trying to do here: minimize the hardware requirements of the design. My solution is 100% free, in that all of the hardware it requires is used anyways.

[@vincentvoillot6365]

@@CompuSAR Yes, there would be an hardware overhead, but that much ? After all the SPI interface with the flash is already hardwired. I know i'm late to the party and you have done a really amazing job with the DDR controller. But didn't you cross path with the LiteX framework during your research ?

[@PedroAngelini]

Amazing solution! I'm imagining the cpu waking up, checking it's task list (program) and going "hold on, how the hell did this get to memory before we had power? *Shrugs* Well might as well get processing" and goes on with it's life. Meanwhile the cache has an apron and a broom and is going "how the hell all of this got so dirty so quickly?!"

[@CompuSAR]

My mental picture is almost reverse. We have a the FPGA frantically working to get the house ready for the guests, just so when they arrive to wipe the last strands of sweat, pretend to be bored, and say, "oh, if I'd known you'd come I'd have cleaned up".

[@LordDecapo]

such a consise cache explainer. Gonna use this as my goto link when talking about caches with new people lol.

[@AlanCanon2222]

Brilliant. I notice the 65C816 has a couple of output lines that can be used to separate cache operations for program data and program instructions. VDA and VPA. I wonder if they were thinking of a way to signal the bus controller to pull program code from an underlying EPROM, yet seamlessly make that address space available as RAM.

[@CompuSAR]

While it can be used this way, I don't know of any implementation that does. Giving the instruction and data buses different values *on the same address* is very rare (though VPB on the W65c02 is designed for, pretty much, precisely this). It's more about having different caches for both. If you're going to have a fast enough (i.e. zero wait) EEPROM, you wouldn't bother putting a cache between it and the CPU. Why would you? It's zero wait state. But if you execute from DRAM, your instruction fetches behave quite differently than data fetches. This means that a single cache will be less effective, with the data and instruction invalidating each other's accesses. Having separate caches for both would make sense. For CompuSAR I did something a little different. The iBus and dBus are completely separate on the RiscV. The dBus goes through an address router that directs it wherever, with the DDR being one option. The iBus *only* goes to the DDR (at the same addresses), but has one more layer of cache. So the dBus goes through a 16KB cache to the DDR, while the iBus goes through a 4KB cache to the same 16KB cache the dBus uses. Without it things worked, but the FPGA would heat to the point where memory actually started coming back incorrectly (bit flips as per kzbin.info/www/bejne/j2PVpIGum7CNZ6s). With the two layers cache things work quite nicely. Since the iBus never writes, I don't need to handle complicated cache invalidation cases. This breaks on self-modifying code, but who cares?

[@AlanCanon2222]

@@CompuSAR I've been thinking of using VPB in the 65816 to choose among irq vectors. I'm thinking of dual 65816s, and I want them each to have independent access to the various IRQ generating devices in the design (UARTS, VIAs). There appear to be a contiguous 7 vectors worth reserved from FFEE to FFEC. So if I can force rewrite the last four bits of the vector as read by the 65816, then I can have each device choose its own handler.

[@CompuSAR]

@@AlanCanon2222 I'm not sure what your setup is. Having different CPUs get different interrupt vectors is an interesting idea. The selection logic is a little big for that. Are you building the computer out of discrete 74xx logic chips?

[@CompuSAR]

Also, bear in mind that on the w65c02s, at least, the MLB signal can't be relied on to signal read-modify-write operations correctly. For all "legacy" operations it is only low for the last two, not three, cycles of the command. So the "read" part is done with the memory not locked. I've never touched the 65c816, so I don't know whether that's also the case there. Funny story: when I first reported this, WDC didn't believe me. Since then they amended the datasheet to record this bug, at least on the 65c02.