On Wed, 29 Apr 2015 02:16:52 -0500, "Tim Williams"

wrote:

Er, well.. surely an LFSR will be flat, not Gaussian, no?
Single bit digital noise has a PDF with two big impulses, about the

worst approximation to Gaussian (or flat) imaginable. So you need to

sum a LOT of them to get something sort of Gaussian... the Central

Limit Theorem thing. Hence the 20 KHz filter. Higher-order filters

work way better than single-pole ones.

If you nab 16-bit words from the shift register, and not the single

bit, you start with a basically flat histogram. Summing a modest

number of them gets Gaussian pretty fast. That's harder to Spice.

Fortunately, there is an app\\\ transform for that:

http://www.design.caltech.edu/erik/Misc/Gaussian.html

shouldn't be too bad to implement on FPGA. Log can be very crudely

obtained as the highest active ('1') bit position, and can be improved

iteratively (by repeated squarings and bit-shifts, or Taylor series

polynomial approximation methods).

Obviously, to shoot it out of a DAC, the bounds must be strictly limited,

so part of your spec will be how many sigma of Gaussian it's good for

(usually 3 or so?).
We have a +-10 volt DAC range, and we figure that 1 volt RMS is a good

number, and our 15-tap FIR filter will give us a crest factor of about

5.5. That sounds OK; I don't think our customers would want truly

Gaussian noise with infinite voltage spikes.

Which, in turn, implies that the argument of the log can't be near zero

(which is what produces the peaky outliers), and certainly can't be zero

exactly (which would be undefined), so perhaps the LFSR's inherent bias

could be tuned to match the dynamic range of the desired output? Nah,

probably not, not for any reasonable sequence length. So you'll have to

do something ugly (and hopefully not badly behaved), like RND * scale +

offset.

There are also methods for that -- ensuring that an output of truncated,

arbitrary range is calculated correctly from an even distribution in some

other range.

The geometric form is interesting, too; a random time delay could trigger

a S&H of complementary (90 degree phase shifted) sine waves, and the other

random number could feed a suitable arrangement of matched diode junctions

or OTAs which computes the sqrt(ln(x)) function, and simultaneously

controls the gain on the S&H buffers.

The "random" time delay has a strictly bounded range, so it could be

triggered on a fixed clock, 'computed', then 'registered' with a second

S&H on the following clock pulse, to give regularly sampled outputs (same

as you'd use extra D-flops to neaten up the transitions in a digital logic

circuit). Who even needs a DAC?

Or you could randomly sample a sin/cos table and vary the VREF into an

MDAC, or...
A tapped analog delay line is easy to Spice. If you poke in random

values and evenly sum the taps, that amounts to summing a sucession of

samples, so it does the Central Limit thing for you. And it's also a

finite-impulse-response filter. Everything turns out the be the same

thing, just looked at from different angles.

I really need a histogram back end for LT Spice. Snarl, snap, I guess

I'll have to make one.

--

John Larkin Highland Technology, Inc

picosecond timing laser drivers and controllers

jlarkin att highlandtechnology dott com

http://www.highlandtechnology.com