Generating Gaussian Noise in FPGA using LFSRs and CLT

Gaussian noise is one of the most commonly used statistical signals in digital communication, radar, SDR, and electronic test systems.

It is used to evaluate how a system behaves under realistic noise conditions.

For example, in telecommunications, a receiver may be tested against Additive White Gaussian Noise (AWGN) to measure BER and receiver sensitivity. More advanced channel models can use Gaussian random variables as building blocks for Rayleigh and Rician fading.

In radar testing, stochastic models can be used to reproduce fluctuating target behavior such as the Swerling I–IV models. In a laboratory, the same concept can be used to test ADCs, DACs, receivers, DSP algorithms and hardware-in-the-loop systems.

In software, generating Gaussian random numbers is relatively straightforward.

But what if we need to generate those samples continuously and directly inside an FPGA? This project explores a hardware-friendly solution based on a simple idea:

Generate uniform pseudo-random numbers using LFSRs, then use the Central Limit Theorem to approximate a Gaussian distribution.

The complete design was developed and statistically validated using MATLAB and AMD Vitis Model Composer before being prepared for FPGA IP generation and Vivado integration.

The Challenge

A Gaussian random-number generator can be implemented using several mathematical approaches.

Some methods require operations such as logarithms, square roots, and trigonometric functions. While these are convenient in software, implementing them efficiently in FPGA logic can require additional hardware resources and design complexity.

For a high-throughput FPGA design, I would prefer an architecture based on operations that map naturally to digital hardware.

This leads to my approach:

The goal is therefore not simply to generate a Gaussian-looking histogram.

The goal is to create a reusable hardware-oriented Gaussian random sequence generator that can be used as an FPGA IP block.

The Basic Idea

An LFSR, or Linear Feedback Shift Register, is a simple digital circuit capable of generating a long pseudo-random sequence.

With suitable feedback, its output can be used as a uniform pseudo-random source.

The Central Limit Theorem provides the second part of my solution.

When independent random variables are added together, their resulting distribution approaches a Gaussian distribution as the number of variables increases.

Therefore, instead of implementing a complicated Gaussian transformation, I can use:

This is attractive for FPGA implementation because the main operations are digital logic, XNOR feedback, and addition.

From Uniform to Gaussian

Each LFSR produces a uniform pseudo-random sequence.

If I normalize the output of each LFSR to approximately:

0 ≤ Uᵢ < 1

For a Uniform(0, 1) random variable - Mean is:

E[U] = 0.5

and the variance is

Var[U] = 1/12

then the sum of twelve sources is:

S = U₁ + U₂ +... + U₁₂

Therefore, for twelve independent variables - Mean is:

E[S] = 12 × 0.5 = 6

and the variance is

Var[S] = 12 × 1/12 = 1

This gives me a particularly convenient result.

If I subtract the expected mean:

G = S − 6

the resulting sequence should approach a zero-mean, unit-variance Gaussian distribution.

The Central Limit Theorem provides the approximation, while the FPGA implementation provides the hardware realization.

Why Twelve LFSRs?

The Gaussian approximation improves progressively as more random variables are summed.

I selected twelve sources as a practical design point that provides a good Gaussian approximation while keeping the number of LFSRs and adders manageable.

Increasing the number of terms can improve the approximation, but also increases the number of LFSRs and additions required.

LFSR Architecture

My implementation uses 12 parallel LFSRs.

Each LFSR has:

• 16-bit state
• 16-bit parallel output
• unsigned fixed-point representation
• 16 fractional bits
• the same initial state
• a different feedback polynomial

Mean of LFSR output is:

LFSR mean = 0.499857

Variance of LFSR output is:

LFSR variance = 0.083311

These values are close to the theoretical values for a Uniform(0, 1) distribution:

Mean = 0.5

Variance = 1/12 ≈ 0.083333

The choice of different feedback polynomials was made after an earlier experiment.

Initially, I used the same feedback polynomial with different initial states. The resulting sequences showed more correlation than desired.

Therefore, I changed the architecture to use different feedback polynomials for the twelve generators.

Rather than assuming that this automatically guarantees independence, we measured the correlation between the generated sequences and used that as an empirical validation of the approach.

Fixed-Point Implementation

Since the final target is FPGA hardware, the implementation uses fixed-point arithmetic.

Each LFSR output is represented using: Fix_16_16

The twelve outputs are generated simultaneously and added together. Since each input lies in the range 0 ≤ Ui < 1, the theoretical range of the sum is 0 ≤ S < 12. Therefore, the summation requires additional integer bits, and the resulting signal is represented using Fix_21_16.

The mean of the summed distribution is then removed [G = S − 6]; giving an approximately zero-mean Gaussian output.

No floating-point Gaussian transformation is required.

MATLAB and Model Composer Development Flow

Before generating FPGA IP, I first validated the algorithm using MATLAB and Vitis Model Composer.

The development flow was:

LFSR Design
     ↓
Model Composer Simulation
     ↓
MATLAB Data Analysis
     ↓
Statistical Validation
     ↓
Fixed-Point Verification
     ↓
IP Generation
     ↓
Vivado Integration

The Model Composer simulation provides the hardware-oriented implementation, while MATLAB is used to analyze the statistical properties of the generated data.

This separation makes it easier to compare the expected mathematical behavior with the actual fixed-point hardware model.

Model Composer Design

The complete Model Composer design consists of twelve parallel LFSR generators followed by the CLT summation and mean-removal stage.

Each clock cycle produces one sample from every LFSR.

The twelve samples are therefore available in parallel for the summation stage.

Statistical Validation

After simulation, the twelve LFSR outputs were exported to MATLAB.

I evaluated three important aspects:

1. Gaussian distribution

I plotted a histogram of the generated sequence and compared it with a Gaussian probability density function.

2. Statistical parameters

I calculated:

• mean
• variance
• standard deviation

3. Source correlation

I calculated the complete 12 × 12 correlation matrix to evaluate the relationship between the twelve LFSR outputs.

Gaussian Distribution Result

The generated sequence produced the following statistics:

The measured mean is very close to zero, and the variance is close to the desired unit variance.

Note: The small deviation from unit variance is expected in a finite-length fixed-point pseudo-random implementation due to finite sequence statistics, quantization, and the non-ideal independence of deterministic LFSR sources.

The histogram follows the expected bell-shaped Gaussian profile, demonstrating the effect of summing the twelve uniform sources.

68–95–99.7 Rule

A standard Gaussian distribution has approximately:

• 68.27% of samples within ±1σ
• 95.45% within ±2σ
• 99.73% within ±3σ

My measured results were:

The results are very close to the expected Gaussian values.

This provides a second validation of the generated distribution beyond simply looking at the histogram.

Verifying the CLT Sum

I also examined the distribution before mean removal.

The sum of the twelve uniform sequences produced:

Sum mean = 5.999473Sum variance = 1.015423

The theoretical mean is:

12 × 0.5 = 6

After subtracting six:

G = S − 6

I obtained:

G mean = 0.000527G variance = 1.015423

The measured mean therefore agrees closely with the theoretical expectation.

Correlation Analysis

The Central Limit Theorem (CLT) result relies on the random sources being sufficiently independent for the approximation to hold.

Because my twelve sources are generated by deterministic LFSRs, I did not simply assume that they were independent.

Instead, I measured the correlation matrix:

The maximum absolute off-diagonal correlation measured was:

0.013464

and occurred between:

U8 and U5

The low measured correlation supports the suitability of the generated sequences for CLT-based architecture.

This is an empirical statistical observation, rather than a mathematical proof of complete independence.

From Algorithm to FPGA IP

Once the statistical behavior of the Model Composer implementation was validated, the next step was to convert the design into reusable FPGA IP.

The intended workflow is:

Vitis Model Composer → IP Generation → Vivado → Simulation → Synthesis → Implementation

The purpose is to turn the Gaussian generator from a simulation model into a reusable hardware block.

For that, add the Vitis Model Composer hub into your design, and you can find it here:

Library Browser → AMD Toolbox → Utilities → Code Generation → Vitis Model Composer Hub

This is the central block for timing and resource analysis, code generation, and export.

Configure the Target Device

Open the Vitis Model Composer Hub.

Set the target device/board to the FPGA platform you actually intend to use

Configure Clock

Go to the Code Generation → Settings section.

Configure:

• target language
• FPGA clock period (ns)
• Simulink system period (sec)

Analyze

The analysis tool evaluates timing constraints and hardware resource utilization following the synthesis and implementation phases. This data allows you to optimize your algorithms, balance resource allocation, and verify system performance targets before final deployment.

To evaluate your design, execute the sequential workflow illustrated below. The generated reports provide the necessary metrics to refine system efficiency and address timing violations.

Click Analyze to begin processing. AMD Vitis Model Composer will compile your design and generate a comprehensive Timing and Resource Analysis Report based on your specific configuration

• Timing Analysis Report: Details clock frequencies, propagation delays, and setup/hold violations to verify your design satisfies all timing constraints.

• Resource Analysis Report: Breaks down the utilization of Look-Up Tables (LUTs), Digital Signal Processors (DSPs), Block RAM (BRAM), and Flip-Flops (FFs) to highlight hardware optimization opportunities.

Export as IP Catalog

The export phase finalises and packages your custom IP block for integration into AMD Vivado.

• Configure all export parameters exactly as shown in the figure below
• Click Export to initiate the packaging process.

Note: Compiling the IP files will take several minutes. A confirmation message will appear when it completes successfully.

This process generates the packaged IP files, which can then be added to the Vivado IP Catalog by configuring the generated directory as an IP repository. You can now seamlessly integrate this custom IP into your target Vivado design flow for system-level routing, placement, and final implementation.

Add Custom IP to Vivado Repository

Open Vivado and initialize a new project.

For your project:

Project type → RTL Project

Select the same FPGA/device you targeted in Model Composer.

After the project setup is complete, navigate to:

Tools → Settings → IP → Repository

Following these configuration steps, your custom IP is fully prepared for integration into the Vivado ecosystem. The block is highly versatile and can be utilized seamlessly within both the IP Integrator and the Block Design environments for your FPGA development workflow.

To integrate the IP into your system layout, open your active Vivado Block Diagram and press CTRL + I to open the IP Search interface. Type the name of your custom IP, select it from the filtered list, and insert it into the workspace.

Current Results

Applications

Because the generator produces a continuous pseudo-random Gaussian sequence, it can be used as a building block in larger real-time test systems.

Telecommunications

In a communication test platform, Gaussian noise can be injected into a digital baseband signal to evaluate receiver performance.

A simplified test setup can be represented as:

Transmitter → Channel Model → Gaussian Noise Injection → Receiver → BER Analysis

This can be used for AWGN testing, receiver sensitivity measurements, and BER evaluation.

Gaussian random sources can also be used as building blocks for more advanced channel models such as Rayleigh and Rician fading.

Radar

A radar test system may require stochastic signal sources to reproduce fluctuating target or clutter conditions.

For example, Swerling I–IV models represent different statistical behaviors of fluctuating target radar cross sections.

The Gaussian generator does not itself implement a Swerling model. Instead, it provides a random source that can be used as a building block within a larger stochastic target, clutter, or channel model.

This distinction is important when moving from a mathematical model to a real-time FPGA test environment.

Hardware-in-the-Loop

The Gaussian generator can also be integrated into a hardware-in-the-loop test environment.

A typical setup can be:

FPGA Test Signal → Gaussian Noise Injection → Device Under Test → Measurement

This allows a real hardware implementation to be tested against controlled and repeatable stochastic signals.

Conclusion

Generating Gaussian random numbers in software is relatively simple.

Generating them continuously and efficiently using FPGA hardware requires a different approach.

In this project, I used twelve parallel 16-bit LFSRs with different feedback polynomials to generate uniform pseudo-random sequences. These sequences were then summed using the Central Limit Theorem to obtain an approximately Gaussian distribution.

The design was implemented and validated using AMD Vitis Model Composer, with MATLAB used for statistical analysis.

The measured results showed:

Mean = 0.000527

Variance = 1.015423

Standard deviation = 1.007682

with:

67.910% / 95.712% / 99.774%

of samples falling within ±1σ, ±2σ and ±3σ respectively.

The maximum measured absolute off-diagonal correlation between the twelve LFSR outputs was 0.013464.

These results demonstrate that a Gaussian-distributed random sequence can be constructed using relatively simple FPGA-friendly building blocks such as LFSRs and adders.