List Offset Merge Sorters (LOMS)

• LOMS are hardware merge networks that map sorted input lists into a 2-D offset array and employ alternating column and row sorts to achieve a merged output.
• This technique supports merging lists of unequal and non-power-of-2 sizes, reducing stage count for both 2-way and k-way merges.
• FPGA implementations of LOMS demonstrate improved speed and resource efficiency compared to traditional Batcher networks and standalone S2MS designs.

List Offset Merge Sorters (LOMS) are a new class of oblivious, hard-wired hardware merge networks for merging multiple already-sorted input lists into one sorted output list by arranging the inputs in a 2-D setup array with intentional horizontal and vertical offsets and then applying a minimal set of alternating column-sort and row-sort stages (Kent et al., 11 Jul 2025). In the 2-way case, LOMS requires only two stages; in higher-way cases it continues the alternating column/row process until the output array is in the defined sorted order. The defining feature is not new merge comparator logic, but the offset placement of sorted lists in the setup array, which enables fast and efficient merging, accommodates unequal input list sizes, and does not require power-of-2 list lengths.

1. Definition and distinguishing architecture

LOMS devices merge multiple sorted input lists into a single sorted output list in hardware by first mapping the lists into a 2-D setup array and offsetting the order of each sorted input list from the order of the others. The paper characterizes them as oblivious, hard-wired hardware merge networks and emphasizes that the key distinguishing feature is not the merge comparator logic itself, but the way the input lists are laid out before sorting begins (Kent et al., 11 Jul 2025).

In the paper’s terminology, a 2-way setup is labeled UP-x/DN-y, where one list is ordered “UP” and the other “DN.” A k-way setup is labeled Xc_Yr, meaning X input lists placed into X columns and Y rows. The offset arrangement is paired with alternating per-row sort direction. This arrangement is what allows a very small number of global sort passes to move values into their final row and column positions.

A common misconception is that LOMS is primarily a new comparator-network family in the same sense as Batcher-style constructions. The paper explicitly states otherwise: the novelty lies in the offset 2-D setup array. This suggests that LOMS should be understood first as a data-layout methodology for merge networks and only secondarily as a specific collection of hardware blocks.

2. Offset placement in the 2-D setup array

LOMS does not treat the input as a flat 1-D stream. Instead, the sorted lists are mapped into a 2-D array in hardware, with each list offset from the others. For the 2-way case, the two sorted lists are interleaved in a 2-column array: the A/UP list is mapped so that within each row values decrease from left to right in the array’s chosen orientation, the B/DN list is mapped in the opposite row order, and the rows of the two lists are vertically displaced (Kent et al., 11 Jul 2025).

This setup has a specific operational consequence. A full column sort sends each item to the correct row region, after which a full row sort completes the merge. In the paper’s UP-8/DN-8 example, Stage 1 performs independent sorts on each column; this moves the top two values of the combined inputs to the top row, the minimum values to the bottom row, and places intermediate values into their correct row bands. Stage 2 then sorts each row in the correct direction, producing the final output array.

The paper also emphasizes that the lists do not need to be equal length and do not need to be powers of 2. Odd/even mixes are allowed, and unpopulated cells are shifted to the bottom and removed if a row becomes fully empty. This is presented as a major advantage over Batcher-style merge networks, which are described as difficult to design unless the 2 input lists are equal, and a power-of-2.

3. Two-stage 2-way merge and the role of S2MS

For 2-way merge, LOMS uses exactly two stages: Stage 1 is parallel full column sorts, and Stage 2 is parallel full row sorts (Kent et al., 11 Jul 2025). The paper states that any 2-way merge arranged in this manner only requires the column-sort and row-sort stages, after which the array is in final sorted order.

The architectural relationship to Single-Stage 2-way Merge Sorters (S2MS) is explicit. LOMS 2-way sorters use S2MS as their first-stage column sorters. In a 2-way LOMS, the first stage is made of parallel S2MS devices sorting each column, the second stage sorts the rows, and the whole device is therefore a 2-stage merge network. S2MS are described as single-stage combinational merge blocks that merge two sorted lists very quickly.

The performance and resource trade-off between the two approaches is central. S2MS by themselves are the fastest 2-way merge sorters in the FPGA family studied, but they tend to consume a large number of LUT resources. LOMS is slower than pure S2MS, but uses fewer resources than comparable S2MS devices. The paper notes that some large LOMS designs can be implemented in a given FPGA when comparable S2MS designs cannot fit. This suggests that the first-stage reuse of S2MS inside LOMS functions as a controlled compromise between speed and LUT consumption rather than as a direct attempt to replace S2MS on absolute delay alone.

4. k-way extension, stage counts, and serpentine order

For k > 2, LOMS continues the alternating column-sort and row-sort process until all values are in correct order. The paper gives the total number of alternating column/row sorts required for a k-way merge and reports the following pattern (Kent et al., 11 Jul 2025):

k	Total stages
2	2
3	3
4	4
5	4
6	5
7	6
up to 14	6

The paper explains that after the first two stages, later stages may not sort full rows or full columns when k > 3; they may instead sort selected substructures, such as edge-column pairs in the 3-way case. For k \ge 3, the final output order is serpentine: each row is sorted in the opposite direction from adjacent rows. The 3-way output order is described as “serpentine sorted order, with the sorted order of each row reversed from the rows above and below that row.”

The 3-way 3c_7r merge sorter is the detailed multiway example. Its flow is: build a 3-column setup array with offset lists; Stage 1, full column sorts; Stage 2, full serpentine row sorts; Stage 3, remaining column sorts in edge columns. After Stage 2, the median of the 21 input values is already known at Row 3 Col 1, even though the full merge requires Stage 3. The paper compares this with the state-of-the-art Multiway Merge Sorting Network, where median determination takes 4 stages and full merge takes 5 stages. The immediate significance is that LOMS is algorithmically shallower for this 3-way configuration, and a plausible implication is that early selection operations can benefit even when a full merge is not required.

5. FPGA implementation and measured performance

The study implemented and synthesized designs on two FPGA targets: AMD Kintex Ultrascale+ xcku5p-ffva676-3-e and AMD Versal Prime xcvm1102-sfva784-2HP-i-S, using AMD Vivado 2024.2 (Kent et al., 11 Jul 2025). For 2-way merge, the paper uses two LUT packing methodologies, 2insLUT and 4insLUT, referring to how many input bits are packed into LUT logic for the S2MS blocks used in the design.

The hardware behavior differs across the two FPGA families. Ultrascale+ slices contain hard-wired MUXF* multiplexers, which the design uses to reduce delay, and the paper notes that forcing these structures in Verilog yields faster designs. Versal Prime lacks these hard-wired internal MUXF structures, so equivalent multiplexing paths must travel through programmable interconnect and often extra LUT stages, increasing delay.

The reported performance results are specific. A List Offset 2-way sorter merges 2 lists, each with 32 values, into a sorted output list of those 64 values in 2.24 nS, which is reported as a speedup of 2.63 versus a comparable Batcher device. For 3-way merge, a LOMS device merging 3 sorted input lists with 7 values fully merges the 21 values in 3.4 nS, a speedup of 1.36 versus the comparable state-of-the-art 3-way merge device. For median detection in the same 3-way setup, LOMS requires only 2 stages, the state-of-the-art multiway merge requires 4 stages, and the speedup for 32-bit median detection ranges from 1.45× to 1.48×.

Against Batcher’s Bitonic Merge Sorters and Odd-Even Merge Sorters, the paper states that LOMS 2-way sorters are significantly faster, while also often using comparable or even fewer LUT resources for smaller configurations. Against S2MS, the comparison is deliberately qualified: S2MS is generally the fastest 2-way merge style, but consumes more LUTs; LOMS is slower than S2MS, but much more resource-efficient. For 32-bit data on Versal Prime, 4insLUT designs use fewer resources, but are slower and can suffer routing congestion, while 2insLUT designs are faster and more scalable.

6. Practical significance, use cases, and interpretive boundaries

The paper attributes the speed and efficiency of LOMS to five structural elements: offset input arrangement, alternating column and row sorting, serpentine order for k \ge 3, S2MS reuse in Stage 1, and avoidance of the deep recursive stage structure of Batcher networks (Kent et al., 11 Jul 2025). The resulting device is described as faster than Batcher’s networks, often smaller than S2MS, flexible for unequal and non-power-of-2 list sizes, and extendable to k > 2 list merging.

Several practical implications are stated directly. LOMS handles unequal input list sizes naturally, does not require power-of-2 sizes, supports both 2-way and k-way merging, can be used for full merging or early median extraction, and enables larger designs to fit in FPGA devices where equivalent pure S2MS designs are too resource-heavy. The paper identifies sorting, selection, filtering, image-processing and filtering tasks where median extraction is the goal, and security-oriented oblivious computation as relevant settings.

An important interpretive boundary is that LOMS does not displace every alternative on every metric. The paper presents S2MS as the fastest 2-way option in the studied FPGA family when maximum speed is the only goal and resources are plentiful, while LOMS is presented as a more resource-efficient design point. Likewise, Batcher devices remain a historical baseline and may be smallest in some cases, but are reported as slower and much less flexible in list sizing. In that sense, LOMS is best understood not as a universal replacement for all hardware merge sorters, but as a hardware merge methodology built around a 2-D offset layout whose principal advantages are shallow stage count, list-size flexibility, and favorable speed–resource trade-offs in the FPGA implementations studied.