This afternoon I tried replacing the 3V3 supply to VIO24-31 with 100nF soldered to the tops of the two 4u7F caps on the VIO_28_31 and VIO_24_27 pins. I removed the tiny 3V3 LDO regulator and supplied power from my RetroBlade2 power circuit (no P2, only the power supply) over 100mm (4") wires to the 10-pin headers for P24-31. While definitely not ideal, I thought it should help. I saw no difference in the jitter (ie the video result of failing to sync properly).
So, I concede that fitting 100nF and replacing the power supply seems to not resolve the issue here. I say "seems" because my method is not ideal to that which you would obtain if the supply was properly built on the pcb. I note that Chip's previous results with fixing the crystal pcb traces does resolve the problems.
I could not locate the gerber plots for the P2-EVAL, but because I fed the 3V3 to VIO P24-31 via the 10-pin headers, I realised that each 3V3 power line has two 4u7F caps on the two P2 pins it supplies, and in addition, the traces goes across the pcb to the 10-pin header. There are no capacitors at the 10-pin headers for bulk or bypass for any external circuit attached. Since I cannot see the gerbers, I have no idea as to the size of the traces going to the pin header. IMHO this is not ideal.
@Cluso99 said:
This afternoon I tried replacing the 3V3 supply to VIO24-31 with 100nF soldered to the tops of the two 4u7F caps on the VIO_28_31 and VIO_24_27 pins. I removed the tiny 3V3 LDO regulator and supplied power from my RetroBlade2 power circuit (no P2, only the power supply) over 100mm (4") wires to the 10-pin headers for P24-31. While definitely not ideal, I thought it should help. I saw no difference in the jitter (ie the video result of failing to sync properly).
So, I concede that fitting 100nF and replacing the power supply seems to not resolve the issue here. I say "seems" because my method is not ideal to that which you would obtain if the supply was properly built on the pcb. I note that Chip's previous results with fixing the crystal pcb traces does resolve the problems.
I could not locate the gerber plots for the P2-EVAL, but because I fed the 3V3 to VIO P24-31 via the 10-pin headers, I realised that each 3V3 power line has two 4u7F caps on the two P2 pins it supplies, and in addition, the traces goes across the pcb to the 10-pin header. There are no capacitors at the 10-pin headers for bulk or bypass for any external circuit attached. Since I cannot see the gerbers, I have no idea as to the size of the traces going to the pin header. IMHO this is not ideal.
Cluso, thanks for trying that. We will get the Gerber files up.
Chip's scope captures show it is mainly a cross-talk issue, more than a supply ripple issue.
That's why moving the crystal on elevated pins cleared the problem.
@Tubular said:
The 100nF are not likely to be small enough, if my interpretation of those C vs frequency graphs is correct
When I get another chance I’ll try 10nF but they will need to be up on wires as I don’t have them in 0402. I do have 1nF 0402 so I’ll give them a shot.
Unfortunately 0402 pads are really just too small to do much testing with them.
Chip, can you just post the tracking around the xtal corner to the vio_24-27 pin? I think there must be some vias around the regulator/caps but I cannot see them.
BTW I am amazed that the crystal routing, although far from ideal, is causing/amplifying this problem so severely. At least a routing fix is easy as the crystal can easily be repositioned much closer to the P2. Because of the internal issues, use a thicker trace to the crystal pins too - but you will still need to bring out the smaller trace from the P2 pin pad before expanding it. As we’ve progressed to finer tracking these crystal traces have suffered, although we can make them much much shorter.
@jmg said:
Chip's scope captures show it is mainly a cross-talk issue, more than a supply ripple issue.
That's why moving the crystal on elevated pins cleared the problem.
That's what we found too. The planes below and also the proximity of the planes to the xtal traces, including the via losses and for the Eval the TH pads extending beyond the signal paths.
In addition, but to a lesser extent, some ripple appears to be added by the slightly higher impedance path between the LDO and output cap. The path for the cap to discharge into the P2 is a very low impedance path, but the recharge from the LDO could be improved.
The issues manifest themselves when the 4 I/Os that share the LDO with the PLL (P28 to P31) are also performing high speed functions, such as Digital Video. Other IO pins are not impacted, so that was another clue to look at the XTAL placement & routing.
Whilst typing.. here's the latest thinking...
The main improvements on the next rev will be that the XTAL will move tight to the P2 with routing on the top layer only. Instead of the TH pads on the the EVAL, we hope to include an U.FL footprint (or part) for clock source experiments. Improved routing from the LDO to the caps will also feature. And the Edge will accept a higher voltage range, perhaps 16V or so. There will be a version of the Edge module with 32MB of PSRAM installed too. The chance of an SD socket (or footprint) has not been forgotten, although is in the "depends on" list at the moment.
Some other improvements are being considered, and will depend to some extent on the data coming from the environment testing we are running at the moment. (Of which the data will be shared here in a few days). Use of an oscillator instead of the XTAL is still a possibility and some testing and design thought is ongoing with that regard. Henrique at the live forum on Tuesday suggested a neat idea for allowing an oscillator to be put to sleep when the P2 is switched to internal RC mode, so that's keeping the oscillator option on the table!
@VonSzarvas said:
... And the Edge will accept a higher voltage range, perhaps 16V or so.
What regulator will that use ?
I noticed these newly released parts, have improved SMPS tech somewhat ( no bootstrap needed and 57-mΩ/20-mΩ ) TPS62902 3-V to 17-V, 2-A, high-efficiency and low IQ buck converter 1.5-mm × 2-mm... TPS62903 3-V to 17-V, 3-A, high-efficiency and low IQ buck converter 1.5-mm × 2-mm... TPS62912 17-VIN, 2-A low noise and low ripple buck converter with integrated ferrite... 2x2mm TPS62913 17-VIN, 3-A low noise and low ripple buck converter with integrated ferrite...2x2mm
These include a loop design that allows for a ferrite bead second stage filter, for very low ripple.
They are a bit more different in the details than the part numbers suggest, TPS6290x have a preset supply table, that includes 3v3 and 1v8
@VonSzarvas said:
The main improvements on the next rev will be that the XTAL will move tight to the P2 with routing on the top layer only. Instead of the TH pads on the the EVAL, we hope to include an U.FL footprint (or part) for clock source experiments..... Use of an oscillator instead of the XTAL is still a possibility and some testing and design thought is ongoing with that regard. Henrique at the live forum on Tuesday suggested a neat idea for allowing an oscillator to be put to sleep when the P2 is switched to internal RC mode, so that's keeping the oscillator option on the table!
It should be possible to have a 2520 footprint support Xtal or Osc, using the rules I tabled above ?
A series C would allow Clipped Sine Osc support too, and I think the series C is fine for Xtal and CMOS OSC choices too.
@VonSzarvas said:
The main improvements on the next rev will be that the XTAL will move tight to the P2 with routing on the top layer only. Instead of the TH pads on the the EVAL, we hope to include an U.FL footprint (or part) for clock source experiments.
Experimenting prolly won't need extra pads. Just use the crystal's pads.
There will be a version of the Edge module with 32MB of PSRAM installed too.
Are there varieties with DDR? DDR, specifically, holds the possibility of a data transfer per sysclock. SDR is always limited to every two sysclocks.
@evanh said:
Are there varieties with DDR? DDR, specifically, holds the possibility of a data transfer per sysclock. SDR is always limited to every two sysclocks.
Do you mean in SO-8 ?
ISSI are showing sampling of a DDR x4 part, but not in SO-8, they call Serial QUADRAM IS66WVQ8M4DBLL, IS67WVQ8M4DBLL x4 2.7~3.6V 166 MHz -40 to 125°C SOIC-16W, BGA(24) S=NOW Serial QUADRAM
Their SO-8 parts look to be SDR only ? IS66WVS4M8BLL, IS67WVS4M8BLL x1, x4 2.7~3.6V 104 MHz -40 to 105°C SOIC-8 S=NOW Serial RAM
Someone was talking about 16-bit wide PSRAM the other day, but that wasn't DDR. Compared well in performance to an 8-bit wide hyperRAM. That about all I know right now.
An Edge board with a 16-bit wide DDR PSRAM would be way cool.
@evanh said:
Someone was talking about 16-bit wide PSRAM the other day, but that wasn't DDR. Compared well in performance to an 8-bit wide hyperRAM. That about all I know right now.
An Edge board with a 16-bit wide DDR PSRAM would be way cool.
It would be, though 2x8bit HyperRAMs configured as 16 bits could get you that same performance level today - it just needs two RWDS pins which avoids those extra RMW cycles. But controlling two RWDS pins in time at the start and end of transfers gets quite a bit trickier in the code and would need another driver to deal with that.
Operating the PSRAM at SDR rates is nice on the P2 in that the write clock can always be centered in the middle of a data bit. DDR doesn't have that luxury on the P2 and needs additional HW timing delays to the clock (as you found). But it could boost performance further.
@jmg said:
@evanh said:
Are there varieties with DDR? DDR, specifically, holds the possibility of a data transfer per sysclock. SDR is always limited to every two sysclocks.
Do you mean in SO-8 ?
ISSI are showing sampling of a DDR x4 part, but not in SO-8, they call Serial QUADRAM IS66WVQ8M4DBLL, IS67WVQ8M4DBLL x4 2.7~3.6V 166 MHz -40 to 125°C SOIC-16W, BGA(24) S=NOW Serial QUADRAM
Interesting parts. That's nasty with the addressing (like HyperRAM was). I like the preamble feature, handy for timing tuning. But what performance advantage does it offer over HyperRAM? It's actual half the width so you need twice as many devices for the same bandwidth plus it still doesn't clock over 133MHz at 3V.
@rogloh said:
Operating the PSRAM at SDR rates is nice on the P2 in that the write clock can always be centered in the middle of a data bit. DDR doesn't have that luxury on the P2 and needs additional HW timing delays to the clock (as you found). But it could boost performance further.
The Edge module is exactly where I think this could be done. A tightly integrated layout could be tuned up to work at sysclock/1 data rates. For both read and write.
Oh, just looked at your board layout and realised that is 4 x 4-bit packages. I had imagined it was a single package. I guess 2 x 8-bit hyperRAM without using RWDS is equivalent.
@VonSzarvas
Thanks. I've looked at the gerbers for the P2-EVAL which are fairly similar to the P2-EDGE.
I noted that the inputs to the 3V3 LDOs seem to have only a single via to the land. If you are sticking with separate LDO's then may I suggest you add a couple more vias on the input.
Also, the outputs from these LDO's also go thru a (nice thick) track to the 10pin header(s) 3V3 pin(s). There is no bulk/bypass caps at these pins, so feedback into the P2 from external circuits is quite a possibility.I've just noticed on the P2_EVAL there are a pair of caps hiding right at the ends of the 10pin connectors. I had missed them totally
It's always a difficult problem, do you output the same 3V3 to the pins they serve on the P2? Good for trying ADC although a proper ADC design should ideally be on the same pcb. But the downside is the power rail is common, and it's a low power (current) rail, so interference from external circuitry is more likely. That's why I prefer a single supply, where all the bulk and bypass caps combine to add more protection.
We now know the VIO_28_31 is the input to this critical PLL and Oscillator section. While I haven't been able to prove any supply problem linked to this area, if you still intend using multiple LOD's, might I suggest you consider adding yet another LDO to solely supply 3V3 to just the VIO_28_31 only, with the VIO_24_27 LDO going to the 10pin header VIO_24_31. This way, the possibly critical VIO_28_31 would not be affected by any external circuitry. While not ideal, it's probably a safer solution.
Added
Wow those LDO's are tiny - the 4 pads and then a diamond thermal pad in the center make it so difficult to remove them !!! Luckily this is not a normal problem.
I just tried my external 3V3 on VIO_24_31 with 10nF and 100nF soldered on top of the pair of 4u7F caps at the VIO_24_27 and VIO28_31 pins. This does not resolve the jitter problem.
Therefore, I concede that the external power does not resolve this jitter problem.
I have absolutely no understanding of the internals of the P2 chip. I know routing the two crystal tracks is incorrect and there should have been a ground track between those pins, I had no idea that the internals and that combined could cause such a severe problem. Usually we keep crystal tracks as short as possible and as fat as practical, and have a ground isolation barrier where possible. I've really learnt something here!
FWIW IMHO there is still room for improvement with the power supply design. I just haven't been able to prove it yet.
@jmg said:
ISSI are showing sampling of a DDR x4 part, but not in SO-8, they call Serial QUADRAM IS66WVQ8M4DBLL, IS67WVQ8M4DBLL x4 2.7~3.6V 166 MHz -40 to 125°C SOIC-16W, BGA(24) S=NOW Serial QUADRAM
Interesting parts. That's nasty with the addressing (like HyperRAM was). I like the preamble feature, handy for timing tuning. But what performance advantage does it offer over HyperRAM? It's actual half the width so you need twice as many devices for the same bandwidth plus it still doesn't clock over 133MHz at 3V.
Isn't hyperRAM's default fixed latency effectively a preamble? These things seem to be pretty much the same. Even the DQSM signal looks the same as RWDS. Only difference is 4-bit vs 8-bit. On that note, looking at the package pinout, it looks like 8-bit is planned for. I can see one minor difference - the QUADRAM's command phase is SDR.
The 133 MHz limit is similar to hyperRAM v1 parts. Can we even get v2 parts yet?
EDIT: Oh, the preamble is a fixed leading data pattern on the data pins.
I don't know about v2 HyperRAM they've been promised for a while now, but not sure if/when they are appearing. @Tubular have you heard any more, with what you've been ordering lately?
Their smallest package seems too small to measure, you have to contact Microchip for actual dimensions, but going by scale it looks around 1x0.8mm. They do have a 2 pin package that is oddly larger. You wonder why they couldn't just pack it into a 0603 (or a wide 0402) package to make it easy
Oh, no. I've been reading the OctalRAM datasheet and it uses an unqualified data naming order that is only confusing, eg: d1,d0,d3,d2,... rather than a simple incrementing sequence. It's not providing anything of value to present some vague byte order for the memory data unless you're building some converter and then it'll need to be a lot more detailed. They are clear cut in the commands, addressing and register data luckily.
Funnily, the hyperRAM parts from ISS don't make this mistake.
Oddly, the OctalRAM parts are using DDR for command phase, same as hyperRAM. Compared to QuadRAM which uses SDR for command.
Is it safe to feed a 20MHz oscillator output directly to the XI pin on the revB P2-EVAL board with the crystal still fitted?
I'm trying to get it to work so I can use P28-P31 for a data bus at high speed without messing up the P2 clock frequency. Is such a solution now known to fully remedy the problem?
If I can do this, I could just solder a pin header to the P2-EVAL board pins and then feed a short ~1 inch wire off the small prototyping breakout board that can plug into P56-P63 for providing an external 20MHz oscillator some power. That would be the easiest way to get it up and running quickly I expect.
Maybe I could populate it with one of those fancy oscillators devices that are frequency adjustable and use P56,57 to control it. Would be a handy module to have lying about.
Comments
This afternoon I tried replacing the 3V3 supply to VIO24-31 with 100nF soldered to the tops of the two 4u7F caps on the VIO_28_31 and VIO_24_27 pins. I removed the tiny 3V3 LDO regulator and supplied power from my RetroBlade2 power circuit (no P2, only the power supply) over 100mm (4") wires to the 10-pin headers for P24-31. While definitely not ideal, I thought it should help. I saw no difference in the jitter (ie the video result of failing to sync properly).
So, I concede that fitting 100nF and replacing the power supply seems to not resolve the issue here. I say "seems" because my method is not ideal to that which you would obtain if the supply was properly built on the pcb. I note that Chip's previous results with fixing the crystal pcb traces does resolve the problems.
I could not locate the gerber plots for the P2-EVAL, but because I fed the 3V3 to VIO P24-31 via the 10-pin headers, I realised that each 3V3 power line has two 4u7F caps on the two P2 pins it supplies, and in addition, the traces goes across the pcb to the 10-pin header. There are no capacitors at the 10-pin headers for bulk or bypass for any external circuit attached. Since I cannot see the gerbers, I have no idea as to the size of the traces going to the pin header. IMHO this is not ideal.
Cluso, thanks for trying that. We will get the Gerber files up.
The 100nF are not likely to be small enough, if my interpretation of those C vs frequency graphs is correct
Chip's scope captures show it is mainly a cross-talk issue, more than a supply ripple issue.
That's why moving the crystal on elevated pins cleared the problem.
When I get another chance I’ll try 10nF but they will need to be up on wires as I don’t have them in 0402. I do have 1nF 0402 so I’ll give them a shot.
Unfortunately 0402 pads are really just too small to do much testing with them.
Chip, can you just post the tracking around the xtal corner to the vio_24-27 pin? I think there must be some vias around the regulator/caps but I cannot see them.
BTW I am amazed that the crystal routing, although far from ideal, is causing/amplifying this problem so severely. At least a routing fix is easy as the crystal can easily be repositioned much closer to the P2. Because of the internal issues, use a thicker trace to the crystal pins too - but you will still need to bring out the smaller trace from the P2 pin pad before expanding it. As we’ve progressed to finer tracking these crystal traces have suffered, although we can make them much much shorter.
There should be caps by each 10pin header.
Gerbers attached.
@VonSzarvas
Thanks. Ill look tomorrow as not possible on iphone
That's what we found too. The planes below and also the proximity of the planes to the xtal traces, including the via losses and for the Eval the TH pads extending beyond the signal paths.
In addition, but to a lesser extent, some ripple appears to be added by the slightly higher impedance path between the LDO and output cap. The path for the cap to discharge into the P2 is a very low impedance path, but the recharge from the LDO could be improved.
The issues manifest themselves when the 4 I/Os that share the LDO with the PLL (P28 to P31) are also performing high speed functions, such as Digital Video. Other IO pins are not impacted, so that was another clue to look at the XTAL placement & routing.
Whilst typing.. here's the latest thinking...
The main improvements on the next rev will be that the XTAL will move tight to the P2 with routing on the top layer only. Instead of the TH pads on the the EVAL, we hope to include an U.FL footprint (or part) for clock source experiments. Improved routing from the LDO to the caps will also feature. And the Edge will accept a higher voltage range, perhaps 16V or so. There will be a version of the Edge module with 32MB of PSRAM installed too. The chance of an SD socket (or footprint) has not been forgotten, although is in the "depends on" list at the moment.
Some other improvements are being considered, and will depend to some extent on the data coming from the environment testing we are running at the moment. (Of which the data will be shared here in a few days). Use of an oscillator instead of the XTAL is still a possibility and some testing and design thought is ongoing with that regard. Henrique at the live forum on Tuesday suggested a neat idea for allowing an oscillator to be put to sleep when the P2 is switched to internal RC mode, so that's keeping the oscillator option on the table!
Cool, Thanks.
Maybe a couple more years and the iPhones will have the Transformer function, into jolly buzzing yellow iPads!
What regulator will that use ?
I noticed these newly released parts, have improved SMPS tech somewhat ( no bootstrap needed and 57-mΩ/20-mΩ )
TPS62902 3-V to 17-V, 2-A, high-efficiency and low IQ buck converter 1.5-mm × 2-mm...TPS62903 3-V to 17-V, 3-A, high-efficiency and low IQ buck converter 1.5-mm × 2-mm...TPS62912 17-VIN, 2-A low noise and low ripple buck converter with integrated ferrite... 2x2mmTPS62913 17-VIN, 3-A low noise and low ripple buck converter with integrated ferrite...2x2mmThese include a loop design that allows for a ferrite bead second stage filter, for very low ripple.
They are a bit more different in the details than the part numbers suggest, TPS6290x have a preset supply table, that includes 3v3 and 1v8
Could the new version also output 5V? That'd be convenient... Maybe with the two NC pins?
Or, is it going directly to 3.3 V and not stopping at 5V?
It should be possible to have a 2520 footprint support Xtal or Osc, using the rules I tabled above ?
A series C would allow Clipped Sine Osc support too, and I think the series C is fine for Xtal and CMOS OSC choices too.
Experimenting prolly won't need extra pads. Just use the crystal's pads.
Are there varieties with DDR? DDR, specifically, holds the possibility of a data transfer per sysclock. SDR is always limited to every two sysclocks.
Do you mean in SO-8 ?
ISSI are showing sampling of a DDR x4 part, but not in SO-8, they call Serial QUADRAM
IS66WVQ8M4DBLL, IS67WVQ8M4DBLL x4 2.7~3.6V 166 MHz -40 to 125°C SOIC-16W, BGA(24) S=NOW Serial QUADRAMTheir SO-8 parts look to be SDR only ?
IS66WVS4M8BLL, IS67WVS4M8BLL x1, x4 2.7~3.6V 104 MHz -40 to 105°C SOIC-8 S=NOW Serial RAMSomeone was talking about 16-bit wide PSRAM the other day, but that wasn't DDR. Compared well in performance to an 8-bit wide hyperRAM. That about all I know right now.
An Edge board with a 16-bit wide DDR PSRAM would be way cool.
That someone might have been me, if you meant from my post here:
https://forums.parallax.com/discussion/173218/psram-vs-hyperram-testing
It would be, though 2x8bit HyperRAMs configured as 16 bits could get you that same performance level today - it just needs two RWDS pins which avoids those extra RMW cycles. But controlling two RWDS pins in time at the start and end of transfers gets quite a bit trickier in the code and would need another driver to deal with that.
Operating the PSRAM at SDR rates is nice on the P2 in that the write clock can always be centered in the middle of a data bit. DDR doesn't have that luxury on the P2 and needs additional HW timing delays to the clock (as you found). But it could boost performance further.
Interesting parts. That's nasty with the addressing (like HyperRAM was). I like the preamble feature, handy for timing tuning. But what performance advantage does it offer over HyperRAM? It's actual half the width so you need twice as many devices for the same bandwidth plus it still doesn't clock over 133MHz at 3V.
The Edge module is exactly where I think this could be done. A tightly integrated layout could be tuned up to work at sysclock/1 data rates. For both read and write.
Yep, that was it.
Oh, just looked at your board layout and realised that is 4 x 4-bit packages. I had imagined it was a single package. I guess 2 x 8-bit hyperRAM without using RWDS is equivalent.
@VonSzarvas
Thanks. I've looked at the gerbers for the P2-EVAL which are fairly similar to the P2-EDGE.
I noted that the inputs to the 3V3 LDOs seem to have only a single via to the land. If you are sticking with separate LDO's then may I suggest you add a couple more vias on the input.
Also, the outputs from these LDO's also go thru a (nice thick) track to the 10pin header(s) 3V3 pin(s). There is no bulk/bypass caps at these pins, so feedback into the P2 from external circuits is quite a possibility. I've just noticed on the P2_EVAL there are a pair of caps hiding right at the ends of the 10pin connectors. I had missed them totally
It's always a difficult problem, do you output the same 3V3 to the pins they serve on the P2? Good for trying ADC although a proper ADC design should ideally be on the same pcb. But the downside is the power rail is common, and it's a low power (current) rail, so interference from external circuitry is more likely. That's why I prefer a single supply, where all the bulk and bypass caps combine to add more protection.
We now know the VIO_28_31 is the input to this critical PLL and Oscillator section. While I haven't been able to prove any supply problem linked to this area, if you still intend using multiple LOD's, might I suggest you consider adding yet another LDO to solely supply 3V3 to just the VIO_28_31 only, with the VIO_24_27 LDO going to the 10pin header VIO_24_31. This way, the possibly critical VIO_28_31 would not be affected by any external circuitry. While not ideal, it's probably a safer solution.
Added
Wow those LDO's are tiny - the 4 pads and then a diamond thermal pad in the center make it so difficult to remove them !!! Luckily this is not a normal problem.
Chip and @VonSzarvas
I just tried my external 3V3 on VIO_24_31 with 10nF and 100nF soldered on top of the pair of 4u7F caps at the VIO_24_27 and VIO28_31 pins. This does not resolve the jitter problem.
Therefore, I concede that the external power does not resolve this jitter problem.
I have absolutely no understanding of the internals of the P2 chip. I know routing the two crystal tracks is incorrect and there should have been a ground track between those pins, I had no idea that the internals and that combined could cause such a severe problem. Usually we keep crystal tracks as short as possible and as fat as practical, and have a ground isolation barrier where possible. I've really learnt something here!
FWIW IMHO there is still room for improvement with the power supply design. I just haven't been able to prove it yet.
Isn't hyperRAM's default fixed latency effectively a preamble? These things seem to be pretty much the same. Even the DQSM signal looks the same as RWDS. Only difference is 4-bit vs 8-bit. On that note, looking at the package pinout, it looks like 8-bit is planned for. I can see one minor difference - the QUADRAM's command phase is SDR.
The 133 MHz limit is similar to hyperRAM v1 parts. Can we even get v2 parts yet?
EDIT: Oh, the preamble is a fixed leading data pattern on the data pins.
I don't know about v2 HyperRAM they've been promised for a while now, but not sure if/when they are appearing. @Tubular have you heard any more, with what you've been ordering lately?
Yes, ten v2, Hyperram 3v3, 400 Mtps are on my desk. They are winbond W956a8*
Cool. BGA is pain to assemble though.
Looking at ISS's list I see OctalRAM parts rated 166 MHz (333 MT/s) at 3.3 Volts. Sadly they're also only BGA.
They're ok to assemble, because we have a george "MoreRam" grill...
Lol, are you gonna spill the beans here...? There'll be demand I'm sure.
We probably best prove it works first.
In the meantime I've been pondering these tiny 2 pin EEPROMs that talk almost i2c, but only have two pins
https://au.mouser.com/datasheet/2/268/20005857A-1220769.pdf
Their smallest package seems too small to measure, you have to contact Microchip for actual dimensions, but going by scale it looks around 1x0.8mm. They do have a 2 pin package that is oddly larger. You wonder why they couldn't just pack it into a 0603 (or a wide 0402) package to make it easy
Oh, no. I've been reading the OctalRAM datasheet and it uses an unqualified data naming order that is only confusing, eg: d1,d0,d3,d2,... rather than a simple incrementing sequence. It's not providing anything of value to present some vague byte order for the memory data unless you're building some converter and then it'll need to be a lot more detailed. They are clear cut in the commands, addressing and register data luckily.
Funnily, the hyperRAM parts from ISS don't make this mistake.
Oddly, the OctalRAM parts are using DDR for command phase, same as hyperRAM. Compared to QuadRAM which uses SDR for command.
Is it safe to feed a 20MHz oscillator output directly to the XI pin on the revB P2-EVAL board with the crystal still fitted?
I'm trying to get it to work so I can use P28-P31 for a data bus at high speed without messing up the P2 clock frequency. Is such a solution now known to fully remedy the problem?
If I can do this, I could just solder a pin header to the P2-EVAL board pins and then feed a short ~1 inch wire off the small prototyping breakout board that can plug into P56-P63 for providing an external 20MHz oscillator some power. That would be the easiest way to get it up and running quickly I expect.
Maybe I could populate it with one of those fancy oscillators devices that are frequency adjustable and use P56,57 to control it. Would be a handy module to have lying about.