Objective evaluation of various FPGA noise sources

[Michael Lee]

I will use this thread to share with everyone the raw output of my different random noise / bit sources from the FPGA. A lot of these designs are already in the scientific literature. Only a few are truly my own creations, built on the ideas of previous ones.

Each one has a rate of 50 Mbits per second, because this is the base clock speed of the device. The system clock can be sped up to about 200 MHz without overheating, but for now 50 MHz should be more than enough. Also, you can run many of the sources in parallel. For example, you could have 20 sources running on one 50 MHz FPGA to get a total of 1 Gbits per second.

As you'll see, none of my sources are perfectly random at 50 MHz. Although, if you set the bar lower to say 1 Mbit output, many should pass randomness tests.

I believe that one or more of these sources, and perhaps new variants yet undiscovered can hold an ITC signal. But that won't be the direct purpose of this thread.

One of the most basic things people look for in random bit streams is called "bias." This is usually measured as the number of 1's divided by the total number of bits. 0.5 or 50% is the desired theoretical value. But I think this is too overemphasized in the literature, because if the bias = 0.5 isn't met, people will revert to "whitening" techniques to make the bit stream look more random. 

Now if your goal is generate cryptographic keys to store your cryptocurrency, whitening may be fine. But if you're trying to "hear" spirits, etc, whitening might end ruining the weak signal we're trying to pick up.

Thus I want to introduce a new metric, I just thought up (special thanks to spirit team  , bias variance. If a bias is 0.75 for a particular noise source, that should be fine, as long as it doesn't keep changing over time. We can always subtract the mean, if we're doing things like summing up the bits over an interval (remember the 6,125,000 samples per group bit?)

 

 

 

[Andres Ramos]

3 minutes ago, Michael Lee said:

I will use this thread to share with everyone the raw output of my different random noise / bit sources from the FPGA. A lot of these designs are already in the scientific literature. Only a few are truly my own creations, built on the ideas of previous ones.

Each one has a rate of 50 Mbits per second, because this is the base clock speed of the device. The system clock can be sped up to about 200 MHz without overheating, but for now 50 MHz should be more than enough. Also, you can run many of the sources in parallel. For example, you could have 20 sources running on one 50 MHz FPGA to get a total of 1 Gbits per second.

As you'll see, none of my sources are perfectly random at 50 MHz. Although, if you set the bar lower to say 1 Mbit output, many should pass randomness tests.

I believe that one or more of these sources, and perhaps new variants yet undiscovered can hold an ITC signal. But that won't be the direct purpose of this thread.

One of the most basic things people look for in random bit streams is called "bias." This is usually measured as the number of 1's divided by the total number of bits. 0.5 or 50% is the desired theoretical value. But I think this is too overemphasized in the literature, because if the bias = 0.5 isn't met, people will revert to "whitening" techniques to make the bit stream look more random. 

Now if your goal is generate cryptographic keys to store your cryptocurrency, whitening may be fine. But if you're trying to "hear" spirits, etc, whitening might end ruining the weak signal we're trying to pick up.

Thus I want to introduce a new metric, I just thought up (special thanks to spirit team  , bias variance. If a bias is 0.75 for a particular noise source, that should be fine, as long as it doesn't keep changing over time. We can always subtract the mean, if we're doing things like summing up the bits over an interval (remember the 6,125,000 samples per group bit?)

 

 

 

Very cool! A problem is that we also will get deviations from the 0.5 bias naturally. Can we calculate these natural occurrences and substract them from the number of deviations, let's say per minute?

I would like to suggest to plot the deviations in due speed as a curve. That would be the easiest way to identify deviations from the bias and correlate them with certain incidents. Hm, am I talking again about the PEAR project? I guess I am.

[Michael Lee]

Here are results for two noise sources.

The first one has pretty solid randomness, but it is biased. https://res.mdpi.com/d_attachment/symmetry/symmetry-12-00506/article_deploy/symmetry-12-00506-v2.pdf

The second has much less bias, but some correlation bits at the highest frequencies. (https://www.hindawi.com/journals/ijrc/2009/501672/)

Most of the noise sources I've coded up sound and look like white noise when you reach the audible range, so we are really honing on non-randomness at the 50 MHz sampling rate. The idea is that we need the higher sampling rate to get more information from spirit.

[Michael Lee]

Here's a few more results, to show you the range of what can happen.

Also, these are all my unique designs that are pretty much extensions of the 2020 paper to 3, 4, and 8 "nodes."

The 47 gates comes from the fact that the aggregate delay is around 20 ns, which is around the period of a 50 MHz clock cycle.

It also should be pointed out that randomness at 50 MHz may not be required for ITC. It may be sufficient that the systems are "chaotic" or that they switch back and forth randomly between nearly periodic states.

[Andres Ramos]

The image pattern of the Tetrahedral 47 gate oscillator shows a relevant grid pattern as if there are no long chains of 1s and 0s but only short ones.