New P2 Silicon

17810121317

Comments

  • 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).

    Kind regards, Samuel Lourenço

    It's too late for the next batch of boards, but we could do that on the round after.
  • cgraceycgracey Posts: 11,710
    edited 2019-08-08 - 23:28:26
    jmg wrote: »
    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)

    The bigger the divider, the more jitter you get. I don't have a number, but dividing 20MHz by 40 results in 4ns of jitter, across temperature.

    Actually, I've been measuring the jitter from my 20MHz function generator that I was using for the P2 jitter test, and it's about 1200ps. Maybe we are way less than 750ps. Hard to say, but it seems plenty good to me. This matter of the I/O pins being so much slower than the core, though, is something to evaluate.
  • I just had an epiphany: The reason the I/Os are working so much more consistently at high-frequency on the v2 silicon is because they were all skew-banded to within 1ns of eachother. Now, they all start missing data at nearly the same temp/frequency, confining their window of ambiguity between new and old data.

    As temperature slowly rises while the part is running very fast, here is what the pin registers see, coming from the core:

    1) New data
    2) Ambiguous data
    3) Old data, due to internal propagation delay within the 3.3V pad circuitry
  • Its good that you could see things similar to what we saw, Chip.

    Since self heating has been greatly reduced, I don't think it will be much of a problem unless things are massively overclocked *and* the P2 is in an enclosure where the heat can't get away.
  • Chip, based on these observations, I can't wait to "listen" to the new VCO on my service monitor! As I recall, with the best divider /2, I saw about 3Khz of phase noise at 250Mhz. I bet we will see a full quieting signal with 0Khz of phase noise in the new silicon. I never saw a change in jitter based solely on heating, only by changing the divisor.

    So excited about this refined version!
    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
  • ke4pjw wrote: »
    Chip, based on these observations, I can't wait to "listen" to the new VCO on my service monitor! As I recall, with the best divider /2, I saw about 3Khz of phase noise at 250Mhz. I bet we will see a full quieting signal with 0Khz of phase noise in the new silicon. I never saw a change in jitter based solely on heating, only by changing the divisor.

    So excited about this refined version!

    That's a great idea!

    I had a little handheld radio that you could listen to any frequency with. I wonder where it is.

    Well, I could just use an FM radio, I suppose. What warble's at 250MHz would probably do so at 100MHz, too.

    It would be easy for me to test the two silicon versions like this.
  • Tubular wrote: »
    Its good that you could see things similar to what we saw, Chip.

    Since self heating has been greatly reduced, I don't think it will be much of a problem unless things are massively overclocked *and* the P2 is in an enclosure where the heat can't get away.

    That's what I'm thinking.

    We need to find out, though, if there's a frequency at which this new-to-old data ambiguity occurs at room temperature.
  • Does the lower power mean less ADC noise? It would be good to see some images of Sinc2/Sinc3/Scope instruction in action some time, the details of which have largely evaporated from my mind by now!
    Formerly known as TonyB
  • Yes how fast do you need to run the P2r2 for it to reach 67C at "typical" ambient temps with simple air based convective cooling I wonder. Hopefully it's something extreme and not in a useful zone of operation at 250MHz for HDMI etc.
  • It depends on board (heat spread) area.

    You wouldn't get to 67 C with P2ES at all, in free air. I doubt you'd get there with P2D2, with the new efficiency of v2 silicon. So it's somewhat contrived fringe issue, but its always good to know just how much margin you have, when designing things.
  • cgracey wrote: »
    We need to find out, though, if there's a frequency at which this new-to-old data ambiguity occurs at room temperature.
    In the v1 chip, it depended quite significantly on whether the I/O was registered or not.
    "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."
  • evanh wrote: »
    cgracey wrote: »
    We need to find out, though, if there's a frequency at which this new-to-old data ambiguity occurs at room temperature.
    In the v1 chip, it depended quite significantly on whether the I/O was registered or not.

    Yes. In the case of DACs, though, it is always registered. Same with ADC.
  • Thank you, that answers an outstanding question I had.

    "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."
  • jmgjmg Posts: 13,917
    cgracey wrote: »
    I keep wracking my brain, trying to figure out if there's anything else I need to be worrying about, at this point. I'll probably transition back to working on Spin2 tomorrow.

    Has the USB code been verified as OK on ES2 ?

  • jmg wrote: »
    cgracey wrote: »
    I keep wracking my brain, trying to figure out if there's anything else I need to be worrying about, at this point. I'll probably transition back to working on Spin2 tomorrow.

    Has the USB code been verified as OK on ES2 ?

    No. Is there some of Garryj's code I could run?
  • jmgjmg Posts: 13,917
    cgracey wrote: »
    jmg wrote: »
    Has the USB code been verified as OK on ES2 ?

    No. Is there some of Garryj's code I could run?

    Maybe here ?
    http://forums.parallax.com/discussion/170149/p2-hosted-usb-keyboard-mouse
  • jmg wrote: »
    cgracey wrote: »
    jmg wrote: »
    Has the USB code been verified as OK on ES2 ?

    No. Is there some of Garryj's code I could run?

    Maybe here ?
    http://forums.parallax.com/discussion/170149/p2-hosted-usb-keyboard-mouse

    Thanks. I just loaded up the file and made some operator changes to get it to compile in PNut (|< became DECOD and >< became REV).

    I un-commented the code that sets up for v2 silicon.

    All I have is a wireless mouse and it just flashes the LED on P56 when I plug it in. Does it not work with wireless mice?
  • Meanwhile, I discovered that I can signal 1080p24 in analog Y-Pb-Pr. The pixel rate is only 59.4MHz. 1080p30 works, as well, with a pixel rate of 74.25MHz.
  • jmgjmg Posts: 13,917
    cgracey wrote: »
    All I have is a wireless mouse and it just flashes the LED on P56 when I plug it in. Does it not work with wireless mice?
    I've not run it, but I find these comments

    ersmith says : I've tried several mice now and they've worked fine. Unfortunately I'm having trouble with keyboards. I've tried two keyboards. The first wasn't detected properly (it triggered the DEV_UNKNOWN "Boot protocol keyboard/mouse not found") so perhaps it just doesn't support boot protocol?
    The second was a wireless combo keyboard/mouse; the mouse part works fine, but only a few function keys are recognized and they're completely wrong (e.g. F1 is coming out as 'd' and F2 as backspace).

    and garryj says :
    Yes, during device enumeration "boot protocol" interfaces must be defined. I have an early MS wireless keyboard/mouse combo where the keyboard supported boot protocol and the mouse did not. Are the keyboards wired, or wireless? If the device is wireless and BlueTooth it's likely it won't work, as it appears that BlueTooth devices that support boot protocol are pretty rare.

    So it seems it pivots on the boot protocol support. A dusty drawer somewhere usually has a wired mouse ? ;)
  • roglohrogloh Posts: 1,272
    edited 2019-08-09 - 09:13:55
    cgracey wrote: »
    Meanwhile, I discovered that I can signal 1080p24 in analog Y-Pb-Pr. The pixel rate is only 59.4MHz. 1080p30 works, as well, with a pixel rate of 74.25MHz.

    Great Chip. Now wondering who will be first to stream uncompressed or even lightly compressed 4:2:2 video from the P2 at that rate and in HD resolution? I guess some of the old PATA type HDD's might even be usable for doing large amounts of video storage at those transfer rates with a 16 bit bus. I think they used to transfer up to 133-166MB/s didn't they? What speeds they could actually sustain is an unknown though.

    What other large storage (tens of GB's) could the P2 "easily" use that would support these HD video bandwidths I wonder.
  • I got Garryj's USB working!

    I had to change >< to REV and also decrement the 2nd term, since the new REV is in terms of MSB position, not number of bits.

    It doesn't light up the LEDs as described in the documentation, but it does report button, X, and Y changes serially at 2MB. So, it's obviously working.
  • jmg wrote: »
    ...A dusty drawer somewhere usually has a wired mouse ? ;)

    I looked under my son's bed and found just such a mouse.
  • cgracey wrote: »
    jmg wrote: »
    ...A dusty drawer somewhere usually has a wired mouse ? ;)

    I looked under my son's bed and found just such a mouse.

    :wink:
    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)
  • cgracey wrote: »
    I got Garryj's USB working!

    I had to change >< to REV and also decrement the 2nd term, since the new REV is in terms of MSB position, not number of bits.

    It doesn't light up the LEDs as described in the documentation, but it does report button, X, and Y changes serially at 2MB. So, it's obviously working.

    Glad you got it working, and thanks for the notes regarding the V2 silicon PNut changes! My apologies for getting a bit lazy on the LED assignments whilst moving from FPGA->P2-Eval + Serial Host add-on.
    garryj
  • Was the change from >< to REV discussed in some thread?

    I see garryj used it to declare constants like this:
    ' USB CRC constants:
            USB5_POLY      = %0_0101 >< 5           ' USB5 polynomial is reflected when calculating CRC
    

    BTW: The forum search tool doesn't like >< for some reason...
    Prop Info and Apps: http://www.rayslogic.com/
  • jmgjmg Posts: 13,917
    edited 2019-08-11 - 09:17:09
    How does the RCFAST, RCSLOW and Icc During reset and Static Icc compare with the previous ES1 ?
    I think RCFAST and RCSLOW target MHz did not change, so any MHz/kHz changes there could indicate across-batch variations ?
    Static Icc is likely unchanged ?
    Icc During RESN=0 could be lower, if clock gating is applied ?
  • MHz+cogs vs I@1.8V	P2 v1	P2 v2	v2/v1
    --------------------------------------------------
    20MHz PLL, 1 cog	66 mA	29 mA	44%
    40MHz PLL, 1 cog	129	55	43%
    80MHz PLL, 1 cog	253	106	42%
    160MHz PLL, 1 cog	497	208	42%
    320MHz PLL, 1 cog	962	407	42%
    

    20 MHz is equivalent to RCFAST. So under half power for that.

    It looks like a slight proportional increase at slower clock frequencies. So 20 kHz RCSLOW will likely be above the half power mark. The rest would be a wild guess I my behalf.
    "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."
  • TonyB_TonyB_ Posts: 1,286
    edited 2019-08-13 - 00:40:31
    TonyB_ wrote: »
    Does the lower power mean less ADC noise? ...

    Bump.

    A brief mention that "the ADC and DAC stuff seems to work fine" but nothing specific on some of the interesting new features.
    Formerly known as TonyB
  • Chip: Did you ever hear from On Semi about when they can deliver chips in the production packages?
  • [
    David Betz wrote: »
    Chip: Did you ever hear from On Semi about when they can deliver chips in the production packages?

    We're being held up by testing troubles.

    On their test setup, they are getting huge currents on random VIO pins, on both dies and packaged parts. When we put a packaged chip on an Eval board, though, there are no high currents. It's not making any sense.

    All my time has been going to resolve this problem.
Sign In or Register to comment.