A study by Haridhayal Maheswaran, Samuel Kennedy and Basel Halak reports a corrected RISC-V instruction-set extension running Classic McEliece encapsulation and decapsulation on a DE1-SoC board with an Intel Cyclone V FPGA. The researchers’ 87.4% and 86.1% cycle reductions, however, came from matched asynchronous-memory simulations, not the FPGA runs. The paper was published in Discover Computing on October 26, 2026; the full study describes results from reduced parameters.
Classic McEliece is a code-based post-quantum key-encapsulation mechanism, or KEM. The FPGA ran its operations with host-generated keys. That makes this a hardware demonstration of selected operations, not a complete on-device key-generation result.
In this article
- What the FPGA demonstration ran
- What the cycle counts measure
- Which cryptographic stages benefit from custom instructions
- Key generation and production-scale memory
- What the tests and power estimates cover
What the FPGA demonstration ran
The researchers extended a single-cycle RV32I processor with tightly coupled custom instructions for Classic McEliece. The design was fitted to a DE1-SoC with an Intel Cyclone V 5CSEMA5F31C6 FPGA, using SYS_T=2, SYS_N=48 and GFBITS=12. Those reduced parameters were chosen for architectural evaluation, not as production-scale performance settings.
The full design used 10,531 adaptive logic modules (ALMs). Its fitted maximum frequency was 118.89 MHz at the slow 85 °C corner, while the processor and accelerators ran at the board’s 5 MHz divided clock. The fitted maximum is therefore not the system’s reported operating clock.
What the cycle counts measure
The large percentage reductions compare the instruction-set extension with an unaccelerated baseline in matched asynchronous-memory simulation. The FPGA implementation used synchronous memory and has separate operation counts. The paper reports these results for different run conditions and operation scopes:
| Run and memory setup | Operation | Cycles and reported reduction | Scope and condition |
| Asynchronous-memory simulation | Encapsulation operation | 1,010 cycles; 87.4% fewer | Matched simulation against the unaccelerated baseline |
| Asynchronous-memory simulation | Decapsulation | 1,708,050 cycles; 86.1% fewer | Matched simulation against the unaccelerated baseline |
| Synchronous-memory FPGA | Encapsulation operation | 1,820 cycles | FPGA operation count |
| Synchronous-memory FPGA | Complete encapsulation, including SHA-256 | 13,585 cycles | Complete-operation count |
| Synchronous-memory FPGA | Decapsulation | 3,654,113 cycles | FPGA run with host-generated keys |
The two FPGA encapsulation figures count different scopes: 1,820 cycles for the encapsulation operation and 13,585 cycles for complete encapsulation including SHA-256. Neither is the asynchronous-simulation comparison behind the percentage reductions. Memory behavior also affects the counts: in the study’s asynchronous configuration, encapsulation took 1,010 cycles and decapsulation 1,708,050 cycles.
Which cryptographic stages benefit from custom instructions
The implementation retained a Chien search over the support list, fixed-size Gaussian elimination for generating a minimal polynomial, and streaming reduction to systematic form during public-key generation. These mappings target specific computational stages rather than accelerating the whole algorithm uniformly.
Integrated profiling also exposed a bottleneck: support generation, driven by a Bénes permutation network, accounted for more than 99% of decapsulation cycles in both reported memory regimes after decoder acceleration. A DMA-assisted composeinv candidate delivered only a 1.0–1.1× improvement in the integrated controlbits stage. Recursive sorting and transfer and startup overhead outweighed the candidate’s benefit, so the researchers rejected that mapping.
Key generation and production-scale memory
The FPGA runs used keys generated by a host computer. Complete key generation on the device was not demonstrated: the full simulated path exceeded a 300-million-cycle budget while controlbits remained in software.
The paper’s analysis of the mceliece348864 parameter set illustrates a separate scaling constraint. It gives a 334,848-byte packed systematic-form matrix and a 261,120-byte public key. The target FPGA has about 496 KiB of block memory. The matrix can fit by itself in principle, but the matrix, public key and processor memories do not fit together. The researchers identify banked or external memory and streaming the right-hand matrix as redesign options; they do not extrapolate performance to this parameter set.
What the tests and power estimates cover
Component-level checks used ModelSim and software reference results; the finite-field inverse test covered all 4,096 field elements. System-level tests passed one reference known-answer test and four directed weight-two error patterns. There are 1,128 such patterns in the tested n=48, t=2 configuration, so the system checks were not exhaustive or statistical.
For the fitted full build at 5 MHz, Quartus PowerPlay estimated total power at 458.34 mW. The researchers estimated about 731 ms and 335 mJ for a decapsulation, with roughly 90% of the estimated energy attributed to static leakage. Those figures are estimates for this Cyclone V build and its activity model.
The researchers performed no side-channel experiment. They also note that fixed instruction latency alone does not establish constant-time software or constant-power hardware.
