Noise generator circuit

[Tony Stewart]

yes spec, I agree https://www.xilinx.com/support/documentation/application_notes/xapp052.pdf
after checking your links, this one is best and also includes my Q47,Q42 stage feedback for a MLS PRSG (max length seq pseudo random seq. gen.). or LFSR ( Linear Feedback Shift Register) to match Bob's spec.

it can be done in HW , or SW

Note the table 3 has only an even number of feedback points into XNOR thus initial condition can be all 1's but not all 0,s
I've verified these designs many times and used for communication BER testing.

 

[Tony Stewart]

Another way to specify a sequence is by it's Run Length Limited values or RLL which specify the minimum , maximum clock cycles per transition interval.

Bob can you spec this? This naturally controls the spectral limits divided into clock rate, approx.
my example would be (1,47) and spectrum is flat with sharp notches at f/93 and f with sub-harmonics and super-harmonics at 2f, 3f...

 

[BobW]

Bob can you spec this?

Sure. First and foremost, from the very first post in this thread:

...a hardware based true random number generator.

From that it should be obvious that I'm not looking to build a pseudo random number generator, which seems to be the direction that this discussion has now taken. I'm well aware of how to build pseudo random number generators. But, if we must discuss them then I'll point out some of the issues. LFSR's are the flavour of the week because everyone's concerned about cryptographically secure random numbers, and LFSR's happen to be reasonably good for that application. As I previously stated, my requirement is to feed random numbers to several parallel processors running Monte Carlo simulations. Hence, it's extremely important that the sequences of random numbers doesn't overlap from one processor to another. So far, I'm only using four processors, but that may increase significantly. To the best of my knowledge there is no way to seed an LFSR in such a way as to guarantee that there will be no overlap. If you know of a method that is provably overlap free then I would be very interested.

On the other hand, for the system that I have running at present, I chose to use a 4 cycle LCG (linear congruence generator), based on Wichmann and Hill's 2005 algorithm. It has a period of 2^120, it passes all of the statistical tests that are necessary for Monte Carlo simulations, and it is trivially simple to implement in high level languages using the fewest lines of code and the smallest state memory size. Most importantly though, it is possible to deterministically set the seed values for different processors to guarantee that there is no sequence overlap. This is paramount.

Edit:
I mentioned earlier that I need to create double precision floating point random numbers, and said that the mantissa would be about 48 bits long. I realized later that IEEE double precision uses 53 bits. That would require an LFSR to be iterated 53 times to generate each random number, or else use 53 LFSR's in parallel. By comparison the LCG requires only a single iteration to generate a 64 bit random number.

 

[Tony Stewart]

Every so-called "true random noise" will have limitations. This is obvious due to the many different test criteria, perhaps in localized randomness, Shannon Entropy , n , a power of 2 or perhaps the autocorrelation histogram or the Markov chain etc. .e.g. the number of consecutive heads in a coin toss or maximum length or the Interval coefficient

I asked for a spec on your criteria. "Monte Carlo" is a method , not a criteria.

for example, we know that avalanche noise is a stoichastic process with a multiplication factor from sufficient charge rate or "threshold current" to noise pulse current , using the inverse ratio. The quantum mechanical tunneling of carriers through the bandgap will have limitations due to the channel length, thickness and conflicting requirements for low doping and doping that results in a finite Multiplication Factor for avalanche to leakage ratio or the ratio of energy of charge flow from excitation to escape of a charged particle.

The above limitations results in a limited range of bandwidth in decades or powers of 2 for Shannon entropy. Although thermal avalanche noise can be non repeating, memory-less and said to have infinite entropy it will have limited bandwidth ratio. A simple PN junction often has a limit of 6 decades due to the RC time constants of the diode capacitance using the R leakage to ESR ratio. eg. 10M/10 ohm = 10^6. This bandwidth ratio is equivalent what a Shannon called entropy of ~3x =18 (10log(2)=3.0103x) This is due to mass mobility and RC time constant inherent characteristics from the physical channel.

Thus the frequency span in decades will be finite.

Thus you need to define the entropy of your data , frequency ratio or the spectral density and span of distribution or some measurable / testable criteria defined by experts. We know there are many solutions and ways to analyze this but it depends on your specs. ... besides overlap and entropy of 120.

For example is would be easy to make a LFSR of length greater than 3DES or 3x56 and then shift for each processor a new result. The memory requirement is simply the Shannon entropy value in bits with an XOR function of the known MLS feedback bits. This could be sent to each CPU in a round robin approach in Real Time DMA dual channel memory with the time interval defined by the core CPU time to process the result or perhaps a faster more clever way.

There are better tools, but I need better requirements. Encryption is hard, but best defined by simple rules. The more complex it is, the greater chance for holes in the randomness. Decoding by brute force is not always the best solution by Monte Carlo rules.

Rolling Codes use a one time key that changes each time upon iteration as well as the method of scrambling.
Do you know anything about the algorithm or spectral density or packet size or are you just trying to hack DES bank information codes?https://en.m.wikipedia.org/wiki/File:Data_Encription_Standard_Flow_Diagram.svg

 

[BobW]

Being the expert that you supposedly are, you should know that simply specifying a couple of parameters is grossly inadequate for determining the quality of a random number generator. It must pass a battery of statistical tests before it can be deemed acceptable.

So, if you feel up to the task, then it needs to have a cycle period of 2^121, and produce double precision floating point values (53 bit mantissa) in the range 0.0<=n<1.0. It should pass the "Big Crush" suite of statistical tests with none of the p values falling within 0.01 of the limiting values (0 and 1). If any test yields a p value below 10^-15 then it can be considered a catastrophic failure of the RNG. If any test yields a p value below 0.01 but above the catastrophic level, then that test should be repeated four more times yielding values above 0.01 (since statistically, a good RND must occasionally fail a randomness test). The p values should also be evenly distributed. Nothing earth shattering here, it's an accepted standard for a good industrial strength RNG.

The four cycle LCG that I currently use, has passed this test suite. And as I previously stated, it has the advantage that I can seed it deterministically to generate non overlapping sequences. Furthermore, what I'm already using is easily implemented as a simple and fast subroutine in the main hardware. Therefore, if I decide to stay with a pseudo random number generator, there is no reason to use external hardware, and certainly no sensible reason to construct some ridiculous DMA hardware just so that I can use an LFSR that doesn't appear to offer any advantage whatsoever.

If you want to try, go ahead, knock yourself out. But please don't waste everyone's time by stringing together random techno jargon into sentences and posting it here, just to try to make yourself appear intelligent. It's not fooling anyone.

 

[Tony Stewart]

Being the expert that you supposedly are, you should know that simply specifying a couple of parameters is grossly inadequate for determining the quality of a random number generator. It must pass a battery of statistical tests before it can be deemed acceptable.

So, if you feel up to the task, then it needs to have a cycle period of 2^121, and produce double precision floating point values (53 bit mantissa) in the range 0.0<=n<1.0. It should pass the "Big Crush" suite of statistical tests with none of the p values falling within 0.01 of the limiting values (0 and 1). If any test yields a p value below 10^-15 then it can be considered a catastrophic failure of the RNG. If any test yields a p value below 0.01 but above the catastrophic level, then that test should be repeated four more times yielding values above 0.01 (since statistically, a good RND must occasionally fail a randomness test). The p values should also be evenly distributed. Nothing earth shattering here, it's an accepted standard for a good industrial strength RNG.

The four cycle LCG that I currently use, has passed this test suite. And as I previously stated, it has the advantage that I can seed it deterministically to generate non overlapping sequences. Furthermore, what I'm already using is easily implemented as a simple and fast subroutine in the main hardware. Therefore, if I decide to stay with a pseudo random number generator, there is no reason to use external hardware, and certainly no sensible reason to construct some ridiculous DMA hardware just so that I can use an LFSR that doesn't appear to offer any advantage whatsoever.

If you want to try, go ahead, knock yourself out. But please don't waste everyone's time by stringing together random techno jargon into sentences and posting it here, just to try to make yourself appear intelligent. It's not fooling anyone.

You have given good test criteria finally. THere are broad applications and many can be specified with a few simple parameters for short or long term randomness. Since you have chosen to omit the application, it was open to guesswork. I have only solved a dozen or so problems that required a measured level of randomness, but I am not a crypto guru.

My favorite project was using biometrics in 3D with vectored fiducials to secure data, where that company was worth over 100m$ in stocks claimed it was unhackable "analogic" ... I debunked it , we chose not to manufacture it , as they requested. The US Navy were disappointed and the stock later returned to it's real value. 0.

Are you familiar with Latin Squares? I would suggest reading this. https://www.grc.com/otg/uheprng.htm

 

[MrAl]

Being the expert that you supposedly are, you should know that simply specifying a couple of parameters is grossly inadequate for determining the quality of a random number generator. It must pass a battery of statistical tests before it can be deemed acceptable.

Hi,

Well, if you have a list of known long length sequence feedback stage choices then you're good to go, unless you dont trust the list, in which case you have to do what you have to do even if you do trust the list, and that is TEST it. If you dont want to test it then you are wasting your time mainly because digital random number generation is one of the most misunderstood topics and in the analog world true noise generation ranks about the same. As it goes, if you think you know how to generate random numbers and you never test it, then you dont know anything about random number generators
BTW i dont know if Tony's suggestion made the list and it very well could have, but im sure we could find out on the web by looking this up.

That wasnt going to be my reply until i read yours, i just wanted to mention that noise generators that use amplifiers may not generate true white noise if they in turn get some non random noise somehow injected into the circuit. If the injected noise is repetitive it could cause a repetition of pattern. I dont know for sure how your randomness needs to be shaped though, what overall properties it needs to comply with.

If you are TRULY serious about this project, and it sounds very much like you are, then you would go out and purchase a good quality hardware RNG that had been thoroughly tested. If you read some of the literature you'll quickly find, if you havent already, that some major blunders have been wondrously achieved <chuckle> in the past by playing around with random number generation that wasnt very good random number generation.

LATER:
Ok, Tony's two point feedback made the list for 47 bits.
For a 55 bit you can use points at 55 and 31.
I guess this might be moot though if you dont want to use this kind of generator.

 

[Tony Stewart]

Hi MrAl,
I agree all conducted and radiated interference must be totally eliminated by at least 150 dB down within the range of signals desired for this application to achieve requirements specified.

I have thoroughly tested these type of MLS PRNG's using a spectrum Analyzer over 8 decades of amplitude, frequency BW and time interval, with variable parameters. There are limitations from the repetetive nature over time but I know how well these prime number linear feedback generators work and their limitations One could in increase the entropy, En by choosing a bigger number like En= 300 at the expense of a very large shift register.

2^21 works very well for BER testers, channel equalizer tests for modems, ADSL etc, but for special microwave Noise Figure Test measurments of amplifiers, expensive oven controlled with pure DC on a carefully biased Avalanche diodes works best.

For massive entropy far beyond this question's requirement, one needs to use Latin Squares. Steve Gibson's design is a 26x26 Latin Square which is very efficient and has super massive entropy of 1536 bits. he writes in my prev link...We achieve those two goals by generating and capturing a very long 1536-bit pseudo-random number — the “SeedKey” — then using that number to set the ultra-high entropy pseudo-random number generator's 1536-bit “initial state” from which a single unique grid will be created.

 

[Tony Stewart]

Bobw <<if my words sound jumbled, then I assumed you know what I do and did not write clearly enough.