---
title: 'AxOSyn: DSE for Approximate Arithmetic Operators'
url: https://www.emergentmind.com/topics/axosyn
type: topic
---

# AxOSyn: DSE for Approximate Arithmetic Operators

AxOSyn is an open-source framework for the design-space exploration of approximate arithmetic operators (AxOs), intended primarily for energy-efficient edge-AI and embedded FPGA settings where controlled computational inaccuracy can be traded for improved power, performance, or area. Its defining feature is that it supports both **selection-based** exploration over existing approximate-operator libraries and **synthesis-based** generation of new operators, while allowing optimization at both operator and application granularity. The framework is organized around multi-objective optimization of **BEHAV–PPA** trade-offs, where BEHAV denotes behavioral quality or error impact and PPA denotes power, performance, and area [2507.20007].

## 1. Definition and conceptual scope

AxOSyn is presented as a modular framework for approximate computing in which arithmetic approximation is treated as a design-space exploration problem rather than as a fixed library lookup or a single synthesis flow. The motivating context is the growing complexity of edge-AI deployments on resource-constrained hardware, where approximate arithmetic operators can complement quantization and precision scaling by providing application-specific hardware reductions [2507.20007].

The framework is designed to separate four concerns that are often entangled in earlier tools: the **approximation model**, the **hardware model**, the **behavioral model**, and the **search method**. This decomposition is the basis for its support of multiple abstraction levels and multiple DSE styles. In the formulation used by the paper, approximate operators are judged by BEHAV–PPA trade-offs, and the framework is intended to support both operator-level optimization and application-specific optimization [2507.20007].

A central distinction in AxOSyn is between **selection** and **synthesis**. In selection mode, exploration proceeds over a predefined set of approximate operators such as EvoApprox-style libraries. In synthesis mode, the framework generates new candidates from an accurate operator and an approximation model, with the current implementation focusing on truncation-based and selective-LUT-pruning schemes similar to AppAxO-like and CoOAx-like flows [2507.20007].

## 2. Formal design-space model

The paper gives AxOSyn a formal structure that separates accurate operators, approximation models, operator behavior, and hardware characterization. At operator level, an approximate operator is obtained by applying an approximation model \(AxOM_m\) with configuration \(config_o\) to an accurate operator \(O_{ac}\):
\[
O_{\cdot} = AxOM_m(O_{ac}, config_o).
\]
The accurate and approximate outputs are written as
\[
Out_{oac} = F_o(O_{ac}, Inp_o), \qquad Out_{o\cdot} = F_o(O_{\cdot}, Inp_o),
\]
with operator-level behavioral error and hardware metrics defined as
\[
BEHAV_{O\cdot} = Err_{Oe}(Out_{oac}, Out_{o\cdot}),
\]
\[
PPA_{O\cdot} = PPA_{Op}(Out_{o\cdot}, Inp_o).
\]
This makes the operator model explicitly bi-criteria: one axis captures numerical deviation, the other captures implementation cost [2507.20007].

The framework distinguishes two search-space representations. For **selection-based** exploration, the search domain is a finite indexed set
\[
O_E = \{O_l\},
\]
where \(l\) indexes a list of available approximate operators. For **synthesis-based** exploration, the search space is encoded as
\[
O_A = \{O_i\}, \qquad O_i = (l_0,l_1,\ldots,l_i,\ldots,l_L), \qquad l_i \in \{0,1\},
\]
so that each candidate operator is represented by a binary configuration string. In the current implementation, this binary encoding is used to express selective LUT pruning and related truncation choices [2507.20007].

The corresponding operator-level optimization problem is formulated as a constrained multi-objective search:
\[
\min (BEHAV_{O\cdot}, PPA_{O\cdot})
\]
subject to
\[
BEHAV_{O\cdot} \le BEHAV_{MAX}, \qquad PPA_{O\cdot} \le PPA_{MAX}.
\]
The paper states that the decision domain is \(\mathcal{O}\), with **selection** using \(O_E\) and **synthesis** using \(O_A\). An analogous application-level formulation optimizes sets of approximate operators \(\{O_o\}\) against application-level BEHAV and hardware objectives under corresponding constraints [2507.20007].

The abstraction hierarchy spans **scenario**, **application**, **task**, **operator behavior**, **operator implementation**, and **accelerator**. The stated intent is to allow approximation to be introduced at several levels, although the experiments in the paper focus mainly on operator-level approximation while allowing application-level BEHAV integration with external tools [2507.20007].

## 3. Architecture, modules, and extensibility

AxOSyn is implemented in Python as an object-oriented framework with classes for functionality, hardware, approximation models, DSE algorithms, PPA estimation methods, and BEHAV estimation methods. These are derived from abstract base classes, and the framework is intended to be used through Jupyter notebooks that can also be adapted into Python scripts. Configuration is handled through YAML, internal data are represented with Python dictionaries, and logging uses CSV; the software stack also includes Vivado 2022.1, DEAP for evolutionary search, Plotly for visualization, PyTorch compatibility for application-level inference evaluation, and multiprocessing for expensive characterization stages [2507.20007].

Its modular architecture is described around four principal components. The **approximation model** defines how approximate operators are generated or represented, including LUT-pruning binary encodings and library indexing. **Functional or behavioral estimation** computes quality effects of approximation at operator, task, or application level. **Hardware or structural estimation** evaluates PPA, either through physical characterization or through ML-based prediction. The **search method** drives random sampling, exhaustive sweep, evolutionary exploration, or user-defined strategies. An optimization layer then extracts Pareto-optimal designs under the relevant objectives and constraints [2507.20007].

The extensibility contract is explicit. A new approximation model is expected to provide interfaces for **identification**, **functionality for a given set of inputs**, and **RTL generation for physical characterization**. The paper also stresses that custom BEHAV and PPA estimators can be integrated without rewriting the search engine, and that user-defined search strategies can be attached through the same modular decomposition. This is presented as a direct response to the limited extensibility of earlier tools that were tied to a single approximation model or a fixed abstraction level [2507.20007].

## 4. Exploration modes and supported operator models

AxOSyn supports both **selection-based** and **synthesis-based** exploration. Selection mode is intended for imported operator libraries such as EvoApprox-style sets and is naturally suited to pre-characterized, finite design spaces. Synthesis mode is meant for the generation of new operator instances by applying an approximation model to an accurate implementation. The paper emphasizes that this second mode enlarges the search space substantially and can reveal application-specific trade-offs unavailable in fixed libraries [2507.20007].

The current implementation is centered on **unsigned integer adders** and **signed integer multipliers**, including Baugh-Wooley-based signed multipliers. The dominant synthesis strategy is **selective LUT pruning**. Fig. 2 in the paper illustrates this with a 4-bit unsigned adder in which pruning a LUT associated with a sum bit reduces hardware cost while altering the arithmetic function. The same framework can also import selection-based libraries, allowing direct comparison between generated and pre-existing AxOs [2507.20007].

The paper explicitly contrasts synthesis-derived spaces with library-derived spaces. In the operator distributions of Fig. 8, AppAxO-style synthesis spaces show broader and more continuous spreads in error and hardware metrics, whereas EvoApprox-style libraries show more discrete clusters. EvoApprox-style operators can include designs with almost no logic, producing lower minima in some hardware metrics and nearly no CARRY4 usage, while AppAxO-style designs exploit FPGA carry chains differently and show broader continuous trade-off structure [2507.20007].

AxOSyn also allows different estimation fidelities. Operator outputs may be obtained by **truth-table look-up**, **PyLUT/software-encoded LUT functionality**, or **polynomial regression**. Truth-table and PyLUT approaches are exact within the characterized design representation, whereas polynomial regression introduces estimation error but can reduce evaluation cost. At hardware level, the framework supports **physical characterization** and **ML-based PPA prediction**. At application level, the paper notes compatibility with PyTorch-based evaluation for AI workloads [2507.20007].

## 5. Empirical demonstrations and quantitative findings

The experimental section is framed primarily as a demonstration of modularity and configurability rather than as a full end-to-end benchmark against competing DSE frameworks. The implementation is evaluated with FPGA-oriented flows using a **Zynq-7000 SoC FPGA on a PYNQ-Z1 board**, Vivado 2022.1, and a mix of exact and surrogate estimators. The explored operators include AppAxO 4x4, 6x6, and 8x8 adders; EvoApprox 8x8 and 12x12 adders; AppAxO 4x4\_8 and 8x8\_16 signed multipliers; and EvoApprox 8x8\_16 multipliers, among related labeled variants [2507.20007].

One set of results concerns operator-output estimation. For unsigned adders 4x4, 6x6, and 8x8 and signed multipliers 4x4 and 8x8, the paper compares PyLUT, look-up, and polynomial regression of degree 1, 2, and 3. PyLUT and look-up incur no output-estimation error because they rely on complete functional truth, whereas polynomial regression exposes a speed–accuracy trade-off: degree-1 models have higher prediction variance, and higher-degree models improve accuracy at the cost of increased estimation time [2507.20007].

A second set of results concerns ML-based estimation of **PDP** and **AVG\_ABS\_ERR**. For **SINT MULT 4x4\_8**, the reported ML modeling errors are **23.76** for PDP train error, **66.43** for PDP test error, **0.179** for AVG\_ABS\_ERR train error, and **0.459** for AVG\_ABS\_ERR test error. For **SINT MULT 8x8\_16**, the corresponding values are **467.15**, **855.37**, **254.69**, and **418.01**. The paper interprets this as evidence that larger operators are harder to model accurately, especially on behavior-related metrics [2507.20007].

The characterization-time results are more decisive. For 10 designs, the paper reports the following times:

| Evaluation path | SINT MULT 4x4_8 (s) | SINT MULT 8x8_16 (s) |
|---|---:|---:|
| True Char PDP -> True Char AVG_ABS_ERR | 1189.51 | 1199.29 |
| PredML PDP -> True Char AVG_ABS_ERR | 2.395 | 2.9876 |
| True Char PDP -> PredML AVG_ABS_ERR | 920.76 | 842.30 |
| PredML PDP -> PredML AVG_ABS_ERR | 84.94 | 4.116 |

These figures show that surrogate-based evaluation can reduce characterization time drastically relative to full physical characterization, although prediction accuracy degrades as operator complexity increases [2507.20007].

The paper also evaluates custom sampling strategies for an 8-bit signed Baugh-Wooley multiplier. **RANDOM**, **PATTERNED**, and **SPECIAL** sampling produce visibly different coverage of power, critical path delay, LUT count, AVG\_ABS\_ERR, and PDP space, and the paper notes that some designs generated by patterned or special sampling contribute uniquely to the combined Pareto front. This is used to argue that AxOSyn’s modular search layer is not merely interchangeable in software terms but materially affects the quality of DSE outcomes [2507.20007].

A further demonstration compares GA-based DSE with exhaustive exploration for a signed 4-bit multiplier. The exhaustive run defines the full trade-off space; the GA-based search evaluates only **88** designs using ML-predicted PDP and AVG\_ABS\_ERR, then re-validates those same 88 designs with higher-fidelity characterization. The predicted and validated Pareto fronts are reported as having hypervolume comparable to the exhaustive Pareto front, supporting the claim that surrogate-guided search can approach exhaustive quality at much lower evaluation cost [2507.20007].

## 6. Significance, limitations, and relation to adjacent tools

AxOSyn is positioned against earlier frameworks such as **EvoApprox**, **ApproxFPGA**, **AppAxO**, and **AGNApprox**. The paper’s argument is that those tools cover only subsets of the design space: library selection without synthesis, synthesis at a single abstraction level, or limited extensibility for new approximation models, estimators, and search methods. AxOSyn’s significance lies less in a single approximation algorithm than in providing a common infrastructure within which such algorithms can be compared, extended, and combined [2507.20007].

Several limitations are also explicit. The current paper focuses mainly on **operator-level approximation** even though the framework is defined hierarchically up to application and accelerator levels. The presently integrated operators are mainly **unsigned adders** and **signed multipliers**. The implemented synthesis methods emphasize **truncation and selective LUT pruning** rather than a broader class of compositional approximate-operator constructions. The ML models shown in the experiments are described as test cases rather than definitive surrogates, and their predictive quality deteriorates for larger operators [2507.20007].

A plausible implication is that AxOSyn should be understood primarily as a research infrastructure layer for approximate-computing DSE rather than as a finalized, domain-complete toolchain. The paper itself identifies future directions including broader operator libraries, ASIC support, composite AxOs, approximation-aware training, graph-based architectures and GNNs, and Bayesian optimization [2507.20007].

The name also invites confusion with unrelated systems. In particular, **“synax”** is a differentiable Galactic synchrotron simulator built on JAX and is not an approximate-arithmetic DSE framework [2410.01136]. Likewise, similarly named systems such as **Axon** for tensor-program superoptimization and **AxoNN** for distributed deep learning address entirely different problem domains [2606.26344; 2110.13005]. In the literature cited here, **AxOSyn** specifically denotes the framework for synthesizing and exploring approximate arithmetic operators introduced in 2025 [2507.20007].

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