An Open Hardware ML-KEM Polynomial Ring Accelerator on Chipyard RISC-V SoC: System-Level Integration and Evaluation

Abstract

With the standardization of the Module-Lattice-Based Key Encapsulation Mechanism (ML-KEM) in NIST FIPS 203 (2024), efficient hardware support for polynomial ring operations has become critical for practical post-quantum cryptography deployment. The dominant computational workload of ML-KEM arises from matrix–vector multiplications over polynomial rings, which involve repeated Number Theoretic Transform (NTT), pointwise multiplication, and modular addition operations. This work proposes an ML-KEM polynomial ring accelerator leveraging Open Intellectual Property (Open IP) and integrates it into an open hardware Chipyard RISC-V System on Chip (SoC) via a Memory-Mapped I/O (MMIO) interface. The design incorporates an NTT-based datapath with multiplier and adder arrays, and employs a scratchpad memory to enable intermediate data reuse and reduce memory access overhead. The proposed architecture is implemented on a Genesys 2 FPGA development board featuring a Kintex-7 XC7K325T Field Programmable Gate Array (FPGA) (Digilent Inc., Pullman, WA, USA) and evaluated at both kernel and system levels. Experimental results show that the accelerator reduces matrix–vector multiplication latency to 7372 cycles, achieving up to 40× speedup over a software baseline. At the SoC level, the complete ML-KEM implementation achieves performance improvements of 1.6× to 2.1× across different parameter sets. These results demonstrate that integrating Open IP within an open hardware SoC provides an effective and reproducible approach for accelerating ML-KEM.

1. Introduction

With the rapid advancement of quantum computing technologies, conventional public-key cryptosystems based on integer factorization and discrete logarithm problems, such as RSA and elliptic curve cryptography, are theoretically vulnerable to quantum attacks enabled by algorithms such as Shor’s algorithm [1]. As a result, the development and standardization of quantum-resistant cryptographic schemes, known as Post-Quantum Cryptography (PQC), have become critical research directions in the fields of cryptography and information security [2]. To facilitate the practical deployment of PQC, the National Institute of Standards and Technology (NIST) officially released Federal Information Processing Standards (FIPS) 203 in 2024, standardizing the Module-Lattice-Based Key Encapsulation Mechanism (ML-KEM) [3]. ML-KEM relies heavily on polynomial ring arithmetic. Due to the extensive use of polynomial operations, particularly matrix–vector polynomial multiplication, efficient ML-KEM implementations on embedded systems and System-on-Chip (SoC) platforms have become a key challenge in PQC hardware research [4,5,6].

In ML-KEM, polynomial multiplication is typically performed using the Number Theoretic Transform (NTT), which converts convolution operations into pointwise multiplications in the transform domain. Previous studies have identified polynomial multiplication and the associated NTT operations as major performance bottlenecks in ML-KEM implementations, leading to extensive research on hardware optimization of NTT and polynomial multiplication units [4,5,6,7]. For example, Yaman et al. proposed a dedicated NTT-based hardware architecture for CRYSTALS-Kyber [7]. However, most of these works focus on the design and evaluation of individual computational modules. In practical implementations, the dominant workload of ML-KEM arises from matrix–vector multiplication over polynomial rings, which involves multiple NTTs, pointwise multiplications, and modular additions. Therefore, optimizing only standalone NTT or polynomial multiplication modules is often insufficient to fully evaluate system-level performance impacts [4,5]. Moreover, system-level performance is influenced not only by arithmetic computation but also by data movement and memory-access overhead, which become increasingly important when integrating accelerators into complete SoC environments. Meanwhile, the emergence of the RISC-V open instruction set architecture and the open hardware ecosystem has enabled researchers to integrate domain-specific accelerators into reproducible SoC platforms and evaluate their performance at the system level. Recent works have explored integrating PQC accelerators into RISC-V-based systems [8]. Among these platforms, Chipyard has become a widely adopted open-source SoC design framework [9]. Such open hardware platforms not only facilitate the development of cryptographic accelerators but also enable system-level validation within full processor and operating system environments, thereby improving the reproducibility and practicality of PQC hardware research.

Based on this background, this work proposes an ML-KEM polynomial ring accelerator leveraging Open Intellectual Property (Open IP) and integrates it into a RISC-V SoC built using the Chipyard framework. The proposed design constructs a complete Rocket Core-based system and incorporates an open-source NTT hardware module proposed by Yaman et al. [7] to accelerate matrix–vector polynomial computations over polynomial rings. Unlike prior works that primarily focus on standalone NTT or polynomial multiplication modules, the proposed accelerator is integrated into the SoC via a Memory-Mapped I/O (MMIO) interface, allowing it to operate within a full processor and operating system environment and enabling system-level hardware validation in a full processor and operating system environment.

The main contributions of the proposed work are summarized as follows:

• Open-IP-based ML-KEM polynomial ring accelerator for matrix–vector polynomial computations;
• Integration of the accelerator into a Chipyard-based RISC-V SoC through an MMIO interface;
• FPGA-based system-level implementation and performance evaluation;
• Demonstration of a reproducible open hardware framework for PQC accelerator research.

2. Background and Related Works

This section reviews the background and related work relevant to ML-KEM hardware acceleration. It first introduces the fundamental polynomial arithmetic in ML-KEM, with a focus on NTT-based computation. Next, prior studies on ML-KEM and Kyber hardware accelerators are surveyed, including both arithmetic-level optimizations and system-level integration approaches. Finally, representative open hardware platforms and RISC-V-based SoC frameworks are discussed to highlight their roles in enabling reproducible and scalable PQC hardware research. Through this review, the limitations of existing approaches are identified, motivating the proposed Open IP-based ML-KEM accelerator with full system-level integration on an open hardware SoC platform. To improve notation consistency and facilitate readability, the definitions and mathematical notations used throughout this paper are summarized in Appendix A.

2.1. ML-KEM and NTT-Based Polynomial Arithmetic

ML-KEM is a PQC standard defined in FIPS 203 by NIST in 2024 [3]. The scheme is derived from the CRYSTALS-Kyber cryptosystem, and its security relies on the hardness of the module Learning-With-Errors (module-LWE) problem [5]. In ML-KEM, most computations are performed over a polynomial ring defined as

$$R_q=Z_q\left[x\right] / (x^n+1),$$

(1)

where the Kyber parameters are typically n = 256 and q = 3329.

During the Key Generation (KeyGen), Encapsulation (Encaps), and Decapsulation (Decaps) procedures, a large number of matrix–vector polynomial multiplications are required. These operations involve repeated polynomial multiplications and modular additions, making them the dominant computational workload in ML-KEM implementations [4,5]. The matrix–vector multiplication over polynomial rings can be expressed as

$$\begin{gathered} C=A^T\odot B=\left[\begin{array}{ccc}{a}_1\left(x\right)& \cdots & a_k\left(x\right)\end{array}\right]\odot \left[\begin{array}{c}{b}_1\left(x\right)\\ ⋮\\ b_k\left(x\right)\end{array}\right], \\ =a_1\left(x\right)\odot b_1\left(x\right)\oplus \dots {\oplus a}_k\left(x\right)\odot b_k\left(x\right), \end{gathered}$$

(2)

where $A$ and $B$ are $k\times 1$ polynomial vectors in $R_q$, and each polynomial $a_i\left(x\right)$, $b_i\left(x\right)$∈$R_q$ has degree less than n. The operator$\odot$denotes pointwise multiplication, and$\oplus$denotes modular addition.

To reduce the computational complexity of polynomial multiplication, ML-KEM employs the NTT, as illustrated in Figure 1. The NTT converts polynomials from the coefficient domain to the transform domain, allowing polynomial multiplication to be performed as element-wise operations. Following the computation flow shown in Figure 1, each pair of polynomials is first transformed into the NTT domain, and the matrix–vector polynomial multiplication is then computed as

$$C\left(\mathrm{x}\right)=\mathrm{I}\mathrm{N}\mathrm{T}\mathrm{T}\left(\mathrm{N}\mathrm{T}\mathrm{T}\left(a_1\left(x\right)\right)\odot \mathrm{N}\mathrm{T}\mathrm{T}\left(b_1\left(x\right)\right)\oplus \cdots \oplus \mathrm{N}\mathrm{T}\mathrm{T}\left(a_k\left(x\right)\right)\odot \mathrm{N}\mathrm{T}\mathrm{T}\left(b_k\left(x\right)\right)\right).$$

(3)

As shown in Figure 1, this computation flow consists of multiple NTT operations, followed by pointwise multiplications and modular accumulation, and finally an Inverse NTT (INTT) operation. Due to the repeated execution of these operations, NTT-based polynomial arithmetic constitutes the primary performance bottleneck in Kyber/ML-KEM implementations [4,5,6]. Therefore, efficient hardware acceleration of these operations is critical for improving the overall system performance of ML-KEM, particularly in embedded and SoC-based environments.

2.2. ML-KEM Hardware Accelerators Survey

With the advancement of NIST PQC standardization, an increasing number of studies have investigated hardware acceleration techniques for ML-KEM and Kyber. Early works primarily focused on the design of efficient NTT architectures and polynomial multiplication units. For example, Karabulut et al. [10] proposed a RISC-V Instruction Set Architecture (ISA) extension for NTT acceleration, while Waris et al. [6], Huang et al. [11], Bisheh-Niasar et al. [12], and Zhang et al. [13] proposed high-speed NTT-based or polynomial-multiplication-oriented hardware architectures, to accelerate Kyber and related post-quantum cryptographic computations. Liu et al. [14] further introduced a configurable NTT/INTT architecture that mitigates memory access conflicts, while Yaman et al. [7] developed an NTT-based polynomial multiplication accelerator specifically tailored for CRYSTALS-Kyber. These studies demonstrate that optimizing NTT and polynomial arithmetic is critical for improving the performance of ML-KEM.

Beyond standalone arithmetic modules, some studies have explored more complete Kyber-oriented hardware architectures. For example, Chen et al. [15] proposed an FPGA-based processor architecture for vectors of polynomials in Kyber, bridging the gap between low-level NTT acceleration and higher-level algorithm support. More recent research has further evolved toward full ML-KEM accelerator architectures. Xing and Li [16] presented a compact FPGA implementation of CRYSTALS-Kyber, achieving a complete hardware realization with low resource utilization through an area-efficient architecture. Kim et al. [17] proposed a configurable hardware accelerator capable of supporting multiple security levels of ML-KEM/Kyber. Ni et al. [18] presented a hardware-efficient ML-KEM design that reduces area consumption while maintaining high throughput. Di Matteo et al. [19] proposed an area-efficient full ML-KEM accelerator, providing a complete hardware implementation that supports standardized ML-KEM operations. In addition, Cui et al. [20] introduced an instruction-based hardware controller for Kyber, enabling closer interaction between the processor and the accelerator. These works extend beyond individual arithmetic units and aim to support larger portions of the ML-KEM algorithm.

In parallel, several studies have explored system-level integration of PQC accelerators. Wang et al. integrated a Kyber accelerator into an FPGA-based RISC-V SoC platform using a hardware–software co-design approach [8]. Dolmeta et al. investigated memory-mapped NTT/INTT accelerators within RISC-V systems [21]. Furthermore, Dam et al. demonstrated the integration of NTT/INTT accelerators in the Chipyard RISC-V SoC framework [22,23], while Abdulrahman et al. implemented NTT acceleration on the OpenTitan platform using the Open-Titan Big Number (OTBN) extension [24]. These studies highlight that, in practical deployments, accelerator performance is influenced not only by arithmetic efficiency but also by system-level factors such as bus architecture, memory access patterns, and hardware–software interaction.

Table 1. ML-KEM hardware accelerator survey and comparison of recent designs.

Work	Year	Algorithm	Architecture	Integration	Impl.	Open IP
Chen et al. [15]	2020	Kyber	Polynomial vector processor	Standalone accelerator	FPGA	No
Huang et al. [11]	2020	Kyber	NTT-based polynomial multiplication	Standalone full accelerator	FPGA	No
Karabulut et al. [10]	2020	NTT	RISC-V ISA extension for NTT	CPU-integrated (ISA extension)	ASIC	No
Xing et al. [16]	2021	Kyber	Full Kyber accelerator	Standalone full accelerator	FPGA	Partial
Yaman et al. [7]	2021	Kyber	Polynomial multiplication accelerator	Standalone accelerator	FPGA	Yes
Bisheh-Niasar et al. [12]	2021	Kyber	NTT-based polynomial multiplier	Standalone accelerator	FPGA	No
Zhang et al. [13]	2021	Kyber	Efficient NTT architecture	Standalone accelerator	FPGA	No
Celik et al. [25]	2023	Kyber	Keccak hardware acceleration	RISC-V CPU (Ibex, MMIO/interrupt-based)	FPGA	No
Liu et al. [14]	2024	NTT/INTT	Configurable NTT/INTT accelerator	Standalone accelerator	ASIC	No
Kim et al. [17]	2024	ML-KEM	Configurable full KEM accelerator	Standalone full accelerator	ASIC	No
Wang et al. [8]	2024	Kyber / Dilithium	HW/SW co-design with polynomial accelerators	RISC-V SoC (HW/SW co-design)	FPGA	No
Dolmeta et al. [21]	2024	Kyber	Memory-mapped NTT/INTT accelerator	RISC-V SoC (MMIO-based)	FPGA	No
Dam et al. (ICDV) [22]	2024	Kyber	NTT black-box accelerator	Chipyard RISC-V SoC (MMIO/peripheral)	FPGA/ASIC	Partial
Waris et al. [6]	2025	Kyber	NTT/INTT-based polynomial multiplier	Standalone accelerator	FPGA	No
Ni et al. [18]	2025	ML-KEM	Full ML-KEM accelerator	Standalone full accelerator	ASIC	No
Cui et al. [20]	2025	Kyber	Instruction-based hardware controller	CPU–accelerator (instruction-based)	ASIC	No
Abdulrahman et al. [24]	2025	ML-KEM / ML-DSA	OpenTitan OTBN extension	OpenTitan SoC (OTBN-based)	ASIC	Partial
Di Matteo et al. [19]	2026	ML-KEM	Full ML-KEM accelerator	Standalone full accelerator	ASIC	No
Dam et al. (Electronics) [23]	2026	ML-KEM	Tightly integrated NTT accelerator with custom instructions	Chipyard RISC-V SoC (RoCC tightly coupled)	ASIC	Partial
Proposed Work	2026	ML-KEM	ML-KEM Polynomial ring accelerator	Chipyard RISC-V SoC (MMIO/peripheral)	FPGA	Yes

summarizes recent PQC hardware accelerator designs. Most prior works focus on accelerating specific computational modules, such as NTT and polynomial multiplication [6,7,14], or cryptographic primitives like Keccak [25]. Some designs extend to full ML-KEM/Kyber acceleration [16,17,18,19], while others explore integration into RISC-V systems through hardware–software co-design or memory-mapped interfaces [8,21]. More recently, open hardware-based implementations have emerged, including accelerators developed on platforms such as OpenTitan and RISC-V SoCs [22,23,24]. However, existing works are still largely limited to either partial algorithm acceleration or isolated hardware components, with relatively few studies addressing full ML-KEM system integration and validation on open hardware platforms.

From the perspective of hardware design methodology, the role of Open IP has become increasingly important. Open IP improves design reusability and development efficiency, and enables reproducible research environments, which are particularly valuable for PQC standardization and deployment. Nevertheless, as shown in Table 1, most existing ML-KEM and Kyber hardware accelerators remain closed or proprietary, with only a few works providing reusable open-source hardware modules. For instance, Yaman et al. [7] provide reusable polynomial multiplication components, while some SoC-based studies (e.g., [22,23,24]) are built on open hardware platforms but only partially release their accelerator designs. A closer examination reveals two key limitations in current Open IP-based PQC hardware designs. First, most open-source implementations focus on individual computational blocks (e.g., NTT or Keccak), lacking integrated IPs that support the complete ML-KEM algorithm flow. Second, even when integrated into open hardware SoC platforms, the modularity and reusability of these designs are often limited, making it difficult to establish a scalable PQC IP ecosystem. As a result, there is still a lack of design approaches that simultaneously achieve full algorithm support, system-level integration, and reusable Open IP.

2.3. Open Hardware and RISC-V SoC Platforms

In recent years, open hardware platforms have become an essential foundation for SoC architecture research and validation, enabling researchers to design and evaluate hardware accelerators in reproducible and scalable environments. With the rapid development of the RISC-V open ISA, several open hardware platforms have been widely adopted in cryptographic and PQC research, including Chipyard, Ibex, OpenTitan, and OpenHW CORE-V.

Ibex is a lightweight RISC-V processor core designed for embedded control and security-oriented applications [26], and it is integrated into the OpenTitan project. OpenTitan is an open-source silicon root-of-trust platform that emphasizes security, verification, and reliability [27]. However, its system architecture is relatively fixed and tailored for security modules and control functions, making it less suitable for flexible SoC architecture exploration. Similarly, the OpenHW Group provides several open-source RISC-V cores, such as CV32E40P [28], along with comprehensive verification frameworks. Nevertheless, these efforts primarily focus on processor core development and verification, offering limited support for full SoC generation and accelerator integration.

In contrast, Chipyard provides a complete and modular SoC generation framework that enables rapid construction of customized RISC-V systems using a generator-based hardware design methodology [9]. The platform supports the integration of various processor cores (e.g., Rocket and BOOM), on-chip interconnects (TileLink), memory hierarchies, and custom hardware accelerators. It also offers a mature simulation and FPGA prototyping environment. Moreover, Chipyard-generated SoCs can support operating systems such as Linux, allowing hardware accelerators to be evaluated within a realistic software execution environment. This capability is particularly important for PQC systems, where the overall performance depends not only on the hardware accelerator itself but also on its interaction with the operating system, drivers, and application-level software. Compared with designs validated only at the Register-Transfer Level (RTL) or simulation level, SoC platforms with operating system support provide a more realistic evaluation of system-level behavior and performance.

Based on this comparison, the proposed work adopts Chipyard as the SoC platform for ML-KEM acceleration for several key reasons. First, it provides full SoC generation capabilities, enabling rapid construction of systems that include processors, memory subsystems, and interconnects. Second, it supports flexible accelerator integration mechanisms, such as MMIO and TileLink-based interfaces. Third, it offers a well-established verification flow, including both simulation and FPGA-based validation. Finally, it enables system-level evaluation with operating system support, improving the practicality and reproducibility of experimental results. As PQC hardware research evolves from arithmetic-level optimization to system-level design, the integration methodology between accelerators and processors has become a critical factor affecting overall performance. Existing approaches can be broadly categorized into three types: (1) loosely coupled architectures, where accelerators are integrated as peripherals or memory-mapped modules [21,22]; (2) tightly coupled architectures, implemented through instruction-set extensions or custom processor interfaces [10,23]; and (3) hardware–software co-design approaches that combine software control with hardware acceleration [8]. In addition, recent studies have explored PQC accelerator designs on open hardware platforms such as OpenTitan [24], although most of these efforts are still limited to specific computational modules or partial algorithm support.

To systematically compare prior work in terms of system integration level, algorithm completeness, and open hardware support,

Table 2. Comparison of System-Level PQC Accelerator Integration.

Work	Algorithm	NTT Accelerator	Full ML-KEM	RISC-V SoC	Open Hardware
Wang et al. (TCHES) [8]	Kyber	✓	Partial	✓	✗
Dolmeta et al. [21]	Kyber	✓	✗	✓	✗
Abdulrahman et al. [24]	ML-KEM	✓	Partial	✓	Partial
Dam et al. (ICDV) [22]	Kyber	✓	✗	✓	Partial
Dam et al. (Electronics) [23]	ML-KEM	✓	Partial	✓	Partial
Proposed Work	ML-KEM	✓ (Integrated NTT datapath)	✓ (HW/SW co-designed ML-KEM)	✓ (Chipyard SoC + OS support)	✓ (Open IP + reproducible)

✓: Supported; ✗: Not supported.

summarizes representative PQC hardware accelerators at the system level. As shown in Table 2, although some designs achieve integration with RISC-V SoC platforms, they often lack either full ML-KEM algorithm support or comprehensive open hardware integration. In contrast, the proposed design in this work provides complete ML-KEM acceleration, integrates seamlessly into a RISC-V SoC, and is validated within an open hardware platform with operating system support. This approach addresses existing limitations in system-level evaluation and reproducibility in PQC hardware research.

From a system-level design perspective, open hardware not only influences the design methodology but also directly determines the deployability and verifiability of PQC accelerators in real-world systems. Compared with conventional closed hardware platforms, open hardware provides complete SoC architectures, standardized bus interfaces, and hardware–software co-design environments, enabling researchers to evaluate accelerator performance under conditions that closely resemble practical deployments. However, as summarized in Table 2, although many existing PQC hardware accelerator designs support integration with RISC-V SoC platforms, there remain significant differences in the level of open hardware support. To facilitate reproducibility and future research, the open hardware resources utilized in this work are summarized in Appendix B.

Specifically, some studies, such as those by Wang et al. [8] and Dolmeta et al. [21], integrate accelerators into RISC-V SoC platforms, but their implementations are often based on specific experimental platforms or customized systems. As a result, they lack comprehensive support from fully open hardware frameworks, which limits their reproducibility and scalability. In contrast, more recent works have begun to adopt open hardware platforms such as OpenTitan and Chipyard. For example, Abdulrahman et al. [24] implemented partial ML-KEM support on OpenTitan using OTBN instruction extensions, while Dam et al. [22,23] integrated NTT accelerators into a Chipyard-based RISC-V SoC. Nevertheless, these studies primarily focus on accelerating NTT or partial algorithm flows, and still exhibit limitations in terms of full ML-KEM support and depth of system-level integration. Furthermore, their open hardware support is often partial, and does not yet form a fully reusable system architecture. As further observed from Table 2, existing works that simultaneously achieve (1) HW/SW co-designed ML-KEM support, (2) integration within a RISC-V SoC, and (3) complete open hardware reproducibility remain limited. Most prior designs satisfy only one or two of these criteria for example, providing SoC integration without full algorithm support, or offering partially open hardware designs without system-level validation. This observation indicates that current PQC hardware research still lacks a comprehensive design paradigm that enables full algorithm implementation and system-level validation on open hardware platforms.

Motivated by these limitations, the proposed work adopts open hardware as the core design foundation and leverages the generator-based SoC framework and complete software execution environment provided by Chipyard to realize system-level integration of an ML-KEM accelerator. By implementing the accelerator on an open RISC-V SoC platform and validating it within an operating system environment, the proposed design ensures both reproducibility and scalability, while enabling realistic performance evaluation under practical application scenarios. Compared with prior work, this study further emphasizes an integrated design paradigm of “Open Hardware + HW/SW co-designed ML-KEM + System-Level Evaluation,” addressing existing gaps in system-level validation and open hardware support in PQC accelerator research. To facilitate reproducibility and future research, the open hardware resources utilized in this work are summarized in Appendix B.

3. Polynomial Ring Multiplication Accelerator for ML-KEM in RISC-V SoC

This section presents the proposed hardware accelerator architecture designed to implement matrix–vector multiplication over the polynomial ring $R_q$, and describes its integration and operation within a 64-bit RISC-V Rocket Core-based SoC platform. This computation constitutes the dominant and most computationally intensive operation in the ML-KEM algorithm. The primary design objective of the proposed work is to reduce redundant main memory accesses of polynomial coefficients across different stages of matrix–vector multiplication, including the NTT, pointwise multiplication, and modular addition. To achieve this goal, a polynomial ring accelerator architecture based on scratchpad memory [29] is proposed, in which all intermediate results are processed entirely within the accelerator. Specifically, transformation, multiplication, and accumulation operations are performed locally without external memory interaction. Through this data reuse mechanism, polynomial coefficients are transferred via I/O only at the beginning and end of the computation. This approach effectively eliminates repeated data movement across the system bus and significantly reduces system latency dominated by data transfer overhead.

3.1. System Architecture of the RISC-V SoC

The SoC architecture adopted in the proposed work is illustrated in Figure 2. The design is based on a RISC-V SoC platform, featuring a single 64-bit Rocket core that supports the RV64GC instruction set. The system operates at a clock frequency of 100 MHz. The processor is equipped with a 16 KB L1 instruction cache and a 16 KB L1 data cache, along with a shared 512 KB L2 cache. In terms of system interconnection, the processor core is connected to the L2 cache and other system components through the system bus, and accesses external DDR main memory via the memory bus. The hardware accelerator is integrated into the SoC through the periphery bus. The MPRA is connected via a 64-bit TileLink-Uncached Lightweight (TL-UL) interface and accessed through MMIO, enabling communication with the processor and memory subsystem. The baseline RISC-V SoC is constructed using the Chipyard framework, which provides a generator-based hardware design methodology for rapid system integration.

The proposed ML-KEM Polynomial Ring Accelerator (MPRA) is integrated into the SoC using the Chisel BlackBox interface provided by Chipyard. The accelerator is incorporated as an MMIO, allowing it to be accessed by the processor through standard load/store operations. In this integration model, the accelerator shares the main memory access channel with the processor, enabling efficient data exchange without requiring specialized instruction extensions.

The implemented SoC is synthesized and deployed using Vivado 2021.1 on a Digilent Genesys 2 development board, which is equipped with a Xilinx Kintex-7 FPGA (XC7K325T-2FFG900C). The MPRA is designed and integrated in Chisel at the RTL, and subsequently synthesized and implemented on the FPGA platform. This hardware implementation environment enables realistic evaluation of system-level performance, particularly the impact of data movement on system latency. Furthermore, it validates the design objective of performing continuous polynomial processing within the accelerator, thereby avoiding repeated accesses to main memory.

3.2. Design of the ML-KEM Polynomial Ring Accelerator

The proposed MPRA datapath is illustrated in Figure 3. The architecture is designed to perform matrix–vector multiplication over the polynomial ring $R_q$, which consists of three primary operations: NTT/INTT operations, polynomial pointwise multiplication, and modular addition. The implementations of the NTT and pointwise multiplication units are based on the design methodology proposed by Yaman et al. [7]. In the proposed work, the overall architecture is further optimized with a focus on data reuse and efficient memory access. A flexible buffering mechanism is introduced between the I/O interface and the computation core to reduce bus access latency and improve computational efficiency.

The functionality of each module in the datapath is described as follows:

• Local Buffer
  The local buffer serves as an intermediate buffer between the CPU interface and the computation core. It temporarily stores polynomial coefficients received from the processor and supports staged data loading and processing. This design reduces the dependency on frequent external memory access during computation.
• Butterfly Array
  The butterfly array performs NTT and INTT operations. It employs a parallel butterfly structure to execute modular multiplication and addition over finite fields, enabling efficient transformation between the time domain and the frequency domain.
• Multiplier Array
  The multiplier array supports pointwise multiplication in the NTT domain. It performs modular multiplication on corresponding polynomial coefficients and serves as the core computational unit for polynomial ring multiplication.
• Adder Array
  The adder array performs modular addition of polynomial coefficients. It is primarily used for accumulation in matrix–vector multiplication, where intermediate results are combined across multiple polynomial products.
• Scratchpad Memory
  The scratchpad memory stores intermediate results generated during NTT, pointwise multiplication, and modular addition stages. By keeping intermediate data within the accelerator, the design enables continuous computation without repeatedly transferring data across the system bus, thereby significantly reducing main memory access overhead.
• Controller
  The controller manages the overall execution flow and scheduling of operations. It coordinates data movement and computation among the modules and interacts with the processor through a status register. This mechanism enables synchronization and provides a programmable interface for controlling the accelerator.

3.3. Matrix–Vector Multiplication over Polynomial Rings for ML-KEM

In the ML-KEM algorithm, matrix–vector multiplication is one of the most computationally intensive operations. Therefore, the proposed work adopts it as the primary target for hardware acceleration. Taking ML-KEM-512 (Kyber512) as an example, the security parameter is $k=2$. Each element in the matrix and vector is a polynomial defined over the ring

$$R_q=Z_{3329}\left[x\right]/(x^{256}+1).$$

Let the polynomial vectors be defined as

$$A=\left[a_1\left(x\right),a_2\left(x\right)\right], B={\left[b_1\left(x\right),b_2\left(x\right)\right]}^T.$$

The matrix–vector multiplication can be expressed as

$$C=A^T⊚B,$$

which can be expanded as

$$C=a_1\left(x\right)⊚b_1\left(x\right)\oplus a_2\left(x\right)⊚b_2\left(x\right),$$

where$⊚$denotes polynomial multiplication over $R_q$, and$\oplus$denotes modular addition.

To reduce the computational complexity of polynomial multiplication, ML-KEM employs the NTT to convert polynomials from the time domain to the NTT domain. In this domain, polynomial multiplication can be transformed into pointwise multiplication. Therefore, the computation can be reformulated as

$$C=INTT\left(\overline{a_1}\left(x\right)⨀\overline{b_1}\left(x\right)\oplus \overline{a_2}\left(x\right)⨀\overline{b_2}\left(x\right)\right),$$

where

$$\overline{a_i}\left(x\right)=NTT\left(a_i\left(x\right)\right), \overline{b_i}\left(x\right)=NTT\left(b_i\left(x\right)\right),$$

and$⨀$denotes pointwise multiplication in the NTT domain.

As illustrated in Figure 4, the input polynomials $a_1\left(x\right),a_2\left(x\right),b_1\left(x\right),b_2\left(x\right)$are first transformed into the NTT domain as $\overline{a_1}\left(x\right),\overline{b_1}\left(x\right),\overline{a_2}\left(x\right),\overline{b_2}\left(x\right),$respectively. The pointwise multiplications are then performed to produce intermediate results

$$e\left(x\right)=\overline{a_1}\left(x\right)⨀\overline{b_1}\left(x\right), f\left(x\right)=\overline{a_2}\left(x\right)⨀\overline{b_2}\left(x\right).$$

These intermediate results are accumulated using modular addition,

$$g\left(x\right)=e\left(x\right)\oplus f\left(x\right),$$

and finally transformed back to the time domain using the INTT to obtain the output polynomial

$$C=INTT\left(g\left(x\right)\right).$$

In the matrix–vector multiplication of ML-KEM, each polynomial multiplication requires an initial NTT transformation, followed by pointwise multiplication and accumulation in the NTT domain. To reduce redundant memory accesses, the proposed polynomial ring accelerator employs an on-chip scratchpad memory to store intermediate results. Figure 5 illustrates the NTT transformation stage. Polynomial coefficients are transferred to the accelerator and processed by the NTT core. The transformed coefficients, such as $\overline{a_1}\left(x\right)$, are subsequently written into the scratchpad memory. This design allows the NTT-domain representation of polynomials to be retained within the accelerator and reused by subsequent computation stages, including pointwise multiplication and modular accumulation. By maintaining intermediate results within the scratchpad memory, the proposed architecture minimizes off-chip memory accesses and eliminates redundant data transfers across the system bus. This dataflow organization improves computational efficiency by enabling reuse of transformed polynomial data during matrix–vector multiplication.

Figure 6 illustrates the pointwise multiplication stage. The transformed polynomial coefficients stored in the scratchpad memory, such as $\overline{a_1}\left(x\right)$ and $\overline{b_1}\left(x\right)$, are read and forwarded to the multiplier array to perform pointwise multiplication. The resulting polynomial $e\left(x\right)$ is written back to the scratchpad memory for subsequent processing. Since matrix–vector multiplication involves multiple polynomial multiplications followed by accumulation, the NTT-domain coefficients stored in the scratchpad can be reused across different computation stages. This reuse mechanism avoids repeated NTT transformations and eliminates redundant accesses to external memory, thereby improving the overall computational efficiency of the accelerator.

Figure 7 shows the accumulation stage of the polynomial ring computation. The intermediate results $e\left(x\right)$ and $f\left(x\right)$ are read from the scratchpad memory and forwarded to the adder array to perform modular addition. This operation produces the accumulated result

$$g\left(x\right)=e\left(x\right)\oplus f\left(x\right),$$

where $\oplus$ denotes modular addition over the ring $R_q$.

The accumulation is performed directly in the NTT domain. All intermediate results are maintained within the scratchpad memory throughout the computation. Through this data reuse mechanism, previously computed intermediate results can be directly accessed and updated by subsequent operations without requiring transfers across the system bus. This approach eliminates redundant accesses to external memory and effectively reduces system-level latency caused by data movement.

Figure 8 illustrates the inverse transformation stage. The accumulated result $g\left(x\right)$ is read from the scratchpad memory and forwarded to the butterfly array to perform the INTT, which converts the data from the NTT domain back to the time-domain polynomial representation. After the INTT operation, the final polynomial result $C$ is obtained. This result is temporarily stored in the local buffer and subsequently transferred back to the CPU through the I/O interface.

Through the proposed datapath design, the polynomial ring accelerator performs the complete ML-KEM polynomial ring computation within a unified hardware architecture. Polynomial coefficients are transferred via I/O only at the beginning and end of the computation, while all intermediate operations are executed within the accelerator. By retaining intermediate results in the scratchpad memory, the proposed architecture reduces main-memory accesses and improves data locality. This design enhances the efficiency of matrix–vector multiplication in ML-KEM.

4. Implementation Results and Discussion

This section presents the FPGA implementation results, micro-benchmark evaluations, and system-level performance analysis of ML-KEM workloads. A systematic comparison with existing RISC-V and FPGA-based platforms is also provided. All experiments are conducted on a Xilinx Kintex-7 FPGA operating at 100 MHz.

4.1. Hardware Resource Utilization

This subsection analyzes the hardware resource overhead introduced by integrating the proposed polynomial ring accelerator into the RISC-V SoC.

Table 3. FPGA resource utilization of the proposed SoC.

Implementation	LUT	FF	BRAM	DSP
Proposed SoC without MPRA	67,356/203,800 (33.05%)	42,918/407,600 (10.53%)	143/445 (32.13%)	15/840 (1.79%)
Proposed SoC with MPRA	78,514/203,800 (38.52%)	52,613/407,600 (12.91%)	177/445 (39.77%)	31/840 (3.69%)

presents a comparison of hardware resource utilization on the Xilinx Kintex-7 FPGA platform, with and without the integration of the NTT-based accelerator. The integration of the proposed accelerator results in a moderate increase in logic resource usage. Specifically, the lookup table (LUT) utilization increases from 33.05% to 38.52%, while Flip-Flop (FF) utilization rises from 10.53% to 12.91%. This increase is primarily attributed to the additional computational units within the accelerator, including the butterfly array, multiplier array, adder array, and associated control logic. In terms of memory resources, Block RAM (BRAM) utilization increases from 32.13% to 39.77%. This increase is mainly due to the implementation of the local buffer and scratchpad memory, which are used to store intermediate results during NTT transformations and polynomial ring computations. These on-chip memory structures enable efficient data reuse and reduce the dependence on external memory access. Furthermore, DSP utilization increases from 1.79% to 3.69%, primarily to support pointwise multiplication operations within the multiplier array.

Overall, the proposed accelerator introduces only a modest hardware overhead while significantly improving the computational efficiency of polynomial ring operations. These results demonstrate the practicality and effectiveness of integrating the proposed design into a RISC-V SoC platform.

4.2. Performance Analysis of Polynomial Ring Computation

To further highlight the differences between the proposed architecture and prior work, this subsection compares the design characteristics of representative hardware accelerators for ML-KEM-related computations.

Table 4. The design characteristics of representative hardware accelerators for ML-KEM-related computations.

Work	Target Operation	NTT Accelerator	Polynomial Multiplication	Modular Addition	Matrix–Vector Multiplication	Hash Accelerator	SoC-Level Evaluation
Yaman et al. [7]	Polynomial Multiplication	✓	✓	✗	✗	✗	Partial
Karabulut et al. [10]	Polynomial Multiplication	✓	✓	✗	✗	✗	Partial
Dam et al. [22]	Polynomial Multiplication	✓	✓	✗	✗	✗	Partial
Celik et al. [25]	Keccak Acceleration	✗	✗	✗	✗	✓	Full
Proposed Work	Matrix–Vector Multiplication over Polynomial Rings	✓	✓	✓	✓	✗	Full

✓: Supported; ✗: Not supported.

summarizes several representative studies, including those by Yaman et al. [7], Karabulut et al. [10], Dam et al. [22], Celik et al. [25], and the proposed design in this work. Most existing studies primarily focus on accelerating single polynomial multiplication using NTT/INTT-based approaches. For example, Karabulut et al. [10] propose a RISC-V instruction set extension to accelerate NTT operations. Yaman et al. [7] develop a dedicated hardware accelerator that leverages NTT and pointwise multiplication to improve the efficiency of polynomial multiplication in CRYSTALS-Kyber. Similarly, Dam et al. [22] integrate an NTT-based accelerator into a RISC-V SoC platform to enhance polynomial computation performance. In contrast, Celik et al. [25] adopt a different optimization approach by accelerating the Keccak hash function within the Kyber algorithm. Their design targets the most time-consuming cryptographic primitive identified through profiling and implements a hardware Keccak core within a RISC-V SoC using a hardware–software co-design methodology. However, their work does not address polynomial arithmetic operations such as NTT, polynomial multiplication, or matrix–vector multiplication. Despite these advancements, most prior works primarily target the acceleration of individual polynomial operations or specific cryptographic primitives. However, the dominant computational workload in the ML-KEM algorithm is matrix–vector multiplication over polynomial rings, which involves multiple polynomial multiplications followed by modular accumulation. As a result, accelerating only a single operation still requires software-controlled data movement and scheduling across multiple computation stages.

The proposed architecture directly targets matrix–vector multiplication over polynomial rings at the hardware level. The accelerator integrates NTT/INTT computation units, a multiplier array for pointwise multiplication, and an adder array for modular addition, enabling the entire polynomial computation flow to be executed within a unified hardware datapath. In addition, a scratchpad memory is employed to store intermediate results, allowing NTT-transformed coefficients to be reused in subsequent pointwise multiplication and accumulation stages. This design avoids frequent accesses to external memory across different computation stages and improves the overall efficiency of polynomial ring computations.

Table 5. Performance Breakdown of Polynomial Ring Operations.

Implementations	Steps		Clocks	Total Clocks	Latency (μs)
Proposed work	NTT (2 NTTs)	Data Load Time	2967	5483	54.83
		NTT Core for NTT	280
	Pairwise Multiplication		122
	INTT (1 INTT)	NTT Core for INTT	150
		Data Store Time	1964
Karabulut et al. [10]	NTT (1 NTT)	Data Load Time	43,756	43,756	✗
		NTT Core for NTT
		Data Store Time
Dam et al. [22]	NTT (1 NTT)	Data Load Time	2084	9842	✗
		NTT Core for NTT	5682
		Data Store Time	2076
Kyber C code [30]	NTT		66,394	143,196	1431.96
	Pairwise Multiplication		18,686
	INTT		56,098

presents the performance comparison of the proposed polynomial ring accelerator with a software implementation and existing hardware–software co-design approaches. In the proposed design, a polynomial multiplication consists of two NTT transformations, one pointwise multiplication, and one INTT transformation. The entire computation requires 5483 clock cycles, corresponding to a latency of 54.83 μs at an operating frequency of 100 MHz. The cycle distribution across different computation stages can be summarized as follows:

• Data load time requires 2967 cycles;
• NTT computation requires 280 cycles;
• Pointwise multiplication requires 122 cycles;
• INTT computation requires 150 cycles;
• Data store time requires 1964 cycles.

From this breakdown, it can be observed that the computational cost of the NTT/INTT cores is relatively small compared to the overall execution time, while data movement accounts for a significant portion of the total latency. Specifically, data loading and storage require 4931 cycles, accounting for approximately 90% of the total execution time, whereas the combined cost of NTT, pointwise multiplication, and INTT is only 552 cycles. This observation indicates that memory access, rather than arithmetic computation, is the dominant performance bottleneck in the proposed system. Therefore, reducing data access and transfer overhead is critical for improving system-level performance. The proposed scratchpad-memory-based architecture enables intermediate results to be reused within the accelerator, thereby reducing unnecessary data transfers and improving data locality. Compared with the reference software implementation, which requires 143,196 cycles for polynomial computation, the proposed hardware accelerator significantly reduces execution time. This improvement is primarily achieved through the hardware implementation of NTT and pointwise multiplication, enabling polynomial computations to be performed within the accelerator. In addition, the proposed design is compared with existing hardware–software co-design approaches. For example, Karabulut et al. [10] accelerate NTT operations using RISC-V instruction set extensions; however, data movement and control are still handled by the processor, resulting in 43,756 cycles for NTT computation. Dam et al. [22] propose an SoC design integrating an NTT module, where the combined cost of NTT computation and data movement is 9842 cycles.

In addition to polynomial ring operations, the proposed work further evaluates the overall performance of the proposed accelerator at the matrix–vector multiplication level, which speeds up the computation for Equation (2) in Section 2.1. In the Kyber/ML-KEM algorithm, matrix–vector multiplication represents one of the dominant computational workloads, and its performance directly impacts overall system efficiency. As shown in

Table 6. Performance comparison of matrix–vector multiplication for ML-KEM.

Implementations	Clocks	Latency (μs)	Speed Up
Kyber C code [30]	296,485	2964.85	1
Proposed HW Accelerator with Pointwise Multiplication Only	12,037	120.37	24.6
Proposed HW Accelerator with Pointwise Multiplication and Modular Addition Support	7372	73.72	40.2

, a pure software implementation requires 296,485 clock cycles to complete a single matrix–vector multiplication, corresponding to a latency of approximately 2964.85 μs at a clock frequency of 100 MHz. When only pointwise multiplication is accelerated in hardware, without optimizing modular addition using the adder array, the required number of clock cycles is reduced to 12,037 cycles, achieving a performance improvement of approximately 24.6× compared to the software baseline. By further incorporating the proposed adder array to accelerate modular addition, the accumulation of intermediate results in the NTT domain is significantly improved. As a result, the total computation time is further reduced to 7372 cycles, corresponding to a latency of 73.72 μs. Compared with the Kyber C reference implementation [30], the proposed architecture achieves an overall performance improvement of approximately 40.2×. These results demonstrate that efficient modular accumulation within the accelerator, combined with reduced intermediate data movement, plays a critical role in improving the performance of matrix–vector multiplication in ML-KEM.

4.3. SoC-Level Performance Evaluation of ML-KEM

Before evaluating performance, the correctness of the proposed implementation was verified using the NIST ML-KEM known answer test (KAT) vectors generated by the official CRYSTALS-Kyber reference implementation [30]. For each parameter set, the outputs of key generation, encapsulation, and decapsulation were compared against the corresponding reference outputs. As summarized in

Table 7. Functional correctness validation using NIST ML-KEM known answer tests.

Parameter Set	KeyGen	Encaps	Decaps
ML-KEM 512	Pass	Pass	Pass
ML-KEM 768	Pass	Pass	Pass
ML-KEM 1024	Pass	Pass	Pass

, all test cases passed successfully, confirming the functional correctness of the proposed implementation.

To evaluate the practical system-level performance of the proposed polynomial ring accelerator, the ML-KEM algorithm is integrated into the RISC-V SoC platform for end-to-end testing. By offloading the primary computational workload in the Kyber/ML-KEM algorithm—namely polynomial ring operations and matrix–vector multiplication—to the proposed hardware accelerator, the overall execution time can be effectively reduced.

Table 8. SoC-Level Performance of ML-KEM with the Proposed Accelerator.

Algorithm	Operation	Kyber C Code [30]	Proposed Work	Speed-Up
ML-KEM 512	KeyGen	802,174	513,555	1.56
	Encaps	929,391	554,479	1.67
	Decaps	1,037,658	492,533	2.10
ML-KEM 768	KeyGen	1,270,151	829,646	1.53
	Encaps	1,447,649	877,912	1.64
	Decaps	1,604,701	788,022	2.03
ML-KEM 1024	KeyGen	1,827,053	1,219,147	1.50
	Encaps	2,120,848	1,295,500	1.63
	Decaps	2,317,043	1,193,890	1.94

presents the system-level performance comparison of ML-KEM under different security parameter sets, including ML-KEM-512, ML-KEM-768, and ML-KEM-1024. The baseline results are obtained by executing the NIST reference Kyber C implementation on the Rocket core, while the accelerated results are measured using the proposed polynomial ring accelerator. The software baseline was compiled using the RISC-V GNU Compiler Collection (GCC) toolchain targeting the RV64GC ISA with the -O2 optimization level and executed in Linux user mode on the Rocket core. The processor configuration includes a 16 KB L1 instruction cache, a 16 KB L1 data cache, and a shared 512 KB L2 cache. Program code and data were stored in external DDR memory and accessed through the standard memory hierarchy of the Chipyard-generated SoC. The evaluation includes key generation, encapsulation, and decapsulation for all ML-KEM parameter sets. As shown in the table, under the ML-KEM-512 parameter set, the execution time of encapsulation is reduced from 929,391 cycles to 554,479 cycles, achieving a speedup of approximately 1.67×. Similarly, decapsulation is reduced from 1,037,658 cycles to 492,533 cycles, achieving a speedup of approximately 2.10×.

Similar performance improvements are observed under higher security levels, including ML-KEM-768 and ML-KEM-1024. For ML-KEM-768, the proposed design achieves speedups of 1.64× and 2.03× for encapsulation and decapsulation, respectively. For ML-KEM-1024, the corresponding speedups are 1.63× and 1.94×. These results indicate that offloading polynomial ring computations to the NTT-based hardware accelerator, combined with an effective data reuse mechanism, can significantly reduce the overall computational workload of ML-KEM on the SoC platform. Furthermore, to provide a system-level comparison, the proposed design is evaluated against the ML-KEM hardware accelerator reported by Celik et al. [25], as shown in

Table 9. SoC-level performance comparison for Kyber-768.

Work	CPU	ISA	Clock Rate	Execution Time	Encaps (SW)	Encaps (SW/HW)	Decaps (SW)	Decaps (SW/HW)
Celik et al. [25]	Ibex Core	RV32IMC	50 MHz	Cycles	5,886,277	3,115,537	6,222,787	3,957,289
				Latency (μs)	117,725.54	62,310.74	124,455.74	79,145.78
Proposed Work	Rocket Core	RV64GC	100 MHz	Cycles	1,447,649	877,912	1,604,701	788,022
				Latency (μs)	14,476.49	8779.12	16,047.01	7880.22

Note: Latency values are calculated using the reported operating frequencies of each design (50 MHz for Celik et al. [25] and 100 MHz for the proposed work).

. Their design employs an Ibex core (RV32IMC) operating at 50 MHz, whereas the proposed system uses a Rocket core (RV64GC) operating at 100 MHz. Based on the comparison results for Kyber-768, the proposed design achieves a substantial reduction in the number of required clock cycles for both encapsulation and decapsulation operations. This demonstrates that the proposed polynomial ring accelerator maintains strong performance advantages even after full system-level integration.

Overall, the experimental results demonstrate that integrating the proposed polynomial ring accelerator into the RISC-V SoC platform effectively accelerates the most critical computational components of the ML-KEM algorithm. Consistent and significant performance improvements are observed across different security parameter sets. Compared with existing RISC-V SoC-based implementations, the proposed design achieves a substantial reduction in end-to-end execution cycles at an operating frequency of 100 MHz. These results validate the effectiveness of the proposed dataflow optimization strategy, particularly in reducing data movement overhead, and highlight its practical benefits for accelerating complete cryptographic workloads.

5. Conclusions

The proposed architecture accelerates matrix–vector multiplication while supporting system-level evaluation in a complete RISC-V environment. By employing scratchpad memory to enable intermediate data reuse, the design effectively reduces data movement across the system bus and improves overall computational efficiency. Unlike prior studies focusing on individual arithmetic modules, this work emphasizes system-level integration and validation. The MMIO-based integration framework improves reproducibility and facilitates practical PQC hardware–software co-design.

Experimental results on a Kintex-7 FPGA platform demonstrate significant performance improvements for ML-KEM-related computations. At the polynomial computation level, the proposed design substantially reduces the number of execution cycles compared to software implementations. At the matrix–vector multiplication level, the scratchpad-based data reuse mechanism achieves approximately 16× performance improvement. At the full ML-KEM system level, speedups of approximately 1.6× to 2.1× are observed across different security parameter sets. These results further indicate that data movement overhead is a key factor affecting system performance, highlighting the importance of on-chip memory and data reuse strategies in PQC hardware acceleration. The results demonstrate that memory access, rather than arithmetic computation, is the dominant system-level bottleneck. The proposed scratchpad-based design reduces unnecessary data transfers while providing a reproducible and scalable framework for PQC accelerator research on open hardware platforms.