HyperRam timing
Rayman
Posts: 14,646
Started thinking about how to quickly read from HyperRam…
Think the best way is to have data on either P0..P7 or P32..P39.
This way, can do a REP loop with WFBYTE on INA (or INB) to transfer data at maximum rate.
If the P2 is at 250 MHz, then will clock HyperRam at 62.5 MHz.
Will use WAITSE1 to wait for HyperRam to raise RWDS, signaling that first byte is ready.
Then, start WFBYTE loop.
Maybe this is all wrong, but if it works, would have 125 MBPS read rate.
One thing I am aware of is that we can't cross a row boundary this way.
Think that means limited to read length max of 1024 bytes at a time...
Think the best way is to have data on either P0..P7 or P32..P39.
This way, can do a REP loop with WFBYTE on INA (or INB) to transfer data at maximum rate.
If the P2 is at 250 MHz, then will clock HyperRam at 62.5 MHz.
Will use WAITSE1 to wait for HyperRam to raise RWDS, signaling that first byte is ready.
Then, start WFBYTE loop.
Maybe this is all wrong, but if it works, would have 125 MBPS read rate.
One thing I am aware of is that we can't cross a row boundary this way.
Think that means limited to read length max of 1024 bytes at a time...
Comments
Bought two S27KL series chips and got them soldered onto a breakout board.
For 8-bit data bus connection, I'm liking P32 better, and was headed that direction.
Isn't there also a way to use the streamer?
I believe from past research that Richard J. S. Morrison was doing something with HyperRAM.
https://forums.parallax.com/discussion/166802/hyperram-solutions-for-p2-and-p1
Burst length can only be 128 bytes maximum for the chip I've been researching, and that has to be set in configuration.
It apparently can handle a 128 byte write burst without delay, but that write pauses DRAM refresh (which is probably okay).
Complications to using the streamer is that, according to the datasheet, it wants to be able to insert latency for boundary crossing even during the data transfer portion of a burst read by doing something with RWDS. Not just during the Command-Address transfer at the beginning.
Interested to see what we can all do with this device. I was headed toward 640x480 16-bit color VGA as it was a no-brainer (five 128 byte bursts per horizontal line). Lots of time to get the data streamed in for the next scanline, for example, once the burst starts.
That's why I mentioned a limit on read length max...
This guy (Kevin Hubbard, github.com/blackmesalabs) has a lot of good work done on the Hyperram subject.
https://github.com/blackmesalabs
I'm not an Verilog RTL expert, but there are loads of good brains here at the forums, that could jump in and help the others, someway.
Hope it helps.
Henrique
Going to try it out tomorrow...
It looked very complicated at first, but now it looks very simple.
But, I might have it wrong, we'll see.
Looking at HyperFlash now. Reading from it looks to be just as easy...
I was planning to tidy up both my code and comments as there’s definitely further improvements to be had - but since others on the forum are keen to implement HyperRAM I thought it might be useful if I posted the code now.
I have a word document describing this in more detail but I’m away from home at the moment and don’t have access to it – but I’ll post this here in the next day or two.