Adam Taylor, Publisher & Founder/Principal Consultant, Adiuvo Engineering & Training
At the design stage, FPGA engineers face several core challenges, from achieving timing and power closure to minimizing device size and optimizing resource utilization. One option is to leverage the higher-performance logic provided by the AMD Spartan™ UltraScale+™ FPGA to implement designs in a smaller logic footprint while still achieving the desired performance. This uses a technique called logic folding, which collapses the required logic resources due to the device’s high-speed fabric.
Logic folding is effectively temporal multiplexing enabled by higher operating frequencies. The high-performance fabric means we can reduce bus widths while still achieving the processing throughput required. For example, an existing design might leverage a 32-bit bus operating at 200 MHz, whereas we can leverage a 16-bit bus at 400 MHz.
To get the best performance from any AMD FPGA, the UltraFast™ design methodology is a great starting point. It ensures the developed Register Transfer Level (RTL) can be correctly mapped to the target FPGA resources. When performing logic folding, especially in an existing design, it is a good idea to ensure the RTL aligns with the UltraFast methodology requirements prior to making any detailed code updates.
Key elements of the UltraFast design methodology include:
Minimize reset use – When possible, minimize the use of resets because, for an SRAM-based FPGA, a global set / reset (GSR) is performed at the end of the configuration. This means variable initialization within the RTL will be implemented when the bit file is generated. The use of resets prevents the synthesis tool from being able to leverage the Shift Register Lookup Table (SRL) as storage elements.
Reset style – If resets are necessary, it is preferable to use a synchronous reset, not an asynchronous reset.
Register I/O – Ensure when interfacing with hard macros, such as block RAMs and Digital Signal Processing (DSP) blocks, to implement the necessary pre- and post-registers. For example, use two pre-adder registers for DSP48E2 alignment, and registered inputs and outputs for block RAM.
Pipelining – Provide pipeline registers at the beginning or end of the datapath module. This allows the synthesis tool to perform retiming, inserting registers in the datapath as needed to achieve the highest performance.
Placement wrapper – Create wrappers around a module to register its I/O. This provides the implementation tool with the ability to locate the registers as needed in the routing path to improve timing closure.
Write flexible code – Leverage generics and parameters to enable the module to be easily configurable for different bus widths, etc.
Leverage capabilities – Take advantage of the device features, such as the Single Instruction, Multiple Data (SIMD) pattern detection capabilities of the DSP48E2.
Spartan UltraScale+ architecture
Based on a 16 nm process node, the UltraScale architecture blends logic density, deterministic timing, high-speed connectivity, and memory bandwidth in a scalable platform. The Spartan UltraScale+ family extends these capabilities to cost-optimized applications with high I/O counts, transceiver support, and hard IP for an LPDDR5-class memory interface, while maintaining low power consumption and offering long product lifecycles.
The architecture is built around high-performance, programmable logic coupled with embedded memory, DSP resources, and high-speed I/O. At its core, it uses configurable logic blocks (CLBs) that contain 6-input Look-Up Tables (LUTs), fast carry chains, and flip-flops, enabling efficient implementation of both combinational and sequential logic.
Spartan UltraScale+ devices incorporate several tiers of memory, including 36 Kb block RAM with built-in ECC and FIFO modes, 288 Kb UltraRAM blocks in larger device sizes offering deeper, more power-efficient storage, and distributed RAM in the LUTs for fast, localized memory. DSP48E2 slices deliver compute capability with 27×18 multipliers, pre/post adders, accumulators, and wide XOR logic, allowing the architecture to meet demanding signal processing workloads.
High-speed serial connectivity is delivered through GTH transceivers, which operate at up to 16.3 Gb/s and appear in devices larger than the Spartan UltraScale+ SU35P devices.
These transceivers include sophisticated equalization, pre-emphasis, and adaptive receiver features designed to support long PCB traces, backplanes, and modern high-speed protocols. Devices with transceivers also provide hard IP for PCIe® Gen4 blocks.
Clocking resources are organized into clock management tiles, each containing a Mixed-Mode Clock Manager (MMCM) and two Phase-Locked Loops (PLLs). Global and regional clock routing networks ensure low skew and flexible distribution. The architecture’s segmented clocking scheme reduces power and improves determinism, while the ability to derive clocks from PLLs, MMCMs, or transceiver outputs provides system-level flexibility. Integration between the clocking network and memory interfaces ensures stable timing for Double Data Rate (DDR) memory and high-performance physical layers (PHYs).
Memory interfaces are another major strength of the UltraScale+ portfolio. While traditional DDR4 interfaces remain widely supported, Spartan UltraScale+ devices introduce hard IP controllers for LPDDR4X and LPDDR5, delivering data rates up to 4266 Mb/s via the XP5IO banks. These hard IP controllers reduce both logic utilization and power, and simplify PCB design compared to soft memory controllers. Devices larger than the SU35P in the Spartan UltraScale+ range support PCIe Gen4 through integrated hard blocks, which also enable a reduction in power dissipation compared to soft implementations.
Getting started with logic folding
When it comes to implementing designs on a Spartan UltraScale+ FPGA using logic folding, we can leverage the capabilities of the programmable logic to implement a solution that is not only faster but also operates at a higher clock frequency.
A good way to demonstrate this is to migrate a module from a Spartan 7 XC7S100 in a -2 speed grade to a Spartan UltraScale+ XCSU35P FPGA, also in a -2 speed grade with a voltage supply of Vnom. The module combines several features common to FPGA applications: a CIC filter implementing a rolling average, high-speed AXI-Stream interfaces, and Cyclic Redundancy Check (CRC) protection.
The architecture of the original Spartan 7 FPGA implementation is outlined above. The design is based around a 32-bit streaming architecture. When implemented within the Spartan 7 FPGA, the maximum speed achieved was 215 MHz. Resource requirements after implementation were 742 LUTs and 487 FFs.
This design utilization and clock rate, therefore, define the baseline performance of the system, and the floorplan of the device when implemented is shown in figure 2.
Determining maximum frequency
As we begin the conversion to the Spartan UltraScale+ FPGA, it is key to understand the maximum clock rate we can achieve with our design in the target device. The best way to determine this is to implement the design while iteratively increasing the target clock frequency until a small negative slack is reported (WNS<0). We can, therefore, calculate the maximum clock frequency using the equation:
FMAX (MHz) = max(1000/(T – WNS))
Conversion rules
To ensure a conversion is as representative as possible, the following rules are used:
- Both devices will be targeted at the same speed grade
- Synthesis and Implementation settings will be identical in both projects
- Performance shall be the same for both modules, e.g., dynamic range
- Latency through the module may be modified to enable a higher clock rate
Spartan UltraScale+ FPGA migration
The first step is creating a project targeting the Spartan UltraScale+ FPGA with the unchanged original module. This allows validation of architectural compatibility and identifies any macros or primitives requiring updates. This also lets us determine the new design’s maximum frequency.
In the Spartan UltraScale+ device, the original module requires 715 LUTs and 487 FFs and operates at 308 MHz, nearly a 100 MHz improvement. This comes from the faster CLB architecture, improved routing, and more efficient DSP/block RAM interfacing. However, this is not the full benefit. By re-architecting the logic to exploit higher fabric speed, we can dramatically improve both Fmax and resource utilization.
Re-architected folded implementation
Figure 3 shows we get a speed increase of nearly 100 MHz for the same module just by changing to a later generation of the device. However, this is not the maximum benefit we can get from changing a generation. By re-architecting the module slightly, we can achieve an implementation that operates at a higher clock rate and significantly reduces the logic footprint.
The most efficient way to achieve a speed update is to reduce the size of the AXI streaming interconnect and the CRC associated with it. Within the original design, the interface used a 32-bit AXI stream and a 32-bit CRC in the Tuser field to protect the input and output data. Within the Spartan 7 device, the 32-bit implementation is required to achieve a throughput of 6,880 Mb/s when operating at the 215 MHz clock.
Re-architecting the design to use a 16-bit interface and an 8-bit CRC in the Tuser field enables the clock frequency to be increased to 450 MHz. This is more than double the original clock frequency within the Spartan 7 device.
This re-architecting means we can leave the 32 bits of the CIC filter unchanged, which ensures the migrated design maintains the dynamic range of the filter. Of course, this approach requires two 16-bit transfers over the AXI Stream to receive the 32 bits required to be passed through the CIC filter. The 32 bits are retained at the filter to keep the dynamic range.
With the clock rate of the Spartan UltraScale+ device being over twice that achieved in the Spartan 7 FPGA, the algorithm is still capable of achieving the required throughput, reaching 7200 Mb/s, a comfortable margin over requirements. This re-architecting of the design reduces the resource requirements significantly, to 531 LUTs and 497 FFs.
This equates to a small increase in registers but leads to a significant decrease in the number of LUTs required with a reduction of approximately 30% against the base case. The floor plan of the device in figure 5 shows the reduction in area, clearly from the baseline.
Power differences
Along with the reduction in resource requirements, the power dissipation of the device will also be impacted by the design changes. There are several factors which come into play when considering the power dissipation. While the advanced fabric enables a more power-efficient solution, we are clocking the folded design at a much faster frequency. When folding a design, we therefore should not expect to see such a dramatic change in the power dissipation as we did with the logic resources. However, when comparing the power dissipation in the original design against the folded design, we do see a slight reduction in power.
The original design required 0.034 watts to power the design, while the updated folded design requires 0.03 watts of power. While small, this demonstrates the folding technique does not adversely affect the demands of existing power architectures. Of course, if folding the design enables us to deploy the design in a small device, there will be a significant reduction in static power required.
Complexities of rearchitecting
This reduction in area over the baseline design required a modification to the original RTL. The main modification of this code was to change the AXI Data and User widths to accommodate a narrower bus. Because this code follows the UltraFast design methodology guidelines, the RTL was parameterized. Therefore, the initial change in bus width was simply the change to a parameter or generic.
The largest change in this re-architecting was the creation of an 8-bit CRC in place of the original 32-bit CRC. This redevelopment required the design and test of a new module and test benching. Because CRC-8 can be sourced from internal IP libraries, open-source IP, or generated using AI tools, the implementation effort was minimal. The 8-bit CRC block was completed within a few hours.
Of course, each design is unique and requires careful consideration as to the level of re-architecting required. However, this example has shown a significant reduction can be achieved by leveraging higher performance, narrower data buses, something which can be achieved easily with parameterization. More complex applications may require more in depth re-architecting, though as this article has demonstrated, the rewards for the time invested can be significant.
Summary
Logic folding is a technique that leverages the higher performance of newer FPGA architectures, such as in the AMD Spartan UltraScale+ family, to reduce logic footprint while still meeting (or exceeding) throughput requirements. Because Spartan UltraScale+ devices can operate at significantly higher clock frequencies than earlier families like Spartan 7, designers can reduce bus widths and time-multiplex operations without sacrificing data rate or algorithmic performance. This enables smaller, faster, more resource-efficient implementations.
The process typically involves understanding the original design’s throughput, determining the maximum achievable clock frequency in the new device, and re-architecting datapaths (such as AXI-Stream widths) to match performance requirements, while minimizing LUT and routing resources. When combined with the UltraFast design methodology, logic folding results in cleaner timing, reduced area, and improved robustness.
Logic folding summary and generic rules
Logic folding is a technique where a designer reduces the width, parallelism, or resource duplication in a digital design and compensates by increasing the operating frequency or reusing hardware across multiple cycles. Modern FPGAs with higher-performance logic fabric make this trade-off attractive because time-multiplexed designs can achieve equivalent throughput while using fewer logic resources. Folding enables smaller devices, lower power consumption, and simpler routing, while still meeting system-level performance requirements.
Define the performance requirements
Identify required throughput, latency, precision, and any system-level constraints. Determine which metrics must remain unchanged when folding.
Determine the available clock frequency headroom
Estimate or measure the maximum clock rate achievable in the target device. Compare this to the original design’s clock rate to understand how much folding is possible.
Reduce parallelism or data width
Narrow datapaths reduce vector widths, or reuse operators instead of duplicating them. Ensure the new multi-cycle structure still meets throughput requirements given the increased clock rate.
Time-multiplex functional units
Replace replicated arithmetic or logic blocks with shared units used across several cycles. Add scheduling or control logic to coordinate multi-cycle operations.
Add or increase pipelining
Insert pipeline registers to support higher operating frequencies. Ensure pipeline depth does not violate system latency constraints.
Preserve algorithmic accuracy
Maintain internal precision, state widths, and accumulator sizes unless mathematically safe to change. Folding should alter when operations occur, not what they compute.
Update control and handshaking
Modify Finite State Machines (FSMs), enables, and valid/ready mechanisms to accommodate multi-cycle behavior. Ensure downstream modules tolerate any added per-sample latency.
Consider memory and buffering needs
Multi-cycle operations often require additional temporary storage or buffering. Ensure that memory access patterns still meet timing and bandwidth needs.
Revalidate timing, throughput, and functional behavior
Run functional simulations and timing analysis. Confirm that the folded design meets timing, achieves required throughput, and behaves identically to the original algorithm.
Document the folding strategy clearly
Capture the updated cycle counts, interface behavior, data formatting, and multi-cycle timing. Provide clear guidance for integration and future maintenance.
