Hardware Optimized Modular Reduction

Abstract

We introduce a modular reduction method that is optimized for hardware and outperforms conventional approaches. By leveraging calculated reduction cycles and combinatorial logic, we achieve a remarkable 30% reduction in power usage, 27% reduction in Configurable Logic Blocks (CLBs), and 42% fewer look-up tables (LUTs) than the conventional implementation. Our Hardware-Optimized Modular Reduction (HOM-R) system can condense a 256-bit input to a four-bit base within a single 250 MHz clock cycle. Further, our method stands out from prevalent techniques, such as Barrett and Montgomery reduction, by eliminating the need for multipliers or dividers, and relying solely on addition and customizable LUTs. This innovative method frees up FPGA resources typically consumed by power-intensive DSPs, offering a compelling low-power, low-latency alternative for diverse design needs.

1. Introduction

Modular reduction, expressed as $\left(a\right)$mod$\left(b\right)\equiv c$, is considered to be both one of the most computationally expensive basic-mathematical instructions, and one of the most important instructions in modern cryptography. In the simplest terms, modular reduction is the remainder of elementary integer division. From this definition, one could naively discern that calculating a modular congruence c requires division. This is easy to perform in software, as shown in Equation (1). The floor function can be replaced by integer division, depending on the software language used.

$$\left(a\right)\mathrm{mod}\left(b\right)\equiv c\equiv a-\lfloor {\displaystyle \frac{a}{b}}\rfloor$$

(1)

Unfortunately, since Equation (1) requires both a division and subtraction operation, this implementation is inefficient for both hardware and software [1]. Another naive approach, which can be quickly implemented in software, is shown in Algorithm 1. This algorithm implements a loop that will continue to reduce the input a until it is less than the modular base, b, returning the modular congruence c.

Algorithm 1 A naive software implementation of modular reduction.

1: $c \leftarrow a$ 2: while$c > b$do 3:    $c \leftarrow c - b$ 4: return c

This implementation presents two issues. The first problem with this implementation is that the number of iterations through the loop is directly related to how large the input a is. For cryptographic purposes, knowing the relative size of the input can be used to assist an attacker in decrypting encrypted data. Second, there is no defined upper-limit to the algorithm. This results in unpredictable latency, where the required iterations approach infinity as the input grows.

Within this work, we explore state-of-the-art methods for modular reduction, with an emphasis on the hardware requirements for the implementation of each. We argue that modern methods could be both faster and more power efficient, and present our own algorithm as a solution.

Our Hardware Optimized Modular Reduction (HOM-R) algorithm will have impacts in a variety of fields, as a wide breadth of topics rely on modular reduction. This includes fields that use a system of modular numbers, referred to as a Residue Number System (RNS). Specifically, however, we targeted our design for cryptography, as algorithms such as Homomorphic Encryption (HE) and Zero-Knowledge Proofs (ZKP) heavily utilize modular reduction, depending on the specific form of the algorithm used [2,3,4,5].

The HOM-R algorithm is also viable for other applications outside of cryptography, however. For example, Kalmykov et al. implemented a novel Error-Correcting Code using a Residue Number System (RNS), which relies heavily on modular arithmetic [6]. Valueva et al. applied the RNS to Convolutional Neural Networks (CNN) as a means to reduce the hardware cost of the machine learning model [7]. This application in AI for RNS is also seen in other works, including a multiplication-free neural network by Salamat et al. [8] and an ASIC implementation of an RNS-based CNN by Sakellariou et al. [9]. Other examples include an accelerator for probability models [10], intrusion detection systems [11], and new data storage methods for increased reliability [12].

As we will see in Section 2, modern approaches to modular reduction either rely on high-power resources, such as digital signal processors (DSPs), or have a high latency. Our motivation for this work is to achieve both low power and low latency. As we demonstrate in Section 5, our algorithm relies solely on bit shifts and a predictable number of additions, allowing us to avoid the use of DSPs whilst only requiring a single clock cycle of latency, even at high clock frequencies.

The rest of the paper is organized as follows: in Section 2, we cover other algorithms that are often used for modular reduction. In Section 3, we describe our algorithm and how to implement it based on use-case. In Section 4, we demonstrate the feasibility of our algorithm by implementing it on a Field Programmable Gate Array (FPGA). In Section 5, we discuss the implementation results of the HOM-R system. Finally, in Section 6, we conclude the paper.

2. Background

When describing modular reduction on hardware, there are two methods that must be considered. However, before we can consider those, there are some special cases where one would not opt for any of these methods. First, let us consider a common case of modular reduction: when the modular base b is a power of two (1, 2, 4, 8, etc.). Of course, for base two modular reduction, one can simply truncate the bit vector, as shown in Equation (2), where ‘&’ represents the bit-wise AND function, and ‘−’ represents the conventional integer subtraction. This method, when implemented in hardware, requires simple combinatorial logic that induces minimal latency and resource usage.

$$\left(a\right)\mathrm{mod}\left(b\right)\equiv c\equiv a\&(b-1)$$

(2)

The second method that can be used for special cases is when the modular base is not a power of two, and the input size is small. One can use a direct look-up table in hardware, or an array in software, to quickly find the modular congruence of the input. With $\left(a\right)\mathrm{mod}\left(b\right)\equiv c$, and $a<n$, this method requires n entries of $\lceil {log}_2\left(n\right)\rceil$ bits, leading to a total memory requirement of $n\lceil {log}_2\left(n\right)\rceil$.

For all other cases, prior to the introduction of the HOM-R system, one’s options for modular reduction include one of the three following algorithms: Montgomery reduction, Barrett reduction, or a more recent addition, a fast modular reduction method by Will et al. [13]. We will include Will’s method as it serves as the basis for our work.

While other options exist, we do not cover those implementations in-depth as they either have large memory/resource requirements depending on the input, or are sub-optimal for hardware due to the reliance on recursion. This includes work by Parhami et al., in which the authors explore segmentation and truncation within look-up tables for modular reduction [14]. Parhami et al. offers another work exploring the inverse of this operation: combining residues into a unified, binary representation [15]. Another work by Opasatian et al. also explores the use of look-up tables similar to Parhami, but their method requires an additional ’adjustment’ step that relies on subtraction. The principle behind this step is similar to that in Montgomery reduction, in that the computed value may be twice the value of the modulus [16]. Lim et al. offer a method for modular reduction that also relies on look-up tables; however, they implement their design in software [17]. Another method is the one by Cao et al., which offers a unique approach that evaluates a binary vector based on the longest run of 1 s and 0 s [18].

2.1. Mongtomery Reduction

Montgomery reduction [19] is one of the most commonly used modular reduction algorithms in modern hardware. The premise of the formula is to represent a residue class using a different modular base. Ideally, this new base is a power of two, which can then be reduced via the modular-base-two method listed above. The delay for Montgomery Reduction comes in play when changing the modular base. Because of this, a number’s base is often changed only once, where the new base representation, referred to as its Montgomery form, is used for all mathematical calculations. This way, any further modular reductions can be performed via the modular-base-two truncation method. Once a number has finished processing and does not require any more operations, its modular base can be converted back to the original, and the final congruence of the original number can be retrieved.

For $\left(a\right)\mathrm{mod}\left(b\right)\equiv c$, let $(R\in \mathbb{Z})>b$ where R is co-prime to b. R should be chosen so that $\left(a\right)\mathrm{mod}\left(R\right)$ is easy to compute; ideally, R should be a power of two. Further, let $b^{\prime }=b^{-1}\mathrm{mod}R$. The Montgomery reduction of input a can then be defined as Equation (3).

$$REDC\left(a\right)=\left(a{R}^{-1}\right)\mathrm{mod}\left(b\right)$$

(3)

Note that one subtraction of b may be required since $0\le REDC\left(b\right)<2b$. It is also important to note that Montgomery reduction only requires $k(k+1)$ multiplications. The number of multiplications required is not correlated to the size of the target number, which is not the case in the following algorithm, the Barrett reduction.

The Montgomery form allows for quick modulo operations where multiple numbers are multiplied or added together, as they can all be converted to the same residue class. Addition in Montgomery space is performed as with regular numbers; however, there is a small caveat to multiplying numbers in Montgomery space. Since two separate numbers in Montgomery space include a R factor, multiplication results in a $R^2$ term. This is an easy obstacle to overcome: since the Montgomery form relies on R being an integer that is a power of two, the result can be divided by a factor of R through a bit-wise right shift of $lo{g}_2\left(R\right)$ bits.

2.2. Barrett Reduction

Barrett’s method [20] is similar to Montgomery’s approach in that it requires the selection of a “magic number” that is relative to the modular base b. When implementing Barrett reduction, one must consider the word size L of the system, which depends heavily on whether a general purpose computer or specialized circuit, such as an FPGA, is used. Depending on the word size, a base $\beta$ must be chosen such that $\beta =2^L$. From $\beta$, we can calculate the required parameter in Equation (4), where $k=\lfloor {\log }_{b}p\rfloor +1$. There is the further limitation that a from $\left(a\right)\mathrm{mod}\left(b\right)\equiv c$ that $0\le a<{\beta }^{2k}$.

$$\mu =\lfloor {\displaystyle \frac{{\beta }^{2k}}{b}}\rfloor$$

(4)

If we assign $q=\lfloor {\displaystyle \frac{a}{b}}\rfloor$, then $a\mathrm{mod}b\equiv c\equiv a-qb$. From Equation (5), we can derive Equation (6).

$${\displaystyle \frac{a}{b}}={\displaystyle \frac{a}{{\beta }^{k-1}}}·{\displaystyle \frac{{\beta }^{2k}}{b}}·{\displaystyle \frac{1}{{\beta }^{k+1}}}$$

(5)

$$0\le \widehat{q}=\lfloor {\displaystyle \frac{\lfloor \frac{a}{{\beta }^{k-1}}\rfloor ·\mu }{{\beta }^{k+1}}}\rfloor \le \lfloor {\displaystyle \frac{a}{b}}\rfloor =q$$

(6)

If we precompute $\mu$, it is easy to see from Equation (6) that the main complexity in the Barrett reduction is caused by the multiplication of $\mu$. The residue c can be computed from this value as $c=a-\widehat{q}p+(\widehat{q}-q)b$, which involves at most two subtractions and three bit shifts.

2.3. Will’s Algorithm

The look-up tables reduction method proposed by Will et al. is a unique and attractive option for modular reduction when compared to Barrett’s and Montgomery’s methods, as it does not require a multiplication primitive [13]. Through a series of bit shifts and additions with precomputed numbers, Will’s method is able to reduce a number to a residue. The basic structure of the algorithm is defined in Algorithm 2, where bit vector width $\beta =\lceil lo{g}_2(a+1)\rceil$, the input vector is split into l-width-vectors, defined as $\widehat{s}=[{\sum }_{i=0}^{l-1}{a}_i{2}^i,\dots ,{\sum }_{i=0}^{l-1}{a}_{\beta -l+i}{2}^i]$, and N is defined as $N=length\left(\widehat{s}\right)-1$. In this Algorithm, and the others that follow, $n<<m$ indicates an integer n shifted left m times.

Algorithm 2 Will’s algorithm for modular reduction [13].
1:	$n\leftarrow N$
2:	while$n>0$do
3:	$T\leftarrow \widehat{s}\left[n\right]$
4:	for $i=\beta -1downto0$ do
5:	$T\leftarrow T<<1$
6:	while $(T\&2^{\beta })\ne 0$ do
7:	$T\leftarrow T\&(2^{\beta }-1)+\left(2^{\beta }\right)\mathrm{mod}b$
8:	$\widehat{s}[n-1]=\widehat{s}[n-1]+T$
9:	while $\widehat{s}[n-1]\&2^{\beta }\ne 0$ do
10:	$\widehat{s}[n-1]\leftarrow \widehat{s}[n-1]\&(2^{\beta }-1)+\left(2^{\beta }\right)\mathrm{mod}b$
11:	$n\leftarrow n-1$
12:	while $\widehat{s}\left[0\right]>b$ do
13:	$\widehat{s}\left[0\right]\leftarrow \widehat{s}\left[0\right]-b$
14:	return $\widehat{s}\left[0\right]$

The mod values in Algorithm 2 are precomputed and stored. Will also emphasizes that there can be a larger number of precomputed values, reducing the number of iterations in the for loop. These are stored in the look-up table, and the modified algorithm is shown as Algorithm 3. In this algorithm, $\delta$ is the width of the look-up table, with each value in the look-up table being calculated by Algorithm 4.

Algorithm 3 Will’s algorithm for modular reduction modified for a user defined modular look-up width $\delta$, and $\widehat{m}$ is defined in Algorithm 4 [13].
1:	$n\leftarrow N$
2:	$mask\leftarrow 0$
3:	for $i=\delta -1downto0$ do
4:	$mask\leftarrow mask+2^i$
5:	$mask\leftarrow mask<<\beta$
6:	while $n>0$ do
7:	$T\leftarrow \widehat{s}\left[n\right]$
8:	for $i=\beta -1downto0$ do
9:	$T\leftarrow T<<\delta$
10:	while $(T\&mask)\ne 0$ do
11:	$\widehat{i}=(T\&mask)>>\beta$
12:	$T\leftarrow T\&(2^{\beta }-1)+\widehat{m}\left[\widehat{i}\right]$
13:	$\widehat{s}[n-1]=\widehat{s}[n-1]+T$
14:	while $\widehat{s}[n-1]\&mask\ne 0$ do
15:	$\widehat{i}=(\widehat{s}[n-1]\&mask)>>\beta$
16:	$\widehat{s}[n-1]\leftarrow \widehat{s}[n-1]\&(2^{\beta }-1)+\widehat{m}\left[\widehat{i}\right]$
17:	$n\leftarrow n-1$
18:	while $\widehat{s}\left[0\right]>b$ do
19:	$\widehat{s}\left[0\right]\leftarrow \widehat{s}\left[0\right]-b$
20:	return $\widehat{s}\left[0\right]$

Algorithm 4 Modular value look-up tables generation with index width $\delta$ [13].

1: $\widehat{m}\leftarrow \left[0\right]\ast 2^{\delta }$ 2: for $i=0upto{2}^{\delta }$ do 3:       $d=i<<\beta$ 4:       $\widehat{m}\left[i\right]\leftarrow d\mathrm{mod}b$ 5: return $\widehat{m}$

From these algorithms, there are a few important things to consider. The first concern is that there is a memory complexity $\Theta \left(2^{\delta }\right)$, so the look-up table size must be determined with device and power constraints in mind, with the optimal $\delta$ value being 1. However, this must be a balanced decision, as a smaller look-up table width will require more bit shifts in Algorithm 3, increasing the latency of the system. Another point of note is the while loops do not have defined latency. This prevents a combinatorial implementation in hardware, as each iteration of the loop will need to be analyzed at the end of a clock cycle. This is a pain-point for latency. Further, it must also be considered that the summation of the look-up table values leads to a value that is larger than the defined index of $\widehat{m}$, resulting in undefined behavior. We evaluate these shortcomings and propose solutions in Section 3.

3. Methods

The design of the HOM-R system has a primary focus on low power usage. In terms of FPGAs or ASICs, this means reducing digital signal processors (DSPs), and keeping the FPGA Look-Up Table (LUT) usage to a minimum. We specifically use the abbreviation “LUT” to refer to the the logic resource utilized by the FPGA, and “look-up table” to refer to the $\widehat{m}$ and $\widehat{m^{\prime }}$ components required by the HOM-R system. By prioritizing resource utilization and power reduction, we are able to formulate an algorithm that results in zero DSPs and minimal LUTs regardless of the base used. We determine Will’s algorithm to be a good starting point for this objective, as it relies purely on additions and bitwise operations.

The primary issue with Will’s algorithm is the number of while loops, which are non-ideal for hardware implementations due to their unpredictable number of iterations. An ideal hardware implementation should focus on utilizing for loops, which have a constrained number of iterations. This allows for predictable latency, thereby allowing the use of combinatorial logic that can fit an entire loop within a single clock cycle. This is opposed to the while loop, which will require the condition to be evaluated based on the output of a circuit. This is only possible by calculating an iteration and re-evaluating the loop condition at the end of a clock cycle, leading to an entire clock cycle being used only for one a single iteration of the loop.

For our implementation of the HOM-R module to solve the equation $\left(a\right)\mathrm{mod}\left(b\right)\equiv c$, the following terminology will be used:

• Stage: Each input vector x of width $\Omega =\lceil lo{g}_2(a+1)\rceil$ will be split into stages of width $\omega$ to solve for a residue width $\beta =\lceil lo{g}_2(b+1)\rceil$. Each stage is represented as a $\widehat{s}$. The input vector is therefore transformed into an array of N stages, represented as $\Psi$, where $N=\lceil (\Omega -\beta )/\omega \rceil$. The calculation for $\Psi$ is shown in Equation (7).

  $$\Psi =[{\widehat{s}}_0,\dots ,{\widehat{s}}_{N-1}]=[\sum _{i=0}^{\beta -1}{a}_i{2}^i,\dots ,\sum _{i=\beta (N-1)}^{N\beta -1}{a}_{\Omega -\beta +i}{2}^i]$$

  (7)
• Base Stage: This is the least significant stage, stage zero. The final residue c will have a maximum width of the width of the modular base b, $\beta$ and will have exactly one stage remaining in $\Psi$, the base stage.
• Modular-Value Look-up Table (MLUT): The look-up table composed of modular values, calculated via Algorithms 5 and 6, and represented by $\widehat{m}$ with a depth $2^{\delta }$ and ${\widehat{m}}^{\prime }$ with a depth $2^{{\delta }^{\prime }}$, respectively. There are N different MLUTs, with each MLUT representing the modular values for different $\widehat{s}$. By utilizing an MLUT for each different stage, we can reduce each stage to the base stage in parallel.
• Overflow Bits: When summing values from $\widehat{m}$, it is possible that the width of the sum exceeds $\beta$. These bits are referred to as overflow bits.

A full description of the required parameters for HOM-R are outlined in

Table 1. Parameter definitions for HOM-R.

Parameter	Description
x	The input vector
b	Modular base
$\widehat{s}$	An individual reduction stage
$\Psi$	The collection of stages. When concatenated together, it is equivalent to x.
N	Number of stages
$\widehat{m}$	Modular value look-up tables
$\sigma$	Stage output after summing each respective $\widehat{m}$ for the stage
$\Omega$	Width of x
$\omega$	Width of the input to a stage
$\delta$	Width of the input to $\widehat{m}$
$\beta$	Maximum width of the residue output

.

Algorithm 5 HOM-R 2D modular value look-up table generation with index width $\delta$ and stage width $\beta$.

1: $\widehat{m}\leftarrow [\left[0\right]\ast 2^{\delta }]\ast (N-1)$ 2: for $i=0uptoN-1$ do 3:     for $j=0upto{2}^{\delta }$ do 4:           $d=j<<\left(\right(i+1)\ast \beta )$ 5:           $\widehat{m}\left[i\right]\left[j\right]\leftarrow d\mathrm{mod}b$ 6: return $\widehat{m}$

Algorithm 6 HOM-R 1D modular value look-up table generation for reducing $c=\mathrm{sum}\left(\sigma \right)$. Index width ${\delta }^{\prime }$ and stage width $\beta$.

1: $\widehat{m^{\prime }}\leftarrow \left[0\right]\ast 2^{{\delta }^{\prime }}$ 2: for $i=0upto{2}^{{\delta }^{\prime }}$ do 3:       $d=i<<\beta$ 4:       ${\widehat{m}}^{\prime }\left[i\right]\leftarrow d\mathrm{mod}b$ 5: return ${\widehat{m}}^{\prime }$

The full HOM-R algorithm is defined in Algorithm 7. Line 1 handles the simplest of cases, when the modular base class is an even power of two. In this case, we can simply truncate the input vector a to be the same length as the modular vector b to retrieve the residue c, saving precious hardware memory.

Algorithm 7 Hardware Optimized Modular Reduction Algorithm for $\left(a\right)\mathrm{mod}b\equiv c$.
1:	if $\lfloor {\log }_2\left(\mathrm{b}\right)\rfloor ==lo{g}_2\left(b\right)$ then return $a\&(b-1)$
2:	$N\leftarrow \lceil (\Omega -\beta )/\omega \rceil$
3:	$\sigma \leftarrow \left[0\right]\ast N$
4:	$\sigma \left[0\right]\leftarrow \Psi \left[0\right]$
5:	for $i=1uptoN$ do
6:	$\mathrm{idx}\leftarrow \Psi \left[i\right] \& (2^{\delta }-1)$
7:	$\sigma \left[i\right]\leftarrow \widehat{m}\left[i\right]\left[idx\right]$
8:	for $j=1upto\lceil \beta /\mathrm{ffi}\rceil$ do
9:	$\mathrm{idx}\leftarrow (\Psi \left[i\right]>>(j\ast \delta )) \& (2^{\delta }-1)$
10:	$\sigma \left[i\right]\leftarrow \sigma \left[i\right]+j\ast 2^{\delta }\ast \widehat{m}\left[i\right]\left[idx\right]$
11:	for $j=0upto\mathrm{NUM}\_\mathrm{SUMS}$ do
12:	$\mathrm{idx}\leftarrow \left(\sigma \right[i]>>\beta )$
13:	$\sigma \left[i\right]\leftarrow \sigma \left[i\right]+\widehat{m}\left[0\right]\left[idx\right]$
14:	$c\leftarrow \mathrm{sum}(œ)$
15:	for $j=0upto\mathrm{NUM}\_\mathrm{SUMS}$ do
16:	$\mathrm{idx}\leftarrow (c>>\beta )$
17:	$c\leftarrow c+{\widehat{m}}^{\prime }\left[idx\right]$
18:	if $c>b$ then
19:	$c\leftarrow \widehat{s}\left[0\right]-b$
20:	return c

The first loop in the system, Lines 3–10, breaks the input vector a into a series of $\widehat{s}$ that compose the array $\Psi$. For each $\widehat{s}$, we compute $\sigma$ according to the modular base b using Equation (8). While $\sigma$ is not the final residue c, it is congruent to the original $\widehat{s}$ relative to b and much smaller than s. We use this value to calculate the final residue c using the rest of the algorithm.

$$\begin{array}{c}\hfill f\left(x\right)=(\widehat{s}>>(x\ast \delta )) \& (2^{\delta }-1)<<\omega \\ \hfill \sigma =f\left(0\right)\mathrm{mod}\left(c\right)+\sum _{i=1}^{\lceil \omega /\delta \rceil }(i\ast 2^{\delta })\ast \left(f\left(i\right)\mathrm{mod}\left(c\right)\right)\end{array}$$

(8)

To help demonstrate how Equation (8) may be implemented for a four-bit $\widehat{s}$ with a stage index s in $\Psi$, composed of bits $b_3{b}_2{b}_1{b}_0$ with a $\delta =2$, we present Equation (9). As shown in Equation (9), this function is merely shifting the vector $\widehat{s}$ left by two bits, isolating two bits at a time, and calculating the residue for each. Since there are four bits in $\widehat{s}$, the vector must be shifted twice. Each shift is equivalent to multiplying by four. We move these factors of four inside or outside the $\widehat{m}$ lookup depending on the location of the bits in the vector $\widehat{s}$.

$$\begin{array}{c}\hfill \sigma =(4\ast 4\ast b_1{b}_0)\mathrm{mod}\left(c\right)+4\ast (4\ast b_3{b}_2)\mathrm{mod}\left(c\right)\\ \hfill =\widehat{m}[s-1]\left[b_1{b}_0\right]+4\ast \widehat{m}[s-1]\left[b_3{b}_2\right]\end{array}$$

(9)

We prove that we can use the bits in $\widehat{s}$ as an index to $\widehat{m}$ in Equation (8) via Lemmas 1–3. Lemma 1 allows us to prove Lemmas 2 and 3. Lemma 2 proves that the bit vectors can be operated on as a sum of the bits, rather than as the entire vector. Lemma 3 demonstrates that the vector can be shifted (multiplied by a power of two), regardless of whether the factor of two is used to compute the modular residue or operate on the modular residue.

Lemma 1.

For $a,b,c,k\in \mathbb{Z},\left(a\right)\mathrm{mod}\left(b\right)\equiv c,\exists k\in \mathbb{Z}$ such that $c=a+kb$.

$$\begin{array}{c}\hfill \mathrm{From}\mathrm{definition}\mathrm{of}\left(a\right)\mathrm{mod}\left(b\right)\equiv c,b\left|\right(a-c)\\ \hfill \mathrm{From}\mathrm{definition}\mathrm{of}{\displaystyle \frac{a-c}{b}},kb=a-c\\ \hfill \therefore c=a+kb.\end{array}$$

Lemma 2.

For $a,b,c,d,m,k,j\in \mathbb{Z},\mathrm{if}a+c\equiv (b+d)\mathrm{mod}m,\mathrm{then}a\equiv b\mathrm{mod}m\mathrm{and}c\equiv d\mathrm{mod}m.$

$$\begin{array}{c}\hfill \mathrm{From}\mathrm{Lemma}1,a+c=(b+d)+(k+j)m\\ \hfill a+c=b+km+d+jm\end{array}$$

$$\begin{array}{c}\hfill \therefore a=b+km\\ \hfill c=d+jm\end{array}$$

Lemma 3.

For $a,b,c,m\in \mathbb{Z},a\left[\right(bc\left)\mathrm{mod}m\right]\equiv \left(ab\right)\left(c\mathrm{mod}m\right).$

$$\begin{array}{c}\hfill \mathrm{From}\mathrm{Lemma}1,\mathrm{l}.\mathrm{h}.\mathrm{s}.\equiv abc+akm\\ \hfill \mathrm{r}.\mathrm{h}.\mathrm{s}.\equiv abc+abjmabc+akm\equiv abc+abjm\\ \hfill \mathrm{Assign}x=abc\\ \hfill x+akm\equiv x+abjm\\ \hfill \therefore \mathrm{Congruent}\mathrm{via}\mathrm{definition}\mathrm{from}\mathrm{Lemma}1.\end{array}$$

For the second inner loop in Algorithm 7, we account for overflow bits in $\sigma$. It is important to note that there can be at most $\delta$ overflow bits. Therefore, if the number of overflow bits exceeds $\delta$, then the corresponding lookup value will be undefined. This is a failure condition that must be avoided. There are potential conditions that may fail this part of the loop, resulting in undefined behavior.

All possible valid values were pre-calculated via an iterative search for combinations $\delta \in [1,18]$ and $\omega \in [1,18]$. We noticed that for this range, valid values of $\delta$ relative to a user chosen $\sigma$ must satisfy $\delta \ge \lceil {\displaystyle \frac{\omega }{2}}\rceil$. We extend this to all possible values of $\sigma$ and $\delta$ in Lemma 4. These combinations guarantee that any modular base with width $\omega$, used with the corresponding $\delta$, will not face the overflow condition described above. By utilizing a for loop with a guaranteed number of iterations, we can utilize a predetermined amount of combinatorial logic within the HOM-R module, allowing for single clock-cycle computations.

Line 13 in Algorithm 7 sums up all values of $\sigma$, storing the sum in c. This sum is then used to compute the maximum value of $c+b$ with lines 15–17. It is important to note that the width of sum($\sigma$) must not exceed ${\widehat{m}}^{\prime }$, as this will result in undefined behavior. There can be a maximum of $2^{{\delta }^{\prime }}$ addends in line 10, as more than this will overflow ${\widehat{m}}^{\prime }$. Therefore, ${\delta }^{\prime }$ must be greater than or equal to $\lceil {\log }_2(N+1)\rceil$. Of course, more bits than necessary will result in a larger circuit, increasing the power draw and space unnecessarily. So, while a ${\delta }^{\prime }$ larger than $\lceil {\log }_2(N+1)\rceil$ is possible, it is recommended to use ${\delta }^{\prime }=\lceil {\log }_2(N+1)\rceil$.

Lemma 4.

For ${log}_2(\sigma +1)\le \omega +\delta$ if $\delta ,\omega ,c\in {\mathbb{Z}}_{\ne 0}^{+},\lceil {\displaystyle \frac{\omega }{2}}\rceil \le \delta \le \omega ,\max \left(c\right)=2^{\delta }-1,\sigma =f\left(0\right)\mathrm{mod}\left(c\right)+{\sum }_{i=1}^{\lceil \omega /\delta \rceil }(i\ast 2^{\delta })\ast \left(f\left(i\right)\mathrm{mod}\left(c\right)\right).$

$$\begin{array}{c}\hfill \mathrm{Evaluate}f\left(i\right)\mathrm{mod}\left(c\right)\mathrm{at}\mathrm{the}\mathrm{largest}\mathrm{value},\\ \hfill \sigma =f\left(0\right)\mathrm{mod}\left(c\right)+\sum _{i=1}^{\lceil \omega /\delta \rceil }(i\ast 2^{\delta })\ast \left(f\left(i\right)\mathrm{mod}\left(c\right)\right)\\ \hfill \max \left(\mathrm{mod}\right(c\left)\right)=\max (c-1,0)\\ \hfill \therefore \max \left(f\left(i\right)\mathrm{mod}\left(c\right)\right)=\max (2^{\delta }-2,0)\\ \hfill \therefore \max \left(\sigma \right)=\max (2^{\delta }-2,0)+\sum _{i=1}^{\lceil \omega /\delta \rceil }(i\ast 2^{\delta })\ast \max (2^{\delta }-2,0).\end{array}$$

$$\begin{array}{c}\hfill \left(\mathrm{A}\right)\mathrm{Evaluate}\mathrm{at}\mathrm{maximum}\mathrm{boundary}\delta =\omega \\ \hfill \sigma =2^{\delta }-2+\sum _{i=1}^1(i\ast 2^{\delta })\ast (2^{\delta }-2)\\ \hfill \sigma =2^{\delta }-2+\left(2^{\delta }\right)(2^{\delta }-2)\\ \hfill \sigma =2^{2\delta }-2^{\delta }-2\\ \hfill \to {log}_2(2^{2\delta }-2^{\delta }-1)\le 2\delta \\ \hfill 2^{2\delta }-2^{\delta }-1\le 2^{2\delta }\\ \hfill -2^{\delta }\le 1\\ \hfill \left(\mathrm{B}\right)\mathrm{Evaluate}\mathrm{at}\mathrm{minimum}\mathrm{boundary}\delta =\lceil {\displaystyle \frac{\omega }{2}}\rceil ,\omega =1\therefore \delta =1\\ \hfill \mathrm{l}.\mathrm{h}.\mathrm{s}.={\log }_2(1+\max (2^{\delta }-2,0)+\sum _{i=1}^2(i\ast 2^{\delta })\ast \max (2^{\delta }-2,0)\\ \hfill ={\log }_2(1+0+({\displaystyle 2^{{\displaystyle \frac{\omega }{2}}}})\left(0\right)+(2\ast 2^{{\displaystyle \frac{\omega }{2}}})\left(0\right))\\ \hfill \mathrm{Evaluate}\mathrm{B}\mathrm{at}\omega =1\\ \hfill {\log }_2\left(1\right)\le {\displaystyle \frac{3}{2}}\\ \hfill 0\le {\displaystyle \frac{3}{2}}\\ \hfill \mathrm{From}\mathrm{A}\left)\mathrm{and}\mathrm{B}\right),\\ \hfill {\log }_2(\sigma +1)\le \omega +\delta .\end{array}$$

Lemma 5.

For $\lceil {\log }_2(x+y+1)\rceil \ge \lceil {\log }_2(y+1)\rceil$ if $x,y\in {\mathbb{Z}}_{\ne 0}^{+}$ and $\lceil {\log }_2(x+1)\rceil =\lceil {\log }_2(y+1)\rceil$.

$$\begin{array}{c}\hfill \lceil {\log }_2(x+y+1)\rceil =\lceil {\log }_2(x(1+{\displaystyle \frac{y}{x}}+{\displaystyle \frac{1}{x}})))\rceil \\ \hfill =\lceil {\log }_2\left(x\right)+{\log }_2(1+{\displaystyle \frac{y+1}{x}})\rceil \\ \hfill \mathrm{Evaluate}{\log }_2(1+{\displaystyle \frac{y+1}{x}})\mathrm{at}\mathrm{minumum}\\ \hfill \to {\log }_2{\log }_2(1+{\mathbb{R}}_{\ne 0}^{+})\\ \hfill \lceil {\log }_2\left(x\right)+{\log }_2(1+{\mathbb{R}}_{\ne 0}^{+})\rceil \ge \lceil {\log }_2(x+1)\rceil \\ \hfill \therefore \lceil {\log }_2\left(x\right)+{\log }_2(1+{\mathbb{R}}_{\ne 0}^{+})\rceil \ge \lceil {\log }_2(y+1)\rceil \\ \hfill \therefore \lceil {\log }_2(x+y+1)\rceil \ge \lceil {\log }_2(y+1)\rceil .\end{array}$$

The first part of the algorithm, Lines 1–17, reduce $\Psi$ to the single $\widehat{s}$ base stage. According to the constraints from the algorithm, the base stage will have the same width as the modular base b. Therefore, $0\le \Psi \left[0\right]<2b$. From Lemmas 5 and 6, we can conclude that either $\widehat{s}\left[0\right]\le b$ or $\widehat{s}\left[0\right]-b<b$ must be true. This reduces the while loop in Algorithm 1, Lines 18–19, to a single if statement. We can therefore determine that an input vector of width $\beta =\Omega$ is at most a single subtraction from being the residue $\left(a\right)\mathrm{mod}\left(b\right)\equiv c$. The final result is the residue $c\equiv \left(a\right)\mathrm{mod}\left(b\right)$.

Lemma 6.

For $\lceil {\log }_2(x-y+1)\rceil \le \lceil {\log }_2(y+1)\rceil$ if $x,y\in {\mathbb{Z}}_{\ne 0}^{+},x>y,$ and $\lceil {\log }_2(x+1)\rceil =\lceil {\log }_2(y+1)\rceil$.

Proof. 

$$\begin{array}{c}\hfill \lceil {\log }_2(x-y+1)\rceil =\lceil {\log }_2(x(1-{\displaystyle \frac{y}{x}}+{\displaystyle \frac{1}{x}})))\rceil \\ \hfill =\lceil {\log }_2(x)+{\log }_2(1+{\displaystyle \frac{1-y}{x}})\rceil \\ \hfill \mathrm{Evaluate}{\log }_2(1+{\displaystyle \frac{1-y}{x}})\mathrm{as}\\ \hfill \to {\log }_2(1+{\displaystyle \frac{1-y}{x}})\in -\infty <\mathbb{R}<0\\ \hfill \to \lceil {\log }_{2}x\rceil \le \lceil {\log }_2(x+1)\rceil \\ \hfill \therefore \lceil {\log }_2(x-y+1)\rceil \le \lceil {\log }_2(y+1)\rceil \end{array}$$

□

4. Implementation

We implemented our modular reduction system on an FPGA, and tested various configurations to compare area usage, power consumption, and resource requirements. The full implementation of the HOM-R system relies on internal sub-modules to reduce the individual stages of the input $\Psi$ to the base stage. Each stage has an input of $\beta$ bits, and an output of $\beta$ bits. The stage-reduction module encompasses Lines 6–13 in Algorithm 7, and is replicated $N-1$ times within the HOM-R system. For the example illustrated within this section, we demonstrate a four-stage HOM-R implementation for $x[15:0]\mathrm{mod}\left(14\right)\equiv y$ with $\beta =4$ and $\delta =2$. A close-up for $\Psi \left[1\right]$ is shown in Figure 1, showcasing the hardware implementation for Lines 6–10 in Algorithm 7.

It is important to note that the same $\widehat{m}$ is replicated in the sub-module. This is illustrated within the dotted-line box in Figure 1. While this requires an increase in resources, it allows the system to operate on the stage splits in parallel. The alternate option is to instead iterate each stage through $\widehat{m}$, at one stage per clock cycle, which we determined to be too expensive.

Since each stage split is reduced to the base-stage, we must sum them together, as in Lines 11–13 of Algorithm 7. This was proven possible in Lemma 2. Similar to the first stage-reduce module, this step is completed with combinatorial logic, reducing the latency of the system. An iterative method was used to find the number of maximum required additions to reduce the width of the sum to $\beta$. The method yielded that a maximum of two additional addition steps following the original summation of the $\widehat{m}$ outputs will always be enough to reduce the width to $\beta$. We illustrate the second half of the stage-reduce module in Figure 2 for $x[15:0]\mathrm{mod}\left(14\right)\equiv y$ with $\beta =4$ and $\delta =2$.

These two series of combinatorial logic result in the full stage-reduce module, shown in Figure 3. We place an optional stage register between the output of the stage-reduce module and the output of the full HOM-R system to help with timing for either high-frequency or large-input systems. However, for all of the values tested within this paper, we did not need to rely on the optional register and therefore removed it from our system.

The stage-reduce module must be replicated $\lceil {\displaystyle \frac{\Omega -\beta }{\omega }}\rceil$ times within the modular reduction module. This replication implements Line 4 of Algorithm 7, and allows us to operate on each stage split in parallel. This results in a significant reduction in latency, fitting multiple loops of the algorithm within a single clock cycle. The replication of stage splits is shown in the full hardware implementation of HOM-R in Figure 4. We also show the optional summation register, which, if enabled in the design, will register the output for the first summation only. This provides a significant improvement in timing for high-operating-frequency systems.

The output of each stage-reduce module must be summed together and reduced, similar to the logic within the stage reduce module. The primary difference is that the size of the look-up table for the reductions, ${\widehat{m}}^{\prime }$, is $\lceil {\log }_2(N+1)\rceil$ rather than the user defined $\delta$. In our example, we use four splits, which results in an $\widehat{m}$ depth of two, as shown in Figure 4.

Once the base stages of the input have been summed and the output reduced to the width of $\beta$, we can ensure that the value is at most $2b$ from Lemmas 5 and 6. We can therefore subtract the modular base b from the input. If there is an asserted overflow bit, then we can ensure that the sum is less than b, and we can accept it as the residue. If there is no overflow bit, then we can be assured that the sum is greater than or equal to b, and we accept the difference as the residue b.

5. Results

Typically, for conventional place and route tool flows utilized by standard applications such as Vivado by AMD or Quartus by Intel, a look-up table for each bit of an output vector is generated depending on a user defined funciton. In this case, that function would be modular reduction. We compare the HOM-R system against this conventional method utilized by Vivado.

For testing, we used a 64-bit vector input with a 150 MHz clock rate. This clock rate was chosen as it was the fastest clock that the conventional method could use before violating timing constraints. Further, since the resource requirements for modular arithmetic depend heavily on the modular base, we tested three different bases for $\beta =32$ and $\beta =16$. For the HOM-R implementation tested, we used $\delta =\omega =8$, and disabled all of the registers in the system. This allowed for the conventional method and the HOM-R system to have the same latency. These results are shown in

Table 2. The conventional modular reduction method compared against the HOM-R system, tested at a clock rate of 150 MHz. For the HOM-R system, $\delta =\omega =8$.

Method	Base	CLBs	LUTs	WNS	Power
HOM-R	0xC53A49B2	131	732	0.377 ns	40 mW
Conventional	0xC53A49B2	172	1126	0.064 ns	51 mW
HOM-R	0xF12E33D6	133	713	0.349 ns	40 mW
Conventional	0xF12E33D6	190	1250	0.017 ns	53 mW
HOM-R	0xAF0C59E5	139	743	0.184 ns	43 mW
Conventional	0xAF0C59E5	177	1190	0.049 ns	54 mW
HOM-R	0xA43C	106	525	1.234 ns	15 mW
Conventional	0xA43C	165	969	0.474 ns	25 mW
HOM-R	0xE127	106	535	1.194 ns	15 mW
Conventional	0xE127	138	951	0.321 ns	27 mW
HOM-R	0x894C	101	520	0.970 ns	15 mW
Conventional	0x894C	135	987	0.190 ns	25 mW

.

It is clear from the table that the HOM-R implementation offers significant improvements over the conventional method for modular reduction. For all test cases, the HOM-R method used an average of 30% less power, 27% fewer configurable logic blocks (CLBs), and 42% fewer LUTs. Further, despite these reductions in power and resources, the HOM-R method showed significantly better timing margins, allowing for a higher maximum operating frequency.

Next, we compare multiple combinations of $\omega$ and $\delta$ for $\Omega =32, \beta =16$ in

Table 3. Results from various configurations of $\omega$ and $\delta$. For this test, $\Omega =32,\beta =16$, and the modular base is 0xF7E3.

$\mathit{\omega }$	$\mathit{\delta }$	CLBs	LUTs	Registers	WNS	Power
2	1	48	183	18	0.040 ns	7 mW
2	2	36	139	16	1.237 ns	5 mW
4	2	45	187	16	0.369 ns	6 mW
4	4	33	136	16	1.562 ns	5 mW
8	4	33	143	16	1.274 ns	6 mW
8	8	39	172	24	2.207 ns	5 mW
16	8	39	273	24	1.078	7 mW

. These tests were run at a clock rate of 150 MHz, with the main limiting test case being $\omega =2$, $\delta =1$. For each value of $\omega$, it is apparent that $\delta =\omega$ is the most resource and power friendly. However, this is not always an option, as $\omega =\delta =16$ results in a LUT that has $2^{16}$ values, which is too large to be synthesized by Vivado. Based on the results in Table 3, it appears best to use $\omega =\delta =8$, however, this is likely due to the configuration of the CLBs for the Kintex UltraScale+ device, and may vary from device family to family.

We also compared the usage of the various registers in the system. For this test, we used $\Omega =64,\omega =8,\delta =8$, and a clock rate of 150 MHz. One would utilize these registers for high-frequency systems. Refer to Figure 3 and Figure 4 for the location of the summation and stage registers. For each register enabled in the system, an extra clock cycle is added to the overall latency.

One can see from

Table 4. Results from various configurations of $\omega$ and $\delta$. For this test, $\Omega =32,\beta =16$, and the modular base is 0xF7E3.

Register En.	CLBs	LUTs	Reg.	WNS	Power
None	131	732	56	0.377 ns	40 mW
Sum	114	673	91	2.516 ns	39 mW
Stage	135	732	202	1.053 ns	41 mW
Stage + Sum	119	673	247	2.822 ns	41 mW

that the summation register has the greatest effect on the system, offering the most relaxed timing margins between the two optional registers. Further, this also offers lower power usage, even when compared to the configuration that does not rely on either register. This is likely due to optimizations performed by the Place and Route Engine, as extra resources are added in the case where no registers are enabled so as to meet the strict timing requirements. To further relax timing constraints, one can utilize both the stage output register and the summation register. This adds two clock cycles of latency, but can be essential for large modular reductions that must operate at high frequencies.

The final test that we conducted on the HOM-R system evaluated $\Omega$ against $\beta$, as shown in

Table 5. Results from various configurations of $\omega$ and $\delta$. For this test, $\Omega =32,\beta =16$, and the modular base is 0xF7E3.

$\Omega$	$\mathit{\beta }$	CLBs	LUTs	Registers	WNS	Power
16	4	6	20	0	2.379 ns	<1 mW
16	8	13	58	5	1.600 ns	4 mW
16	12	7	15	0	2.994 ns	<1 mW
32	4	3	27	0	1.961 ns	<1 mW
32	8	27	131	8	0.806 ns	8 mW
32	12	128	770	42	0.552 ns	17 mW
64	4	11	85	0	1.497 ns	7 mW
64	8	54	341	40	0.243 ns	19 mW
64	12	480	2806	481	−0.466 ns	56 mW
128	4	29	167	0	0.996 ns	9 mW
128	8	94	619	104	0.012 ns	26 mW
128	12	1131	6536	902	−1.916 ns	108 mW
256	4	73	505	0	0.384 ns	17 mW
256	8	186	1264	102	−0.063 ns	49 mW
256	12	2594	14061	119	−2.965 ns	210 mW

. For each test, we used a value of $\beta =\omega =\delta$ at a clock rate of 250 MHz. While not every iteration passed timing, we included failing iterations for comparison with those test iterations that did pass timing.

It can be determined from the table that an increasing $\Omega$ leads to both a linear increase in resource usage and power consumption. This is expected, because a larger input will require more logic to reduce it to the predetermined $\beta$. Further, it can also be concluded that an increase in $\beta$ directly results in an increase in power consumption, resource usage, and harsher timing requirements. The failing cases in the table could be remedied with the enabling of registers, as in Table 4.

6. Conclusions

In this paper, we presented a new method for modular reduction that is optimized for hardware. Using a calculated number of reduction cycles, we can use combinatorial logic to reduce large input vectors down to a modular base. Our results show an average of 30% less power usage, 27% fewer CLBs, and 42% fewer LUTs than the conventional method for modular reduction used by Vivado. Further, the HOM-R implementation allows for more relaxed timing requirements, and is able to reduce a 256-bit number down to a four-bit base in a single 250 MHz clock cycle.

Our design also allows for the implementation of registers at multiple stages in the reduction algorithm, enabling the design to be used in systems with high click frequencies. We showed that even with the implementation of these registers, there are only negligible increases in power consumption and resource utilization, while significant gains are offered in terms of timing requirements.

Moreover, we offer a significant contribution over other popular modular reduction methods, such as Barrett and Montgomery reduction, in that we do not require any multipliers or dividers. Our algorithm is implemented using only simple addition and LUTs with variable sizes, determined by the user’s timing and resource requirements. This improvement is significant, as multiplication and division require DSPs, which are both limited and power hungry on devices such as FPGAs. By removing these requirements, we free up resources for designs that require them, and offer a low-power, low-latency alternative.