High frequency output from CMOS 74HC04 ring oscilator as digital input on ATTiny - Page 1
Forum section: electronics / projects

author: beduino
author_rank: Regular Contributor
timestamp: September 10, 2018, 09:04:10 pm
content: Hello,I'm working now on TRNG based on two CMOS 74HC04 Galois ring oscilators with additional XOR gates.Output from these two RO's is connected to microcontroler digital input pins (ATTiny85 8Mhz-16MHz 5Vcc )and maybe some kind of buffer like D-type Flip-Flop 74HC74D is needed to catch with addidional clock or MPU clock output high speed logic gates output,to be able make post processing on MPU by reading as digital input on MPU two pins or MPU pins will do something similar to D-type Flip flopwhen pins are used in digital mode?Propagation time in 74HC04http://www.ti.com/lit/gpn/sn74hc04(6 inverters) based ring oscilators is at the range of 10ns, so quite high output signal frequency .Regards.Bedu.

author: ogden
author_rank: Super Contributor
timestamp: September 10, 2018, 09:08:14 pm
content: Quote from: beduino on September 10, 2018, 09:04:10 pmWhat is "quite high signal frequency"? You are advised to specify exact or estimated frequency w/o letting others guess or calculate it. This is typical two clock domain application and Attiny is most likely slow clock here. So yes - it is advised to make some arm/latch/read external logic so MCU can "request" next bit to be latched in the register, then read it.

author: beduino
author_rank: Regular Contributor
timestamp: September 10, 2018, 10:24:01 pm
content: Quote from: ogden on September 10, 2018, 09:08:14 pmIt looks like signal frequency might be order of magnitude times higher than MPU clock: 1/10ns ~ 100 MHz,Anyway, looking at alternate port functions section of Attiny85 MPU datasheet we have D-type Flip-Flops at SYNCHRONIZER section of READ Port Pin (RPx) block already clocked by CPU clock, so maybe it doesn't make sense use on PCB D-type Flip-Flop while it looks like MPU itself have built in read port pin latchInput digital signals are random noise bits aka TRNG, so it is not a problem we miss some bits while sampling at 10 times lower frequency at best I/O digital MPU pins....Probably, I will go for test without external D-type Flip Flop and we'll see if TRNG noise bits postprocessed by MPU will pass afew standard tests for randomness

author: MK14
author_rank: Super Contributor
timestamp: September 10, 2018, 10:26:49 pm
content: A latch would be very difficult, to get it "properly" working. Because you would fail to meet the data set up time (datasheet link below), before clocking the 74HC74D, which may cause it to not work correctly (metastability, which could mean the data would stick to the same logic level (or randomly oscillate etc), for a brief period of time). Which would probably reduce/limit the randomness.https://toshiba.semicon-storage.com/info/docget.jsp?did=37138&prodName=74HC74DIf you tried it. It probably would appear to work ok, but some of the random bits, may stick.So it could go 1, 1, 0, 1, 0, 1, 0, 1, 1, 1, 111111111111111111111111111111111111111111 (metastability), 0, 1, 0, 0, 1, etc. (or randomly oscillate, which ironically is what you want TRND etc).It is possible the metastabilty may be of short enough duration, so it appears to work ok. But it would be bad practice, to ignore it.One option, would be to use the variant of ring oscillators, which uses small valued capacitors (plenty examples on web on how to do this), to slow it down a bit. So the MCU can reliably read the logic levels, all by itself (no latches).Or just try it (straight into MCU, no latches), and see if you get about 50% logic 1's and vice versa. I.e. random as desired.

author: MK14
author_rank: Super Contributor
timestamp: September 10, 2018, 10:35:56 pm
content: [Quote from: beduino on September 10, 2018, 10:24:01 pm10 nano seconds high, then 10 nano seconds low = 50 MHz.Also, if you use all 5 (6 wouldn't be a odd number) inverters, in a chain, I think it slows down a lot. So it would be something like 50/5 = around 10 MHz.

author: ogden
author_rank: Super Contributor
timestamp: September 10, 2018, 10:43:47 pm
content: Quote from: beduino on September 10, 2018, 10:24:01 pmYou have SYNCHRONIZER which runs at 16MHz with slew rate which is way too slow for proper 100MHz data latching. If Attiny could successfully latch 100MHz data, then why it is not specified for 100MHz, but just 16MHz?QuoteIt's not about missing anything. It's about properly recognizing 0 versus 1 at given moment of time. While Attiny clock changes it's state, incoming data most likely will manage to change it's state more than one time - yes, *during* clock transition! It could be so that your generator output gives balanced number of 1's and 0's for longer periods, but Attiny result is biased to 0's or 1's. It could get something that differs from steady 0's or 1's output but my guess - it will not be "white" nor balanced.

author: beduino
author_rank: Regular Contributor
timestamp: September 11, 2018, 07:25:31 am
content: Quote from: MK14 on September 10, 2018, 10:35:56 pmThanks, for pinting out I've missed estimated signal period in the case of one inverter based clock.Yep, it is 74HC04 chained inverters based Galois RO,but with additional xor 74HC86 gates between stages of similar around 10ns propagation time depending on operating voltage 2V-6V, so it might run at higher signal frequency than 10 MHz - something like 25 MHz.External D-type Flip Flop 74HC74D with maximum frequency at 5V around 70MHz looks like should be fine to latch this random digital noise if pure MPU reading of its digital I/O pins with internal latch synchronized by CPU clock will not pass tests for randomnes.Metastability is what I want, so no problem oscilatiions while reading MPU pins

author: iMo
author_rank: Super Contributor
timestamp: September 11, 2018, 09:51:35 am
content: Based on your schematics you have got 13 logic elements inside the ring oscillator in your pseudorandom generator (mind your pattern repeats every xx clocks).Your signal max freq will then beFclock = 1 / (2*10ns*13) = 3.85MHz

author: MK14
author_rank: Super Contributor
timestamp: September 11, 2018, 02:06:42 pm
content: Quote from: beduino on September 11, 2018, 07:25:31 amSo by messing with the switches, to the Xor gates. You can effectively, change (mess with), the timing/characteristics of the ring oscillator. Allowing you to get varying timings and hence randomness.My understanding (these random number generators, can get very complicated, so I'm perfectly happy to stand being corrected here), is that you may need to also use a (high quality) pseudorandom number generator (inside the MCU), which you "mix" with the true random number generator bits and/or seed the pseudorandom with the true random number generator bits.This is to compensate/reduce and hopefully eliminate real life discrepancies between your supposed true random number generator, and a practical real life one.E.g. One of the big concerns, would be that instead of the long average bit ratio being exactly 50.000000%, it could be 59% (logic 1) : 41% (logic 0), etc.Because of the above, that is why the Intel True Random Number generator (New instructions: RDRAND - Ivy bridge and later, RDSEED - Broadwell and later, AMD at around Zen), present, in later versions of their cpu range, uses cryptographically secure algorithms (essentially using them as high quality pseudorandom number generators), to "mix" with the true random number bits, generated inside most/many modern Intel cpus.There are articles on the internet, going into some (but not necessarily all) details, about how the Intel random number generators work.What I have written above, is a hugely condensed/simplified version. The actual/real details (Intel and later AMD cpus), gets way, way more complicated. They (Intel/AMD), don't seem to be happy to release the detailed technical details (e.g. schematics etc), of exactly how their true random number generators work, unfortunately.

author: MK14
author_rank: Super Contributor
timestamp: September 11, 2018, 04:37:17 pm
content: The process, I was describing in my post above (fixing deficiencies in true random number sources), is often called "Whitening".E.g.https://crypto.stackexchange.com/questions/18356/whitening-and-randomness-extractionAnd hence (I would prefer the wiki page, to call it or refer to "Whitening", but it doesn't)https://en.wikipedia.org/wiki/Randomness_extractorThere are all sorts of faults/difficulties/issues when making true random number generators, that usually without some kind of "Whitening" step/process, means that the random numbers will be of poor quality (or at least, not perfect random numbers).Many, later, higher end (big) MCUs, have now got built in hardware true random number generators. Usually intended for cryptographic applications, but you can use them as true random number generators, for just about anything.

author: beduino
author_rank: Regular Contributor
timestamp: September 11, 2018, 08:07:53 pm
content: Quote from: MK14 on September 11, 2018, 02:06:42 pmI would not like to provide exact schematics of this TRNg circuit for the moment, but I believe in I've implemented in hardware some kind of Von Neumann corrector and as we can see "the hardware corrector design is patent pending by Intel Corporation" - not sure how old this article was about Intel RNGI didn't even look into this "Intel patent pending" hardware corrector, but it can be easy implmented in MPU,so that is why for the moment my PCB without hardware corrector looks like this below for testing purposes,but probably MPU will have to be very close to logic gates - it is standalone PCB with two TRNG outputs.Quote from: MK14 on September 11, 2018, 02:06:42 pmThis simple hardware based TRNG is not designed for critical security cryptographic applications, so if those TRNG bits will pass A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications:https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-22r1a.pdfit will be fine - if not still can be usefull to user shifting registers without MPU and blink LEDs or artificial stars, etc in some fun projects

author: MK14
author_rank: Super Contributor
timestamp: September 12, 2018, 07:42:27 pm
content: Something on the lines of the "Von Neumann corrector", should improve the quality of things for you, and slow down the frequency of the ring counters rate of information sampled by the MCU, further still.But I think ring counters, tend to produce only some truly random bits, and then many relatively predictable bits. Despite the "Von Neumann corrector", which should at least improve the situation.I.e. your ring counter(s) and sampling system, will often produce some kind of semi-fixed binary pattern.E.g. 1,1,0,1,1,0,1,1,0,1,1,0,1,1,0,1,1,0,1,1,0,1,1,0,1,1,0,1,1,0,1,1,0,1,1,0,1,1,0,1,1,0,1,1,0,1,1,0,1,1,0,1,1,0Because of the aliasing and things (beat frequencies etc), between the oscillator(s) and sampling frequency, but occasionally (due to random jitter because of temperature variations and other sources of drift with the ring oscillators), there will be these truly random bit changes.I have no exact idea, but presumably for every truly random bit, post "Von Neumann corrector", you will get 5, or even 100, relatively/statistically non-random ones. N.B. the 5..100 range is a total guess, and could be way, way out.So a quality statistically set of tests for true randomness (at least mathematically, even if not in real life), suchas the diehard tests (https://en.wikipedia.org/wiki/Diehard_tests), and other tests, such as the one you linked to. There are more modern ones available. But be careful, some of them need a crazily huge number of random test numbers to work well (which is fine for a PC based one, but if it takes ages to serially send your numbers into a PC for post processing, it could be a factor).They would probably detect the fact that only a small number of the bits are truly randomly distributed, and the rest have a kind of pattern to them.I.e. They would notice that there is a statistical relationship, between past bits and new bits.Anyway, it sure will be fun trying it out, and since it sounds like you are using it for hobbyist purposes. It does not matter if it is not 100% truly random in its nature.

author: beduino
author_rank: Regular Contributor
timestamp: September 12, 2018, 08:34:24 pm
content: Quote from: MK14 on September 12, 2018, 07:42:27 pmFirst attempt with TRNG was some time ago by using floating MPU pin and software simple PRNG running on MPU, but it could be nice have decent quality TRNG without need to use MPU for Von Neumann corrector , so just drawing PCB with my hardware implemented corrector, so only one TRNG bit output from PCB similar to shown earlier with Vcc 2V-6V and GND (three pins) should do the trick, I hopeLogic gates just arrived from my electronics supplier today, so it is time to make test PCB using old school thermal transfer method, but in slightly more interesting way I will show maybe on YT, because of it is quite interesting I think for small PCB boards like this one (inch x inch 25mm x 25mm )

author: MK14
author_rank: Super Contributor
timestamp: September 12, 2018, 08:45:17 pm
content: 1 inch square, is small and neat. Clearly surface mount, and not through hole. (Otherwise, very neat soldering, and good job on squeezing the DILs into such a small space).Anyway, I hope your build goes well.If it goes badly, and one of the chips, randomly changes its output all the time, due to a chip fault. It would still appear to work, 100% ok. So, win win, I guess.