Give it a try, writes with my driver are probably okay still as they are, but if you halve the streamer rate you might get it to at least read the correct data back. Whether the game likes it that slow is another story though... but if 4 bit is fast enough now at sysclk/2 then 8 bit widths at sysclk/4 get you the same bandwidth, so maybe there is still hope for that at some point.
@rogloh said:
Give it a try, writes with my driver are probably okay still as they are, but if you halve the streamer rate you might get it to at least read the correct data back. Whether the game likes it that slow is another story though... but if 4 bit is fast enough now at sysclk/2 then 8 bit widths at sysclk/4 get you the same bandwidth, so maybe there is still hope for that at some point.
Problem is that the setup/wait phases actually make up the majority of each transaction and they don't scale. 8bit at /4 probably works, but mmmmh slowdown. Also, the hot-patching system won't work, so no Metal Slug X.
NeoYume needs 1 bank for AV, then the second bank for USB or whatever input is to be used. 8 should be enough, we can always use resistors and ADCs. One bank is SD and UART. 5 banks left. Maybe a 4 bank, 32 bit, 64 MB thing?
(and dreams about a P2+ with a dedicated memory bus, or, maybe, as in RPi Zero/1, with a (lot of) memory glued on top of it)
Yes. 32-bit bus, 4 banks+2 pins. Maybe it will need clk/4 to work, but having 32-bit bus it still can be fast enough. Pin assignment can be a problem there, these pins 28..31 which don't like fast signals may be a problem. If not, the simplest solution can be 0..33 for the PSRAM.
Boards with RAM parts onboard (eg: EC32MB) should breeze in at sysclock/2. The challenge for those layouts is to achieve sysclock/1 with DDR parts.
EDIT: That said, larger part counts (eg: 96 MBytes) will be more demanding even for onboard solutions. But a taller EC96MB board, using sysclock/2, feels like a doable feat to me. The resulting 3x16bit arrangement helps.
@Rayman said:
What about 16-bit bus, 2 chips deep for 64 MB?
Not so convenient with P2-Eval, but would be perfect for a board I'm making (If I can get to run NeoYume without dying).
I'd still go for the triple stack, since thats kinda the theorethical maximum for neoyume (since largest games top out at 64MB gfx + 16 MB adpcm + 5MB program)
I'll solder up the extra chips on one of my 64MB PSRAM test boards today and test it out to see if I can get sysclk/2 operation going with the two banks in parallel.
Currently with the single bank I can easily already achieve sysclk/2, even with P2-EVAL. It was still running at 350MHz when I tested it with really good overlap, here are the timing test results I got...
LOL. Here's a 96MB or 128MB setup...by using some extension headers passing through low profile headers on the bottom board. Not sure it would work given the trace length increases for the data bus and clock etc, but it's possibly something I can attempt in my setup if I cut/patch a CS track or two. I'll first have to scavenge more PSRAM chips. Both my test boards already have 32MB fitted and I think I have up to 11 devices available here right now including the 8 chips off VonSzarvas original test boards he sent me, or wait to order more. Firstly I need to make a board 64MB.
Probably easier to keep using VonSzarvas' test board as is rather than desolder 4 chips and cut traces...although the flying lead clock was always a bit of an issue with its length. That's why I made my own board after that. I can start with it anyway. This could also be useful to test my own boards with some extra capacitive load put on the data bus, even with the chips inactive if I tie its CE pin high, to see how they respond to that situation.
@rogloh said:
Probably easier to keep using VonSzarvas' test board as is rather than desolder 4 chips and cut traces...although the flying lead clock was always a bit of an issue with its length. That's why I made my own board after that. I can start with it anyway. This could also be useful to test my own boards with some extra capacitive load put on the data bus, even with the chips inactive if I tie its CE pin high, to see how they respond to that situation.
IMHO, better if you can hand-make a twisted pair for that clock line; but connect the ground wire just at the ram board, as to avoid a huge loop, at the worst signal so far.
P.S. a low diameter 50Ohm coax will do it even better, within the same concerns about grounding.
Found the same test sockets, from Enplas Corp., with a better price tag; now AUD 5.01 (plus AUD 6.34 shipping), directly from China. Perhaps the per-unit shipping cost can be lowered if/when buying more than one test socket per order.
By checking their design at the datasheet, I was able to be ensured that TWO ram chips will fit perfectly inside; the eventual user just needs to make sure no one (nor both) is reversed in any sense, so not to harm the test-board, not the chips themselves.
Those ones come soldered over an adapter pcb, intended for thru-hole-alike plugging, wich can be seen as moot for the actual purpose, since extra pin lengths, pcb and solder will only increase the parasytics (capacitance and inductance).
As for the datasheet, I got the links from them and downloaded the files, but not any further information of interest, besides physical dimensions. Not a single word about contact resistance, series inductance or parasytic capacitance.
Maybe those factors will mostly deppend-on DUT-related data, wich is uncertain from their standpoint.
Did a check at the equivalent product from Yamaichi, and there's the same lack of details; frightening, specially considering their higher price tags.
Both makers are good on dimmensional detailings, and basics such as number of insertion/removal cycles, insulation resistances, maximum currents and voltages the sockets would withstand. The rest is hidden in the fog.
Just soldered one chip of the 4 I need so there are now two parallel PSRAM chips on that nibble. Getting surprisingly good results (good overlapping bands) when I test both chips in 4 bit mode. Either I'm lucky with my chips, or my layout is reasonably decent (probably more a fluke than by talented PCB design ).
Here are the results for both chips from 300-340MHz. Looks quite clean. Maybe when all 4 chips are added in and operating it won't be as good due to more noise or crosstalk etc, but it's a good start so far.
@rogloh said:
Probably easier to keep using VonSzarvas' test board as is rather than desolder 4 chips and cut traces...although the flying lead clock was always a bit of an issue with its length. That's why I made my own board after that. I can start with it anyway. This could also be useful to test my own boards with some extra capacitive load put on the data bus, even with the chips inactive if I tie its CE pin high, to see how they respond to that situation.
IMHO, better if you can hand-make a twisted pair for that clock line; but connect the ground wire just at the ram board, as to avoid a huge loop, at the worst signal so far.
P.S. a low diameter 50Ohm coax will do it even better, within the same concerns about grounding.
Actually just realized (in time thankfully), that I can't use the VonSzarvas board like this, as it was designed to be fitted outside the P2-EVAL like normal boards. I would have shorted the 5V, 3.3V and GND had I tried this!
Actually just realized (in time thankfully), that I can't use the VonSzarvas board like this, as it was designed to be fitted outside the P2-EVAL like normal boards. I would have shorted the 5V, 3.3V and GND had I tried this!
Wow! Phew! Frying chips&frogs (frogs = rãns, in portuguese, wich sound like rams).
When color-identifying is not an option, I simply hate asymetric power connections; anywhere, nowhere, never liked them...
How about this? For those craving memory or bandwidth! Easily 128MB, maybe up to 192 or 256MB with a more populated memory board design. Two driver COGs, independent simultaneous 16 bit buses for highest performance.
It only leaves P24-P31 and P56-P63 IO available. Which could be okay for a composite/Svideo + audio + USB gamepad based emulator thingy. Might be slightly harder with VGA instead but doable if you go to RGBS or cut USB down to 2 or 3 pins from 4 and put audio on P56/P57 perhaps...?
Soldered in all 4 chips after pinching one more device and obtained good results for 2x16 bit banks ganged in parallel... seems okay to at least 340MHz here. So 64MB this way seems okay for Wuerfel_21's emulator. I'm going to check if I can get to 96MB though I don't really want to mod my now working boards that much by cutting traces etc.
PSRAM memory read delay test over frequency, ESC exits
Enter the base pin number for your PSRAM (0,16,32,40) [40]: 0
Enter the chip enable pin number for your PSRAM [57]: 80
Enter the clock pin number for your PSRAM [56]: 82
Enter a starting frequency to test in MHz (50-350) : [50] 330
Enter the ending frequency to test in MHz (330-350) : [350] 340
Enter 1 to use the automatic delay value only, or 0 to test over the delay range : [0] 0
Enter 1 to display the first error encountered, or 0 to not display error details : [0] 0
Testing P2 from 330000000 - 340000000 Hz
Successful data reads from 100 block transfers of 8192 random bytes
Frequency Delay 3 4 5 6 7 8 9 10 11 12 13 14
330000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 37% 100% 100% 0%
331000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%
332000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%
333000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%
334000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%
335000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%
336000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%
337000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%
338000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%
339000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%
340000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%
Enter the base pin number for your PSRAM (0,16,32,40) [40]: 0
Enter the chip enable pin number for your PSRAM [57]: 84
Enter the clock pin number for your PSRAM [56]: 86
Enter a starting frequency to test in MHz (50-350) : [50] 330
Enter the ending frequency to test in MHz (330-350) : [350] 340
Enter 1 to use the automatic delay value only, or 0 to test over the delay range : [0] 0
Enter 1 to display the first error encountered, or 0 to not display error details : [0] 0
Testing P2 from 330000000 - 340000000 Hz
Successful data reads from 100 block transfers of 8192 random bytes
Frequency Delay 3 4 5 6 7 8 9 10 11 12 13 14
330000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 34% 100% 100% 0%
331000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 2% 100% 100% 0%
332000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%
333000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%
334000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%
335000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%
336000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%
337000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%
338000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%
339000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%
340000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%
Ok so here's my 64MB board running with VonSzarvas 32MB board fitted underneath (that board's own CE is pulled high and it's clock pin was floating so it doesn't interfere). This at least loads the data bus with 3 PSRAM devices on each nibble, but not the clock, although each bank could get its own clock pin in a custom board design. You can see it tapering off around 333MHz. So based on this result I think the safer solution is just to use a 64MB board (2 parallel chips only per data bus). If you want 96MB or 128MB you'd need another data bus. Another way to go would be to have a board with two buses, one 64MB as x16 plus a separate 4 bit nibble or byte based setup up to 16/24MB that can be accessed independently. That would only need 4x8 pin headers.
Note my 64MB board runs two clocks to each bank so it only has two loads as well. I have 4 clocks and 4 CEs. One CE per byte and per PCB layer, same for the clock. This allows the lanes to be split into bytes.
Update: Admittedly the results with 3 chips could be better if all devices were populated on a good board design and it wasn't some double-decker nightmare like I am testing. We don't have such a board right now though.
@rogloh said:
Note my 64MB board runs two clocks to each bank so it only has two loads as well. I have 4 clocks and 4 CEs. One CE per byte and per PCB layer, same for the clock. This allows the lanes to be split into bytes.
A PDF of the schematic would help with comprehension.
@rogloh said:
Note my 64MB board runs two clocks to each bank so it only has two loads as well. I have 4 clocks and 4 CEs. One CE per byte and per PCB layer, same for the clock. This allows the lanes to be split into bytes.
A PDF of the schematic would help with comprehension.
Yeah normally I make one but since this board was fairly simple, unfortunately I didn't make one. At least I can't see it in my design files for this board.
Ok so imagine labeling the four top layer chips A1, A2, A3, A4 and the bottom 4 as B1, B2, B3, B4, where each side forms it's own 16 bit group. A1 and B1 share the same bus pins, A2 and B2 share, A3&B3 etc.
The CE pins connect like this:
CE0 goes to A1, A2
CE1 goes to A3, A4
CE2 goes to B1, B2
CE3 goes to B3, B4
The CLK pins connect like this:
CLK0 goes to A1, A2
CLK1 goes to A3, A4
CLK2 goes to B1, B2
CLK3 goes to B3, B4
This allows independent byte access with two drivers or access with one driver as 2 banks of 16 bits.
Here's untested goodness that allows configuring multibank for 16bit. Only supports consecutive select pins as it were, so idk if that works without bridging some or hacking the code in some way. Also IDK if multiple clocks works.
Ok, I'll try it out though think my board interleaves the control pins like this which means the chip enables are not consecutive and also they need to be pin groups...which my driver already handles. This is the incrementing control pin sequence with the numbering from above.
Comments
Far out that's slow isn't it.
Here's the reason - https://about.usps.com/newsroom/service-alerts/international/welcome.htm
I thought I'd heard something about that in the news a while back.
No, I meant I slowed down sysclock. Haven't tried lowering the actual read rate.
Give it a try, writes with my driver are probably okay still as they are, but if you halve the streamer rate you might get it to at least read the correct data back. Whether the game likes it that slow is another story though... but if 4 bit is fast enough now at sysclk/2 then 8 bit widths at sysclk/4 get you the same bandwidth, so maybe there is still hope for that at some point.
Problem is that the setup/wait phases actually make up the majority of each transaction and they don't scale. 8bit at /4 probably works, but mmmmh slowdown. Also, the hot-patching system won't work, so no Metal Slug X.
NeoYume needs 1 bank for AV, then the second bank for USB or whatever input is to be used. 8 should be enough, we can always use resistors and ADCs. One bank is SD and UART. 5 banks left. Maybe a 4 bank, 32 bit, 64 MB thing?
(and dreams about a P2+ with a dedicated memory bus, or, maybe, as in RPi Zero/1, with a (lot of) memory glued on top of it)
I really want to see a 32 bit board just for the meme. Please, someone build it! I NEED IT. Would need 5 headers on the P2Eval though.
Actual pin usage for I/O:
If you really wanted you could have all the I/O (SD card aside) on one 8pin group.
Do you mean 32-bit external memory bus?
Yes. 32-bit bus, 4 banks+2 pins. Maybe it will need clk/4 to work, but having 32-bit bus it still can be fast enough. Pin assignment can be a problem there, these pins 28..31 which don't like fast signals may be a problem. If not, the simplest solution can be 0..33 for the PSRAM.
What about 16-bit bus, 2 chips deep for 64 MB?
Not so convenient with P2-Eval, but would be perfect for a board I'm making (If I can get to run NeoYume without dying).
Boards with RAM parts onboard (eg: EC32MB) should breeze in at sysclock/2. The challenge for those layouts is to achieve sysclock/1 with DDR parts.
EDIT: That said, larger part counts (eg: 96 MBytes) will be more demanding even for onboard solutions. But a taller EC96MB board, using sysclock/2, feels like a doable feat to me. The resulting 3x16bit arrangement helps.
I'd still go for the triple stack, since thats kinda the theorethical maximum for neoyume (since largest games top out at 64MB gfx + 16 MB adpcm + 5MB program)
I'll solder up the extra chips on one of my 64MB PSRAM test boards today and test it out to see if I can get sysclk/2 operation going with the two banks in parallel.
Currently with the single bank I can easily already achieve sysclk/2, even with P2-EVAL. It was still running at 350MHz when I tested it with really good overlap, here are the timing test results I got...
https://forums.parallax.com/discussion/comment/1526283/#Comment_1526283
LOL. Here's a 96MB or 128MB setup...by using some extension headers passing through low profile headers on the bottom board. Not sure it would work given the trace length increases for the data bus and clock etc, but it's possibly something I can attempt in my setup if I cut/patch a CS track or two. I'll first have to scavenge more PSRAM chips. Both my test boards already have 32MB fitted and I think I have up to 11 devices available here right now including the 8 chips off VonSzarvas original test boards he sent me, or wait to order more. Firstly I need to make a board 64MB.
ahhhh ... sysclock/2 stats will be amusing at least.
Probably easier to keep using VonSzarvas' test board as is rather than desolder 4 chips and cut traces...although the flying lead clock was always a bit of an issue with its length. That's why I made my own board after that. I can start with it anyway. This could also be useful to test my own boards with some extra capacitive load put on the data bus, even with the chips inactive if I tie its CE pin high, to see how they respond to that situation.
IMHO, better if you can hand-make a twisted pair for that clock line; but connect the ground wire just at the ram board, as to avoid a huge loop, at the worst signal so far.
P.S. a low diameter 50Ohm coax will do it even better, within the same concerns about grounding.
Found the same test sockets, from Enplas Corp., with a better price tag; now AUD 5.01 (plus AUD 6.34 shipping), directly from China. Perhaps the per-unit shipping cost can be lowered if/when buying more than one test socket per order.
https://sunsky-online.com/p/TBD05541245/SOP16-OTS-16-1.27-03-150mil-Programmer-Adapter-Socket.htm
By checking their design at the datasheet, I was able to be ensured that TWO ram chips will fit perfectly inside; the eventual user just needs to make sure no one (nor both) is reversed in any sense, so not to harm the test-board, not the chips themselves.
Those ones come soldered over an adapter pcb, intended for thru-hole-alike plugging, wich can be seen as moot for the actual purpose, since extra pin lengths, pcb and solder will only increase the parasytics (capacitance and inductance).
As for the datasheet, I got the links from them and downloaded the files, but not any further information of interest, besides physical dimensions. Not a single word about contact resistance, series inductance or parasytic capacitance.
Maybe those factors will mostly deppend-on DUT-related data, wich is uncertain from their standpoint.
Did a check at the equivalent product from Yamaichi, and there's the same lack of details; frightening, specially considering their higher price tags.
Both makers are good on dimmensional detailings, and basics such as number of insertion/removal cycles, insulation resistances, maximum currents and voltages the sockets would withstand. The rest is hidden in the fog.
Just soldered one chip of the 4 I need so there are now two parallel PSRAM chips on that nibble. Getting surprisingly good results (good overlapping bands) when I test both chips in 4 bit mode. Either I'm lucky with my chips, or my layout is reasonably decent (probably more a fluke than by talented PCB design
).
Here are the results for both chips from 300-340MHz. Looks quite clean. Maybe when all 4 chips are added in and operating it won't be as good due to more noise or crosstalk etc, but it's a good start so far.
PSRAM 4 bit memory read delay test over frequency, ESC exits Enter the base pin number for your PSRAM (0,4,8...52) [40]: 0 Enter the chip enable pin number for your PSRAM [57]: 16 Enter the clock pin number for your PSRAM [56]: 18 Enter an additional CE/CLK P2 pin to drive high (0-55), or a higher value to exit [56]: 20 Enter an additional CE/CLK P2 pin to drive high (0-55), or a higher value to exit [56]: 56 Enter a starting frequency to test in MHz (100-350) : [100] 300 Enter the ending frequency to test in MHz (300-350) : [300] 340 Enter 1 to use the automatic delay value only, or 0 to test over the delay range : [0] 0 Enter 1 to display the first error encountered, or 0 to not display error details : [0] 0 Testing P2 from 300000000 - 340000000 Hz Successful data reads from 100 block transfers of 8192 random bytes Frequency Delay 3 4 5 6 7 8 9 10 11 12 13 14 300000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 301000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 302000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 303000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 304000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 305000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 306000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 307000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 308000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 309000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 310000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 311000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 312000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 313000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 314000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 315000000 (11) 0% 0% 0% 0% 0% 0% 0% 98% 100% 100% 0% 0% 316000000 (11) 0% 0% 0% 0% 0% 0% 0% 91% 100% 100% 0% 0% 317000000 (11) 0% 0% 0% 0% 0% 0% 0% 41% 100% 100% 0% 0% 318000000 (11) 0% 0% 0% 0% 0% 0% 0% 8% 100% 100% 0% 0% 319000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 80% 0% 320000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 321000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 322000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 323000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 324000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 325000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 326000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 327000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 328000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 329000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 330000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 331000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 332000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 333000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 334000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 335000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 336000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 337000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 338000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 339000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 340000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% Enter the base pin number for your PSRAM (0,4,8...52) [0]: 0 Enter the chip enable pin number for your PSRAM [16]: 20 Enter the clock pin number for your PSRAM [18]: 22 Enter an additional CE/CLK P2 pin to drive high (0-55), or a higher value to exit [56]: 16 Enter an additional CE/CLK P2 pin to drive high (0-55), or a higher value to exit [56]: 56 Enter a starting frequency to test in MHz (100-350) : [300] 300 Enter the ending frequency to test in MHz (300-350) : [340] 340 Enter 1 to use the automatic delay value only, or 0 to test over the delay range : [0] 0 Enter 1 to display the first error encountered, or 0 to not display error details : [0] 0 Testing P2 from 300000000 - 340000000 Hz Successful data reads from 100 block transfers of 8192 random bytes Frequency Delay 3 4 5 6 7 8 9 10 11 12 13 14 300000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 301000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 302000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 303000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 304000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 305000000 (11) 0% 0% 0% 0% 0% 0% 0% 91% 100% 100% 0% 0% 306000000 (11) 0% 0% 0% 0% 0% 0% 0% 62% 100% 100% 0% 0% 307000000 (11) 0% 0% 0% 0% 0% 0% 0% 23% 100% 100% 0% 0% 308000000 (11) 0% 0% 0% 0% 0% 0% 0% 1% 100% 100% 0% 0% 309000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 0% 310000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 99% 0% 311000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 312000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 313000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 314000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 315000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 316000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 317000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 318000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 319000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 320000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 321000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 322000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 323000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 324000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 325000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 326000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 327000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 328000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 329000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 330000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 331000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 332000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 333000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 93% 100% 100% 0% 334000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 74% 100% 100% 0% 335000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 38% 100% 100% 0% 336000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 10% 100% 100% 0% 337000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 338000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 339000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 340000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%Actually just realized (in time thankfully), that I can't use the VonSzarvas board like this, as it was designed to be fitted outside the P2-EVAL like normal boards. I would have shorted the 5V, 3.3V and GND had I tried this!
Wow! Phew! Frying chips&frogs (frogs = rãns, in portuguese, wich sound like rams).
When color-identifying is not an option, I simply hate asymetric power connections; anywhere, nowhere, never liked them...
How about this? For those craving memory or bandwidth! Easily 128MB, maybe up to 192 or 256MB with a more populated memory board design. Two driver COGs, independent simultaneous 16 bit buses for highest performance.
It only leaves P24-P31 and P56-P63 IO available. Which could be okay for a composite/Svideo + audio + USB gamepad based emulator thingy. Might be slightly harder with VGA instead but doable if you go to RGBS or cut USB down to 2 or 3 pins from 4 and put audio on P56/P57 perhaps...?
Soldered in all 4 chips after pinching one more device and obtained good results for 2x16 bit banks ganged in parallel... seems okay to at least 340MHz here. So 64MB this way seems okay for Wuerfel_21's emulator. I'm going to check if I can get to 96MB though I don't really want to mod my now working boards that much by cutting traces etc.
PSRAM memory read delay test over frequency, ESC exits Enter the base pin number for your PSRAM (0,16,32,40) [40]: 0 Enter the chip enable pin number for your PSRAM [57]: 80 Enter the clock pin number for your PSRAM [56]: 82 Enter a starting frequency to test in MHz (50-350) : [50] 330 Enter the ending frequency to test in MHz (330-350) : [350] 340 Enter 1 to use the automatic delay value only, or 0 to test over the delay range : [0] 0 Enter 1 to display the first error encountered, or 0 to not display error details : [0] 0 Testing P2 from 330000000 - 340000000 Hz Successful data reads from 100 block transfers of 8192 random bytes Frequency Delay 3 4 5 6 7 8 9 10 11 12 13 14 330000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 37% 100% 100% 0% 331000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 332000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 333000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 334000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 335000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 336000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 337000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 338000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 339000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 340000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% Enter the base pin number for your PSRAM (0,16,32,40) [40]: 0 Enter the chip enable pin number for your PSRAM [57]: 84 Enter the clock pin number for your PSRAM [56]: 86 Enter a starting frequency to test in MHz (50-350) : [50] 330 Enter the ending frequency to test in MHz (330-350) : [350] 340 Enter 1 to use the automatic delay value only, or 0 to test over the delay range : [0] 0 Enter 1 to display the first error encountered, or 0 to not display error details : [0] 0 Testing P2 from 330000000 - 340000000 Hz Successful data reads from 100 block transfers of 8192 random bytes Frequency Delay 3 4 5 6 7 8 9 10 11 12 13 14 330000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 34% 100% 100% 0% 331000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 2% 100% 100% 0% 332000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 333000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 334000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 335000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 336000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 337000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 338000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 339000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 340000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%Clean! Better than I was expecting. Hopes are raised again.
Ok so here's my 64MB board running with VonSzarvas 32MB board fitted underneath (that board's own CE is pulled high and it's clock pin was floating so it doesn't interfere). This at least loads the data bus with 3 PSRAM devices on each nibble, but not the clock, although each bank could get its own clock pin in a custom board design. You can see it tapering off around 333MHz. So based on this result I think the safer solution is just to use a 64MB board (2 parallel chips only per data bus). If you want 96MB or 128MB you'd need another data bus. Another way to go would be to have a board with two buses, one 64MB as x16 plus a separate 4 bit nibble or byte based setup up to 16/24MB that can be accessed independently. That would only need 4x8 pin headers.
Note my 64MB board runs two clocks to each bank so it only has two loads as well. I have 4 clocks and 4 CEs. One CE per byte and per PCB layer, same for the clock. This allows the lanes to be split into bytes.
Update: Admittedly the results with 3 chips could be better if all devices were populated on a good board design and it wasn't some double-decker nightmare like I am testing. We don't have such a board right now though.
Roger.
PSRAM memory read delay test over frequency, ESC exits Enter the base pin number for your PSRAM (0,16,32,40) [40]: 0 Enter the chip enable pin number for your PSRAM [57]: 84 Enter the clock pin number for your PSRAM [56]: 86 Enter a starting frequency to test in MHz (50-350) : [50] 320 Enter the ending frequency to test in MHz (320-350) : [350] 350 Enter 1 to use the automatic delay value only, or 0 to test over the delay range : [0] 0 Enter 1 to display the first error encountered, or 0 to not display error details : [0] 0 Testing P2 from 320000000 - 350000000 Hz Successful data reads from 100 block transfers of 8192 random bytes Frequency Delay 3 4 5 6 7 8 9 10 11 12 13 14 320000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 321000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 322000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 323000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 324000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 325000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 326000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 327000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 328000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 329000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 330000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 331000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 332000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 333000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 99% 0% 334000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 99% 95% 0% 335000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 95% 94% 0% 336000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 337000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 80% 74% 0% 338000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 65% 59% 0% 339000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 42% 28% 0% 340000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 341000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 4% 2% 0% 342000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 343000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 344000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 345000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 346000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 347000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 348000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 349000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 350000000 (13) 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0%A PDF of the schematic would help with comprehension.
Yeah normally I make one but since this board was fairly simple, unfortunately I didn't make one. At least I can't see it in my design files for this board.
Ok so imagine labeling the four top layer chips A1, A2, A3, A4 and the bottom 4 as B1, B2, B3, B4, where each side forms it's own 16 bit group. A1 and B1 share the same bus pins, A2 and B2 share, A3&B3 etc.
The CE pins connect like this:
CE0 goes to A1, A2
CE1 goes to A3, A4
CE2 goes to B1, B2
CE3 goes to B3, B4
The CLK pins connect like this:
CLK0 goes to A1, A2
CLK1 goes to A3, A4
CLK2 goes to B1, B2
CLK3 goes to B3, B4
This allows independent byte access with two drivers or access with one driver as 2 banks of 16 bits.
Hmm, that's only two devices loading each signal - Probably a significant factor.
Here's untested goodness that allows configuring multibank for 16bit. Only supports consecutive select pins as it were, so idk if that works without bridging some or hacking the code in some way. Also IDK if multiple clocks works.
EDIT: also published the git branch because why not: https://github.com/IRQsome/NeoYume/tree/beegram
Ok, I'll try it out though think my board interleaves the control pins like this which means the chip enables are not consecutive and also they need to be pin groups...which my driver already handles. This is the incrementing control pin sequence with the numbering from above.
CE0
CE1
CLK0
CLK1
CE2
CE3
CLK2
CLK3