Optical NTT Engines: Precision, Conversion and Power

Topics We'll Cover

• Fourier Transforms in Optics
• The Mismatch: Exact Modular Arithmetic
• Route 1: Digit Decomposition
• Route 2: A Hybrid NTT via Bluestein
• Route 3: Small Primes and Error Correction
• The Precision Rule, Checked Functionally
• The Precision Tax
• Conversion Energy and Static Power
• Interactive: Optical Engine Explorer
• When It Wins and When It Loses
• What Would Change the Verdict
• What to Take Away

Fourier Transforms in Optics

A lens computes a two-dimensional Fourier transform physically: the optical field in its front focal plane appears, Fourier-transformed, in its back focal plane. Two lenses with a mask between them (a 4f system) multiply in the frequency domain, which is a convolution in space. The transform itself costs time-of-flight and no switching energy.

• Everything around the optics costs energy: DACs and modulators in, detectors and ADCs out, lasers, and thermal tuning. The sister series covers this power accounting in general (LLM Inference Simulators deck 07, "Power in Photonic and Novel Compute").
• Published photonic FHE work includes PHAT (Yang et al., arXiv:2609.11613), a photonic accelerator for TFHE whose FFTs run on optically addressed phase-change memory, and OptoLink (Saiham et al., arXiv:2506.12962), which uses photonics for the memory bandwidth side.

The Mismatch: Exact Modular Arithmetic

The NTT of a limb is not a complex DFT, so the optics cannot run it directly. What it can compute exactly, given enough precision, is an integer convolution: convolve small non-negative integers with a complex FFT and round. Every route below turns modular NTT work into integer convolutions small enough that rounding is exact. The same trick lets TFHE libraries multiply polynomials with 64-bit floating-point FFTs.

Route 1: Digit Decomposition

Split each operand into d digits of b bits, x = Σ_i x_i·2^bi. A convolution of the full operands becomes d² convolutions of digit planes, recombined digitally with shifts and adds.

• Output size of one plane-pair convolution of length n: at most n·(2^b−1)². Summing the d products of equal weight i+i' in the analogue domain before the ADC ("grouped") multiplies that by d, and needs 2d−1 output planes instead of d².
• Exactness: a signed ADC with 2^ENOB codes over ±FS errs by at most FS/2^ENOB; rounding is exact if that is below ½: 2^ENOB−1 > d·n·(2^b−1)².
• The trade: narrower digits need fewer bits of analogue precision but more planes, and every plane is another pass through the converters.

Route 2: A Hybrid NTT via Bluestein

The mapping the companion simulator models, one illustrative route among several:

• Bluestein's identity jk = (j² + k² − (k−j)²)/2 turns Σ_j x_jω^jk into a chirp multiply, a convolution with ψ^−m2 (where ψ² = ω, so q ≡ 1 mod 2n), and another chirp multiply. Both chirps and the convolution kernel are integers mod q, so the convolution is an integer convolution.
• What is offloaded: only the last log₂n of the log₂N butterfly stages, which is (log₂n)/2 butterflies per point. A 16-point block offloads 2 butterflies per point; a 4,096-point block, 6.
• What it costs per point: (d + 2d−1) planes × 2n samples per n points, through a DAC or an ADC: 2(3d−1) conversions per point.

Route 3: Small Primes and Error Correction

CraterLake's 28-bit words come from ARK's comparison table (arXiv:2205.00922, Table VII); SHARP's 36-bit words and 180 MB of on-chip memory are as reported in FHEmem (arXiv:2311.16293) and Osiris (arXiv:2408.09593).

The Precision Rule, Checked Functionally

precision.py implements route 2 end to end in pure Python: Bluestein chirps, digit planes, complex FFT convolutions, a signed ADC with 2^ENOB codes, rounding and recombination. It is checked against a direct modular DFT. Here q = 12,289 (14-bit limbs) and the block is 16 points:

The rule is tight: exact at the predicted ENOB, wrong one bit below, for every digit width. The hardware model's choice of b is tested against this functional model, the analogue counterpart of checking a cycle model against RTL.

The Precision Tax

What the rule implies for real limb widths (grouped planes; 2(3d−1) conversions per point; from examples/results.py):

• Each cell shows digit width b, digit count d and conversions per transform point.
• Tens to hundreds of conversions buy two to six butterflies. Bigger blocks offload more stages but need more ENOB; at 8 ENOB nothing is feasible for these limb widths.
• This is the general lesson of deck 07 of the sister series made specific: the optical win must be amortised over many operations per conversion, and exact FHE arithmetic makes conversions per point grow with limb width.

Conversion Energy and Static Power

A simple comparison: a digital butterfly costs 10 pJ in the illustrative model, so one ENOB-8 conversion pair (7.7 pJ) is already comparable to the work it replaces, before precision multiplies the conversion count.

Interactive: Optical Engine Explorer

Set the engine and run a full ark-set bootstrap on the chosen digital design, with and without it. "Ideal" is a hypothetical engine that is exact at any precision (one plane in, one out), an upper bound on what optics could do here.

When It Wins and When It Loses

Full ark-set bootstraps (baseline algorithm), from examples/results.py:

• Loses, with exact rounding at realistic ENOB: 23× slower and 37× more energy, because conversions per point dwarf the butterflies saved.
• Wins on speed only in the ideal case, and only for an NTT-bound design (17.46 → 12.59 ms, 1.39×), where it moves the bound to the MAC lanes. Energy still rises, because lasers and tuning add static power.
• Does nothing for a memory-bound design. On the ARK-class design it is worse, because at this converter rate it is slower than ARK-class digital NTT units and the design is waiting on keys anyway.
• Energy break-even for the ideal engine (ENOB 8, energy question only): a conversion must cost under 30 pJ with 5 W of laser and tuning power, or 47 pJ with none; with 20 W it never breaks even.

What Would Change the Verdict

• Precision per conversion. Only exactness forces digit planes. Workloads that tolerate approximation (CKKS encoding and decoding use complex FFTs; ML layers outside the encrypted domain) avoid the tax entirely. The sister series Fourier Optics for Inference works through that float case for LLM inference: a noise rule instead of exactness, averaging passes instead of digit planes, and a simulated optical prefill pool.
• More work per conversion. Chaining optical stages, or doing a whole length-N transform per pass, raises butterflies offloaded per point, but needs more ENOB at the output.
• Different mappings. Optical matrix-vector engines could take on base conversion, which is a matrix product, or polynomial products as convolutions; PHAT's TFHE design maps FFT-based polynomial multiplication. Each needs its own precision analysis.
• Converter technology. The break-even energy above is a target: about 30 pJ per conversion pair at 8 ENOB, together with low static power.
• The memory system first. As decks 03 and 05 show, a balanced FHE accelerator is limited by keys and plaintexts before NTTs; photonic interconnect (OptoLink's direction) addresses that bottleneck directly.

What to Take Away

• Optics computes complex FFTs and convolutions; FHE needs exact modular NTTs. The bridge is integer convolution on digit planes, here via Bluestein.
• The exact-rounding rule 2^ENOB−1 > d·n·(2^b−1)² is tight, as the functional model shows.
• The precision tax: at 50-bit limbs and 12 ENOB, 298 conversions per point to offload 2 butterflies.
• Converter energy grows as 2^ENOB, and laser and tuning power is paid all the time.
• Simulated: a realistic engine loses badly; an ideal one helps only NTT-bound designs and costs energy; neither helps a memory-bound design.