Shop OBEX P1 Docs P2 Docs Learn Events
New P2 Silicon Observations - Page 16 — Parallax Forums

New P2 Silicon Observations

1131416181923

Comments

  • Yes, these are all completely populated boards with SPI Flash. Haven't you loaded your board yet? :)
  • cgraceycgracey Posts: 14,209
    Yes, these are all completely populated boards with SPI Flash. Haven't you loaded your board yet? :)

    Aside from the P2, I just have a bypass cap on VDD and one on VIO.
  • cgraceycgracey Posts: 14,209
    edited 2018-10-10 13:34
    It would be important to make a program that simply does a GETRND and outputs it to the pins. Each time power cycles, it should show something different.

    The big PRNG is seeded from ADC noise by the ROM booter.
  • Cluso99Cluso99 Posts: 18,069
    Yep. I goofed badly there. Corrected to GIps. G instructions/s
  • Did the fuses, (ie: code protection etc...) make it in in the end? I don't see any reference to them in the ROM source code (yet). Even if they did they're probably pretty far down the list of things to test as they're 'destructive' (or at least one-way) tests.

    In other news, we should probably remember to document not to rely on the PRNG seeding for anything specifically security related. It occurred to me today that just shorting rx_pin to ground while powering the chip on may make the seed predictable.
  • jmgjmg Posts: 15,175
    __red__ wrote: »
    Did the fuses, (ie: code protection etc...) make it in in the end? I don't see any reference to them in the ROM source code (yet). Even if they did they're probably pretty far down the list of things to test as they're 'destructive' (or at least one-way) tests.
    Fuses did not make the cut, as their yield was too low.

  • cgraceycgracey Posts: 14,209
    __red__ wrote: »
    ...In other news, we should probably remember to document not to rely on the PRNG seeding for anything specifically security related. It occurred to me today that just shorting rx_pin to ground while powering the chip on may make the seed predictable.

    We use an internal GIO calibration mode which doesn't involve the external pin. We actually measure GND, but use the noise from many measurements to seed the PRNG. Doing an ADC conversion on GND doesn't return 0, but about 1/8, averaged over many bits. We use those bits to seed the PRNG. Not only does their duty vary slightly at all times, but the positions of 1's and 0's is ever-changing.
  • regarding P2 analog, over in the prop2-fpga-files thread, jmg was saying
    -- it's not just Vio that needs to be clean, any ground noise, or ground movement, is going to 50% impose on the Analog reference too, via that CMOS gate threshold effect.
    There is no separate Analog Gnd, so even a few millivolts movement in GND will cause crosstalk.
    10 bits at 3v3 needs < 3.3mV movements.

    On the shared ground - the pads get their own ground from the inside of the exposed pad (well, the exposed ring in the current mockup), rather than getting Gnd from some path across the die. So the 'shared ground' portion is across the exposed pad and solder, after that you're on ground planes where you can tap a reference ground potential. Given typical copper ground planes are a fraction of a milliohm per square, I would think that path would all be sub-milliohm total, and if we're talking about an amp of current, you're only going to 'move' less than a millivolt.

    But if you do want something 'less coupled' for reference purposes, you could expose the pad analog ground by outputting low to a neighboring pin. The N fet seems to be around 16 ohms, and of course you can buffer that if you want an even lower impedance reference ground, for a driven shield or plane.
  • Cluso,
    Boy do I wish we were rating in Tflops :D That would be comparable to GPUs for floating point operations!
  • Cluso99Cluso99 Posts: 18,069
    Roy Eltham wrote: »
    Cluso,
    Boy do I wish we were rating in Tflops :D That would be comparable to GPUs for floating point operations!

    Yeah, me too. All I can say it was after midnight and I must have been caffeine deprived :(
  • cgraceycgracey Posts: 14,209
    I had a talk with the engineer at ON Semi today about the P2 respin. We talked about clock-gating.

    At this point, it sounds like a big hassle to introduce clock-gating. It would slow down the project and cost more money. I think we should just go with what we've got.

    Any thoughts?
  • Sounds good to me, I never wanted you to add the clock gating. To me higher speed is way more important that power draw.

    In my opinion, battery tech these days means having the absolute lowest power usage isn't nearly as big a deal.
  • potatoheadpotatohead Posts: 10,261
    edited 2018-10-22 23:06
    I second Roy.

    This one is shaping up to be quite fast. I did not want gating either. And for same reasons.

    Doing that gating undoes the validation we have been doing, IMHO. And it could render things like the new HDMI feature out of reach.

    This chip will be quite useful even at low clocks. People do have options to balance power with compute and response speed.

    Should this all be successful, the matter could be revisited, and maybe known to be worth it.

  • I thought clock-gating was a dead duck that went out the window when HDMI was added, if not earlier. Talking of which, I really hope the HDMI logic will fit.
  • Go with the existing (after respin) faster version.

    Faster multi-core processing may bring in more customers.
  • I'm fine with that as I know I can always throttle the clock easily which is good enough for some of my applications. We don't want to mess up P2 now especially since everyone is scrambling for P2s, just serve it up like it is and save up for P3.

    How does this affect the 2 cog version though? I'm guessing even without clock gating that with a quarter of the memory and cogs it would draw <20ma on RCFAST?
  • evanhevanh Posts: 16,041
    Come back to it once the money is flowing.
  • RaymanRayman Posts: 14,768
    I vote for speed over power savings...

  • Heater.Heater. Posts: 21,230
    I don't need clock gating.

    I'd love a chip to for this Christmas. Even one of the first batch with whatever faults it has. Been dreaming of Chipmas for such a long time...

    As my son said when he was toddler and wanted something "No, no, I don't want it, I need it".


  • cgraceycgracey Posts: 14,209
    evanh wrote: »
    Come back to it once the money is flowing.

    I think this is the way to do it, if at all.
  • evanhevanh Posts: 16,041
    MRAM will be an option by then! :D
  • evanhevanh Posts: 16,041
    And 110 nm too.
  • cgraceycgracey Posts: 14,209
    edited 2018-10-23 00:01
    I've been doing some simulations to nail down the race condition between DIR and OUT that is causing the low-going glitch when DIR (and OUT, consequently) is changed from high to low.

    In this simulation, DIR is delayed by 200ps relative to OUT.

    Lo and behold:
    2307 x 1185 - 49K
  • cgraceycgracey Posts: 14,209
    Taking out two inverters cuts the 200ps down to 133ps and the glitch goes away!

    I will simulate this at the various corners now.
  • cgracey wrote: »
    evanh wrote: »
    Come back to it once the money is flowing.

    I think this is the way to do it, if at all.

    Once you have a fiscal reason to revisit the design, then you can target a smaller process and get speed/power for free!
  • evanhevanh Posts: 16,041
    I thought the glitch also happened when OUT was held high, and only DIR being lowered.

  • cgraceycgracey Posts: 14,209
    evanh wrote: »
    I thought the glitch also happened when OUT was held high, and only DIR being lowered.

    Ah, yes, but remember that each cog's OUT output is AND'd with its DIR output, so when the DIR output goes low, so does the OUT output.
  • evanhevanh Posts: 16,041
    News to me! Maybe that should be changed.



  • cgraceycgracey Posts: 14,209
    The timing rule is that the DIR signal must not arrive at the I/O pad circuit after the OUT signal. At all corners, this is the case, with some slack, actually. DIR can be a little later, but not enough to try to qualify. If we just make a timing rule on the respin that DIR arrives no later than OUT, we should be golden.
  • cgraceycgracey Posts: 14,209
    evanh wrote: »
    News to me! Maybe that should be changed.



    Think about it. It would be messy. If you set an OUT bit high, and any other cog had that same pin's DIR bit high, the pin would go high. It's nice to qualify OUT bits in cogs with local DIR bits.
Sign In or Register to comment.