Yeah we could do that. I might take a look tomorrow to validate each bank by making the LED pins the CS pins for each bank and accessing different ranges, getting late here now and I'm tiring.
Tried hardcoded, no difference. Some games go black screen instead of displaying garbage. I think the former indicates that the BIOS starts up? I think it happens on games where the bios ends up in a high half??? That'd be strange.
Ok, it just seems like nothing works right at all if address is over $800000. Even setting up two banks as mirrors and trying to write/read between them doesn't work. Seems to reproduce with the stock psram4drv, too.
EDIT: nah, seems to work now, idk. Still no good as far as second CEs.
Two things:
- I am an idiot and forgot to disable the line where it pulls high all the unused banks
- Messed with the timings for the banks in MegaYume anyways and yep, not all banks are actually reliable. Unregistered I/O improves it, but is still unstable on bank 4. Maybe I can mess around some more and find a setting that works even better... Really don't want to deal with changing anything but CS per bank.
(Also, do note that the 24MB board has some spicy slowdown in games susceptible to that sort of thing (Twinkle Star Sprites, basically). Not terrible, but certainly a bit spicier than on the P2EDGE)
@Wuerfel_21 said:
You can't route a trace inbetween the pins, right?
Could be a good bit more compact if you turn the chips sideways and route the hot signals on the bottom layer directly underneath the chips.
Though it may just be that 6 chips is too much.
The PSRAM's drive strength could easily be insufficient on these PSRAMs to have 6 chips paralleled based on Yanomani's discovery. When I get the board I will try some read back verification.
Also, be sure to try out all of P0, P16, P32 as the base pins for this 96MB board. P2 EVAL didn't have especially tightly controlled skew when we used the HyperRAM board. P16-P23 was the better location IIRC.
The fact that you got anything working is good for that MS2 demo above, at least some chips are responding (for a while). Mainly audio corruption until the crash it seemed.
Huh, I thought I read something about the 0..15 port being the one optimized for the HyperRAM board?
Anyways, will try different pin positions tomorrow. Maybe run your funny integrity test.
BTW, the 24MB setup has been running in the background for a couple hours now. I really think that one's a gooden. I think an 8bit * 3 banks setup would work out nicely for 48MB.
Relatedly, the reason the sound is so brap is because of load order.
sprite graphics
68000 program
ADPCM
fix graphics and Z80 program (only read once)
BIOS
In this case the later banks are less reliable, so it's mostly the ADPCM getting corrupted (and it may actually be crashing in a BIOS call, I don't know)
The PSRAM's drive strength could easily be insufficient on these PSRAMs to have 6 chips paralleled based on Yanomani's discovery. When I get the board I will try some read back verification.
Some snapshots from a good scope screen (>250 MHz-bandwidth) will help a lot, in determining if, and how far capacitive loading at all involved signals can be affecting those access times and delay setups.
If one can only see sine-wave-alike waveforms, then the involved lanes will sure be swamped in a muddy, capacitivelly-loaded terrain.
Please note that not only the involved connector/semiconductor pins are to be blamed alone; long traces ever contribute their share, either with more paralleled capacitance, parasitic inductance, and series resistance.
None of these factors will contribute a dime to any better behavior of the expansion boards.
@Wuerfel_21 said:
Anyways, will try different pin positions tomorrow. Maybe run your funny integrity test.
Yeah best to run the PSRAM delay test. You may need to mod it slightly to drive the unused CS pins high so they don't interfere with the DUT.
Run it from say 320-340MHz for each device so it covers your operating range. What we want to see is the same delay timing value around your frequency to be showing 100% reliable data and not that some chips are transitioning between delays at that frequency while others are stable, particularly if they are a pair of 8MB devices in a common 16MB bank. Although in your case it sounds worse because you have one delay for ALL devices, right. My driver can set the delay per bank. Maybe I could even offset with an extra delay for the secondary sub-bank but it would be harder to setup and take more cycles of overhead each request. For emulators this is not ideal given you want to minimize latency. I can see why you didn't want to do the odd/even nibble thing, that adds quite a lot of extra P2 cycles per access.
BTW, the 24MB setup has been running in the background for a couple hours now. I really think that one's a gooden. I think an 8bit * 3 banks setup would work out nicely for 48MB.
Hmm, maybe 3 loads is okay, but 6 is too much...or lots of signal reflections happening with the extra devices populated.
You could get an alternative 64MB, 96MB or 128MB board for P2-EVAL if you do what I did for my own PSRAM board and put the memory board inside the P2-EVAL footprint using 3 x 8 bit headers. This is 2, 3 (or possibly 4) 16 bit banks. You could run the clocks separately and have two 8 bit buses or ganged together using a pin group for 16 bit operation which remains flexible. It will only work with the P2 EVAL though, not the breakout for the original P2-EDGE without PSRAM. Benefit is that it has the highest performance. Downside is that you lose another 8 bit bank and it covers more of the P2-EVAL board if you wanted to see the LEDs or fit fans etc. Maybe extended pin headers would still allow a small heatsink or slim fan. With a decent double sided design I think you might be able to fit up to 128MB worth of parts, whether it works timing wise with 4 loads is TBD.
It could also be useful if you use this expansion board to simultaneously breakout VGA/audio and/or HDMI/USB? so you have an all-in-one solution for this type of emulator application. Maybe a top board the same size as P2EVAL or L shaped wired to up to 5x8 or 6x8 pin headers could give you what you want as far as expansion. You do need to be mindful of the P28-P31 thing though and not put high speed data there. Connectors like HDMI, USB and audio could possibly fit in the corners...VGA might have to overhang an unwired connector if it's too bulky to fit, or continue to use a remaining 1x8 breakout for that.
Here's one of my test boards with only half the memory actually fitted (4 chips are underneath).
About 9mm of clearance from top of P2 to bottom of memory board.
@Wuerfel_21 & @Rayman, you can try a quick memory test delay scan with 4 bit PSRAMs - I've just modded my test to support generic data bus and control pin locations now so it should suit the P2EVAL not just lock us into the P2Edge.
You can hit enter to accept the default value(s) where they are relevant and it retains their prior values each time you run through the loop, so it should be quick to test it with a bunch of different CE pin values for example if you target a smaller frequency range of interest. You can test all 12 PSRAMs this way on that 96MB and compare their delay timing results.
Only one device driver will be created at a time, using the original PSRAM4 bit driver. So that we can exercise the memory with multiple banks, but one at a time, I've added the ability to mask off certain extra CS pins by driving them high during the test. The prompt will keep asking for pins to drive high until you pass one above 55. It will also ignore any of these pins that are already setup for the PSRAM itself. Each time it restarts the outer loop it will float any of these IO pins and start the test again.
Here's a ZIP file with this, you just need to build it with flexspin and load it:
RLs-MacBook-Pro:p2memorydrv_09b-2 roger$ flexspin -2 psram4_delay_test.spin2
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2021 Total Spectrum Software Inc.
Version 5.9.3-beta-v5.9.2-33-g35412c83 Compiled on: Sep 26 2021
psram4_delay_test.spin2
|-psram4-generic.spin2
|-|-psram4drv.spin2
|-SmartSerial.spin2
|-ers_fmt.spin2
psram4_delay_test.p2asm
Done.
Program size is 87200 bytes
RLs-MacBook-Pro:p2memorydrv_09b-2 roger$ loadp2 -t psram4_delay_test.binary
( Entering terminal mode. Press Ctrl-] or Ctrl-Z to exit. )
PSRAM 4 bit memory read delay test over frequency, ESC exits
Enter the base pin number for your PSRAM (0,4,8...52) [40]: 40
Enter the chip enable pin number for your PSRAM [57]: 57
Enter the clock pin number for your PSRAM [56]: 56
Enter an additional pin to drive high (0-55), or a higher value to exit [56]: 55
Enter an additional pin to drive high (0-55), or a higher value to exit [56]: 54
Enter an additional 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] 320
Enter the ending frequency to test in MHz (320-350) : [320] 322
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 - 322000000 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 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0%
321000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0%
322000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0%
Enter the base pin number for your PSRAM (0,4,8...52) [40]:
Very interesting to see such a large device variation on the larger board. Some chips work much better than others, although this is overclocking the PSRAM after all. A delay of 13 looks like the best option for most of the parts at this frequency band of interest.
I wonder if there is any correlation with trace distance to each RAM as to which are better than others...
Pin 10 CE and pin 12 CE devices with CLK0 looks very good (CE0, CE2), the others appear to be a mixed bag with many device's transfer reliability tapering off quite a bit earlier than your operating frequency of what, something around ~338 MHz or so, right? With results like these it's no wonder the emulator is having issues.
The fact that only one delay value is working is not a good sign..ideally two of the delay column values should work (one with registered, the other with unregistered data bus pins) when the signal is not distorted. But that's not happening and the signal integrity could be a problem. Most probably load or reflections etc but it could be timing skew as well if the data bus bit paths have different lengths.
Also if you choose to stop on first error the test will print the send and received data and their xor so you can see what type of error it was, a gross error, single bit error(s), offset by 1 byte delay timing error etc.
I wonder if this can be repeated on P16-P31 to see if it helps increase the performance a bit more like we saw with HyperRAM. Although this might have been with Rev B P2-EVALs.
We cross posted with my edit.. I just added this..
Also if you choose to stop on first error the test will print the send and received data and their xor so you can see what type of error it was, a gross error, single bit error(s), offset by 1 byte delay timing error etc.
Delay=11 Test iteration 1 encountered 8192 read errors out of 8192
First error at offset 0
data sent: 1110101111011000 0101000001000010 0001110110011010 1101111010110110
data read: 1111111111011000 0101010001101110 1001110110111111 1111111111110111
difference: 0001010000000000 0000010000101100 1000000000100101 0010000101000001
0%
Delay=12 Test iteration 1 encountered 449 read errors out of 8192
First error at offset 55
data sent: 0110110110111000 0001110100100000 1011000100111110 0000001011001110
data read: 0110110110111000 0001111100100000 1011000100111111 0000001011001110
difference: 0000000000000000 0000001000000000 0000000000000001 0000000000000000
0%
Delay=13 Test iteration 7 encountered 1 read errors out of 8192
First error at offset 0
data sent: 1110010101111000 1001011100001110 1010101010001100 1010101110000010
data read: 1111010101111000 1001011100001110 1010101010001100 1010101110000010
difference: 0001000000000000 0000000000000000 0000000000000000 0000000000000000
90%
Delay=14 Test iteration 1 encountered 8192 read errors out of 8192
First error at offset 0
data sent: 1111000001000001 1010101000101000 1110101011000000 1111000011001010
data read: 1111111101000101 1010101010101010 1110111011001100 1111111111001110
difference: 0000111100000100 0000000010000010 0000010000001100 0000111100000100
0%
Ok in this case it looks like delay=12 and delay=13 were the best options but there are several bit errors. Delay=12 got 55 longs into the 8192 long test before the first error was encountered, but delay=13 hit a bit error on the first long. Looks like a signal integrity type of issue not offset by 1 nibble etc. If there was some fixed pattern to the failing bit lane it could be skew or drive strength variation among the output drivers. I already see two of the bit lanes were affected, bit 0 and bit1. Maybe these traces have more RF signal integrity issues on the board, or the driver on this chip's pins are weaker/slower etc. Hopefully at some slower frequency like 250MHz or so, all the chips work. Might be worth a quick check there too.
Just a little doubt of mine: can your driver be tweaked to execute the Write ops at the Psrams at lower frequencies (in the sense of number of P2 Sysclks spent at each High/Low level part of the whole Psrams Clk-line-periods), then execute the Read ops at the "normal" higher frequencies, as it's doing, right now?
Sure, the initial command/address phase will also need to be tweaked too, just to ensure the ram chips will get exactly what is expected for them to receive, as sent by your driver.
Ok, at least it works lower down, but the fact there are crossover regions where only one delay value seemingly works is not ideal. We used to see this with HyperRAM at sysclk/1 rates. There's not much timing margin here at all really. I think I also saw similar results initially with PSRAM with flying leads for clock pins until I made my own board and it tightened up the timing. P2-EDGE PSRAM performance is probably the best here because it has very short path lengths so it's well constrained, plus only a single load on each P2 pin.
Comments
Can't you resort to the available leds, both the ones at the Eval, or the two, at the Edge?
Yeah we could do that. I might take a look tomorrow to validate each bank by making the LED pins the CS pins for each bank and accessing different ranges, getting late here now and I'm tiring.
Tried hardcoded, no difference. Some games go black screen instead of displaying garbage. I think the former indicates that the BIOS starts up? I think it happens on games where the bios ends up in a high half??? That'd be strange.
Should probably do some sort of readback test.
Ok, it just seems like nothing works right at all if address is over $800000. Even setting up two banks as mirrors and trying to write/read between them doesn't work. Seems to reproduce with the stock psram4drv, too.
EDIT: nah, seems to work now, idk. Still no good as far as second CEs.
So here's another funny: Setting up bank 2 as mirror of bank 0, but with swapped halves.
It seems that the driver can not read correctly from the top half. That alone shouldn't break ROM loading, but I guess the issue goes a bit deeper.
Displays the pain string.
Displays nothing.
Ok, problem identified: banks over 0 don't quite work on the 96MB board, needs timing tweaked I guess.
Two things:
- I am an idiot and forgot to disable the line where it pulls high all the unused banks
- Messed with the timings for the banks in MegaYume anyways and yep, not all banks are actually reliable. Unregistered I/O improves it, but is still unstable on bank 4. Maybe I can mess around some more and find a setting that works even better... Really don't want to deal with changing anything but CS per bank.
In other words, "shits busted unless I'm missing something. Can we have a board with less funny U-Turns?".
Will see if the 24MB unit has feelings other than eternal pain.
24MB board is stable (at least to the point where it doesn't have obvious corruption and crashes >_>).
So here's neoyume with multi-bank support.
Very good to hear! At least the 24MB one's a go.
You can't route a trace inbetween the pins, right?
Could be a good bit more compact if you turn the chips sideways and route the hot signals on the bottom layer directly underneath the chips.
Though it may just be that 6 chips is too much.
(Also, do note that the 24MB board has some spicy slowdown in games susceptible to that sort of thing (Twinkle Star Sprites, basically). Not terrible, but certainly a bit spicier than on the P2EDGE)
The PSRAM's drive strength could easily be insufficient on these PSRAMs to have 6 chips paralleled based on Yanomani's discovery. When I get the board I will try some read back verification.
Also, be sure to try out all of P0, P16, P32 as the base pins for this 96MB board. P2 EVAL didn't have especially tightly controlled skew when we used the HyperRAM board. P16-P23 was the better location IIRC.
The fact that you got anything working is good for that MS2 demo above, at least some chips are responding (for a while). Mainly audio corruption until the crash it seemed.
Huh, I thought I read something about the 0..15 port being the one optimized for the HyperRAM board?
Anyways, will try different pin positions tomorrow. Maybe run your funny integrity test.
BTW, the 24MB setup has been running in the background for a couple hours now. I really think that one's a gooden. I think an 8bit * 3 banks setup would work out nicely for 48MB.
Relatedly, the reason the sound is so brap is because of load order.
In this case the later banks are less reliable, so it's mostly the ADPCM getting corrupted (and it may actually be crashing in a BIOS call, I don't know)
Some snapshots from a good scope screen (>250 MHz-bandwidth) will help a lot, in determining if, and how far capacitive loading at all involved signals can be affecting those access times and delay setups.
If one can only see sine-wave-alike waveforms, then the involved lanes will sure be swamped in a muddy, capacitivelly-loaded terrain.
Please note that not only the involved connector/semiconductor pins are to be blamed alone; long traces ever contribute their share, either with more paralleled capacitance, parasitic inductance, and series resistance.
None of these factors will contribute a dime to any better behavior of the expansion boards.
A good reference from Cypress (now Infineon):
https://infineon.com/dgdl/Infineon-AN98567_Understanding_Load_Capacitance_and_Access_Time-ApplicationNotes-v03_00-EN.pdf?fileId=8ac78c8c7cdc391c017d074259566561
Yeah best to run the PSRAM delay test. You may need to mod it slightly to drive the unused CS pins high so they don't interfere with the DUT.
Run it from say 320-340MHz for each device so it covers your operating range. What we want to see is the same delay timing value around your frequency to be showing 100% reliable data and not that some chips are transitioning between delays at that frequency while others are stable, particularly if they are a pair of 8MB devices in a common 16MB bank. Although in your case it sounds worse because you have one delay for ALL devices, right. My driver can set the delay per bank. Maybe I could even offset with an extra delay for the secondary sub-bank but it would be harder to setup and take more cycles of overhead each request. For emulators this is not ideal given you want to minimize latency. I can see why you didn't want to do the odd/even nibble thing, that adds quite a lot of extra P2 cycles per access.
Hmm, maybe 3 loads is okay, but 6 is too much...or lots of signal reflections happening with the extra devices populated.
You could get an alternative 64MB, 96MB or 128MB board for P2-EVAL if you do what I did for my own PSRAM board and put the memory board inside the P2-EVAL footprint using 3 x 8 bit headers. This is 2, 3 (or possibly 4) 16 bit banks. You could run the clocks separately and have two 8 bit buses or ganged together using a pin group for 16 bit operation which remains flexible. It will only work with the P2 EVAL though, not the breakout for the original P2-EDGE without PSRAM. Benefit is that it has the highest performance. Downside is that you lose another 8 bit bank and it covers more of the P2-EVAL board if you wanted to see the LEDs or fit fans etc. Maybe extended pin headers would still allow a small heatsink or slim fan. With a decent double sided design I think you might be able to fit up to 128MB worth of parts, whether it works timing wise with 4 loads is TBD.
It could also be useful if you use this expansion board to simultaneously breakout VGA/audio and/or HDMI/USB? so you have an all-in-one solution for this type of emulator application. Maybe a top board the same size as P2EVAL or L shaped wired to up to 5x8 or 6x8 pin headers could give you what you want as far as expansion. You do need to be mindful of the P28-P31 thing though and not put high speed data there. Connectors like HDMI, USB and audio could possibly fit in the corners...VGA might have to overhang an unwired connector if it's too bulky to fit, or continue to use a remaining 1x8 breakout for that.
Here's one of my test boards with only half the memory actually fitted (4 chips are underneath).
About 9mm of clearance from top of P2 to bottom of memory board.
Earlier work:
https://forums.parallax.com/discussion/comment/1523795/#Comment_1523795
@Wuerfel_21 & @Rayman, you can try a quick memory test delay scan with 4 bit PSRAMs - I've just modded my test to support generic data bus and control pin locations now so it should suit the P2EVAL not just lock us into the P2Edge.
You can hit enter to accept the default value(s) where they are relevant and it retains their prior values each time you run through the loop, so it should be quick to test it with a bunch of different CE pin values for example if you target a smaller frequency range of interest. You can test all 12 PSRAMs this way on that 96MB and compare their delay timing results.
Only one device driver will be created at a time, using the original PSRAM4 bit driver. So that we can exercise the memory with multiple banks, but one at a time, I've added the ability to mask off certain extra CS pins by driving them high during the test. The prompt will keep asking for pins to drive high until you pass one above 55. It will also ignore any of these pins that are already setup for the PSRAM itself. Each time it restarts the outer loop it will float any of these IO pins and start the test again.
Here's a ZIP file with this, you just need to build it with flexspin and load it:
RLs-MacBook-Pro:p2memorydrv_09b-2 roger$ flexspin -2 psram4_delay_test.spin2 Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2021 Total Spectrum Software Inc. Version 5.9.3-beta-v5.9.2-33-g35412c83 Compiled on: Sep 26 2021 psram4_delay_test.spin2 |-psram4-generic.spin2 |-|-psram4drv.spin2 |-SmartSerial.spin2 |-ers_fmt.spin2 psram4_delay_test.p2asm Done. Program size is 87200 bytes RLs-MacBook-Pro:p2memorydrv_09b-2 roger$ loadp2 -t psram4_delay_test.binary ( Entering terminal mode. Press Ctrl-] or Ctrl-Z to exit. ) PSRAM 4 bit memory read delay test over frequency, ESC exits Enter the base pin number for your PSRAM (0,4,8...52) [40]: 40 Enter the chip enable pin number for your PSRAM [57]: 57 Enter the clock pin number for your PSRAM [56]: 56 Enter an additional pin to drive high (0-55), or a higher value to exit [56]: 55 Enter an additional pin to drive high (0-55), or a higher value to exit [56]: 54 Enter an additional 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] 320 Enter the ending frequency to test in MHz (320-350) : [320] 322 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 - 322000000 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 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 321000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% 322000000 (11) 0% 0% 0% 0% 0% 0% 0% 100% 100% 100% 0% 0% Enter the base pin number for your PSRAM (0,4,8...52) [40]:Okay, result for the 24MB board.
$ loadp2 -p COM8 -t psram4_delay_test.binary ( Entering terminal mode. Press Ctrl-] to exit. ) 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]: 5 Enter the clock pin number for your PSRAM [56]: 4 Enter an additional CE/CLK P2 pin to drive high (0-55), or a higher value to exit [56]: 6 Enter an additional CE/CLK P2 pin to drive high (0-55), or a higher value to exit [56]: 7 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] 320 Enter the ending frequency to test in MHz (320-350) : [320] 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 (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% 97% 100% 100% 0% 341000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 64% 100% 100% 0% 342000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 343000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 344000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 345000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 346000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 347000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 348000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 349000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 350000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 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 [5]: 6 Enter the clock pin number for your PSRAM [4]: 4 Enter an additional CE/CLK P2 pin to drive high (0-55), or a higher value to exit [56]: 5 Enter an additional CE/CLK P2 pin to drive high (0-55), or a higher value to exit [56]: 7 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) : [320] 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 (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% 341000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 96% 100% 100% 0% 342000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 52% 100% 100% 0% 343000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 5% 100% 100% 0% 344000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 345000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 346000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 347000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 348000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 349000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 350000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 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 [6]: 7 Enter the clock pin number for your PSRAM [4]: 4 Enter an additional CE/CLK P2 pin to drive high (0-55), or a higher value to exit [56]: 5 Enter an additional CE/CLK P2 pin to drive high (0-55), or a higher value to exit [56]: 6 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) : [320] 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 (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% 98% 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% 98% 100% 100% 0% 334000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 95% 100% 100% 0% 335000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 89% 100% 100% 0% 336000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 76% 100% 100% 0% 337000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 66% 100% 100% 0% 338000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 23% 100% 100% 0% 339000000 (11) 0% 0% 0% 0% 0% 0% 0% 0% 1% 100% 100% 0% 340000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 341000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 342000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 343000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 344000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 345000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 346000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 347000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 348000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 349000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0% 350000000 (12) 0% 0% 0% 0% 0% 0% 0% 0% 0% 100% 100% 0%Forum chokes on big log, so gist: https://gist.github.com/Wuerfel21/0e89677f0c2fafb0644cca2fdf55f783
Very interesting to see such a large device variation on the larger board. Some chips work much better than others, although this is overclocking the PSRAM after all. A delay of 13 looks like the best option for most of the parts at this frequency band of interest.
I wonder if there is any correlation with trace distance to each RAM as to which are better than others...
Pin 10 CE and pin 12 CE devices with CLK0 looks very good (CE0, CE2), the others appear to be a mixed bag with many device's transfer reliability tapering off quite a bit earlier than your operating frequency of what, something around ~338 MHz or so, right? With results like these it's no wonder the emulator is having issues.
The fact that only one delay value is working is not a good sign..ideally two of the delay column values should work (one with registered, the other with unregistered data bus pins) when the signal is not distorted. But that's not happening and the signal integrity could be a problem. Most probably load or reflections etc but it could be timing skew as well if the data bus bit paths have different lengths.
Also if you choose to stop on first error the test will print the send and received data and their xor so you can see what type of error it was, a gross error, single bit error(s), offset by 1 byte delay timing error etc.
I wonder if this can be repeated on P16-P31 to see if it helps increase the performance a bit more like we saw with HyperRAM. Although this might have been with Rev B P2-EVALs.
I wonder why 14 is just solid zeroes?
I did try on P16 and it is slightly better I think, but not really.
We cross posted with my edit.. I just added this..
Yeah that did look a bit weird. Although it didn't work for the 24MB board either so it's probably too slow a delay in general.
338MHz, Bank 4, low nibble, on P0
Ok in this case it looks like delay=12 and delay=13 were the best options but there are several bit errors. Delay=12 got 55 longs into the 8192 long test before the first error was encountered, but delay=13 hit a bit error on the first long. Looks like a signal integrity type of issue not offset by 1 nibble etc. If there was some fixed pattern to the failing bit lane it could be skew or drive strength variation among the output drivers. I already see two of the bit lanes were affected, bit 0 and bit1. Maybe these traces have more RF signal integrity issues on the board, or the driver on this chip's pins are weaker/slower etc. Hopefully at some slower frequency like 250MHz or so, all the chips work. Might be worth a quick check there too.
Hi @rogloh
Just a little doubt of mine: can your driver be tweaked to execute the Write ops at the Psrams at lower frequencies (in the sense of number of P2 Sysclks spent at each High/Low level part of the whole Psrams Clk-line-periods), then execute the Read ops at the "normal" higher frequencies, as it's doing, right now?
Sure, the initial command/address phase will also need to be tweaked too, just to ensure the ram chips will get exactly what is expected for them to receive, as sent by your driver.
Enter the base pin number for your PSRAM (0,4,8...52) [0]: 0 Enter the chip enable pin number for your PSRAM [14]: 14 Enter the clock pin number for your PSRAM [8]: 8 Enter an additional CE/CLK P2 pin to drive high (0-55), or a higher value to exit [56]: 10 Enter an additional CE/CLK P2 pin to drive high (0-55), or a higher value to exit [56]: 11 Enter an additional CE/CLK P2 pin to drive high (0-55), or a higher value to exit [56]: 12 Enter an additional CE/CLK P2 pin to drive high (0-55), or a higher value to exit [56]: 13 Enter an additional CE/CLK P2 pin to drive high (0-55), or a higher value to exit [56]: 15 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) : [338] 180 Enter the ending frequency to test in MHz (180-350) : [338] 330 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 180000000 - 330000000 Hz Successful data reads from 100 block transfers of 8192 random bytes Frequency Delay 8 9 10 11 12 13 14 180000000 (8) 0% 100% 100% 0% 0% 0% 0% 181000000 (8) 0% 100% 100% 0% 0% 0% 0% 182000000 (8) 0% 100% 100% 0% 0% 0% 0% 183000000 (8) 0% 100% 100% 0% 0% 0% 0% 184000000 (8) 0% 100% 100% 0% 0% 0% 0% 185000000 (8) 0% 100% 100% 0% 0% 0% 0% 186000000 (8) 0% 100% 100% 0% 0% 0% 0% 187000000 (8) 0% 100% 100% 0% 0% 0% 0% 188000000 (8) 0% 100% 100% 0% 0% 0% 0% 189000000 (8) 0% 100% 100% 0% 0% 0% 0% 190000000 (9) 0% 100% 100% 0% 0% 0% 0% 191000000 (9) 0% 100% 100% 0% 0% 0% 0% 192000000 (9) 0% 100% 100% 0% 0% 0% 0% 193000000 (9) 0% 100% 100% 0% 0% 0% 0% 194000000 (9) 0% 100% 100% 0% 0% 0% 0% 195000000 (9) 0% 100% 100% 1% 0% 0% 0% 196000000 (9) 0% 100% 100% 0% 0% 0% 0% 197000000 (9) 0% 100% 100% 10% 0% 0% 0% 198000000 (9) 0% 100% 100% 61% 0% 0% 0% 199000000 (9) 0% 100% 100% 99% 0% 0% 0% 200000000 (9) 0% 100% 100% 100% 0% 0% 0% 201000000 (9) 0% 100% 100% 100% 0% 0% 0% 202000000 (9) 0% 100% 100% 100% 0% 0% 0% 203000000 (9) 0% 100% 100% 100% 0% 0% 0% 204000000 (9) 0% 100% 100% 100% 0% 0% 0% 205000000 (9) 0% 100% 100% 100% 0% 0% 0% 206000000 (9) 0% 99% 100% 100% 0% 0% 0% 207000000 (9) 0% 94% 100% 100% 0% 0% 0% 208000000 (9) 0% 77% 100% 100% 0% 0% 0% 209000000 (9) 0% 22% 100% 100% 0% 0% 0% 210000000 (9) 0% 1% 100% 100% 0% 0% 0% 211000000 (9) 0% 0% 100% 100% 0% 0% 0% 212000000 (9) 0% 0% 100% 100% 0% 0% 0% 213000000 (9) 0% 0% 100% 100% 0% 0% 0% 214000000 (9) 0% 0% 100% 100% 0% 0% 0% 215000000 (9) 0% 0% 100% 100% 0% 0% 0% 216000000 (9) 0% 0% 100% 100% 0% 0% 0% 217000000 (9) 0% 0% 100% 100% 0% 0% 0% 218000000 (9) 0% 0% 100% 100% 0% 0% 0% 219000000 (9) 0% 0% 100% 100% 0% 0% 0% 220000000 (9) 0% 0% 100% 100% 0% 0% 0% 221000000 (9) 0% 0% 100% 100% 0% 0% 0% 222000000 (9) 0% 0% 100% 100% 0% 0% 0% 223000000 (9) 0% 0% 100% 100% 0% 0% 0% 224000000 (9) 0% 0% 100% 100% 0% 0% 0% 225000000 (9) 0% 0% 100% 100% 0% 0% 0% 226000000 (9) 0% 0% 100% 100% 0% 0% 0% 227000000 (9) 0% 0% 100% 100% 0% 0% 0% 228000000 (9) 0% 0% 100% 100% 0% 0% 0% 229000000 (9) 0% 0% 100% 100% 0% 0% 0% 230000000 (9) 0% 0% 100% 100% 0% 0% 0% 231000000 (9) 0% 0% 100% 100% 0% 0% 0% 232000000 (9) 0% 0% 100% 100% 0% 0% 0% 233000000 (9) 0% 0% 100% 100% 0% 0% 0% 234000000 (9) 0% 0% 100% 100% 0% 0% 0% 235000000 (9) 0% 0% 100% 100% 0% 0% 0% 236000000 (9) 0% 0% 100% 100% 0% 0% 0% 237000000 (9) 0% 0% 100% 100% 0% 0% 0% 238000000 (9) 0% 0% 100% 100% 0% 0% 0% 239000000 (9) 0% 0% 100% 100% 0% 0% 0% 240000000 (10) 0% 0% 100% 100% 0% 0% 0% 241000000 (10) 0% 0% 100% 100% 0% 0% 0% 242000000 (10) 0% 0% 100% 100% 0% 0% 0% 243000000 (10) 0% 0% 100% 100% 0% 0% 0% 244000000 (10) 0% 0% 98% 100% 0% 0% 0% 245000000 (10) 0% 0% 96% 100% 0% 0% 0% 246000000 (10) 0% 0% 96% 100% 0% 0% 0% 247000000 (10) 0% 0% 80% 100% 0% 0% 0% 248000000 (10) 0% 0% 47% 100% 0% 0% 0% 249000000 (10) 0% 0% 8% 100% 0% 0% 0% 250000000 (10) 0% 0% 0% 100% 0% 0% 0% 251000000 (10) 0% 0% 0% 100% 0% 0% 0% 252000000 (10) 0% 0% 0% 100% 0% 0% 0% 253000000 (10) 0% 0% 0% 100% 0% 0% 0% 254000000 (10) 0% 0% 0% 100% 0% 0% 0% 255000000 (10) 0% 0% 0% 100% 0% 0% 0% 256000000 (10) 0% 0% 0% 100% 0% 0% 0% 257000000 (10) 0% 0% 0% 100% 0% 0% 0% 258000000 (10) 0% 0% 0% 100% 0% 0% 0% 259000000 (10) 0% 0% 0% 100% 0% 0% 0% 260000000 (10) 0% 0% 0% 100% 0% 0% 0% 261000000 (10) 0% 0% 0% 100% 28% 0% 0% 262000000 (10) 0% 0% 0% 100% 94% 0% 0% 263000000 (10) 0% 0% 0% 100% 100% 0% 0% 264000000 (10) 0% 0% 0% 100% 100% 0% 0% 265000000 (10) 0% 0% 0% 100% 100% 0% 0% 266000000 (10) 0% 0% 0% 100% 100% 0% 0% 267000000 (10) 0% 0% 0% 100% 100% 0% 0% 268000000 (10) 0% 0% 0% 100% 100% 0% 0% 269000000 (10) 0% 0% 0% 100% 100% 0% 0% 270000000 (10) 0% 0% 0% 100% 100% 0% 0% 271000000 (10) 0% 0% 0% 100% 100% 0% 0% 272000000 (10) 0% 0% 0% 100% 100% 0% 0% 273000000 (10) 0% 0% 0% 100% 100% 0% 0% 274000000 (10) 0% 0% 0% 100% 100% 0% 0% 275000000 (10) 0% 0% 0% 100% 100% 0% 0% 276000000 (10) 0% 0% 0% 100% 100% 0% 0% 277000000 (10) 0% 0% 0% 96% 100% 0% 0% 278000000 (10) 0% 0% 0% 93% 100% 0% 0% 279000000 (10) 0% 0% 0% 80% 100% 0% 0% 280000000 (10) 0% 0% 0% 65% 100% 0% 0% 281000000 (10) 0% 0% 0% 30% 100% 0% 0% 282000000 (10) 0% 0% 0% 3% 100% 0% 0% 283000000 (10) 0% 0% 0% 0% 100% 0% 0% 284000000 (10) 0% 0% 0% 0% 100% 0% 0% 285000000 (10) 0% 0% 0% 0% 100% 0% 0% 286000000 (10) 0% 0% 0% 0% 100% 0% 0% 287000000 (10) 0% 0% 0% 0% 100% 0% 0% 288000000 (10) 0% 0% 0% 0% 100% 0% 0% 289000000 (10) 0% 0% 0% 0% 100% 0% 0% 290000000 (11) 0% 0% 0% 0% 100% 0% 0% 291000000 (11) 0% 0% 0% 0% 100% 0% 0% 292000000 (11) 0% 0% 0% 0% 100% 0% 0% 293000000 (11) 0% 0% 0% 0% 100% 0% 0% 294000000 (11) 0% 0% 0% 0% 100% 0% 0% 295000000 (11) 0% 0% 0% 0% 100% 0% 0% 296000000 (11) 0% 0% 0% 0% 100% 0% 0% 297000000 (11) 0% 0% 0% 0% 100% 0% 0% 298000000 (11) 0% 0% 0% 0% 100% 0% 0% 299000000 (11) 0% 0% 0% 0% 100% 0% 0% 300000000 (11) 0% 0% 0% 0% 100% 0% 0% 301000000 (11) 0% 0% 0% 0% 100% 0% 0% 302000000 (11) 0% 0% 0% 0% 100% 0% 0% 303000000 (11) 0% 0% 0% 0% 100% 8% 0% 304000000 (11) 0% 0% 0% 0% 100% 95% 0% 305000000 (11) 0% 0% 0% 0% 100% 100% 0% 306000000 (11) 0% 0% 0% 0% 100% 100% 0% 307000000 (11) 0% 0% 0% 0% 100% 100% 0% 308000000 (11) 0% 0% 0% 0% 100% 100% 0% 309000000 (11) 0% 0% 0% 0% 100% 100% 0% 310000000 (11) 0% 0% 0% 0% 100% 100% 0% 311000000 (11) 0% 0% 0% 0% 100% 100% 0% 312000000 (11) 0% 0% 0% 0% 100% 100% 0% 313000000 (11) 0% 0% 0% 0% 100% 100% 0% 314000000 (11) 0% 0% 0% 0% 100% 100% 0% 315000000 (11) 0% 0% 0% 0% 100% 100% 0% 316000000 (11) 0% 0% 0% 0% 99% 100% 0% 317000000 (11) 0% 0% 0% 0% 97% 100% 0% 318000000 (11) 0% 0% 0% 0% 98% 100% 0% 319000000 (11) 0% 0% 0% 0% 97% 100% 0% 320000000 (11) 0% 0% 0% 0% 92% 100% 0% 321000000 (11) 0% 0% 0% 0% 91% 100% 0% 322000000 (11) 0% 0% 0% 0% 79% 100% 0% 323000000 (11) 0% 0% 0% 0% 62% 100% 0% 324000000 (11) 0% 0% 0% 0% 27% 100% 0% 325000000 (11) 0% 0% 0% 0% 14% 100% 0% 326000000 (11) 0% 0% 0% 0% 1% 100% 0% 327000000 (11) 0% 0% 0% 0% 0% 100% 0% 328000000 (11) 0% 0% 0% 0% 0% 99% 0% 329000000 (11) 0% 0% 0% 0% 0% 100% 0% 330000000 (11) 0% 0% 0% 0% 0% 100% 0%Ok, at least it works lower down, but the fact there are crossover regions where only one delay value seemingly works is not ideal. We used to see this with HyperRAM at sysclk/1 rates. There's not much timing margin here at all really. I think I also saw similar results initially with PSRAM with flying leads for clock pins until I made my own board and it tightened up the timing. P2-EDGE PSRAM performance is probably the best here because it has very short path lengths so it's well constrained, plus only a single load on each P2 pin.