Price I don't know about yet. Hoping they can be similar at least.
But, PCB was $14 each for Qty.50 and P2 is $16.
The real issue is the DC-DC converter chip at $14 each. It's something special with integrated inductor, but you have to pay for that.
Also, it seems to be a rare thing and could go out of stock at any time...
A smaller difference perhaps is the 8-bit bus hyperram vs 16-bit bus PSRAM. HyperRam uses less pins, so that is good.
Also, can turn off hyperram if you don't need it and get those pins back.
Suppose the RTC module is a another, perhaps less important, but useful feature for things I'm doing.
Nice to have the actual time for datalogging...
@Rayman said:
Also, can turn off hyperram if you don't need it and get those pins back.
That frustrated me a little when I realised that was so. HyperRAM is most effective when paired with fastest sysclock/1 timings. Any degradation from track length will reduce effectiveness.
I guess I should invest some time experimenting how well the P2Stamp's arrangement works when those PLCC contacts aren't connected. I'll need to solder it into place ... which means I need to do a carrier board layout too ...
@Rayman said:
Also, can turn off hyperram if you don't need it and get those pins back.
That frustrated me a little when I realised that was so. HyperRAM is most effective when paired with fastest sysclock/1 timings. Any degradation from track length will reduce effectiveness.
Is there any board that really manages sysclk/1 (at useful sysclk)?
Also when looking through those datasheets, I realized that with the output clocks we're running at sysclk/2, we should really set the latency count to 3. I think both my code and Roger's driver just rely on the default 6 or 7 setting, which is quite terrible.
(incidentally, with that allegedly upcoming 16x chip, if you could run it sysclk/1, you'd beat the EC32MB in bandwidth)
@Wuerfel_21 said:
Is there any board that really manages sysclk/1 (at useful sysclk)?
No, but there's only the one - An Eval add-on, implicit long tracks ... and data pins shared with HyperFlash chip makes the clock lead the data, which is in conflict with using a clock lagging capacitor or resistor.
@evanh I have both the Eval add-on and the P2STAMP, so that's two already. I usually use the former to test my HyperRAM codepaths - though I'm not sure how many people actually have the Hyper add-on board, like, is it worth the trouble?
@Wuerfel_21 said:
Also when looking through those datasheets, I realized that with the output clocks we're running at sysclk/2, we should really set the latency count to 3. I think both my code and Roger's driver just rely on the default 6 or 7 setting, which is quite terrible.
(incidentally, with that allegedly upcoming 16x chip, if you could run it sysclk/1, you'd beat the EC32MB in bandwidth)
I believe I had an API that can change the latency count for HyperRAM but it's not automatic configured based on P2 frequency so probably just defaults to the reset startup value by default. I've not looked at any HyperRAM for quite some time. I vaguely recall that the memory on the P2 Stamp I received had a slightly different timing to the original V1 HyperRAM the driver was based on and may have needed a tweak in the code to set it correctly.
Ye, the winbond part on the stamp defaults to 7 cycles, the eval addon defaults to 6 cycles. The exact given clock limit for 3 cycle seems to not be consistent between manufacturers, but 4 cycles is always safe for P2 sysclk/2 operation. For not-so-extreme overclocking, 3 cycles is the way. Should maybe figure this out next time I work with HyperRAM.
@Rayman said:
Edge and this are very similar.
Guess the real benefit is size.
Stamp is ~1.25"x1.25" for an area of 1.56 sq.in., if mounted using headers instead of PLCC-80 socket.
Edge (with uSD and PSRAM) is ~2.2" x 2.2" for an area of 4.8 sq.in.
So, that's a big difference, 3X smaller...
Yes, smaller and flatter if I cut out my board so this can solder down flush. My applications end up really dense, looking like this: (Yes, these just use P1)
Yes, this top photo is a tester for an entire panel of 10 units to be tested. The panel is 11-1/2"X11-1/2" The largest size our MFG plant wants to tackle.
The one being wired (bottom photo) is for a panel of 20 units in a similar size. The 'Spikes' apply pressure and when the lid is closed, those cams (Metal with angled slots) will motor forward, tightening the lid straight down with up to 30 KG of force to compress all the spring supports and 'pogos' that will make contact with the test points on the units.
Each unit gets it's own P1 board that does the entire inspection, then reports the results to the OBC that informs the operator that everything passed, or which units failed, and why. Those boards are custom for this line.
There are commercial units to do all of this, but MFG wants this linear close, and the number of test points demands some motorized help closing. We can build this for a fraction of the cost of the 'big boys'.
I've started testing the HyperRAM on this P2Stamp module. Looks like stability of the Prop2 itself hits a brick wall at around 360 MHz sysclock - Drawing 1.1 Watt from the 12 Volt supply so shouldn't be the onboard LTM4622 regulator limiting things. It's good for delivering 2.5 Amps x 1.8 Volts = 4.5 Watts. It's actually behaving like thermally crashing but there's no heat that I've noticed, so not too sure of why just yet.
I just measured the 1v8 rail and it is 1.81 Volts. Comparing to my testing Eval board which is 1.86 Volts and can achieve 370 MHz with light loads. That small difference in voltage right there may explain the difference in useable max frequency. I'd entirely overlooked this interaction in the past.
That's fine really. Its heat-sinking ability is limited, so when compute loaded it'll be better to operate at a lower voltage so as to reduce the amount of heat generation.
Well, the old version 2 tester from a couple years back is doing well. I haven't touched the low level parts and it's already producing great results on the P2Stamp module at sysclock/1. No capacitor added.
When using registered tx data + unregistered clock I get up to 310 MHz sysclock before data corruption sets in. But when using unregistered tx data + registered clock I get up to 330 MHz sysclock before data corruption sets in. Going by historical evidence, a registered clock has always produced greater range with reading performance. So I suspect the limit is still with the data reads than writes. Which will be nice to know. I'll have a look with the scope tonight. Also still to test all pin combinations for read data. I might still get lucky for 340 MHz say.
So I might have cracked the write timings already. It simply needs a clean direct signal path so that when the clock pin is using opposite registration to data pins, that provides enough phase shift all by itself.
PS: u/r columns below are for reading data pins unregistered and registered respectively. Applied at the command-data turnaround transition.
It's a pity that sysclk/1 starts to fail out around 334MHz and can't be coaxed to perform ~10MHz higher since this is right around the operating P2 clock range of the emulators Ada wrote. A sysclk/2 transfer byte rate is hopefully still good enough for running them though.
And here's same timings using an Eval board with the Hyper add-on plain, no added capacitor:
PS: I do get a lot of 100% results using base pin 0 but it's still scrappy with holes in the middle.
@rogloh said:
It's a pity that sysclk/1 starts to fail out around 334MHz and can't be coaxed to perform ~10MHz higher since this is right around the operating P2 clock range of the emulators Ada wrote. A sysclk/2 transfer byte rate is hopefully still good enough for running them though.
Yep, sysclock/2 is fine right up to crashing from hubRAM errors.
I've now completed all combinations at sysclock/1 - Which turned out to only be CLK registering, RXDAT registering and RXDAT Schmitting. Inverting CLK polarity has no effect on the RAM's responses since transactions are fixed to first rising clock edge after CE goes low. It ignores any half cycles.
Results were all worse than I already had. The posted sysclk/1 example above, that petered out at 330 MHz, is the best result - Registered CLK, Unregistered DAT.
It can still be improved using temperature and voltage management of course.
EDIT: Here's a small amount of cooling. It helps enough to get to 370 MHz sysclock without crashing. The 100% line makes it to 338 MHz. Some improvement. Stepping the voltage up to 1.9 Volts I expect will give a good improvement. I'll need to find a 27k ohm SMD resistor to do that.
Comments
Price I don't know about yet. Hoping they can be similar at least.
But, PCB was $14 each for Qty.50 and P2 is $16.
The real issue is the DC-DC converter chip at $14 each. It's something special with integrated inductor, but you have to pay for that.
Also, it seems to be a rare thing and could go out of stock at any time...
A smaller difference perhaps is the 8-bit bus hyperram vs 16-bit bus PSRAM. HyperRam uses less pins, so that is good.
Also, can turn off hyperram if you don't need it and get those pins back.
Suppose the RTC module is a another, perhaps less important, but useful feature for things I'm doing.
Nice to have the actual time for datalogging...
That frustrated me a little when I realised that was so. HyperRAM is most effective when paired with fastest sysclock/1 timings. Any degradation from track length will reduce effectiveness.
I guess I should invest some time experimenting how well the P2Stamp's arrangement works when those PLCC contacts aren't connected. I'll need to solder it into place ... which means I need to do a carrier board layout too ...
Is there any board that really manages sysclk/1 (at useful sysclk)?
Also when looking through those datasheets, I realized that with the output clocks we're running at sysclk/2, we should really set the latency count to 3. I think both my code and Roger's driver just rely on the default 6 or 7 setting, which is quite terrible.
(incidentally, with that allegedly upcoming 16x chip, if you could run it sysclk/1, you'd beat the EC32MB in bandwidth)
No, but there's only the one - An Eval add-on, implicit long tracks ... and data pins shared with HyperFlash chip makes the clock lead the data, which is in conflict with using a clock lagging capacitor or resistor.
@evanh I have both the Eval add-on and the P2STAMP, so that's two already. I usually use the former to test my HyperRAM codepaths - though I'm not sure how many people actually have the Hyper add-on board, like, is it worth the trouble?
I meant there was only one other before the P2Stamp. It was impossible to make reliable at sysclock/1. I lost interest after that.
@knivd
Very interested. I would enjoy purchasing one when you get it finished.
Martin
And since I am here "HELLO" to @evanh
I believe I had an API that can change the latency count for HyperRAM but it's not automatic configured based on P2 frequency so probably just defaults to the reset startup value by default. I've not looked at any HyperRAM for quite some time. I vaguely recall that the memory on the P2 Stamp I received had a slightly different timing to the original V1 HyperRAM the driver was based on and may have needed a tweak in the code to set it correctly.
Ye, the winbond part on the stamp defaults to 7 cycles, the eval addon defaults to 6 cycles. The exact given clock limit for 3 cycle seems to not be consistent between manufacturers, but 4 cycles is always safe for P2 sysclk/2 operation. For not-so-extreme overclocking, 3 cycles is the way. Should maybe figure this out next time I work with HyperRAM.
Yes, smaller and flatter if I cut out my board so this can solder down flush. My applications end up really dense, looking like this: (Yes, these just use P1)

or this. There will be 20 boards on it..

Okay, what is that? Is that a ginormous circuit board lying flat under the grid of spikes?
Yes, this top photo is a tester for an entire panel of 10 units to be tested. The panel is 11-1/2"X11-1/2" The largest size our MFG plant wants to tackle.
The one being wired (bottom photo) is for a panel of 20 units in a similar size. The 'Spikes' apply pressure and when the lid is closed, those cams (Metal with angled slots) will motor forward, tightening the lid straight down with up to 30 KG of force to compress all the spring supports and 'pogos' that will make contact with the test points on the units.
Each unit gets it's own P1 board that does the entire inspection, then reports the results to the OBC that informs the operator that everything passed, or which units failed, and why. Those boards are custom for this line.
There are commercial units to do all of this, but MFG wants this linear close, and the number of test points demands some motorized help closing. We can build this for a fraction of the cost of the 'big boys'.
I've started testing the HyperRAM on this P2Stamp module. Looks like stability of the Prop2 itself hits a brick wall at around 360 MHz sysclock - Drawing 1.1 Watt from the 12 Volt supply so shouldn't be the onboard LTM4622 regulator limiting things. It's good for delivering 2.5 Amps x 1.8 Volts = 4.5 Watts. It's actually behaving like thermally crashing but there's no heat that I've noticed, so not too sure of why just yet.
360MHz is pretty good though. Above where my 4-layers can reliably get to without raising the core voltage…
Probably a lot higher freq than anyone would use in the field…
Also above where @Wuerfel_21 emulators operate…
True, it is.
I just measured the 1v8 rail and it is 1.81 Volts. Comparing to my testing Eval board which is 1.86 Volts and can achieve 370 MHz with light loads. That small difference in voltage right there may explain the difference in useable max frequency. I'd entirely overlooked this interaction in the past.
That's fine really. Its heat-sinking ability is limited, so when compute loaded it'll be better to operate at a lower voltage so as to reduce the amount of heat generation.
I'm happy it's explainable.
Could increase value of the power supply feedback resistor and boost Vdd.
Don't think will for Stamp though...
Well, the old version 2 tester from a couple years back is doing well. I haven't touched the low level parts and it's already producing great results on the P2Stamp module at sysclock/1. No capacitor added.
When using registered tx data + unregistered clock I get up to 310 MHz sysclock before data corruption sets in. But when using unregistered tx data + registered clock I get up to 330 MHz sysclock before data corruption sets in. Going by historical evidence, a registered clock has always produced greater range with reading performance. So I suspect the limit is still with the data reads than writes. Which will be nice to know. I'll have a look with the scope tonight. Also still to test all pin combinations for read data. I might still get lucky for 340 MHz say.
So I might have cracked the write timings already. It simply needs a clean direct signal path so that when the clock pin is using opposite registration to data pins, that provides enough phase shift all by itself.
PS: u/r columns below are for reading data pins unregistered and registered respectively. Applied at the command-data turnaround transition.
It's a pity that sysclk/1 starts to fail out around 334MHz and can't be coaxed to perform ~10MHz higher since this is right around the operating P2 clock range of the emulators Ada wrote. A sysclk/2 transfer byte rate is hopefully still good enough for running them though.
And here's same timings using an Eval board with the Hyper add-on plain, no added capacitor:
PS: I do get a lot of 100% results using base pin 0 but it's still scrappy with holes in the middle.
EDIT: Fix "base pin" naming
With above registered clock pin and unregistered data pins, it's maybe 0.6 ns for clock transition ahead of the data transition:

And reversed when the clock and data registering is reversed:

It looks to be a 3 ns slope! That's from Prop2 pin drive. So attenuation will set in when? At 150 MHz odd maybe.
EDIT: Err, forget that. The analogue frontend of the scope is only rated for 200 MHz.
PS: Here's a photo of the probing for the above screenshots


Dirty probes!
They've had some use and been some places. Lost two of the ground clips and broken a hook sadly. And Yokogawa don't sell them any longer.
Yep, sysclock/2 is fine right up to crashing from hubRAM errors.
I've now completed all combinations at sysclock/1 - Which turned out to only be CLK registering, RXDAT registering and RXDAT Schmitting. Inverting CLK polarity has no effect on the RAM's responses since transactions are fixed to first rising clock edge after CE goes low. It ignores any half cycles.
Results were all worse than I already had. The posted sysclk/1 example above, that petered out at 330 MHz, is the best result - Registered CLK, Unregistered DAT.
It can still be improved using temperature and voltage management of course.
EDIT: Here's a small amount of cooling. It helps enough to get to 370 MHz sysclock without crashing. The 100% line makes it to 338 MHz. Some improvement. Stepping the voltage up to 1.9 Volts I expect will give a good improvement. I'll need to find a 27k ohm SMD resistor to do that.
A run at 65 degC ambient, an approximation of running with some compute load. It achieves 340 MHz before crashing. RAM 100% reaches to 318 MHz.
And at 95 degC, for estimated heavy compute, we get crash at 326 MHz and RAM 100% reaches 300 MHz.