With @Tubular 's assistance I'm getting an SRAM breakout board design made to test SRAM driver software on the P2 with the P2-EVAL.
Here's an image of the board. It's about 3.5x3.25 inches to support the Eagle placement limit. Was designed originally to be snapped in half with a slot routed down the middle to assist with this but the fab house balked at that and wanted 8x the price, so this sneaky modification they have accepted is both halves combined with a common ground plane now and I will just need to chop it in two with some other tools.
Supports SOJ-36 SRAM or 44 pin TSSOP-II SRAM depending on which half you use. I only have the SOJ-36 RAM here right now to begin with which just goes to 512kB but the TSSOP goes up to 2MB.
It's a simple design with little care done about matching lengths etc, so I will have to see what the signal integrity is like at high speed, certainly will be better than the breadboard! Mostly just solid ground plane underneath apart from a few small traces.
Will need to fit this in the P2-EVAL from P8-P39 to deal with the clock issue on the P2 on pins 28-31. I've put the control signals up there which will limit the simultaneous transitions somewhat vs address or data.
For a 2MB setup it uses these pins:
A0-A20 = P8-P28
CS = P29
WR = P30
RD = P31
D0-D7 = P32-P39
Edit: Damn, I forgot the pullup on the CS pin so if it floats it could still enable the chip. No biggie for a test board like this, but it would make sense on a proper board.
Me too.. The 512kB SOJ-36 RAM's access time I have lying about here is rated to only 12ns so @sysclk/2 I can only clock the P2 to around 166MHz if I don't overclock it. I'll be happy enough if it reaches that speed. There are some 10ns TSSOP2 parts around from ISSI, be good to find an 8ns one but it might be harder to get.
@rogloh said:
@aaaaaaaargh Here's a new SRAM video demo binary that will run the P2 @ 75MHz instead of 50MHz and the RAM at 37.5MB/s which is enough for 8bpp VGA plus some write bandwidth left over. It should fix your jitter issue over VGA. I built it for your 25MHz crystal. You may need to tweak your delay value to suit the best image output.
Hi rogloh, would it be possible to make a 20Mhz version of the P2@75 Mhz sramvga.bin? I am testing a new p2+sram backback setup without breadboard and short wires and like to see how that performs with vga...
Cool! Only thing I'd change is that you've acres of board space - Put in layouts for four or six chips, and you only have to install one or two. Grab a few spare pins for more chip selects, and you're off to the races! (Alternately, use more read/write pins, but that starts to cost more pins the more chips you have).
That and I have a P2 Edge and Breadboard not a P2 Eval, but that's my butt. ;-) S.
@rogloh said:
@aaaaaaaargh Here's a new SRAM video demo binary that will run the P2 @ 75MHz instead of 50MHz and the RAM at 37.5MB/s which is enough for 8bpp VGA plus some write bandwidth left over. It should fix your jitter issue over VGA. I built it for your 25MHz crystal. You may need to tweak your delay value to suit the best image output.
Hi rogloh, would it be possible to make a 20Mhz version of the P2@75 Mhz sramvga.bin? I am testing a new p2+sram backback setup without breadboard and short wires and like to see how that performs with vga...
I don't have my setup handy right now to validate this (always risky), but here's a zip with hopefully what you want, i.e. running the SRAM video on a 75MHz P2 using 20MHz XTAL. I just rebuilt my last sramvideo.spin2 file, so if I've changed things in that demo since it might not be what I had running last time. It's been about a month now and I've since moved onto other things so I'm not 100% sure what state it was left in, so YMMV. It's last file change date was on 22 April, same as when the last zip was created so it's probably still the same as before.
@Scroungre said:
Cool! Only thing I'd change is that you've acres of board space - Put in layouts for four or six chips, and you only have to install one or two. Grab a few spare pins for more chip selects, and you're off to the races! (Alternately, use more read/write pins, but that starts to cost more pins the more chips you have).
That and I have a P2 Edge and Breadboard not a P2 Eval, but that's my butt. ;-) S.
At this stage it is just going to be a test board so I can run my driver at high speed and not be plagued by noise, and it won't get lots of chips fitted. For video use I expect PSRAM is the better option in general, though for emulator applications if you can spare the pins, the latency is better with SRAM. The console emulation thread had some numbers I figured out for HyperRAM and PSRAM access times. Direct SRAM easily beats them.
@rogloh said:
@aaaaaaaargh Here's a new SRAM video demo binary that will run the P2 @ 75MHz instead of 50MHz and the RAM at 37.5MB/s which is enough for 8bpp VGA plus some write bandwidth left over. It should fix your jitter issue over VGA. I built it for your 25MHz crystal. You may need to tweak your delay value to suit the best image output.
Hi rogloh, would it be possible to make a 20Mhz version of the P2@75 Mhz sramvga.bin? I am testing a new p2+sram backback setup without breadboard and short wires and like to see how that performs with vga...
I don't have my setup handy right now to validate this (always risky), but here's a zip with hopefully what you want, i.e. running the SRAM video on a 75MHz P2 using 20MHz XTAL. I just rebuilt my last sramvideo.spin2 file, so if I've changed things in that demo since it might not be what I had running last time. It's been about a month now and I've since moved onto other things so I'm not 100% sure what state it was left in, so YMMV. It's last file change date was on 22 April, same as when the last zip was created so it's probably still the same as before.
WOW - at delay 6 this works perfecly! No noise at all - and yet this is still on breadboard, I changed to a new p2 board ( retroblade2 ) and a better power supply and a new pin assignment:
Still can't believe how well this works in this kind of setup!
Enter SRAM module data pin base [48] : 32
Enter SRAM module addr pin base [0] : 0
Enter SRAM module CE pin [21] : 21
Enter SRAM module WE pin [22] : 22
Enter SRAM module OE pin [23] : 23
Enter SRAM module read delay [5] : 6
Enter output (0=NTSC, 1=VGA) [0] : 1
Enter A/V video module base pin [24] : 40
Yes video sourced from external RAM can work nicely coming out from the P2 once it's dialled in, you should check out what PSRAM can do when I release it.
At the end of the sequence that image is possibly coming from HUB RAM I think (but it can look like that when the RAM has no noise too). Do the drawn graphics tests work okay with no pixel noise now while they get written to the screen?
My SRAM boards might arrive next week with any luck.
Today I made a new board to test PSRAM / other serial RAMs and Tubular just submitted it tonight as well. It's going to be interesting to see how fast we can get it to work with a secondary bank of SOP-8 footprints on the back surface (not shown), I think it's worth a try anyway. I'm no RF layout engineer that's for sure so it might not clock to its full potential, but I'm willing to give it a go. The upper section will be cut off and I can use that for some P2-EVAL header adapters to various PCBs I have.
@rogloh said:
At the end of the sequence that image is possibly coming from HUB RAM I think (but it can look like that when the RAM has no noise too). Do the drawn graphics tests work okay with no pixel noise now while they get written to the screen?
Just a couple asides about hacking up PCBs: Cut-off grinders chew through printed circuit board like they're going out of style, but make truly horrible dust. Get more mileage out of that N-95 COVID mask! (and use big ventilation fans). Hacksaws work if you don't mind the exercise (and it's hard on their blades). I'm told good things about sheet-metal brakes but I've never tried one. Also if the board house squawks about notches, put a lot of holes in a line - enough holes and it might even cheerfully snap off nicely, and if it doesn't it'll cut a lot easier. Edges are easily sanded. S.
@rogloh said:
Me too.. The 512kB SOJ-36 RAM's access time I have lying about here is rated to only 12ns so @sysclk/2 I can only clock the P2 to around 166MHz if I don't overclock it. I'll be happy enough if it reaches that speed. There are some 10ns TSSOP2 parts around from ISSI, be good to find an 8ns one but it might be harder to get.
Years ago, RAM data sheets used to identify which address lines fed the X and Y memory array axes.
The access times are a bit faster on the output-side scan, so if you know which pins those were, more over-clocking would be possible.
I see digikey now stock this
ISSI IS61WV204816BLL-10TLI SRAM Chip Async Single 2.5V/3.3V 32M-bit 2M x 16 10ns 48-Pin TSOP-I
Is it easy to allow support for that package too ?
ISSI IS61WV204816BLL-10TLI SRAM Chip Async Single 2.5V/3.3V 32M-bit 2M x 16 10ns 48-Pin TSOP-I
Is it easy to allow support for that package too ?
16 bit wide SRAM memory just needs a little more work in the driver to adjust streamer commands, but in theory it's also quite doable with lots more pins used. It's probably a better candidate for a multiplexed solution I expect. Also gets trickier to hand solder at 0.5mm pitch unless you have good eyes.
I've used some of ISSI's higher density 16 bit wide SRAMs before in a P1V memory expansion solution for the BeMicro board which worked quite well. An 8ns part would be a closer match for a 252MHz P2 outputting VGA/DVI when operated at sysclk/2 but that might be harder to come by.
@Scroungre said:
Just a couple asides about hacking up PCBs: Cut-off grinders chew through printed circuit board like they're going out of style, but make truly horrible dust. Get more mileage out of that N-95 COVID mask! (and use big ventilation fans). Hacksaws work if you don't mind the exercise (and it's hard on their blades). I'm told good things about sheet-metal brakes but I've never tried one. Also if the board house squawks about notches, put a lot of holes in a line - enough holes and it might even cheerfully snap off nicely, and if it doesn't it'll cut a lot easier. Edges are easily sanded. S.
Yes this is partially my fault I explained we have a bandsaw that is good for cutting FR4. Its good advice about the holes though, they make it easier to keep going in a straight line, as well as lowering the amount of material to be removed. No big deal for this board, but a good idea for next time
Also if the board house squawks about notches, put a lot of holes in a line - enough holes and it might even cheerfully snap off nicely, and if it doesn't it'll cut a lot easier. Edges are easily sanded.
This was the one they didn't like...I guess it was too obvious I was going to break them apart.
@Tubular said:
I think some places refer to it as a slot aspect ratio, maybe they'd accept it if the slot was wider?
I think I've seen limits like 8:1 quoted
Some like the slot to be 2mm. Or you could use v-groove. Guess it's the fact there are 2 designs. Some charge extra, some only charge for pcb area.
This looks a simple pcb. Could you perhaps have put one layout on the other side? Even if you had to use 3 kynar wire links? - No, looking closer, the ground plane is going to block this I think.
@Cluso99 said:
This looks a simple pcb. Could you perhaps have put one layout on the other side? Even if you had to use 3 kynar wire links? - No, looking closer, the ground plane is going to block this I think.
Yeah it's a very simple test board with just a single memory device on each half. Since the memories have the same basic pinout order, I originally had the two footprints interleaved on the same surface but it became a bit of a squeeze to point to point route the data bus on the top surface with a nice ground plane underneath it, and this was easy to do with just 8 mil trace and space. If I had more time and went finer to 6 mil I might have squeezed it in. But there was also a time deadline required to get this in the ordered batch so I just made it simple. Copied and rotated the design to the top and adjusted traces for the finer pitch TSSOP-2 part. Quick and easy, except they rejected it because of the slot and I so I needed to make it appear more like a single board and resubmit. Live and learn.
easier to understand how to control it for beginners, no RWDS, or special timing to worry about
no burst size/refresh limits
it's somewhat easier to DIY as HyperRAM is BGA only. Though PSRAM is easy too in SOIC and is a good choice.
SRAM downsides are:
higher costs in general
lower densities
lower bandwidth when directly addressed by P2 (sysclk/2 reads max vs sysclk/1 reads for HyperRAM)
more pins needed unless you include more complex CPLD solutions on top, or other multiplexing methods
Yes, it's a shame SRAMs with ALE and CLK never hit critical mass.
You can use vanilla parts like 74LVC161 to Latch and then count for 4-8-12 bits of index based burst readback, they are spec'd to 150MHz min, 200MHz typ
Also if the board house squawks about notches, put a lot of holes in a line - enough holes and it might even cheerfully snap off nicely, and if it doesn't it'll cut a lot easier. Edges are easily sanded.
This was the one they didn't like...I guess it was too obvious I was going to break them apart.
(removed the picture)
Ahh, the problem they had there was that it was an INTERNAL slot. They hate those. It requires Z action on the cutting head, which is very expensive in terms of cutting time (and programming time, too).
EXTERNAL slots in the outline (like you have on the top and bottom edges) they don't care about at all. Again, as pointed out, those were also rather wider, too.
They may also have had a beef with very small holes very close together (and close to the end of the slot itself. It's less important now, but back in the day there was huge pressure to use as few hole sizes as possible.
Generally, PCB houses charge by the area these days, so the ones I've worked with didn't seem to care much. I did get an email from one about "On this board there are two entirely separate layouts. You know this?" "Yes, they're a matched pair" I replied. "We're not going to cut them apart for you." "No, that's okay." "Okay."
I cut them apart on my own. Next time I'd design the slot between them smaller - I had designed for a fairly thick cutting wheel, and it made rather more dust than it had to. S.
Edited to take out my effort at ASCII art and put in a few more remarks.
Hope to solder some of this up this weekend and then test SRAM at high(er) speed. Once I order more PSRAMs I can also test my own breakout there too. I've already tested my memory driver with a couple of VonSzarvas test boards and it worked well (apart from sensitive clock leads), though my board has a different layout and could have signal reflection issues depending on where the chips are mounted. TBD.
Other small board adapters shown are for full size SD and PMOD and future Si5351 testing stuff I wanted to do.
@evanh said:
Fun fun. More tinkering than you can shake a stick at.
Yep - just finished soldering the SOJ RAM so I have an SRAM board all ready to test now. It's buzzed out okay too so my SMD soldering worked out. Pretty easy pitch.
@Tubular said:
Looks really good Roger
I just realised I have the same SD card breakout, and the PMod and si5351 are likely to come in handy too
Yes that SD card breakout is a pretty cheap one you can find around with a 5V to 3.3V reg included so it won't load the 3.3V power output. Still only SPI bus not SD.
@rogloh said:
At the end of the sequence that image is possibly coming from HUB RAM I think (but it can look like that when the RAM has no noise too). Do the drawn graphics tests work okay with no pixel noise now while they get written to the screen?
Yes all tests run without noise! Great!!
Just ran the video tests on this new test board, all that breadboard pixel noise I had seen before is gone!
This is with the P2 at 75MHz. I'll now need to push it higher until it fails. With this 12ns SRAM at sysclk/2 read rates the P2 should be able to clock over 160MHz or so, but the signal integrity could still restrict it....let me try it.
Update: Wow, 150 and 175MHz P2 speeds also both worked, but the test runs so fast now I'll need to slow them down to make sure I'm not missing some corruption.
Update2: my random read delay test seems to top out with the P2 at 303MHz, it's about twice what I expect for 12ns SRAM. Not sure if this memory really is reading that fast, or if there is a bug somewhere. Seems too good to be true. I think the SRAM driver is reading at sysclk/2 not sysclk/4 but I need to check it.
Update3: Wow I can actually get 1080p60 8bpp out of this RAM @ 277MHz, although with 512kB fitted it is not enough for the full frame. Amazing for a 12ns RAM to still read stable pixel data at 138.5MHz! I do see some shimmer at 297MHz, but my Dell monitor wants its full HD signal at 138.5MHz anyway so operating at this speed is fine.
Here's it working at 1080p (with foldover in the 512kB SRAM)
So my driver framework can now output video from either Hub RAM, HyperRAM, PSRAM, or SRAM, and you can have a mix of them too (I still need to test that but it's designed to work). Other COGs still get write access to these RAMs. It could also read region image data from HyperFlash too if needed, but that would be limited to just static image data.
That is cool. Just shows that, in good conditions, the specs are conservative. Temperature in particular will be a factor. They'll be spec'd for 70+ C, with some leeway.
Also, the timing compensation transition around 180 MHz is narrow and will shift with temperature, and board layout too. Those regions are always going to be risky to use in an automated way.
Comments
Just out of curiosity
Is there a benefit over hyperram? I mean most sram have lower access times
SRAM benefits are:
SRAM downsides are:
With @Tubular 's assistance I'm getting an SRAM breakout board design made to test SRAM driver software on the P2 with the P2-EVAL.
Here's an image of the board. It's about 3.5x3.25 inches to support the Eagle placement limit. Was designed originally to be snapped in half with a slot routed down the middle to assist with this but the fab house balked at that and wanted 8x the price, so this sneaky modification they have accepted is both halves combined with a common ground plane now and I will just need to chop it in two with some other tools.
Supports SOJ-36 SRAM or 44 pin TSSOP-II SRAM depending on which half you use. I only have the SOJ-36 RAM here right now to begin with which just goes to 512kB but the TSSOP goes up to 2MB.
It's a simple design with little care done about matching lengths etc, so I will have to see what the signal integrity is like at high speed, certainly will be better than the breadboard! Mostly just solid ground plane underneath apart from a few small traces.
Will need to fit this in the P2-EVAL from P8-P39 to deal with the clock issue on the P2 on pins 28-31. I've put the control signals up there which will limit the simultaneous transitions somewhat vs address or data.
For a 2MB setup it uses these pins:
A0-A20 = P8-P28
CS = P29
WR = P30
RD = P31
D0-D7 = P32-P39
1MB uses these pins
A0-A19 = P9-P28
CS = P29
WR = P30
RD = P31
D0-D7 = P32-P39
512kB uses these pins:
A0-A18 = P10-P28
CS = P29
WR = P30
RD = P31
D0-D7 = P32-P39
Here's a pic of what the render looks like.
Edit: Damn, I forgot the pullup on the CS pin so if it floats it could still enable the chip. No biggie for a test board like this, but it would make sense on a proper board.
Nice work, very interested in the results!
Me too.. The 512kB SOJ-36 RAM's access time I have lying about here is rated to only 12ns so @sysclk/2 I can only clock the P2 to around 166MHz if I don't overclock it. I'll be happy enough if it reaches that speed. There are some 10ns TSSOP2 parts around from ISSI, be good to find an 8ns one but it might be harder to get.
Hi rogloh, would it be possible to make a 20Mhz version of the P2@75 Mhz sramvga.bin? I am testing a new p2+sram backback setup without breadboard and short wires and like to see how that performs with vga...
Cool! Only thing I'd change is that you've acres of board space - Put in layouts for four or six chips, and you only have to install one or two. Grab a few spare pins for more chip selects, and you're off to the races! (Alternately, use more read/write pins, but that starts to cost more pins the more chips you have).
That and I have a P2 Edge and Breadboard not a P2 Eval, but that's my butt. ;-) S.
I don't have my setup handy right now to validate this (always risky), but here's a zip with hopefully what you want, i.e. running the SRAM video on a 75MHz P2 using 20MHz XTAL. I just rebuilt my last sramvideo.spin2 file, so if I've changed things in that demo since it might not be what I had running last time. It's been about a month now and I've since moved onto other things so I'm not 100% sure what state it was left in, so YMMV. It's last file change date was on 22 April, same as when the last zip was created so it's probably still the same as before.
At this stage it is just going to be a test board so I can run my driver at high speed and not be plagued by noise, and it won't get lots of chips fitted. For video use I expect PSRAM is the better option in general, though for emulator applications if you can spare the pins, the latency is better with SRAM. The console emulation thread had some numbers I figured out for HyperRAM and PSRAM access times. Direct SRAM easily beats them.
WOW - at delay 6 this works perfecly! No noise at all - and yet this is still on breadboard, I changed to a new p2 board ( retroblade2 ) and a better power supply and a new pin assignment:
Still can't believe how well this works in this kind of setup!
Really looking forward to that driver
Yes video sourced from external RAM can work nicely coming out from the P2 once it's dialled in, you should check out what PSRAM can do when I release it.
At the end of the sequence that image is possibly coming from HUB RAM I think (but it can look like that when the RAM has no noise too). Do the drawn graphics tests work okay with no pixel noise now while they get written to the screen?
My SRAM boards might arrive next week with any luck.
Today I made a new board to test PSRAM / other serial RAMs and Tubular just submitted it tonight as well. It's going to be interesting to see how fast we can get it to work with a secondary bank of SOP-8 footprints on the back surface (not shown), I think it's worth a try anyway. I'm no RF layout engineer that's for sure so it might not clock to its full potential, but I'm willing to give it a go. The upper section will be cut off and I can use that for some P2-EVAL header adapters to various PCBs I have.
Yes all tests run without noise! Great!!
Just a couple asides about hacking up PCBs: Cut-off grinders chew through printed circuit board like they're going out of style, but make truly horrible dust. Get more mileage out of that N-95 COVID mask! (and use big ventilation fans). Hacksaws work if you don't mind the exercise (and it's hard on their blades). I'm told good things about sheet-metal brakes but I've never tried one. Also if the board house squawks about notches, put a lot of holes in a line - enough holes and it might even cheerfully snap off nicely, and if it doesn't it'll cut a lot easier. Edges are easily sanded. S.
Years ago, RAM data sheets used to identify which address lines fed the X and Y memory array axes.
The access times are a bit faster on the output-side scan, so if you know which pins those were, more over-clocking would be possible.
I see digikey now stock this
ISSI IS61WV204816BLL-10TLI SRAM Chip Async Single 2.5V/3.3V 32M-bit 2M x 16 10ns 48-Pin TSOP-I
Is it easy to allow support for that package too ?
16 bit wide SRAM memory just needs a little more work in the driver to adjust streamer commands, but in theory it's also quite doable with lots more pins used. It's probably a better candidate for a multiplexed solution I expect. Also gets trickier to hand solder at 0.5mm pitch unless you have good eyes.
I've used some of ISSI's higher density 16 bit wide SRAMs before in a P1V memory expansion solution for the BeMicro board which worked quite well. An 8ns part would be a closer match for a 252MHz P2 outputting VGA/DVI when operated at sysclk/2 but that might be harder to come by.
Yes this is partially my fault I explained we have a bandsaw that is good for cutting FR4. Its good advice about the holes though, they make it easier to keep going in a straight line, as well as lowering the amount of material to be removed. No big deal for this board, but a good idea for next time
This was the one they didn't like...I guess it was too obvious I was going to break them apart.
I think some places refer to it as a slot aspect ratio, maybe they'd accept it if the slot was wider?
I think I've seen limits like 8:1 quoted
Some like the slot to be 2mm. Or you could use v-groove. Guess it's the fact there are 2 designs. Some charge extra, some only charge for pcb area.
This looks a simple pcb. Could you perhaps have put one layout on the other side? Even if you had to use 3 kynar wire links? - No, looking closer, the ground plane is going to block this I think.
Yeah it's a very simple test board with just a single memory device on each half. Since the memories have the same basic pinout order, I originally had the two footprints interleaved on the same surface but it became a bit of a squeeze to point to point route the data bus on the top surface with a nice ground plane underneath it, and this was easy to do with just 8 mil trace and space. If I had more time and went finer to 6 mil I might have squeezed it in. But there was also a time deadline required to get this in the ordered batch so I just made it simple. Copied and rotated the design to the top and adjusted traces for the finer pitch TSSOP-2 part. Quick and easy, except they rejected it because of the slot and I so I needed to make it appear more like a single board and resubmit. Live and learn.
Yes, it's a shame SRAMs with ALE and CLK never hit critical mass.
You can use vanilla parts like 74LVC161 to Latch and then count for 4-8-12 bits of index based burst readback, they are spec'd to 150MHz min, 200MHz typ
(removed the picture)
Ahh, the problem they had there was that it was an INTERNAL slot. They hate those. It requires Z action on the cutting head, which is very expensive in terms of cutting time (and programming time, too).
EXTERNAL slots in the outline (like you have on the top and bottom edges) they don't care about at all. Again, as pointed out, those were also rather wider, too.
They may also have had a beef with very small holes very close together (and close to the end of the slot itself. It's less important now, but back in the day there was huge pressure to use as few hole sizes as possible.
Generally, PCB houses charge by the area these days, so the ones I've worked with didn't seem to care much. I did get an email from one about "On this board there are two entirely separate layouts. You know this?" "Yes, they're a matched pair" I replied. "We're not going to cut them apart for you." "No, that's okay." "Okay."
I cut them apart on my own. Next time I'd design the slot between them smaller - I had designed for a fairly thick cutting wheel, and it made rather more dust than it had to. S.
Edited to take out my effort at ASCII art and put in a few more remarks.
Boards arrived to me today (thanks Tubular!).
Hope to solder some of this up this weekend and then test SRAM at high(er) speed. Once I order more PSRAMs I can also test my own breakout there too. I've already tested my memory driver with a couple of VonSzarvas test boards and it worked well (apart from sensitive clock leads), though my board has a different layout and could have signal reflection issues depending on where the chips are mounted. TBD.
Other small board adapters shown are for full size SD and PMOD and future Si5351 testing stuff I wanted to do.
Fun fun. More tinkering than you can shake a stick at.
Looks really good Roger
I just realised I have the same SD card breakout, and the PMod and si5351 are likely to come in handy too
Yep - just finished soldering the SOJ RAM so I have an SRAM board all ready to test now. It's buzzed out okay too so my SMD soldering worked out. Pretty easy pitch.
Yes that SD card breakout is a pretty cheap one you can find around with a 5V to 3.3V reg included so it won't load the 3.3V power output. Still only SPI bus not SD.
Just ran the video tests on this new test board, all that breadboard pixel noise I had seen before is gone!
This is with the P2 at 75MHz. I'll now need to push it higher until it fails. With this 12ns SRAM at sysclk/2 read rates the P2 should be able to clock over 160MHz or so, but the signal integrity could still restrict it....let me try it.
Update: Wow, 150 and 175MHz P2 speeds also both worked, but the test runs so fast now I'll need to slow them down to make sure I'm not missing some corruption.
Update2: my random read delay test seems to top out with the P2 at 303MHz, it's about twice what I expect for 12ns SRAM. Not sure if this memory really is reading that fast, or if there is a bug somewhere. Seems too good to be true. I think the SRAM driver is reading at sysclk/2 not sysclk/4 but I need to check it.
Update3: Wow I can actually get 1080p60 8bpp out of this RAM @ 277MHz, although with 512kB fitted it is not enough for the full frame. Amazing for a 12ns RAM to still read stable pixel data at 138.5MHz! I do see some shimmer at 297MHz, but my Dell monitor wants its full HD signal at 138.5MHz anyway so operating at this speed is fine.
Here's it working at 1080p (with foldover in the 512kB SRAM)
So my driver framework can now output video from either Hub RAM, HyperRAM, PSRAM, or SRAM, and you can have a mix of them too (I still need to test that but it's designed to work). Other COGs still get write access to these RAMs. It could also read region image data from HyperFlash too if needed, but that would be limited to just static image data.
WOWZERS, @rogloh !!!!
That is cool. Just shows that, in good conditions, the specs are conservative. Temperature in particular will be a factor. They'll be spec'd for 70+ C, with some leeway.
Also, the timing compensation transition around 180 MHz is narrow and will shift with temperature, and board layout too. Those regions are always going to be risky to use in an automated way.