since getting ddr3 working is a long and arduous process, I think it would be worthwhile to, until we have working ddr3, create a simple interface on the fpga so it connects to a computer of some sort and the computer is running a program to emulate ram, that way we can run linux with multiple gigabytes of ram necessary for compiling programs and other things that won't fit in the fpga's block ram or in hyperram. I was thinking we'd create a simple wishbone interface that translates memory accesses to uart messages and communicates with the computer, since uarts can run at multiple mhz. another idea is to use some faster interface that connects to another fpga, where that fpga can run at 50-100mhz necessary to get ddr3 to run. The idea I think we should go with is using the SPI master in the RPi to connect to a SPI slave in the FPGA which is connected to a wishbone slave that acts like plain ram. see comment #2 for details. * TODO: write program in C that emulates ram and that allows connecting to either a spidev spi master (for fpga) or a named socket SOCK_DGRAM (other side connects to nmigen simulation) * TODO: write spi slave to wishbone slave translator in nmigen, that looks like just memory to the wishbone master * because open fpga tools do not yet support multiple clock domains well, this should run entirely in the cpu clock domain and assume the cpu clock is >2x as fast as the spi clock and just use a 2-state fsm to detect the spi clock edges. * TODO: write named socket SOCK_DGRAM to spi master translator in python for testing the spi slave stuff in a nmigen simulation. this should use O_NONBLOCK * TODO: get it to work on a FPGA connected to a RPi.
(In reply to Jacob Lifshay from comment #0) > I was thinking we'd create a simple wishbone interface that translates > memory accesses to uart messages and communicates with the computer, since > uarts can run at multiple mhz. HyperRAM is much simpler and there is the advantage that models of the actual HyperRAM ICs are available. cocotb can be used to create a compatible software variant that is checked against the model. or, nuts to it: much simpler protocols barely above what wishbone is can also be written. at some point we do need an inter-memory protocol, to connect FPGAs together. this would be a step in that direction.
(In reply to Luke Kenneth Casson Leighton from comment #1) > or, nuts to it: much simpler protocols barely above what wishbone > is can also be written. at some point we do need an inter-memory > protocol, to connect FPGAs together. this would be a step in that > direction. the main issue is things like the RPi don't speak HyperRAM or wishbone, so using a protocol they already support is much better. After doing some research, the RPi 4B apparently supports SPI (master only afaict) at 125MHz divided by any power of two (250MHz divided by any even number from 2 to 65536 but only powers of two work or something), so we could have our FPGA act as a simple SPI slave and the RPi can just repeatedly read the address to access and do the memory read/write as needed. If we do a good job wiring it up (twisted pair and termination resistors), we could probably get it to work at >10MHz (so like 1MB/s) in any case, we will need the FPGA to wait for the computer to respond since it may be busy servicing some interrupt or switched contexts or something. This is another major problem with trying to talk to another computer using the HyperRAM protocol -- iirc HyperRAM has no way to indicate the RAM isn't ready yet.
I have a BeagleWire [1], which I baught several years ago. This one has 32 MB SDRAM. I also have a Rasperry Pi Pico, which might be used as an interface to a host computer. It is also used to IPL the 486 MHz IBM "Gekko" PowerPC CPU on the Gamecube. [1] https://www.crowdsupply.com/qwerty-embedded-design/beaglewire [2] https://hackaday.com/2022/07/05/raspberry-pi-pico-modchip-unlocks-the-gamecube/
(In reply to Tobias Platen from comment #3) > I have a BeagleWire [1], which I baught several years ago. This one has 32 > MB SDRAM. I also have a Rasperry Pi Pico, which might be used as an > interface to a host computer. It is also used to IPL IPL has the advantage it's already written.
(In reply to Luke Kenneth Casson Leighton from comment #4) > (In reply to Tobias Platen from comment #3) > > I have a BeagleWire [1], which I baught several years ago. This one has 32 > > MB SDRAM. I also have a Rasperry Pi Pico, I also have one of those...though I was thinking of just using the SPI master built into the Raspberry Pi (non-Pico) since those directly have enough ram to act as memory. > which might be used as an > > interface to a host computer. It is also used to IPL > > IPL has the advantage it's already written. I expect IPL to not support acting like r/w memory though...which is what we need.
I added a todo list for getting this to work both in nmigen simulation and for RPi connected to FPGA.