New P2 Silicon Observations

1131416181923

Comments

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

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    P2 SHORTFORM DATASHEET +++++ TAQOZ documentation
    Brisbane, Australia
  • 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: 10,524
    edited October 10 Vote Up0Vote Down
    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.
  • Yep. I goofed badly there. Corrected to GIps. G instructions/s
    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)
  • 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.
  • __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.

  • __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!
  • 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 :(
    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)
  • 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: 9,574
    edited October 22 Vote Up0Vote Down
    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.

    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • 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.
    Formerly known as TonyB
  • 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?

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    P2 SHORTFORM DATASHEET +++++ TAQOZ documentation
    Brisbane, Australia
  • Come back to it once the money is flowing.
    Money is a placeholder for cooperation
  • I vote for speed over power savings...

    Prop Info and Apps: http://www.rayslogic.com/
  • 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".


  • evanh wrote: »
    Come back to it once the money is flowing.

    I think this is the way to do it, if at all.
  • MRAM will be an option by then! :D
    Money is a placeholder for cooperation
  • And 110 nm too.
    Money is a placeholder for cooperation
  • cgraceycgracey Posts: 10,524
    edited October 23 Vote Up0Vote Down
    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
  • 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!
  • I thought the glitch also happened when OUT was held high, and only DIR being lowered.

    Money is a placeholder for cooperation
  • 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.
  • News to me! Maybe that should be changed.



    Money is a placeholder for cooperation
  • 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.
  • 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.