---
title: 'FuseMap: Adaptive ASIC-Based LUT Mapping'
url: https://www.emergentmind.com/topics/fusemap
type: topic
---

# FuseMap: Adaptive ASIC-Based LUT Mapping

FuseMap is a framework for improving FPGA LUT mapping by fusing ASIC technology mapping into the FPGA synthesis flow. It targets the dependence of FPGA LUT mapping quality on the structure of the Boolean network presented to the LUT mapper, and it treats the choice of ASIC standard-cell library cells as a tunable variable rather than a fixed prerequisite. In the reported formulation, FuseMap uses reinforcement learning in the concrete form of a multi-armed bandit to select a library subset that reshapes the pre-mapped network into one that is more favorable for subsequent FPGA LUT mapping, with the primary quality measures being LUT count, LUT depth, and area-delay product (ADP) [2507.10912].

## 1. Problem setting and conceptual basis

In FPGA synthesis, a Boolean network must be converted into a network of $k$-input LUTs, where each LUT can implement any Boolean function of up to $k$ inputs. The objectives emphasized for FuseMap are **\#LUT**, interpreted as a proxy for area, **depth / LUT depth**, interpreted as a proxy for delay, and sometimes the combined metric **ADP**. The paper states that LUT mapping quality is highly sensitive to the structure of the Boolean network before mapping, so improvements can arise not only from the LUT mapper itself but also from structural transformations that occur earlier in the flow [2507.10912].

FuseMap is based on the observation that ASIC technology mapping and FPGA LUT mapping have traditionally been treated as separate optimization problems, even though an ASIC mapping stage can act as a structural pre-processing step before LUT mapping. The key claim is not that any ASIC mapping is beneficial. On the contrary, the motivating case studies show that simply combining a vanilla ASIC mapper with a vanilla LUT mapper can worsen LUT count by about **7% to 24%**. The central insight is instead that **library selection is a design knob**: using a partially selected ASIC library can sometimes produce a better final FPGA LUT result than using the full library. This is particularly relevant for modern LUT sizes such as $K=6$, which may exceed the size of many individual standard cells and therefore make the ASIC stage a form of network reshaping rather than a final implementation target [2507.10912].

The paper also situates FuseMap within the conventional AIG-based view of technology mapping. A cut $C$ is defined as a set of leaf nodes such that each path from a PI to the root passes through at least one leaf, and a cut is $K$-feasible if the number of leaves does not exceed $K$. This background is not presented as a new theory of LUT mapping, but as the combinational setting in which the structural effects of the ASIC pre-mapping stage become consequential.

## 2. Fused mapping mechanism

FuseMap inserts an ASIC mapping stage before LUT mapping and tunes the ASIC library selection so that the resulting post-ASIC, pre-LUT network is easier to map well into LUTs. The fused methodology has two coupled components: an intermediate **standard-cell mapping step** and an adaptive search over the subset of cells exposed to that step. Rather than assuming that the full standard-cell library is optimal, FuseMap searches for a curated subset that improves downstream FPGA QoR [2507.10912].

This mechanism is best understood as a controlled restructuring of the Boolean network. A standard-cell mapper operating on the full library may generate a decomposition that is locally sensible for ASIC objectives but unfavorable for a later LUT covering stage. Restricting the available cells changes the decomposition space and, in some designs, yields a network that is more amenable to low-LUT or low-depth FPGA implementation. The paper characterizes this as a way of using ASIC mapping ideas incrementally within FPGA technology mapping rather than as a replacement for LUT mapping itself.

A recurring misconception is that FuseMap is merely a sequential concatenation of two conventional tools. The reported evidence does not support that interpretation. The beneficial effect arises from **optimizing the library composition**, not from applying an unmodified ASIC mapper in front of an unmodified LUT mapper. This suggests that the ASIC stage is functioning less as a final technology commitment than as a tunable structural transform.

## 3. Optimization formulation

Although FuseMap is described as reinforcement learning, the implementation is specifically a **multi-armed bandit (MAB)** formulation. The state $\mathcal{S}$ encodes which cells have been selected from the library:

$$
\mathcal{S} = [S_0, S_1, \ldots, S_{\mathcal{N}-1}], \qquad S_i \in \{0,1\},
$$

with the complete-selection constraint

$$
\sum_{i=0}^{\mathcal{N}-1} S_i = n.
$$

If the library has $\mathcal{N}$ candidate cells, then each cell corresponds to a discrete action $a^i$, and in the bandit interpretation each cell is an arm. The optimization target may be **\#LUT**, **delay**, or **ADP**, with

$$
ADP = Delay \times \#LUT.
$$

The reward is formulated so that lower QoR values are better, using a negative sign to convert minimization into reward maximization. For ADP, the paper defines a normalized reward using baseline delay and area computed from the full library, and it states that the same general idea applies when optimizing \#LUT alone or delay alone [2507.10912].

FuseMap implements two policies. **FuseMap-$\epsilon$** is an $\epsilon$-greedy policy that chooses the best-known action with probability $1-\epsilon$ and a random action with probability $\epsilon$:

$$
a^i =
\begin{cases}
\arg\max_{a^i \in \mathcal{A}} p_{a^i} & \text{with probability } 1-\epsilon,\\
\text{random } a^i \in \mathcal{A} & \text{with probability } \epsilon.
\end{cases}
$$

**FuseMap-UCB** uses upper confidence bounds:

$$
a^i = \arg\max_{a^i \in \mathcal{A}} \left( p_{a^i} + c \sqrt{\frac{\log(t)}{n_{a^i}}} \right),
$$

where $t$ is the current iteration, $n_{a^i}$ is the number of times action $a^i$ has been selected, and $c$ controls exploration strength. The paper also gives a probability-update rule of the form

$$
p_{a^i}(t+1) = \frac{p_{a^i}(t) n_{a^i}(t) + \mathcal{R}_{\mathcal{S}(t)}}{n_a(t)},
$$

with the caveat that the notation in the manuscript is compressed. The intended role of the update is clear: action desirability is adjusted using the observed reward from the current selected subset.

An important interpretive point is that FuseMap is not a deep-RL policy over netlist states. The paper’s formulation is considerably lighter-weight: model-free, iterative, and explicitly centered on bandit-style cell selection.

## 4. Algorithmic workflow and implementation context

The operational workflow begins with a baseline LUT mapping using the full standard-cell library. FuseMap then initializes cell-selection probabilities over the library and iteratively performs five steps: select a subset of cells, run ASIC technology mapping using that subset, feed the resulting netlist into LUT mapping, compute reward from the resulting \#LUT, delay, or ADP, and update the action probabilities using the MAB procedure. After a user-defined number of iterations, the framework returns the best-performing library subset and its corresponding mapping result [2507.10912].

The reported baseline LUT flow in ABC is

```text
resyn; strash; dch; strash; resyn; if -K 6; mfs2
```

and the FuseMap flow inserts ASIC mapping with

```text
map -a
```

after the `dch` stage and before LUT mapping, using the iteratively updated library. The experiments are conducted in the ABC framework on an **Intel Xeon Gold 6418H CPU**.

The benchmark suites include **ISCAS 85**, **ISCAS 89**, **ITC/ISCAS 99**, **VTR 8.0**, and **EPFL**. The paper reports detailed figures on **24 designs** and also an expanded set of **161 designs** across ISCAS89, EPFL, and VTR for average ADP improvement. The technology libraries are **ASAP7**, described as a 7nm predictive PDK / standard-cell library, and **NAN45**, identified as FreePDK45. The study also considers sampled subsets of ASAP7 with sizes $\{30, 40, 50, 60, 70\}$, and one motivating case study uses a random partial sample of **80 out of 161 cells** from ASAP7.

These details indicate that FuseMap is formulated as a closed-loop wrapper around an existing mapping toolchain rather than as a replacement mapper. A plausible implication is that the framework can inherit the maturity of established synthesis tools while still altering the effective search space through adaptive library restriction.

## 5. Empirical behavior and quantitative results

The motivating experiments show that a naive fused flow is often counterproductive: vanilla ASIC mapping before LUT mapping increases \#LUT by **7% to 24%** relative to vanilla LUT mapping. This negative result is central to the paper’s argument, because it isolates the actual source of improvement: not fusion in the abstract, but adaptive **cell selection** within the fused flow [2507.10912].

Under the full FuseMap evaluation on **ASAP7**, the paper reports across **24 designs** that FuseMap improves **\#LUT in 20 out of 24 designs**, with average \#LUT improvement of about **9%** in the main results section; the conclusion summarizes this as **8%** average LUT minimization improvement. For **delay / LUT depth**, the average improvement is about **3%**, with some designs showing much larger reductions; the paper highlights **s35932** with about **32%** delay reduction. For **ADP**, the reported average improvement is about **9%**, and the paper states that the **9% ADP improvement** also holds on average across the larger benchmark set.

The results are explicitly design-dependent. The paper notes that some circuits improve strongly, while others may show worse delay or area. In the motivating case studies, design **s832a** achieves up to **30% reduction in \#LUT** under selected-cell fused mapping. At the same time, some designs can worsen on average, and some exhibit worse worst-case outcomes. The data therefore support a conditional conclusion: FuseMap is effective as a design-specific search procedure, not as a universally monotone transformation.

Convergence is reported as relatively fast. FuseMap usually converges within about **10 to 12 iterations**, and for some designs and sample sizes convergence occurs within **5 to 10 iterations**. Smaller subsets can converge faster, although they may yield slightly worse final LUT results in some cases. No significant divergence or instability is reported.

The paper also reports dependence on the choice of initial standard-cell library. Results differ between **ASAP7** and **NAN45**, reinforcing the claim that library composition matters and that a synthetic, tuned library for fused mapping may be a meaningful future direction.

## 6. Interpretation, limitations, and nomenclatural distinctions

FuseMap proposes a synthesis paradigm in which ASIC mapping is treated as a tunable pre-processing stage for FPGA LUT mapping rather than as a separate downstream domain. The practical implication is that standard-cell libraries become an optimization variable within FPGA synthesis: a learned or adaptive subset may produce better LUT area, delay, and ADP than the full library [2507.10912].

The stated limitations are equally important. FuseMap exhibits **design-specific behavior** and is not uniformly beneficial for every circuit. It is **library-sensitive**, since the search space and attainable results depend on the initial standard-cell library. There is also a **sampling trade-off**: smaller sampled libraries may accelerate convergence or improve certain outcomes, but they also increase the risk of failed or poor mappings due to insufficient cell diversity. In methodological terms, the MAB procedure uses a **black-box reward** and does not explicitly model the internal structure of the mapping process. The reported optimization scope is limited to LUT count, delay, and ADP; the paper notes that other FPGA metrics, such as routing congestion or post-routing timing, are not directly optimized, even though the reward function could be extended.

The name “FuseMap” is also potentially ambiguous in the broader arXiv literature. It is distinct from **“MapFusion: A General Framework for 3D Object Detection with HDMaps”**, which injects HD map priors into LiDAR-based 3D object detection [2103.05929]; from **“Road Network Fusion for Incremental Map Updates”**, which is also referred to as **MapFuse** and merges human-annotated and GPS-inferred road maps [1802.02351]; from **“SEF-MAP: Subspace-Decomposed Expert Fusion for Robust Multimodal HD Map Prediction”**, a camera–LiDAR BEV fusion method for HD map prediction [2602.21589]; and from **“FUSE: A Framework for Unified State Estimation in Robotic SLAM Systems”**, which concerns state-estimation interfaces and map-update policy in SLAM rather than FPGA synthesis [2605.18047]. It is likewise unrelated to **“FuseSeg: LiDAR Point Cloud Segmentation Fusing Multi-Modal Data”**, which addresses LiDAR point cloud segmentation through RGB–LiDAR feature warping [1912.08487].

Within its own domain, FuseMap is best characterized as an **RL-guided library tuning framework** for FPGA technology mapping. Its contribution is not a new LUT mapper in isolation, but the demonstration that adaptive selection of ASIC standard cells can materially improve the Boolean network presented to a conventional LUT mapper, even though naive ASIC-to-LUT fusion often degrades QoR.

Source: https://www.emergentmind.com/topics/fusemap