FHE Hub — FHE Accelerator Simulators

FHE Accelerator Simulators

How long does a CKKS bootstrap take on a given accelerator, is the design bound by NTT throughput or by evaluation-key traffic, how much on-chip SRAM is enough, and does an optical NTT engine win once conversion energy and precision are counted? Five decks and a tested SimPy simulator answer these questions, from CKKS as a hardware workload through the anatomy of bootstrapping, the simulator itself (live in the browser) and optical transform engines, to design-space results.

CKKS bootstrappingNTTKey switchingSimPyMemory-bound vs NTT-boundOptical NTTPower & energy5 decks + code

Presentations in This Series

  1. FHE for Hardware Engineers: CKKS as a Workload →
    CKKS seen from the datapath, not the proof: RNS polynomials in Zq[X]/(XN+1), how big ciphertexts and evaluation keys really are, the five primitive kernels (NTT, modular multiply-add, automorphism, base conversion, rescale), noise and levels, and why key switching dominates. Includes a live parameter calculator.
    liveCKKS · RNS · NTT · Key switching
  2. Anatomy of CKKS Bootstrapping →
    ModRaise, CoeffToSlot (a homomorphic DFT evaluated with baby-step giant-step rotations), EvalMod (a polynomial approximation of modular reduction) and SlotToCoeff, with exact operation counts per stage, where the levels go, and the data-movement profile that makes bootstrapping a memory problem.
    liveModRaise · CoeffToSlot · EvalMod · SlotToCoeff
  3. Simulating an FHE Accelerator →
    The modelled machine (NTT units, modular multiply-add lanes, an automorphism network, a scratchpad, HBM and key streaming), the operation-trace format and where traces come from (a scheme model, HEIR, OpenFHE), the SimPy engine, its metrics and its validation ladder, and the whole simulator running live in the browser.
    liveSimPy · Trace format · Scratchpad · HBM
  4. Optical NTT Engines: Precision, Conversion and Power →
    Fourier transforms in optics, and what it takes to map an exact modular NTT onto an analogue complex FFT: digit decomposition, small-prime RNS, rounding and error correction, ENOB, DAC/ADC energy from a Walden figure of merit, and laser and thermal-tuning power. The simulator then shows when an optical engine wins and when it loses.
    liveFourier optics · Digit planes · Bluestein · ENOB
  5. Results and the Design Space →
    What the simulator says: SRAM size against key traffic, the NTT-bound and memory-bound regimes, power and energy per bootstrap under a TDP, the algorithmic acceleration techniques, a design-space sweep, silicon area as a third axis (a three-way power, performance and area front), the model's limitations, a reading list (F1, CraterLake, BTS, ARK, SHARP, GPU work, HEIR, OpenFHE, Lattigo) and practice questions.
    liveSRAM sizing · Regimes · Energy / bootstrap · Min-KS

Companion Code

  1. </>
    FHE_Accelerator_Sim →
    A SimPy discrete-event simulator of an FHE accelerator running CKKS bootstrapping: a scheme model that turns bootstrapping into NTT, base-conversion, multiply-add and automorphism kernels; NTT, MAC, automorphism and optional optical units; a scratchpad whose misses become evaluation-key, plaintext and ciphertext traffic over shared HBM; bound attribution, hot-spots, Perfetto traces; a power model with a dynamic power manager under a TDP, and DVFS; an optical precision model with a functional check; OpenFHE calibration and two recorded OpenFHE bootstrap traces it replays; a front end for the HEIR compiler with three HEIR-compiled programs; algorithm options (hoisting, Min-KS, seeded keys, on-the-fly plaintexts, OpenFHE's lazy ModDown, SlotToCoeff-first ordering); an area, yield and silicon-cost model (7 nm, calibrated from ARK's published breakdown and a CACTI sweep, illustrative); 126 tests; and the JavaScript port used live in decks 03 and SimEng 13.
    codePython · SimPy · pytest · Hypothesis · JavaScript

Headline Results

Every number is read from examples/results.md when this page is built. Hardware coefficients are illustrative.

How to read this series. Deck 01 treats CKKS as a workload and deck 02 takes bootstrapping apart; together they are the "what you are simulating". Deck 03 is the simulator and its validation, with the live JavaScript port. Deck 04 asks whether an optical transform engine helps. Deck 05 collects the results, the reading list and practice questions. For the mathematics of FHE, start with the Cryptography FHE deck in the Cryptography section of the Mathematics hub. For simulator methodology in general (discrete-event simulation, metrics, power, acceleration, framework integration), see the sister series LLM Inference Simulators. New to simulation altogether? Start with Introduction to Simulation, an engineering-wide on-ramp from field solvers to system models.

Glossary: Concepts and Where They Are Explained

Every concept the decks rely on, with a short explanation and links to where it is explained in depth: in this series, in the Cryptography decks (the mathematics) or in the sister series LLM Inference Simulators (simulator methodology). Each deck's contents slide links to the entries it uses.

FHE and CKKS

LWE and Ring-LWE
The hard problems FHE rests on: given noisy linear equations b = a·s + e (mod q), recovering s is hard. Ring-LWE works with polynomials instead of vectors, so one sample carries N coefficients, which is what makes NTTs the core kernel.Explained in: Cryptography 08 · LWE · Cryptography 08 · Ring-LWE
CKKS
The FHE scheme for approximate arithmetic on real or complex vectors. Values are encoded with a scale Δ; noise is treated as rounding error; each multiplication is followed by a rescale that consumes one level.Explained in: Cryptography 08 · CKKS · FHESim 01 · noise, scale and levels
RNS polynomials and limbs
The ciphertext modulus Q is a product of word-sized primes, so each polynomial is stored as one row ('limb') of N residues per prime. A ciphertext at level ℓ has ℓ+1 limbs; all arithmetic stays in 64-bit words.Explained in: FHESim 01 · the data: RNS polynomials · Cryptography 08 · RNS and NTT
Number-theoretic transform (NTT)
The FFT over a finite field Zq. It moves a limb between coefficient and evaluation form in (N/2) log N butterflies, so polynomial multiplication becomes element-wise. Every key switch and rescale runs NTTs.Explained in: Cryptography 08 · RNS and NTT · Cryptography 10 · the NTT · Cryptography 10 · NTT hardware architectures · FHESim 01 · primitive kernels
Modular reduction (Barrett, Montgomery)
Ways to compute a·b mod q without division, using precomputed constants. Every butterfly and multiply-add lane in an FHE accelerator contains one.Explained in: Cryptography 10 · Montgomery reduction in SystemVerilog · Cryptography 10 · the NTT
Levels, scale and rescale
A multiplication squares the scale; rescale divides by a prime and drops a limb. So each multiplicative level costs one prime, the level of a ciphertext sets how much work every operation on it does, and level 0 cannot be multiplied.Explained in: FHESim 01 · noise, scale and levels · Cryptography 08 · noise growth
Automorphism and slot rotation
Substituting X → X5r permutes a polynomial's coefficients so that the packed slots rotate by r. The permutation is free of arithmetic, but the result needs a key switch with a rotation key specific to r.Explained in: FHESim 01 · primitive kernels · FHESim 02 · BSGS rotations
Key switching and evaluation keys
After a multiplication (relinearisation) or a rotation, part of the ciphertext is under the wrong key; key switching fixes it using an evaluation key (78–210 MiB for the N = 216 sets used here). It dominates the cost of FHE.Explained in: FHESim 01 · key switching, step by step · FHESim 01 · why key switching dominates · Cryptography 08 · relinearisation and key switching
Hybrid key switching: dnum, special primes, ModUp and ModDown
The limbs are split into dnum digits of α limbs. Each digit is base-converted up to Q·P (ModUp, with α special primes P), multiplied by the key, and converted back (ModDown). dnum trades key size against work and security.Explained in: FHESim 01 · key switching · FHESim 01 · the dnum trade-off
Base conversion
Re-expresses an RNS polynomial in a different set of primes, as a matrix product over limbs. It is the heart of ModUp and ModDown and often the second-largest cost after NTTs.Explained in: FHESim 01 · primitive kernels
HMult, HRot, PMult, CMult
The homomorphic operations: ciphertext×ciphertext multiply (with relinearisation), rotation, ciphertext×plaintext multiply and ciphertext×constant multiply. Only HMult and HRot need a key switch.Explained in: FHESim 01 · why key switching dominates · FHESim 02 · operation counts per stage
Slots, packing and sparse packing
A CKKS ciphertext holds N/2 complex numbers in parallel 'slots' (SIMD). Using fewer slots (sparse packing) shrinks the bootstrap's DFTs but adds a SubSum of rotations.Explained in: FHESim 01 · RNS polynomials · FHESim 02 · ModRaise and SubSum

Bootstrapping

Bootstrapping
Evaluating decryption homomorphically to turn a level-0 ciphertext into one at a high level: ModRaise, CoeffToSlot, EvalMod, SlotToCoeff. It costs hundreds of key switches and gigabytes of keys.Explained in: FHESim 02 · why bootstrap · Cryptography 08 · bootstrapping
ModRaise
Reinterprets a level-0 ciphertext modulo the full Q, which adds a multiple of q0 the rest of bootstrapping must remove. Cheap: transforms only.Explained in: FHESim 02 · ModRaise
CoeffToSlot and SlotToCoeff (homomorphic DFT)
The encoding transform and its inverse, evaluated homomorphically as a few sparse matrix-vector products (an FFT factorised into levels). Rotation- and key-heavy: the memory-bound part of bootstrapping.Explained in: FHESim 02 · CoeffToSlot · FHESim 02 · SlotToCoeff
Baby-step giant-step (BSGS)
Evaluates a d-diagonal matrix with about 2√d rotations instead of d: n1 baby-step rotations of the input, n2 inner sums, and one giant-step rotation per sum.Explained in: FHESim 02 · BSGS rotations
Hoisting
Several rotations of the same ciphertext share one decomposition and ModUp (Halevi and Shoup), saving NTTs; the rotation keys stay distinct.Explained in: FHESim 02 · BSGS rotations
EvalMod: Chebyshev series and double angle
Approximates the modular reduction with a scaled cosine evaluated as a Chebyshev series (baby-step giant-step polynomial evaluation) followed by double-angle steps cos 2x = 2cos²x − 1. Multiplication-heavy, one key.Explained in: FHESim 02 · EvalMod
SlotToCoeff first
Running SlotToCoeff before ModRaise, on the nearly exhausted input: cheap keys, one EvalMod for real data, and its levels are not taken from the top. OpenFHE's BTSlotsEncoding.Explained in: FHESim 02 · ordering variants · FHESim 05 · acceleration techniques
Min-KS, seeded keys and on-the-fly plaintexts
Algorithmic ways to cut key and plaintext traffic: rotate iteratively by one step so a BSGS loop reuses one key (Min-KS, from ARK), regenerate half of each key from a seed, and generate DFT plaintexts on chip.Explained in: FHESim 02 · algorithmic levers · FHESim 05 · acceleration techniques · ARK (arXiv:2205.00922)
Lazy ModDown (OpenFHE's BSGS)
Keeping rotated ciphertexts in the extended Q·P basis and doing one ModDown per DFT level, so baby steps cost no NTTs and many more of them are used. Fewer NTTs, more keys.Explained in: FHESim 02 · checked against OpenFHE · FHESim 02 · algorithmic levers
Amortised time per slot (TA.S.)
Bootstrap time plus the multiplications it enables, divided by the levels left and the slots: the cost per useful operation. Used by ARK and the 100x GPU paper to compare different parameters.Explained in: FHESim 02 · where the levels go · ARK (arXiv:2205.00922)
FLEXIBLEAUTO rescaling (OpenFHE)
An OpenFHE mode that rescales automatically and lazily, before each multiplication, on copies of its inputs. Convenient for users; in a kernel trace it shows up as many extra rescales.Explained in: FHESim 02 · checked against OpenFHE

Hardware, memory and bounds

Scratchpad, LRU and spills
The accelerator's on-chip SRAM, modelled as a least-recently-used store of ciphertexts, keys and plaintexts. A miss loads from HBM; evicting a live ciphertext writes it back (a spill).Explained in: FHESim 03 · scratchpad and traffic · FHESim 05 · SRAM against key traffic
Silicon area and the area model
Die area in mm² per component (NTT, MAC and permutation units, scratchpad, uncore, HBM PHYs). The simulator's model is at 7 nm, calibrated from ARK's published breakdown and a CACTI sweep, and illustrative; area never changes a simulated time or energy.Explained in: FHESim 05 · SRAM against key traffic and area · SimEng 13 · what sets area · SimEng 13 · estimating area before layout
Die yield and silicon cost
The fraction of dies with no fatal defect: Poisson e−A·D0 or Murphy's model, which is kinder to large dies. With dies per wafer it turns area into cost per good die, which grows faster than area.Explained in: SimEng 13 · why area is cost · SimEng 13 · when to split the die
HBM and key streaming
Off-chip high-bandwidth memory. Evaluation keys and DFT plaintexts are too big to keep on chip, so they stream from HBM, which is why bootstrapping is often memory-bound.Explained in: FHESim 03 · the modelled architecture · FHESim 01 · why key switching dominates
Roofline and ridge point
Performance is capped by compute or by memory bandwidth; the ridge point is the arithmetic intensity where the two meet. Work below it is memory-bound.Explained in: LLM Inference Simulators 03 · the roofline · FHESim 05 · NTT-bound against memory-bound
NTT-, MAC-, memory- and power-bound
The simulator's verdict: the most-utilised resource sets the bound (HBM, NTT units, multiply-add lanes), or power when the power limit throttles a compute-bound design.Explained in: FHESim 03 · metrics and hot-spots · FHESim 05 · regimes
Hot-spot attribution
For each stage of the workload, the resource that was busiest: where an upgrade would help.Explained in: LLM Inference Simulators 06 · hot-spot attribution · FHESim 03 · metrics and hot-spots

Power

Static and dynamic power
Static power is drawn all the time (leakage, lasers, tuning); dynamic energy is paid per operation and per byte moved. Energy = static × time + Σ operations × energy each.Explained in: LLM Inference Simulators 07 · where the joules go · LLM Inference Simulators 07 · the simulator's power model · FHESim 03 · cost and power model
TDP, DVFS and power caps
The thermal design power is the limit the chip must not exceed. DVFS lowers clock and voltage together (energy per operation ~ clock²); a power cap throttles to stay under a limit.Explained in: LLM Inference Simulators 07 · DVFS and power caps · FHESim 03 · cost and power model
Dynamic power manager against worst-case clocking
Worst-case clocking picks one clock at which everything at full rate fits the TDP; a dynamic manager gives each kernel the highest clock that fits the power actually free at that moment.Explained in: FHESim 05 · power and energy per bootstrap · FHESim 03 · cost and power model

Optical transforms

Fourier optics and the 4f system
A lens Fourier-transforms the light field; two lenses with a mask between them multiply in the frequency domain, which is a convolution. The transform is free; the converters and lasers around it are not.Explained in: FHESim 04 · Fourier transforms in optics · LLM Inference Simulators 07 · power in photonic compute
Digit decomposition (bit slicing)
Splitting each operand into d digits of b bits so that low-precision analogue products can be recombined exactly in digital logic. Narrower digits need less precision but more passes.Explained in: FHESim 04 · route 1: digit decomposition
Bluestein's algorithm
Rewrites a DFT as chirp multiplies around a convolution (using jk = (j² + k² − (k−j)²)/2), which lets a convolution engine compute an exact modular DFT.Explained in: FHESim 04 · route 2: a hybrid NTT
ENOB and exact rounding
Effective number of bits: the real precision of an analogue chain. Rounding to the exact integer needs the error below one half, which sets a minimum ENOB for each block size and digit width.Explained in: FHESim 04 · the rounding rule · FHESim 04 · checked functionally
Walden figure of merit
Converter energy per sample ≈ FoM × 2ENOB, so every extra bit of precision doubles the energy of each DAC or ADC conversion.Explained in: FHESim 04 · conversion energy · LLM Inference Simulators 07 · power in photonic compute

Simulation and validation

Discrete-event simulation
Simulated time jumps from event to event (a kernel finishing, a transfer completing) instead of ticking every cycle, which is why a whole bootstrap simulates in tens of milliseconds.Explained in: LLM Inference Simulators 02 · anatomy of a discrete-event simulator · LLM Inference Simulators 02 · processes as coroutines
SimPy processes and resources
SimPy's vocabulary: processes are Python generators that yield events (timeouts, requests); a Resource is a server with a FIFO queue. Units and HBM are Resources here.Explained in: LLM Inference Simulators 02 · SimPy vocabulary · LLM Inference Simulators 02 · modelling hardware in SimPy · FHESim 03 · the SimPy engine
The fidelity ladder
Models from spreadsheet to RTL, each slower and more exact. This simulator sits at the transaction/discrete-event rung: one event per kernel, not per cycle.Explained in: LLM Inference Simulators 01 · the fidelity ladder · FHESim 03 · what the simulator must answer
Kernel-level trace
The contract between a scheme model or compiler and the hardware model: HE operations with their inputs, outputs, keys, plaintexts, levels and primitive kernels.Explained in: FHESim 03 · the trace · FHESim 03 · where traces come from
Perfetto and Chrome traces
A timeline format and viewer: one row per resource, one slice per kernel or transfer, for seeing overlap and idle time.Explained in: LLM Inference Simulators 06 · traces in Perfetto
The verification ladder
Layers of evidence: unit tests against hand formulas, invariants, analytic checks, behaviour, property-based tests, calibration and differential tests.Explained in: LLM Inference Simulators 06 · the verification ladder · FHESim 03 · validation
Property-based testing (Hypothesis)
Instead of fixed examples, generate many random configurations and check that invariants hold for all of them; Hypothesis shrinks any failure to a minimal case.Explained in: LLM Inference Simulators 06 · testing frameworks · FHESim 03 · validation
Flow-shop makespan
An analytic check: n identical jobs, each a load of time a then a compute of time b on two machines, finish at a + b + (n−1)·max(a, b). The engine must reproduce it exactly.Explained in: FHESim 03 · validation
Differential testing and a bit-exact twin
Running two independent implementations on the same input and requiring identical output, here the Python simulator and its JavaScript port.Explained in: LLM Inference Simulators 06 · the verification ladder · FHESim 03 · validation
Calibration and out-of-sample prediction
Fit as few model coefficients as possible to measurements (here, one rate to an OpenFHE multiplication), then judge the model on quantities it was not fitted to.Explained in: FHESim 03 · validation · FHESim 05 · against published numbers
Design sweeps and Pareto fronts
Simulate a grid of designs; a design is Pareto-optimal if no other is at least as good on every metric (latency, energy, and now area) and better on one. The front is the set of sensible choices; everything else is dominated.Explained in: FHESim 05 · sweeps and Pareto fronts · FHESim 05 · the three-way SRAM front · SimEng 13 · Pareto fronts · LLM Inference Simulators 08 · smarter experiments

Compilers and libraries

MLIR, dialects and SSA
MLIR is a compiler framework of 'dialects' (sets of operations) lowered step by step. Its IR is in static single assignment (SSA) form: every value is defined once, so def-use chains give the dependencies directly.Explained in: LLM Inference Simulators 09 · MLIR in one slide
HEIR
Google's MLIR-based FHE compiler: it chooses parameters, packing, rotations, levels and bootstrap placement, and emits code for libraries or hardware. Its ckks-dialect output drives this simulator.Explained in: LLM Inference Simulators 09 · HEIR · FHESim 03 · where traces come from · FHESim 03 · a HEIR front end
OpenFHE
An open-source FHE library (C++). Here it is used to calibrate timing, and an instrumented build records the kernel stream of real bootstraps.Explained in: Cryptography 08 · FHE libraries · FHESim 02 · checked against OpenFHE · FHESim 03 · where traces come from