Something like half the transistors or more of new CPUs is the cache memories (L1, L2, and L3).
Also, if we took the P2 to 40nm or smaller, we would not leave it with the same ram and number of cores. So the number of transistors would go way up, and thus the power considerations go up.
However, shrinking the process does still mean more leakage and higher current required, until you get to things like finfet and other newer processes that reduce the leakage and current requirements.
Of course, the biggest hurdle is the much higher costs, like multiple orders of magnitude more money for masks/etc.
I just heated up the P2 from the back of the P2 Eval board while running at 297MHz. I was outputting 720p24 HDMI. Things stopped working when the top of the chip got to ~110 C (230 F).
I also tested 1080p analog while running at 250MHz, which outputs pixels at 148.5MHz. It got up to ~145 C (293 F) before it stopped working.
I never noticed any pixel jitter along the way, in either case. In the case of the HDMI program, I was even initially dividing the crystal by 20, then multiplying it by 297 in the VCO to get 297MHz out of the PLL.
Okay, I just saw some jitter at about 67 C (152 F). There's a narrow temperature band, where it comes and goes, on the way up and on the way down. So, there still is some temperature-related jitter, after all.
I also just did another test, running the P2 at 360MHz while outputting 1080p. At 100C, the screen blanked, but then came back after I took the heat off. This is indication that our 3.3V I/O circuits are running out of steam at that temp and frequency, while the core remains running.
I just heated up the P2 from the back of the P2 Eval board while running at 297MHz. I was outputting 720p24 HDMI. Things stopped working when the top of the chip got to ~110 C (230 F).
I also tested 1080p analog while running at 250MHz, which outputs pixels at 148.5MHz. It got up to ~145 C (293 F) before it stopped working.
I never noticed any pixel jitter along the way, in either case. In the case of the HDMI program, I was even initially dividing the crystal by 20, then multiplying it by 297 in the VCO to get 297MHz out of the PLL.
Okay, I just saw some jitter at about 67 C (152 F). There's a narrow temperature band, where it comes and goes, on the way up and on the way down. So, there still is some temperature-related jitter, after all.
I also just did another test, running the P2 at 360MHz while outputting 1080p. At 100C, the screen blanked, but then came back after I took the heat off. This is indication that our 3.3V I/O circuits are running out of steam at that temp and frequency, while the core remains running.
Okay, I just saw some jitter at about 67 C (152 F). There's a narrow temperature band, where it comes and goes, on the way up and on the way down. So, there still is some temperature-related jitter, after all.
I also just did another test, running the P2 at 360MHz while outputting 1080p. At 100C, the screen blanked, but then came back after I took the heat off. This is indication that our 3.3V I/O circuits are running out of steam at that temp and frequency, while the core remains running.
Did you had taken the precaution of spreading some thermal grease over the globe top chip surface and also provided a square piece of aluminium foil, so as to even temperature distribution, while avoiding unnintended hot spots?
Perhaps excess heat has been captured and concentrated, due to hot air vortices, exactly at the exposed metal pads, protruding from the wire frame, thus you can expect those metal protrusions to be hotter than the rest of the chip, carrying heat all the way inside the globe top.
Okay, I just saw some jitter at about 67 C (152 F). There's a narrow temperature band, where it comes and goes, on the way up and on the way down. So, there still is some temperature-related jitter, after all.
I also just did another test, running the P2 at 360MHz while outputting 1080p. At 100C, the screen blanked, but then came back after I took the heat off. This is indication that our 3.3V I/O circuits are running out of steam at that temp and frequency, while the core remains running.
Was this at the worst case divisor?
No, but I just tried the worst-case:
clkinit1 long %1_100111_1011001111_1111_10_00 '20MHz / 40 * 720 * 1 = 360MHz
clkinit2 long %1_100111_1011001111_1111_10_11
The temperature range of the jitter does expand greatly with a big crystal multiplier.
Well, something surprising happened....
I just ran a test where the clock frequency was the same as the pixel frequency and there was no jitter, at all. I ran the temperature up to 110 C and back down a few times and never saw a bit of jitter. Weird. In this case, the SETXFRQ value was a clean $8000_0000, for one-to-one.
Okay, I just saw some jitter at about 67 C (152 F). There's a narrow temperature band, where it comes and goes, on the way up and on the way down. So, there still is some temperature-related jitter, after all.
I also just did another test, running the P2 at 360MHz while outputting 1080p. At 100C, the screen blanked, but then came back after I took the heat off. This is indication that our 3.3V I/O circuits are running out of steam at that temp and frequency, while the core remains running.
Did you had taken the precaution of spreading some thermal grease over the globe top chip surface and also provided a square piece of aluminium foil, so as to even temperature distribution, while avoiding unnintended hot spots?
Perhaps excess heat has been captured and concentrated, due to hot air vortices, exactly at the exposed metal pads, protruding from the wire frame, thus you can expect those metal protrusions to be hotter than the rest of the chip, carrying heat all the way inside the globe top.
The back of the PCB is a nice clean, flat target for the hot air. There's a via stack right under the chip that equalizes bottom-PCB temp with bottom-P2-pad temp. So, I think I'm heating the chip pretty effectively.
Okay, I just saw some jitter at about 67 C (152 F). There's a narrow temperature band, where it comes and goes, on the way up and on the way down. So, there still is some temperature-related jitter, after all.
I also just did another test, running the P2 at 360MHz while outputting 1080p. At 100C, the screen blanked, but then came back after I took the heat off. This is indication that our 3.3V I/O circuits are running out of steam at that temp and frequency, while the core remains running.
Did you had taken the precaution of spreading some thermal grease over the globe top chip surface and also provided a square piece of aluminium foil, so as to even temperature distribution, while avoiding unnintended hot spots?
Perhaps excess heat has been captured and concentrated, due to hot air vortices, exactly at the exposed metal pads, protruding from the wire frame, thus you can expect those metal protrusions to be hotter than the rest of the chip, carrying heat all the way inside the globe top.
The back of the PCB is a nice clean, flat target for the hot air. There's a via stack right under the chip that equalizes bottom-PCB temp with bottom-P2-pad temp. So, I think I'm heating the chip pretty effectively.
Ohh, I see. The words did passed in front of my eyes, but I didn't noticed them right. You was heating the Eval board from its bottom side...
Then there weren't any hot air vortex, coming from the top side, directly hitting the globe top resin.
Well, then it just leaves a single conduction path, from each pad footprint at the land pattern, thru the soldered metal wireframe pin and internally connected gold wire, right to the internal pad, as a means of transfering heat into and out the surrounding padframe area.
So, it seems this jitter issue has something to do with NCO pixel frequencies that are not clean divisions of main clock frequencies.
Plus the weird thermal sensistivity to this. Maybe when things are not an integer divider, every now and again something slips and the amount of this slip is also somehow temperature dependent. It slips by a lot, more than a pixel as it accumulates and it is cyclic. Not sure how you are observing it Chip and if it is the same as we saw but you might want to look at this thermal pixel jitter effect on an analog monitor. When Tubular captured it on my hires monitor we were seeing what looked like ringing effects that varied in amplitude periodically when it was heated through a specific temperature window.
I just tried this combo and no jitter, tested ambient to 110 C to ambient:
setxfrq ##$5555_5555+1 'This is 1/3, the +1 gets correct initial rollover
clkinit1 long %1_100111_0110111101_1111_10_00 '20MHz / 40 * 446 * 1 = 223MHz (3 x 74.25MHz)
So, this temp-related jitter problem doesn't seem to occur when you have simple integral relationships between the NCO pixel and PLL clock frequencies.
Due to the huge difference in metal quantities, the GND pad is surelly absorbing way more heat than the sum of all other 100 metal pads, so the chip dice substrate should be hotter than any individual pin connected area, at the corresponding padframe structure.
Not an exact image nor heat distribution, but something like this...
So, it seems this jitter issue has something to do with NCO pixel frequencies that are not clean divisions of main clock frequencies.
Plus the weird thermal sensistivity to this. Maybe when things are not an integer divider, every now and again something slips and the amount of this slip is also somehow temperature dependent. It slips by a lot, more than a pixel as it accumulates and it is cyclic. Not sure how you are observing it Chip and if it is the same as we saw but you might want to look at this thermal pixel jitter effect on an analog monitor. When Tubular captured it on my hires monitor we were seeing what looked like ringing effects that varied in amplitude periodically when it was heated through a specific temperature window.
Yes, that is what I would expect PLL jitter to look like - frequency ringing.
I know that the core logic is not missing a beat, but maybe the pads have something to do with this. What if temperature-driven clock and data skew are causing the pads to register right at the boundary between current and old data? That would make sense, considering that this only happens at very high frequencies where the NCO is sometimes generating back-to-back updates to the I/O pins. By inhibiting that possibility by using clean NCO values that serve as integer divisors, there are no back-to-back (too high frequency) updates to the I/O pads, so they are faithfully registering the intended data.
Here is the zoomed in effect of what we saw...
20 pixels vertical scale per line, 32 pixel horizontal scale per column. Excursion is several pixels.
Rogloh, do you have the ability to repeat that test, but keep a 1:1 relationship between clock and pixel frequencies? This would mean using $8000_0000 as the SETXFRQ value.
What kind of monitor are you using to test jitter? An LCD monitor in my experience will generally only sample the signal very briefly, once for each pixel. Scoping the signal is prob. better for measuring the Jitter. you can also adjust the sampling settings on the monitor to bring the samples closer to the pixel edges.
Altough if it doesn't show up, that's likely already good enough.
When I got jitter on the earlier tests, the effects were like the TV was getting wrong HSYNC signalling. This would definitely be caused by the pins registering data in transition, causing false HYSNC's.
I think the problem is that the I/O pins can't update fast enough at very high frequencies. They can clock fast, but the data can't change on every clock without registering glitches.
Rogloh, do you have the ability to repeat that test, but keep a 1:1 relationship between clock and pixel frequencies? This would mean using $8000_0000 as the SETXFRQ value.
Away vacationing right now but perhaps Tubular/ozpropdev might be able to do that with their P2-EVAL boards. My Sony hires monitor is at home, but perhaps they have another one they can use in the meantime to try to reproduce it.
Rogloh, do you have the ability to repeat that test, but keep a 1:1 relationship between clock and pixel frequencies? This would mean using $8000_0000 as the SETXFRQ value.
Away vacationing right now but perhaps Tubular/ozpropdev might be able to do that with their P2-EVAL boards. My Sony hires monitor is at home, but perhaps they have another one they can use in the meantime to try to reproduce it.
Don't worry about it. It's not necessary. I just did a jitter test on the v1 using my scope....
So, the v2 PLL is WAY better with the new filtering.
I just did some tests on both the v1 and v2 silicon, where I used my function generator to feed a stable 20MHz into the P2, since the P2's crystal was shifting frequency quite a bit under the heat. I ran temp from room ambient to 100C and back down to room ambient. I used a program to toggle P32 which I looked at on the scope with infinite persistence, 100us after triggering on a rise. This makes it easy to see jitter. 100us is almost an eternity to the PLL.
The jitter was so much worse on the v1 silicon that I had to use a program 8x slower to not be swamped out by jitter, even without changing the temperature. Actually, running the temp up and down did not seem to make a huge difference on either silicon version.
I ran each P2 at 320MHz using an initial crystal divisor of 40, to get 500KHz, then multiplying that by 640 in the VCO to get 320MHz out. This is a pretty brutal combination of divisor and multiplier.
Here is the program for the v1, which makes a 5MHz square wave:
DAT org
hubset clkinit1 'set clock to 320MHz
waitx clkwait
hubset clkinit2
rep #2,#0 'generate square wave
drvnot #32
waitx #12+16
clkinit1 long %1_100111_1001111111_1111_10_00 '20MHz / 40 * 640 * 1 = 320MHz
clkinit2 long %1_100111_1001111111_1111_10_11
clkwait long 20_000_000 / 200
For the v2 silicon, instead of the WAITX, I just used a NOP, causing the loop to generate a 40MHz square wave.
Here is the v1 silicon jitter, coming it at around 30ns:
Here is the v2 silicon jitter, a mere 4ns:
I believe that what I saw earlier today was not jitter, but just the I/O being so much slower than the core that it was, with rising temperature, transitioning between old and new data being clocked into it. As it got hotter, it became one clock behind where it should have been. During the temperature transition, its inputs become ambiguous within a narrow temperature range and it latches data that was in the process of changing. This was causing false HSYNCs on my TV.
I did one more test on v2 silicon where I set the crystal divider to 1 and the multiplier to 16, in order to get 320MHz. This means that PLL corrections come 40x more frequently than they did in the previous tests, so there's less opportunity for jitter to develop. I ran the temperature from room ambient to 110 C and back down to room ambient.
I don't think there's more than 750ps of jitter here:
...
The jitter was so much worse on the v1 silicon that I had to use a program 8x slower to not be swamped out by jitter, even without changing the temperature. Actually, running the temp up and down did not seem to make a huge difference on either silicon version.
I ran each P2 at 320MHz using an initial crystal divisor of 40, to get 500KHz, then multiplying that by 640 in the VCO to get 320MHz out. This is a pretty brutal combination of divisor and multiplier.
Here is the v1 silicon jitter, coming it at around 30ns:
Here is the v2 silicon jitter, a mere 4ns:
That's certainly much better, & a bigger improvement than expected. Maybe the clock gating has lowered the Gnd/Vcc spikes enough to quiet down the VCO Analog sections ?
4ns could still be an issue at the very highest pixel rates, depending on how the target tracks the variations. I guess that improves with higher PFD, so that would be suggested for very high pixel uses.
30ns is an certainly issue, even at modest pixel rates !
I believe that what I saw earlier today was not jitter, but just the I/O being so much slower than the core that it was, with rising temperature, transitioning between old and new data being clocked into it. As it got hotter, it became one clock behind where it should have been. During the temperature transition, its inputs become ambiguous within a narrow temperature range and it latches data that was in the process of changing. This was causing false HSYNCs on my TV.
Yes, there will be multiple things to watch then this is pushed along...
Will the new boards have a TCXO? I think it might justify. Doesn't need to be an expensive one, since the extra precision is not critical: the only thing critical is the stability (maybe Stratum 3 compliant).
Will the new boards have a TCXO? I think it might justify. Doesn't need to be an expensive one, since the extra precision is not critical: the only thing critical is the stability (maybe Stratum 3 compliant).
Good question
A TCXO was on the 'to do list' but it's not clear if that list 'needed to get done' ...
I did one more test on v2 silicon where I set the crystal divider to 1 and the multiplier to 16, in order to get 320MHz. This means that PLL corrections come 40x more frequently than they did in the previous tests, so there's less opportunity for jitter to develop. I ran the temperature from room ambient to 110 C and back down to room ambient.
I don't think there's more than 750ps of jitter here:
That's good to see. How does that vary with the XTAL Divider ? (aka PFD MHz)
Comments
Also, if we took the P2 to 40nm or smaller, we would not leave it with the same ram and number of cores. So the number of transistors would go way up, and thus the power considerations go up.
However, shrinking the process does still mean more leakage and higher current required, until you get to things like finfet and other newer processes that reduce the leakage and current requirements.
Of course, the biggest hurdle is the much higher costs, like multiple orders of magnitude more money for masks/etc.
I'm back to forum activity just now. Looking for the official links. Will post them ASAP.
P.S. Here they are...
SMPTE 274M:
last.hit.bme.hu/download/firtha/video/SMPTE/SMPTE-274M%201080.pdf
CTA-861-G:
https://web.archive.org/web/20171201033424/https://standards.cta.tech/kwspub/published_docs/CTA-861-G_FINAL_revised_2017.pdf
I also tested 1080p analog while running at 250MHz, which outputs pixels at 148.5MHz. It got up to ~145 C (293 F) before it stopped working.
I never noticed any pixel jitter along the way, in either case. In the case of the HDMI program, I was even initially dividing the crystal by 20, then multiplying it by 297 in the VCO to get 297MHz out of the PLL.
I also just did another test, running the P2 at 360MHz while outputting 1080p. At 100C, the screen blanked, but then came back after I took the heat off. This is indication that our 3.3V I/O circuits are running out of steam at that temp and frequency, while the core remains running.
You'll be able to almost cook some french-style eggs over P2, while working, without causing any harm. Very good!
Was this at the worst case divisor?
Did you had taken the precaution of spreading some thermal grease over the globe top chip surface and also provided a square piece of aluminium foil, so as to even temperature distribution, while avoiding unnintended hot spots?
Perhaps excess heat has been captured and concentrated, due to hot air vortices, exactly at the exposed metal pads, protruding from the wire frame, thus you can expect those metal protrusions to be hotter than the rest of the chip, carrying heat all the way inside the globe top.
No, but I just tried the worst-case:
clkinit1 long %1_100111_1011001111_1111_10_00 '20MHz / 40 * 720 * 1 = 360MHz
clkinit2 long %1_100111_1011001111_1111_10_11
The temperature range of the jitter does expand greatly with a big crystal multiplier.
Well, something surprising happened....
I just ran a test where the clock frequency was the same as the pixel frequency and there was no jitter, at all. I ran the temperature up to 110 C and back down a few times and never saw a bit of jitter. Weird. In this case, the SETXFRQ value was a clean $8000_0000, for one-to-one.
setxfrq ##$4000_0000
clkinit1 long %1_100111_1001010001_1111_10_00 '20MHz / 40 * 594 * 1 = 297MHz
So, it seems this jitter issue has something to do with NCO pixel frequencies that are not clean divisions of main clock frequencies.
The back of the PCB is a nice clean, flat target for the hot air. There's a via stack right under the chip that equalizes bottom-PCB temp with bottom-P2-pad temp. So, I think I'm heating the chip pretty effectively.
Ohh, I see. The words did passed in front of my eyes, but I didn't noticed them right. You was heating the Eval board from its bottom side...
Then there weren't any hot air vortex, coming from the top side, directly hitting the globe top resin.
Well, then it just leaves a single conduction path, from each pad footprint at the land pattern, thru the soldered metal wireframe pin and internally connected gold wire, right to the internal pad, as a means of transfering heat into and out the surrounding padframe area.
setxfrq ##$5555_5555+1 'This is 1/3, the +1 gets correct initial rollover
clkinit1 long %1_100111_0110111101_1111_10_00 '20MHz / 40 * 446 * 1 = 223MHz (3 x 74.25MHz)
So, this temp-related jitter problem doesn't seem to occur when you have simple integral relationships between the NCO pixel and PLL clock frequencies.
20 pixels vertical scale per line, 32 pixel horizontal scale per column. Excursion is several pixels.
Not an exact image nor heat distribution, but something like this...
https://infratec-infrared.com/thermography/industries-applications/electronics-electrical/
Yes, that is what I would expect PLL jitter to look like - frequency ringing.
I know that the core logic is not missing a beat, but maybe the pads have something to do with this. What if temperature-driven clock and data skew are causing the pads to register right at the boundary between current and old data? That would make sense, considering that this only happens at very high frequencies where the NCO is sometimes generating back-to-back updates to the I/O pins. By inhibiting that possibility by using clean NCO values that serve as integer divisors, there are no back-to-back (too high frequency) updates to the I/O pads, so they are faithfully registering the intended data.
Rogloh, do you have the ability to repeat that test, but keep a 1:1 relationship between clock and pixel frequencies? This would mean using $8000_0000 as the SETXFRQ value.
Altough if it doesn't show up, that's likely already good enough.
I think the problem is that the I/O pins can't update fast enough at very high frequencies. They can clock fast, but the data can't change on every clock without registering glitches.
Away vacationing right now but perhaps Tubular/ozpropdev might be able to do that with their P2-EVAL boards. My Sony hires monitor is at home, but perhaps they have another one they can use in the meantime to try to reproduce it.
Don't worry about it. It's not necessary. I just did a jitter test on the v1 using my scope....
I just did some tests on both the v1 and v2 silicon, where I used my function generator to feed a stable 20MHz into the P2, since the P2's crystal was shifting frequency quite a bit under the heat. I ran temp from room ambient to 100C and back down to room ambient. I used a program to toggle P32 which I looked at on the scope with infinite persistence, 100us after triggering on a rise. This makes it easy to see jitter. 100us is almost an eternity to the PLL.
The jitter was so much worse on the v1 silicon that I had to use a program 8x slower to not be swamped out by jitter, even without changing the temperature. Actually, running the temp up and down did not seem to make a huge difference on either silicon version.
I ran each P2 at 320MHz using an initial crystal divisor of 40, to get 500KHz, then multiplying that by 640 in the VCO to get 320MHz out. This is a pretty brutal combination of divisor and multiplier.
Here is the program for the v1, which makes a 5MHz square wave:
For the v2 silicon, instead of the WAITX, I just used a NOP, causing the loop to generate a 40MHz square wave.
Here is the v1 silicon jitter, coming it at around 30ns:
Here is the v2 silicon jitter, a mere 4ns:
I believe that what I saw earlier today was not jitter, but just the I/O being so much slower than the core that it was, with rising temperature, transitioning between old and new data being clocked into it. As it got hotter, it became one clock behind where it should have been. During the temperature transition, its inputs become ambiguous within a narrow temperature range and it latches data that was in the process of changing. This was causing false HSYNCs on my TV.
I don't think there's more than 750ps of jitter here:
4ns could still be an issue at the very highest pixel rates, depending on how the target tracks the variations. I guess that improves with higher PFD, so that would be suggested for very high pixel uses.
30ns is an certainly issue, even at modest pixel rates !
Yes, there will be multiple things to watch then this is pushed along...
Will the new boards have a TCXO? I think it might justify. Doesn't need to be an expensive one, since the extra precision is not critical: the only thing critical is the stability (maybe Stratum 3 compliant).
Kind regards, Samuel Lourenço
Good question
A TCXO was on the 'to do list' but it's not clear if that list 'needed to get done' ...
On my P2D2Pi fork, I have expanded the TCXO 'multi footprints' to include up to the Murata (VC) TCXO, and I added a DAC -> VC jumper.
https://www.murata.com/search/productsearch?cate=cgsubCrystalOscillators&partno=XTCLH*J&pageno=1&sort=a_output