New P2 Silicon

1679111217

Comments

  • 28M of dark silicon!
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • So 40nm is next ;)
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • 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.
  • Congrats on the milestone Chip. Looking forward to using the new features.
  • YanomaniYanomani Posts: 882
    edited 2019-08-08 - 19:52:33
    Hi Chip

    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

    cgracey wrote: »
    potatohead wrote: »
    @Chip, how in the world did he find those? Any chance we can see em?

    Yanomani, do you have links to those papers?

    They were from some standards organizations that usually want money for access to their standards.
  • cgraceycgracey Posts: 11,711
    edited 2019-08-08 - 19:38:32
    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.
  • Links to the aforementioned files were posted as a P.S., at my original post.

    You'll be able to almost cook some french-style eggs over P2, while working, without causing any harm. Very good! :lol:

    cgracey wrote: »
    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.
  • cgracey wrote: »
    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?
    Terry's Workbench

    Feel the need for speed between your PC's com port and Prop?
    Try the FTDI 245 and the FullDuplexParallel Object.
    Check out my spin driver for the Parallax "96 x 64 Color OLED Display Module" Product ID: 28087
    22FPS video from the P2 on the Parallax "96 x 64 Color OLED Display Module" https://www.youtube.com/watch?v=ja84rf38QHM
  • cgracey wrote: »
    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.
  • ke4pjw wrote: »
    cgracey wrote: »
    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.
  • cgraceycgracey Posts: 11,711
    edited 2019-08-08 - 20:54:22
    Now I tried it with these settings and NO JITTER:

    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.
  • Yanomani wrote: »
    cgracey wrote: »
    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.
  • cgracey wrote: »
    Yanomani wrote: »
    cgracey wrote: »
    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.

  • roglohrogloh Posts: 1,278
    edited 2019-08-08 - 21:15:45
    cgracey wrote: »
    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.
  • 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.
    pixels.png
    624 x 396 - 434K
  • 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...

    https://infratec-infrared.com/thermography/industries-applications/electronics-electrical/
  • rogloh wrote: »
    cgracey wrote: »
    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.
  • rogloh wrote: »
    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.
    pixels.png

    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.
  • Wuerfel_21Wuerfel_21 Posts: 351
    edited 2019-08-08 - 21:30:23
    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.
  • roglohrogloh Posts: 1,278
    edited 2019-08-08 - 21:40:58
    cgracey wrote: »
    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 wrote: »
    cgracey wrote: »
    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....
  • cgraceycgracey Posts: 11,711
    edited 2019-08-08 - 22:37:11
    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:

    P2_v1_jitter.jpg


    Here is the v2 silicon jitter, a mere 4ns:

    P2_v2_jitter.jpg




    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.
    430 x 346 - 51K
    436 x 353 - 53K
  • cgraceycgracey Posts: 11,711
    edited 2019-08-08 - 22:52:50
    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:

    P2_v2_jitter_just_multipling.jpg
    1079 x 856 - 196K
  • jmgjmg Posts: 13,920
    cgracey wrote: »
    ...
    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 !
    cgracey wrote: »
    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...

  • samuellsamuell Posts: 406
    edited 2019-08-08 - 23:05:03
    Hi Chip,

    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

  • jmgjmg Posts: 13,920
    samuell wrote: »
    Hi Chip,

    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' ...

    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

  • jmgjmg Posts: 13,920
    cgracey wrote: »
    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)

Sign In or Register to comment.