It is pity that the addition of the 22pF cap required for allowing sysclk/1 writes reduces the frequency range overlap from your read results when transitioning between bands, evanh.
Yep, I'm seeing roughly that shape with the starting of step slopes together and the lagging slope stretching out further along. The rise and fall slopes is the part that actually becomes more parallel when the Hyper accessory board is attached (Data leans over more to match the capacitor loaded clock). Bonus of having the HyperFlash along for the ride.
However, if we can output a 90 degree phase shifted signal on a second pin, we could do more. I'm not sure whether that is possible, though. Perhaps the transition smartpin mode may help here
Using unregistered P24 output, along with registered data pins, adds more than 0.5 ns. Possibly as much as 0.8 ns. I consider this an important component of the success of my earlier work.
Tubular your model has the load capacitance at only 3.75pF. The data sheet for HyperRAM clock pin shows 6-9pF as the range. Maybe playing with this and experimenting with the 10pF and 75vs123 ohm DAC levels etc you might get a better result?
It is pity that the addition of the 22pF cap required for allowing sysclk/1 writes reduces the frequency range overlap from your read results when transitioning between bands, evanh.
Yeah, that's a downer for sure. The sysclock options will be curtailed as a result. Probably best to have a calibration check at least on power up.
Maybe something fancier would be in order for closely placed HyperRAM part in a faster board layout.
A PCB with a Series R or L and a shunt C could be useful to trial. The R could control overshoot from larger values of C.
C could also wire to a P2 pin, to give the choice of GND, Float, or !CLK for effective 2*C delay options.
Tubular your model has the load capacitance at only 3.75pF. The data sheet for HyperRAM clock pin shows 6-9pF as the range. Maybe playing with this and experimenting with the 10pF and 75vs123 ohm DAC levels etc you might get a better result?
I think thats for the 128 Mb version, which is probably just two stacked dies hence double? Or are you looking at issi sheet? This is the cypress table i used
Yeah this was for the ISSI 128Mb part on the Parallax board which is an MCP (stacked die). I am assuming the same part is fitted on evanh's board being tested. I confirmed this part is on my own board.
Looking through your posted test code @evanh it appears you can run it at sysclk/1 with the streamer (read_block_dma) or can use direct byte banging which is slower and its data read loop does this...6 clock cycles per byte:
rep @.rend2, hrbytes
outnot #ram_ck
getbyte pa, ina+pinx, #bytx 'collect data byte from three HR clocks prior (14 sysclocks)
wfbyte pa 'stash it
.rend2
So for you posted test results over the frequency range, was it with the streamer reading back with sysclk/1 transfers, or byte banging reads with sysclk/6 transfers? It looks like the posted code defaults to byte banging because HR_READS was commented out.
'#define HR_READS
#ifdef HR_READS
call #read_block_dma '****** EDIT HERE ******
#else
call #read_block_bb '****** EDIT HERE ******
#endif
I just want to know if you've been able to get up to 350MHz reads with sysclk/1 and the streamer which I asked earlier but didn't get the clear answer...
No, 350 MHz is not achievable for reads. The list of frequency bands is what can be done for read data at sysclock/1 with this setup of Eval Board and Hyper accessory.
As for the source code, it does have a lot of legacy code in it. Some not even my own. Yes, when testing writes I use a slow read-back for verifying the written data. And vice-versa, slow writes for testing read speeds.
EDIT: A tighter board layout with carefully placed dedicated HyperRAM will be able to achieve faster read speeds with wider usable bands. Maybe with this, 350 MHz would be reached.
Frequency bands for HR Read Data using Eval Board and Hyper Accessory (data pins P16-P23, clock pin P24):
1-96 MHz, 112-193 MHz, 232-288 MHz: All registered pins, no capacitor.
1-87 MHz, 107-174 MHz, 217-266 MHz: All registered pins, 22 pF capacitor on clock.
1-92 MHz, 113-183 MHz, 226-279 MHz: -5 °C, All registered pins, 22 pF capacitor on clock.
1-82 MHz, 101-165 MHz, 208-253 MHz: 55 °C, All registered pins, 22 pF capacitor on clock.
1-94 MHz, 107-188 MHz, 221-277 MHz: Registered data pins, no capacitor.
1-84 MHz, 103-168 MHz, 208-256 MHz: Registered data pins, 22 pF capacitor on clock.
1-88 MHz, 108-177 MHz, 216-268 MHz: -5 °C, Registered data pins, 22 pF capacitor on clock.
1-79 MHz, 97-159 MHz, 199-243 MHz: 55 °C, Registered data pins, 22 pF capacitor on clock.
EDIT: A tighter board layout with carefully placed dedicated HyperRAM will be able to achieve faster read speeds with wider usable bands. Maybe with this, 350 MHz would be reached.
I have a development P2 board RevB silicon with matched trace lengths to a HyperRam module. Would it be of any help or interest for anyone if I run evanh's test code with a view to recording any change in top speed ?
- in that case, please link me the right code to use, and a little step guide on test gear config and what to record. Keep it simple please, so I can fit the task without thinking
Cool, yes, just have to edit comment out the three #defines: HR_READ, D_REGD, and CK_REGD to get the various testing combinations. Download both source files - https://forums.parallax.com/discussion/comment/1493582/#Comment_1493582
Use Fastspin to build: fastspin -2b test-hr-streamer.spin2
Use Loadp2 to run: loadp2 -v -t test-hr-streamer.binary
Or if you have FlexGUI installed then use that and run with open terminal option.
EDIT: Base pin is set to P16 by default and assumes pin order of the accessory board. To change, edit "hr_base".
EDIT2: If you don't have the same pin order the individual control pins can be easily reassigned just after the dotted line in the top constants.
No, 350 MHz is not achievable for reads. The list of frequency bands is what can be done for read data at sysclock/1 with this setup of Eval Board and Hyper accessory.
Thanks evanh, this is useful information as well as your updated low temp measurement. So it seems to push the crossover points higher up in frequency as the temperature drops. Eventually it would be good for us to collect this data at high temp too if possible plus with/without that cap fitted and create operating charts that show this information making it easier to use. I wonder it is fairly linear with temp over the normal operating range and how much overall process variation changes things, both on the P2 side and on the memory side.
If the P2 could somehow read its own/local board temp then we could potentially modify the registered pin setting and read delay clocks as required, assuming it is operating within the crossover range affected by temperature. One good thing is that around 252MHz it seems reasonably stable as well as at 200MHz and these are sweet spots for video.
I think you could get a pretty good idea of the P2 temperature from the GIO and VIO calibration values - remember these move with frequency, with different pins having various paths. Evanh did some great ODS plots showing the trajectories.
I believe its no so much frequency that causes the motion of calibration points, but rather the chip temperature. We would need to revisit that testing and impose external heating, rather than self heating, to check this theory out.
Then there is the question of whether the paths are the same or different between chips, i suspect the latter, but it needs to be confirmed. This would potentially just need a calibration pass, and you could possibly use self heating to traverse the pathways, if you knew what board design the P2 chip is sitting on (P2D2, P2ES etc)
I had intended to have a go at taking my own measurements of those but never got it sorted. There was always something else holding my attention.
PS: I've updated the read data frequency bands above - Added high temp and correcting low temp to -5 °C. Only just got the thermocouple reattached after the oven had desoldered it. Ambient room temp is in the low 20s so 25 °C would be a suitable round number to represent those measurements. Also, the 55 °C tests weren't entirely steady either, by in large I heated the boards up to 60 then let them cool down through 55 as the testing ran.
Just ran the HR write test at 55 °C and that tops out at 335 MHz. So that's a just over 20 MHz drop from 25 °C result. Nicely inline with read performances.
When I get my video driver modified and linked back into this new driver's mailbox scheme (I think I will do that today, it's a very minor change and should just fit), it should be easy to observe data errors. I want to now try to boost it up at around 250-300MHz with sysclk/1 to get faster transfers. That should allow even higher resolution modes than I worked with last time and will be a pretty good integration stress test.
Same here. It actually worked pretty well before many months back in its own limited way, but then I went and essentially rewrote it with all those extra features like multi-bank, register access, new poller, burst control, lists, fills, copies and graphics transfers etc. It has been a long slog.
Rule of thumb I'm getting is there is a couple of bad spots to avoid: 80-90 MHz and 160-180 MHz.
And above 200 MHz the temperature induced deviations really demand calibrating.
It's alive! I can now finally see HyperRAM frame buffers again with my updated video driver and read/write to this memory as well using this new external HyperRAM memory driver. Sample code is just drawing circles in the lower graphics region with the main SPIN COG, and the driver COG is sourcing this video data from HyperRAM. It is currently operating at a resolution of 800x600x8bpp and the P2 is clocking at 200MHz and transferring data at sysclk/1 from HyperRAM.
Still messing around with it to prove it is all good and eliminate minor issues (e.g. white vertical lines) but right now I'm stoked!
UPDATE: just fixed the white lines, I still had the delay set to 1 clock from my testing instead of 3 which read in two $ff's at the start of each 320 byte burst causing white pixels.
It's alive! ...
It is currently operating at a resolution of 800x600x8bpp and the P2 is clocking at 200MHz and transferring data at sysclk/1 from HyperRAM.
Sounds good.
How does that cope with some temperature cycling, as in the margin tests evanh did above ?
It's alive! I can now finally see HyperRAM frame buffers again with my updated video driver and read/write to this memory as well using this new external HyperRAM memory driver. Sample code is just drawing circles in the lower graphics region with the main SPIN COG, and the driver COG is sourcing this video data from HyperRAM. It is currently operating at a resolution of 800x600x8bpp and the P2 is clocking at 200MHz and transferring data at sysclk/1 from HyperRAM.
Excellent, well done!
As well as 640x480, sysclk of 252MHz could do 800x600 @ 56.25Hz, pclk 36MHz, if your monitor supports that (but not 800x600 DVI/HDMI of course).
Comments
Using unregistered P24 output, along with registered data pins, adds more than 0.5 ns. Possibly as much as 0.8 ns. I consider this an important component of the success of my earlier work.
C could also wire to a P2 pin, to give the choice of GND, Float, or !CLK for effective 2*C delay options.
I think thats for the 128 Mb version, which is probably just two stacked dies hence double? Or are you looking at issi sheet? This is the cypress table i used
Here's the updated spice model and its graph.
So for you posted test results over the frequency range, was it with the streamer reading back with sysclk/1 transfers, or byte banging reads with sysclk/6 transfers? It looks like the posted code defaults to byte banging because HR_READS was commented out.
I just want to know if you've been able to get up to 350MHz reads with sysclk/1 and the streamer which I asked earlier but didn't get the clear answer...
As for the source code, it does have a lot of legacy code in it. Some not even my own. Yes, when testing writes I use a slow read-back for verifying the written data. And vice-versa, slow writes for testing read speeds.
EDIT: A tighter board layout with carefully placed dedicated HyperRAM will be able to achieve faster read speeds with wider usable bands. Maybe with this, 350 MHz would be reached.
Frequency bands for HR Read Data using Eval Board and Hyper Accessory (data pins P16-P23, clock pin P24):
1-96 MHz, 112-193 MHz, 232-288 MHz: All registered pins, no capacitor.
1-87 MHz, 107-174 MHz, 217-266 MHz: All registered pins, 22 pF capacitor on clock.
1-92 MHz, 113-183 MHz, 226-279 MHz: -5 °C, All registered pins, 22 pF capacitor on clock.
1-82 MHz, 101-165 MHz, 208-253 MHz: 55 °C, All registered pins, 22 pF capacitor on clock.
1-94 MHz, 107-188 MHz, 221-277 MHz: Registered data pins, no capacitor.
1-84 MHz, 103-168 MHz, 208-256 MHz: Registered data pins, 22 pF capacitor on clock.
1-88 MHz, 108-177 MHz, 216-268 MHz: -5 °C, Registered data pins, 22 pF capacitor on clock.
1-79 MHz, 97-159 MHz, 199-243 MHz: 55 °C, Registered data pins, 22 pF capacitor on clock.
1-80 MHz, 90-162 MHz, 180-241 MHz, 276-317 MHz: Registered clock pin, no capacitor.
1-73 MHz, 86-145 MHz, 171-221 MHz, 259-295 MHz: Registered clock pin, 22 pF capacitor on clock.
1-77 MHz, 91-153 MHz, 183-233 MHz, 273-309 MHz: -5 °C, Registered clock pin, 22 pF capacitor on clock.
1-68 MHz, 81-137 MHz, 161-208 MHz, 250-281 MHz: 55 °C, Registered clock pin, 22 pF capacitor on clock.
1-78 MHz, 87-156 MHz, 173-233 MHz, 264-308 MHz: All unregistered pins, no capacitor.
1-71 MHz, 83-140 MHz, 165-214 MHz, 249-286 MHz: All unregistered pins, 22 pF capacitor on clock.
1-75 MHz, 88-147 MHz, 175-225 MHz, 260-299 MHz: -5 °C, All unregistered pins, 22 pF capacitor on clock.
1-66 MHz, 78-132 MHz, 154-200 MHz, 238-272 MHz: 55 °C, All unregistered pins, 22 pF capacitor on clock.
EDIT: Graphed linearity of the temperatures - EDIT2: Grouped legend symbols. EDIT3: And the graph colours too.
I have a development P2 board RevB silicon with matched trace lengths to a HyperRam module. Would it be of any help or interest for anyone if I run evanh's test code with a view to recording any change in top speed ?
- in that case, please link me the right code to use, and a little step guide on test gear config and what to record. Keep it simple please, so I can fit the task without thinking
Use Fastspin to build: fastspin -2b test-hr-streamer.spin2
Use Loadp2 to run: loadp2 -v -t test-hr-streamer.binary
Or if you have FlexGUI installed then use that and run with open terminal option.
EDIT: Base pin is set to P16 by default and assumes pin order of the accessory board. To change, edit "hr_base".
EDIT2: If you don't have the same pin order the individual control pins can be easily reassigned just after the dotted line in the top constants.
If the P2 could somehow read its own/local board temp then we could potentially modify the registered pin setting and read delay clocks as required, assuming it is operating within the crossover range affected by temperature. One good thing is that around 252MHz it seems reasonably stable as well as at 200MHz and these are sweet spots for video.
I believe its no so much frequency that causes the motion of calibration points, but rather the chip temperature. We would need to revisit that testing and impose external heating, rather than self heating, to check this theory out.
Then there is the question of whether the paths are the same or different between chips, i suspect the latter, but it needs to be confirmed. This would potentially just need a calibration pass, and you could possibly use self heating to traverse the pathways, if you knew what board design the P2 chip is sitting on (P2D2, P2ES etc)
https://forums.parallax.com/discussion/download/124010/20-300%20Mhz%20%2859%20pins%29A.png
PS: I've updated the read data frequency bands above - Added high temp and correcting low temp to -5 °C. Only just got the thermocouple reattached after the oven had desoldered it. Ambient room temp is in the low 20s so 25 °C would be a suitable round number to represent those measurements. Also, the 55 °C tests weren't entirely steady either, by in large I heated the boards up to 60 then let them cool down through 55 as the testing ran.
EDIT: I've added the linearity graph as well. It looks generally straight to me - https://forums.parallax.com/discussion/comment/1493809/#Comment_1493809
And above 200 MHz the temperature induced deviations really demand calibrating.
Still messing around with it to prove it is all good and eliminate minor issues (e.g. white vertical lines) but right now I'm stoked!
UPDATE: just fixed the white lines, I still had the delay set to 1 clock from my testing instead of 3 which read in two $ff's at the start of each 320 byte burst causing white pixels.
+1; +1
How does that cope with some temperature cycling, as in the margin tests evanh did above ?
Excellent, well done!
As well as 640x480, sysclk of 252MHz could do 800x600 @ 56.25Hz, pclk 36MHz, if your monitor supports that (but not 800x600 DVI/HDMI of course).