FPGA-Based Feedback Control for Optical Frequency Combs

The Control Problem

Optical frequency combs — whether generated through Kerr nonlinearity in microresonators or electro-optic modulation — are among the most precisely engineered light sources available to researchers today. But generating a comb is only half the battle. Keeping it stable is the other half, and it is a hard control problem.

A typical Kerr-comb stabilization loop must simultaneously regulate:

• •Pump laser frequency — locked to the resonator mode via PDH or transmission locking
• •Pump power — to maintain the parametric gain threshold without mode-hopping
• •Resonator temperature — slow thermal drift handled by a secondary loop
• •Carrier-envelope offset (CEO) and repetition rate — for fully stabilized combs referenced to an optical clock

Each of these loops has a different bandwidth requirement. Thermal loops may be satisfied at a few kHz; pump frequency locking against cavity acoustic noise demands bandwidths in the hundreds of kHz range. Crucially, any shared-resource bottleneck — a CPU scheduler, an OS interrupt, a USB transaction — can introduce latency that reduces achievable loop bandwidth or, worse, causes intermittent glitches that unlock the comb.

EO-combs present a related but distinct challenge. Because the comb lines are deterministically generated by RF modulation, the control problem shifts toward stabilizing the pump laser and the RF drive simultaneously. The latency requirements are similar; the signal processing topology differs.

Why FPGA?

An FPGA solves the latency problem at the architectural level. The signal path is implemented directly in reconfigurable logic: ADC samples clock in on every cycle, the filter and controller pipeline executes in a fixed, deterministic number of cycles, and the corrected output reaches the DAC with no OS jitter, no interrupt latency, no shared bus arbitration.

The loop runs at the ADC sample rate — typically 125 MHz to 6.4 GHz depending on platform. There is no scheduler. There is no operating system in the datapath.

Hardware Platform: From Prototype to Production

Our reference implementation runs on the Red Pitaya STEMlab (Xilinx Zynq-7000), which provides a convenient starting point: 14-bit ADC/DAC at 125 MSPS, integrated ARM processor, and Ethernet — all on a €300 board. It is an excellent platform for developing and validating control algorithms, and for early-stage experiments where the analog front-end noise floor is not the limiting factor.

However, Red Pitaya is explicitly a prototyping and demonstration platform. For production deployments in precision optical systems, its analog specifications are a meaningful constraint:

• •ADC noise floor — the 14-bit front end has limited SFDR and SNR for high-dynamic-range applications such as PDH error signal readout near the shot-noise limit
• •Clock quality — the onboard oscillator is adequate for many applications but insufficient for sub-Hz linewidth locking or optical clock work
• •Output drive — DAC output impedance and slew characteristics limit what actuators can be driven directly

For applications that push these limits, the right answer is a custom analog front-end paired with a higher-performance FPGA platform. In practice this means:

• •Xilinx Zynq UltraScale+ RFSoC — integrated RF-class ADC/DAC at up to 6.554 GSPS (12-bit) or 2 GSPS (14-bit), with dramatically improved noise and spurious performance; directly suitable for microwave-rate signal processing in EO-comb or millimeter-wave locking applications
• •Custom PCB — tailored analog front-end (differential input, anti-alias filter, low-noise LDO references), purpose-built clock distribution (ultra-low phase noise OCXO or disciplined to a reference), and matched DAC output stages for your specific actuator

The RTL signal processing core — DDS, CIC filter, PID, lock-in demodulator — is largely platform-agnostic. Moving from Red Pitaya to RFSoC does not require rewriting the control logic; it requires adapting the ADC/DAC interface wrappers, retuning filter coefficients for the new sample rate, and carefully characterizing the new analog chain. That tuning work is non-trivial and application-specific, but the architecture carries over directly.

We use Red Pitaya throughout our documentation because it is accessible, reproducible, and sufficient to demonstrate every concept covered here. Where a production system would deviate, we will say so explicitly.

System Architecture

Our feedback control system is organized into three layers:

1. FPGA Signal Processing Core (RTL, 125 MHz)

The FPGA fabric implements the real-time signal processing pipeline in SystemVerilog:

• •Multi-tone DDS — generates reference signals for lock-in demodulation or system identification
• •CIC decimation filter — reduces the 125 MSPS ADC rate to 1 MSPS for the controller stage, with 6 stages and a decimation factor of 125 (see CIC filter specs)
• •PI/PID controller — fixed-point Q16.16 arithmetic with configurable gains and anti-windup clamping (see PID implementation)
• •Lock-in demodulator — quadrature demodulation for phase-sensitive detection, useful for PDH locking and modulation transfer spectroscopy
• •Output MUX — routes any internal signal node to the monitoring outputs for real-time inspection (see output MUX selection)

All parameters (gains, setpoints, filter coefficients, DDS frequencies) are memory-mapped over an AXI4-Lite register interface (full register map).

2. Embedded Software Layer (ARM Cortex-A9, Linux)

The dual-core ARM processor running Linux handles everything that does not require cycle-accurate timing:

• •A Rust/Axum HTTP server exposes a REST API over the AXI register map
• •Handles parameter read/write, status polling, and data streaming
• •Manages the scope capture buffer and streams waveform data to the web client

Because all real-time work lives in the FPGA fabric, Linux scheduling jitter is irrelevant to control performance.

3. Web Interface (Vue 3, TypeScript)

A single-page application running in the browser provides:

• •Real-time oscilloscope — live ADC/DAC waveform display via WebSocket streaming
• •Parameter panels — gain sliders, setpoint entry, output enable toggles
• •Allan deviation display — computed from streamed data to assess frequency stability in real time
• •Transfer function viewer — for open-loop characterization during initial setup

No proprietary software installation required. Any device with a modern browser can access the full instrument interface.

Open and Auditable by Design

Every layer of the stack is open and inspectable:

• •The RTL source (SystemVerilog) describes exactly what signal processing is happening
• •The register map is documented and directly accessible via the REST API
• •The web application is standard TypeScript/Vue — no binary blobs

For research groups that need to publish, audit, or modify their control system, this matters. A black-box PID box with a serial interface cannot be verified or extended. Our system can.

What Comes Next

This architecture forms the foundation for the specific topics we will cover in upcoming posts:

• •A detailed walkthrough of the Red Pitaya hardware and Zynq SoC platform
• •Fixed-point PID implementation on FPGA: bit widths, gain range, anti-windup
• •Lock-in amplification in RTL: DDS, multiplier, CIC low-pass, phase recovery
• •Using Allan deviation to characterize lock performance and identify noise floors

If you have a comb stabilization, cavity locking, or precision measurement problem you are working on, get in touch. You can also explore the full signal chain architecture and register map on our technology page.