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.
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.
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.
...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.
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.
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.
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?
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.
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.
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.
Comments
Aside from the P2, I just have a bypass cap on VDD and one on VIO.
The big PRNG is seeded from ADC noise by the ROM booter.
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.
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.
Boy do I wish we were rating in Tflops 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
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?
In my opinion, battery tech these days means having the absolute lowest power usage isn't nearly as big a deal.
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.
Faster multi-core processing may bring in more customers.
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?
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".
I think this is the way to do it, if at all.
In this simulation, DIR is delayed by 200ps relative to OUT.
Lo and behold:
I will simulate this at the various corners now.
Once you have a fiscal reason to revisit the design, then you can target a smaller process and get speed/power for free!
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.
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.