Peregrino: A Full-Hardware Accelerator for the Complete Falcon Post-Quantum Digital Signature Scheme on Resource-Constrained Edge Devices

I. INTRODUCTION

• Falcon’s recursive structure and floating-point arithmetic make it difficult to implement in hardware, where native FPUs are absent.These challenges help explain the limited number of FPGA implementations.Source: §I · p. 1, §II · p. 2
• Falcon’s compact signatures and keys make it worth researching despite Hawk’s faster key-pair and signature generation, which trades away compactness and verification performance.Falcon was selected by NIST, while Hawk avoids floating-point arithmetic.Source: §I · p. 1
• Peregrino is presented as the first from-scratch hardware accelerator for all three Falcon operations, designed for CPU-peripheral use in resource-constrained environments.The design uses HDL’s parallelism and modular organization to reduce resource utilization relative to the only other complete implementation, generated through HLS.Source: §I · pp. 1–2

II. RELATED WORK

• Prior Falcon hardware work spans individual operations and function-level accelerators, while the only complete implementation identified is HLS-generated FalconTakesOff.Examples cover signature generation and verification, sampling, NTRU solving, and FFT/NTT acceleration.Source: §II · pp. 2–3

III. FALCON PRELIMINARIES

• Falcon’s three foundations are the GPV framework, NTRU lattices, and an optimized sampler using the Fast Fourier Transform.NTRU lattices reduce public-key size in O(n), according to the cited passage.Source: §III · p. 3
• Key-pair generation solves the NTRU equations and builds a tree in FFT representation; the resulting key pair can be reused for many signatures.The passage describes key generation as the most computationally expensive operation.Source: §III · p. 3
• Signature generation hashes the message and uses the fast Fourier sampler to produce a signature satisfying the scheme’s equation.The process repeats sampling until the signature meets the norm bound and can be compressed.Source: §III · pp. 3–4
• Verification hashes the salt and message, recovers a signature component using the public key, and accepts only when the resulting vector’s norm is below the bound.The passage describes verification as faster and simpler than key and signature generation.Source: §III · pp. 3–4

IV. HARDWARE DESIGN

• Peregrino derives hardware modules from Falcon software, providing control to modify the design while preserving reference-code functionality.The stated aim is to use hardware parallelism to increase operations per clock cycle and reduce execution time.Source: §IV · p. 4
• Software-to-hardware adaptation must address pointer-based memory access, changing data types, floating-point operations, large multiplications, and recursion.Software functions can reuse state without generating additional resources, unlike direct hardware replication.Source: §IV · p. 4

A. Modular Design

• Each module corresponds to a reference-software function and can be replaced by an equivalent module selected by the developer.The paper presents this structure as supporting portability and flexibility.Source: A. Modular Design · pp. 4–5
• Multiplexers let multiple upper modules request operations from a shared lower module without duplicating hardware, provided the requests are not simultaneous.Modules communicate through requests rather than operating independently at all times.Source: A. Modular Design · p. 4
• The fpr sub-module example shows an interface for connections between modules and memories.The passage notes enable signals from upper modules and control and data-transmission signals.Source: A. Modular Design · pp. 4–5

B. Memory Centric Architecture

• The memory-centric architecture makes central memory accessible from any module through signals that emulate software pointers.This avoids relying on conventional memory and reduces the need for numerous data-transmission stages between modules.Source: B. Memory Centric Architecture · p. 5

C. Memory Management Unit

• The MMU handles 8-, 16-, 32-, and 64-bit data using central memory, two FSMs, segmentation, and concatenation modules.The central memory is sized for Falcon-1024 keys, tree computations, and temporary buffers; 8 bits is the base word length.Source: C. Memory Management Unit · p. 5
• The reading/writing FSM manages addresses for larger data sizes, while the movement FSM transfers byte-ranged memory zones between origin and destination addresses.Concatenation combines bytes from memory into properly sized data; segmentation divides 64-bit inputs into bytes for storage.Source: C. Memory Management Unit · p. 5

D. Floating Point Arithmetic

• Falcon’s emulated floating-point representation follows IEEE-754’s 64-bit format: one sign bit, 11 exponent bits, and 52 mantissa bits.The exponent stores the power of two applied to the mantissa, which stores magnitude.Source: D. Floating Point Arithmetic · p. 5
• The hardware modules use Falcon’s software functions for emulated floating-point operations as their design reference.The passage directs readers to the reference code for operation details and handling potentially conflicting values.Source: D. Floating Point Arithmetic · p. 5

E. Karatsuba Algorithm

• The FPGA’s 25x18 DSP multipliers can require up to four DSPs for a large-number multiplication, increasing logic delay and reducing clock frequency.The cited device’s DSPs have a 48-bit accumulator; the multiplication itself takes one clock cycle.Source: E. Karatsuba Algorithm · p. 5
• Karatsuba reduces large multiplications by splitting operands, multiplying smaller values, and combining intermediate results.The design applies it to 64-bit multiplications, and in one accelerator variant also to selected sensitive 32-bit multiplications.Source: E. Karatsuba Algorithm · pp. 5–6
• Two accelerator variants compare Karatsuba use in 64-bit multiplications alone versus 64-bit and selected sensitive 32-bit multiplications.One variant operates at greater frequency but uses more clock cycles, and the comparison evaluates which is more efficient.Source: E. Karatsuba Algorithm · p. 6

F. ffSampling Recursive Function

• Replicating recursive ffSampling modules for speed would consume FPGA resources beyond what is available.The proposed design instead separates algorithm operations and lower-module requests from intermediate-state storage and state-flow control.Source: F. ffSampling Recursive Function · p. 6
• The ffSampling actuation module follows reference-code behavior through three subroutines, with state control selecting the subroutine based on recursion position and stack values.The state-control module stores addresses, polynomial degree, and checkpoints in a custom stack to resume after child execution.Source: F. ffSampling Recursive Function · pp. 6–7

G. Accelerator IP Interface

• The interface includes writing a 48-character seed to RAM for pseudo-random context generation..Source: G. Accelerator IP Interface · p. 7
• The processor interface supports seed and message writes to RAM, pseudo-random-context reads, and public-key and signature transfers through the MMU.Transfers use read, write, and ready signals; ram select distinguishes seed storage from message storage.Source: G. Accelerator IP Interface · p. 7
• The processor can request key-pair generation, signature generation, or signature verification through the accelerator interface.IP start and IP ready control execution, while acc select chooses the operation.Source: G. Accelerator IP Interface · p. 7

V. IMPLEMENTATION RESULTS

• Evaluation used 1000 seed-message pairs on an Artix 7 XC7A200T FPGA with a MicroBlaze soft-core, and reported Falcon-1024 results.Tables I–III compare key-pair generation, signature generation, and verification; Fig. 6 reports mean cycles with 95% confidence intervals when available.Source: §V · p. 7, Table I · p. 8, Table II · p. 8
• Functional correctness was checked against reference-software module outputs, cross-verified signatures, and official NIST KAT vectors.Signatures generated by either implementation verified in the other, and the KAT vectors were reproduced exactly.Source: §V · p. 7
• 92%/96%/85% clock-cycle reductions for key-pair generation, signature generation, and verification remain when MicroBlaze register-interface transfers are included.For the accelerator alone, the respective reductions are 92%/97%/91%; data transfers can account for up to 39% of total cycles in the worst case, signature verification.Source: §V · p. 7
• 1,9× fewer LUTs, 3,4× fewer FFs, 2,7× fewer BRAMs, and 9,9× fewer DSPs are used by Peregrino than by the HLS-based design for the entire scheme.The comparison sums resource use across key-pair generation, signature generation, and verification.Source: Table IV · p. 9, §V · p. 9
• 60% fewer signature-generation cycles, 10% fewer verification cycles, and 1,5% more key-pair-generation cycles were measured on the Cortex-A9 with emulated floating point.With a native FPU, verification cycles were reduced by 10%.Source: §V · p. 9
• Peregrino’s comparisons report a 21% signature-generation cycle reduction against an emulated-floating-point Intel implementation and 25%/66%/44% performance improvements over the ARM Cortex-M4 implementation in.The Cortex-M4 software was optimized at assembler level; the reported comparison retains that baseline.Source: §V · p. 9

• 75 MHz to 80 MHz raises maximum frequency with Karatsuba, but the added cycles leave the 64-bit version at 75 MHz faster end to end.The higher frequency comes from shortening the critical path of the large-number multipliers; its cycle penalty exceeds the frequency gain.Source: §VI · pp. 9–10
• Peregrino leads the ARM Cortex-M4 and MicroBlaze in key-pair generation and verification, but not the emulated Intel run or updated ARM Cortex-M4.Source: §VI · p. 10
• The accelerator is most valuable on edge nodes without a native FPU; on more capable platforms, selective use is appropriate for operations such as verification.Processors with native FPUs outperform it in key-pair and signature generation, and GHz-class CPUs finish faster in absolute time.Source: §VI · p. 10
• 1.9× fewer LUTs, 3.4× fewer FFs, 2.7× fewer BRAMs, and 9.9× fewer DSPs let Peregrino fit on one FPGA, while FalconTakesOff requires at least two.Peregrino does not improve area-time product over the HLS design; its distinction is feasibility within one mid-range FPGA’s resource budget.Source: §VI · p. 10
• At 75–80 MHz, Peregrino’s latency remains above GHz-class CPUs; native-FPU platforms outperform it in key-pair and signature generation.A dedicated DMA path could recover most data-transfer overhead bound to the MicroBlaze register interface.Source: §VI · p. 10
• The design does not evaluate side-channel resistance, and ffSampling’s variable latency depends on secret Gaussian samples drawn for every signature.A masked multiplier and full side-channel evaluation are future work for deployment in untrusted settings.Source: §VI · p. 10

• Peregrino implements key-pair generation, signature generation, and verification in hand-written RTL, with each module functionally equivalent to the reference software and validated against NIST KAT vectors.The accelerator is exposed to a MicroBlaze soft-core through an AXI Lite wrapper.Source: §VII · p. 10
• 1.9× fewer LUTs, 3.4× fewer FFs, 2.7× fewer BRAMs, and 9.9× fewer DSPs let Peregrino fit on one FPGA, unlike the prior full HLS implementation.As a MicroBlaze peripheral, it reduces key-pair generation, signature generation, and verification cycles by 92%, 96%, and 85% over emulated floating-point reference software.Source: §VII · p. 10
• Raising the 75–80 MHz operating frequency and replacing the register-based host interface with dedicated DMA are proposed to close most of the latency gap to high-performance processors.A masked sampler multiplier and full side-channel evaluation remain future work toward deployment in untrusted settings.Source: §VII · p. 10