Multi-Level Optimization Strategies for FPGA-Based Mixcolumn and Linear Diffusion Layers: A Survey

Table 1. Specific research questions for a survey literature review

Figure 1. Framework of the review objectives for analyzing and classifying FPGA-based MixColumn and diffusion-layer optimization techniques

The survey conducts a complete and fair evaluation through duplicable research design which studies all MixColumn and diffusion-equivalent implementation methods for lightweight cryptography on FPGAs. The paper follows IEEE survey guidelines to create a synthesis of different approaches instead of performing a meta-analysis which would unite results from different system implementations according to the study [20]. Review methodology process shown in Figure 2.

Improving the execution speed and implementation efficiency of AES-like and lightweight ciphers on FPGA largely determined by optimizing their linear diffusion layer, MixColumn in AES, or diffusion-equivalent linear layers (often MDS-based) in lightweight permutations and ciphers. This is because diffusion dominates either (i) finite-field constant multiplication cost and XOR-network depth, or (ii) routing and LUT-packing pressure when mapped onto FPGA fabrics. Consequently, the literature offers a sequence of methodologies that trade off area (LUT/slices), Fmax, latency (cycles), and throughput, with significant variation in benchmarking assumptions and reporting completeness as shown in Tables 4-6.

Based on the descriptions of each step outlined in the study [30], it can be deduced that the most mathematically demanding and time-intensive phase of AES is the mixed column stage. The primary reason for this is the engagement of multiplication inside the Galois field domain via the Maximum Distance Separable (MDS) matrix. An increase in the time required for encryption may enhance the likelihood of successfully compromising the algorithm. Enhancing the execution speed of lightweight algorithms may therefore decrease the probability of their compromise. This may be accomplished by minimizing the time required for the mix column phase. In this section elaborates a few of the techniques and also their limitations by classifying these techniques based on their optimization.

5.1 Arithmetic-level optimization

Major methodology class implements MixColumn multiplication through finite-field arithmetic engineering as shown in Table 4. The study [1] treat MixColumn as a GF (2^8) multiplication problem and focus on the hardware realization of the required field operations (constant multiplications and reductions). Similarly, “minimized MixColumn” architectures in AES propose simplified arithmetic datapaths or reduced logic for the GF operations to reduce area/latency [31]. However, arithmetic-heavy designs often encounter increased depth and routing pressure when barrel shifters, reduction networks, or wide XOR trees are inserted, which can be detrimental to post-route Fmax even if gate counts appear reduced analytically-an issue that becomes visible when designs target FPGA timing closure rather than only functional correctness [1, 31], some works replace the standard MixColumns multiplication structure with an alternative arithmetic primitive. Although arithmetic-level optimizations can reduce the computational complexity of MixColumn operations, they may also increase routing congestion and critical-path depth due to large XOR networks and reduction logic. As a result, some designs achieve lower area but suffer from reduced Fmax and timing efficiency after FPGA implementation. Therefore, improving arithmetic complexity alone does not always guarantee better overall hardware performance.

The study [32] evaluate two approaches for computing AES MixColumns on Cyclone-IV devices, including a more parallelized signal organization, motivated by MixColumns being a computational hotspot in the Datapath, where the objective is to expose area-speed trade-offs across different MixColumns realizations rather than proposing a single universally optimal form.

As shown in Table 4, the study [2] propose a modified MixColumns block using a Vedic-multiplier-based approach and report reduced LUT/slice usage and reduced delay versus a conventional design, demonstrating that multiplier style selection can shift the area–timing balance even when the MixColumns matrix remains unchanged. This methodology is particularly relevant when a baseline arithmetic realization becomes routing- or depth-limited: rather than only restructuring XOR networks, the work changes the multiplication micro-primitive that drives the diffusion Datapath. In lightweight hash permutations where diffusion resembles MixColumns-style matrix operations, several works adopt a lookup-driven methodology to reduce the cost of intensive GF multiplications.

In the study [5], where the implementation reduces intensive MixColumns computation through LUT-based techniques and optimized round scheduling. In AES-focused MixColumns, the fundamental approach executes constant-field multiplication and modular reduction over GF(2^8), resulting in a combinational network that is sensitive to XOR depth and routing, the performance improvement in these designs is mainly achieved by replacing complex GF(2^8) arithmetic operations with LUT-based computation and optimized scheduling techniques, which reduce combinational complexity and shorten critical paths. The study [2] explicitly targets this bottleneck by proposing a modified MixColumns implementation where multiplication is carried out using a Vedic multiplier methodology (Urdhwa Tiryakbhyam), replacing typical shift/XOR (and associated shifters) with a structured multiplication approach intended to improve performance and efficiency. This is conceptually aligned with the general trend that treats MixColumns as a “multiplier design problem,” where the diffusion layer is optimized by rethinking how constant multiplications are realized in hardware rather than merely re-coding the textbook equations [2]. The improvement achieved by the Vedic multiplier approach is mainly related to the reduction of arithmetic complexity and more structured data processing, which helps decrease delay and improve hardware efficiency. However, the effectiveness of this method may depend on the target FPGA architecture, since complex multiplier structures can still introduce routing overhead and additional hardware utilization in large-scale implementations.

A complementary, more architecture-driven viewpoint emerges from the improved bit-sliding technique proposed for low-latency and low-area implementations across multiple ciphers, including AES, SKINNY, and GIFT [14]. Instead of introducing new field-multiplication arithmetic, this approach relies on a structural principle: when diffusion or diffusion-equivalent linear layers are implemented in highly serialized datapaths, data movement and scheduling, such as how bits or columns are shifted and combined over cycles, become as important as the arithmetic itself. In this sense, the method addresses a limitation implicitly present in multiplier-heavy solutions, such as the Vedic-multiplier-based MixColumns design [2]: even if the multiplication primitive is optimized, the overall design may still lose efficiency when the surrounding dataflow requires expensive shifting or buffering, or when it creates unbalanced critical paths.

Thus, the Vedic-multiplier-based MixColumns design and the improved bit-sliding technique represent two distinct but related directions: compute-primitive optimization and dataflow/scheduling optimization, respectively [2, 14]. Both directions aim to reduce the practical cost of diffusion in FPGA or serial architectures. For LED and PHOTON, the diffusion layer is typically an MDS-based linear transformation applied at nibble granularity and is commonly described through MixColumns-like operations. Several studies indicate that efficient implementation of this mixing step is critical because it can dominate area and timing when realized naively. This point is illustrated by the FPGA implementation of PHOTON, where the diffusion step is implemented as MixColumns Serial and involves constant multiplications in a smaller finite field [33]. Similarly, MixColumns-style implementation choices for LED/PHOTON show that compact architectures are often achieved through careful serialization and FPGA-friendly primitives rather than wide parallel multipliers [5, 18].

The SKINNY family specification defines its diffusion layer explicitly as MixColumns. Unlike AES, however, this transformation is based on a binary matrix and is typically implemented as XOR combinations of state rows or columns, which makes the multiplication bottleneck substantially lighter than AES-style GF(2^8) arithmetic [34]. This structural property shifts the main optimization focus toward architecture-level organization, including serialization, memory mapping, and state-update scheduling, rather than heavy arithmetic optimization. A representative FPGA implementation follows this direction by adopting a column-serial structure to accelerate SKINNY while maintaining low area cost, and by optimizing the S-box through embedded dual-port block memory to reduce logic utilization [6]. Therefore, in SKINNY, the diffusion layer is not difficult because of field multipliers; instead, the key design challenge is coordinating ShiftRows and MixColumns under tight area constraints without causing severe throughput degradation. Serial or column-wise organizations are natural solutions to this problem, although they may reduce throughput because operations are distributed across multiple clock cycles to maintain low area consumption [6].

For AES, another optimization direction reformulates MixColumns and InvMixColumns as fine-grained Boolean functions that can be mapped directly onto FPGA LUT primitives [19]. This approach shifts the optimization problem from XOR-tree arithmetic to LUT-level computation. By combining this representation with a MATLAB-based pre-synthesis stage involving algebraic simplification and shared-subexpression extraction at the GF(2^8) polynomial level, the design reduces redundant logic and narrows the latency gap between encryption and decryption, where InvMixColumns is usually more expensive [19]. Another strategy optimizes AES MixColumns through involutory MDS matrices, in which the diffusion matrix is reformulated to satisfy the involutory property, meaning that the matrix is equal to its own inverse [35]. This reduces implementation asymmetry between encryption and decryption and can improve hardware efficiency.

5.2 Architectural optimization

Another recurring methodology treats MixColumns optimization as a system-level throughput problem rather than a local multiplier problem, as summarized in Table 5. An AES design based on eight-stage parallel computation parallelizes both SubBytes and MixColumns, achieving very high throughput at the cost of increased area, which reflects an explicit throughput–area trade-off [27]. A similar system-level direction is found in high-throughput AES-128 designs that combine loop unrolling and multi-level pipelining, where MixColumns is engineered not as an isolated faster multiplier but as a stage that must be balanced within a deeply pipelined round datapath [36]. The resulting throughput improvement is mainly obtained through parallel processing, loop unrolling, and deep pipelining, which allow multiple operations and rounds to execute simultaneously. However, these techniques increase hardware resource utilization because of replicated logic blocks and additional pipeline registers, leading to higher area consumption and power overhead [37].

For LED, implementation studies that compare different MixColumns granularities, such as 4-bit and 8-bit datapaths, show that datapath width directly reshapes the area–speed balance [28]. These results further confirm that MixColumns realization is a key factor in the overall area–performance trade-off rather than a purely local arithmetic issue. When LED is benchmarked alongside lightweight ciphers such as SIMECK, compact resource usage, throughput, and implementation efficiency also show that diffusion cost must be interpreted within the full cipher architecture [28].

Scheduling-centric optimization provides another important direction. Bit-sliding techniques applied to AES, SKINNY, and GIFT target both low latency and low area through bit-serial scheduling and technology-aware evaluation [10]. This methodology differs from pure LUT-based or XOR-minimization approaches because it treats diffusion as a time-distributed operation performed incrementally. Such an approach can be advantageous under severe area constraints, although the increased number of cycles requires careful interpretation of throughput. Instead of modifying MixColumns arithmetic or finite-field computations, this strategy optimizes hardware architecture and data movement inside the pipeline. Techniques such as bit-sliding, swap-and-rotate operations, pipelined state/key storage, and optimized scheduling allow one round to be executed in exactly 128 clock cycles with reduced latency and improved throughput [10].

A further group of studies focuses on full-core FPGA benchmarking of lightweight ciphers, where diffusion is embedded as part of the round transformation. The FPGA implementation of mCrypton reports area, maximum frequency, throughput, and power metrics, enabling energy-aware analysis rather than frequency-only comparison [9]. PRINCE implementations on Virtex boards emphasize throughput and efficiency, while FPGA implementations of PRIDE and PRESENT for IoT environments report area, speed, power, and energy measurements [18, 19]. These works are useful for survey-level analysis because they shift the discussion beyond raw throughput toward architectural-level and platform-level optimization.

The multi-cipher bit-sliding methodology provides an especially direct comparator for SKINNY because the same serialization principle is applied to AES, SKINNY, and GIFT under low-area and low-latency objectives [14]. This creates a useful bridge between AES-style and XOR-linear diffusion families: in AES, the main bottleneck is often finite-field multiplication, whereas in SKINNY and GIFT, the dominant challenge is more closely related to dataflow organization and scheduling [6, 14, 34].

A representative SKINNY implementation adopts a column-serial structure to improve performance while maintaining low area cost, and further reduces logic utilization by implementing the S-box with embedded dual-port block memory [6]. Its relevance to a MixColumns survey is mainly methodological. In SKINNY, the diffusion layer is not difficult because of finite-field multipliers; rather, the key design challenge is coordinating ShiftRows and MixColumns under tight area constraints without causing severe throughput degradation. This naturally motivates serial or column-wise organizations [6]. A complementary direction is provided by work that emphasizes architecture-level serialization and datapath-width selection, showing that the area–latency–energy envelope can be controlled through structural design choices under practical deployment constraints [21].

By contrast, the full-cipher lightweight design SFN combines SPN and Feistel principles and introduces a MixRows layer within the SPN component, making diffusion an embedded part of the round function rather than an isolated module optimized separately [38]. Its iterative FPGA architecture is evaluated under low-utilization and low-power objectives for IoT-class constraints, positioning the contribution closer to system-level feasibility than diffusion micro-primitive redesign. This supports the broader observation that many practical lightweight-cryptography FPGA implementations optimize diffusion through scheduling and structural choices, such as iteration, serialization, and resource sharing, rather than by redesigning constant-multiplication networks.

Viewed together, these studies represent three different optimization levels: LUT/Boolean-level diffusion specialization, datapath-width and serial-architecture tuning for MDS-based diffusion, and round-level diffusion integration within a complete lightweight-cipher datapath [20, 21, 38-41]. This distinction clarifies why cross-paper comparison should separate diffusion micro-architecture from system integration and evaluation metrics.

5.3 Platform-dependent / FPGA-aware optimization

MixColumns-centric studies clarify where delay/area pressure originates, their comparison often becomes difficult to generalize because the reported outcomes are not always normalized across devices and tool flows (a limitation also visible across older AES FPGA implementations. This motivates a key survey observation: module-level improvements must be interpreted under explicit target assumptions (family/tool constraints) in order to be meaningfully compared in a cross-paper.

Notably, these throughput-first works are methodologically similar even when their internal MixColumns logic differs: the unifying theme is that frequency closure and sustained throughput are achieved primarily through architectural organization (pipeline stage boundaries, unrolling depth, and parallel round scheduling) rather than solely reducing the XOR count of the linear layer.

To modify the cost profile of GF multiplications, another methodology abstracts MixColumns into a purely linear Boolean network and optimizes it by minimizing XOR count and depth, as summarized in Table 6. A compact linear realization of AES MixColumns has been presented as a short program or circuit with reduced XOR gate count and depth, positioning the design as an algorithmic and circuit-level optimum [41]. This class of work is valuable because it provides a mapping-independent cost model and a strong baseline for estimating how small the underlying logic could be. However, it does not fully capture FPGA-specific realities such as LUT packing, routing congestion, and post-route maximum frequency. Therefore, an important cross-paper gap remains: XOR-optimal designs must be connected to FPGA-native mapping metrics before they can be directly compared with full-core FPGA implementations.

Frequency and throughput improvements can also be achieved by restructuring diffusion operations into LUT-oriented transformations that better match FPGA LUT architectures and reduce critical-path complexity [42]. However, when such results are reported only at the full-core hash or cipher level, it becomes difficult to isolate the specific contribution of diffusion-layer optimization to the overall hardware performance.

For lightweight block ciphers such as LED and SKINNY, diffusion optimization is often treated primarily as a datapath-granularity and scheduling problem. LED-oriented FPGA evaluations comparing LED with SIMECK show that diffusion-heavy SPN ciphers and Feistel-like ciphers lead to fundamentally different hardware bottlenecks [8, 43]. In LED, diffusion is closely tied to MDS mixing, whereas in SIMECK, the round-function structure shifts optimization effort away from MixColumns-style matrix multiplication and toward round-function primitives and scheduling.

Although mCrypton is not always described using the same “MixColumns” terminology as AES, it still includes a diffusion-equivalent linear transformation that must be implemented efficiently in hardware. Efficiency-focused FPGA implementations of mCrypton show that lightweight cipher design requires careful balancing of architecture and resource mapping rather than isolated micro-optimizations [41].

Finally, higher-level surveys and classification studies provide the broader context for why diffusion-layer comparison matters. Lightweight block cipher classifications for specific processors emphasize that lightweight suitability is platform-dependent. Similarly, IoT-focused lightweight cryptography surveys motivate cross-family comparison of diffusion-layer implementations because IoT endpoints range from extremely constrained devices to moderately capable edge accelerators [12, 35]. Therefore, a rigorous FPGA-focused comparison should treat MixColumns and diffusion as a cross-family implementation problem. Different papers optimize different points in the same design space, including arithmetic cost, LUT mapping, pipelining and unrolling, and routing realism. Research gaps often appear where reporting is incomplete or where benchmarking assumptions prevent fair normalization across FPGA devices and toolflows [15, 44].