Response to Reviewer tJhd

We sincerely thank you for your careful review and for your constructive, insightful, and valuable comments. Please find below our detailed responses to your inquiries.

Weakness 1 & Weakness 2: Integrating with Prior Works

It would be better to demonstrate the effectiveness of the proposed interconnection design by integrating the proposal with other prior works.

Thank you for your valuable suggestion! In response, we have integrated our proposed interconnection generation method into two representative learning-to-optimize arithmetic circuit optimization frameworks: RL-MUL [1] and ArithTreeRL [2], and report the results in the table below.

1. Why We Build Our Approach Upon MUTE

As noted in the main paper, our method ARITH-DAS is implemented atop the MUTE framework. This decision is motivated by two primary considerations.

First, MUTE represents one of the most recent and competitive State-of-the-Art (SOTA) methods for arithmetic circuit optimization. It provides a solid and well-maintained baseline, with strong performance across various circuit configurations, making it a reliable foundation for developing and benchmarking our proposed interconnection strategy.

Second, the evolutionary nature of MUTE is particularly advantageous for our learning framework. Evolutionary methods inherently explore a broader and more diverse design space compared to purely gradient-based or heuristic approaches. This diversity of intermediate designs generated during the evolution process enables the collection of a larger and more representative training set, which is crucial for effectively learning a generalizable and robust interconnection policy. As a result, MUTE not only provides a strong backbone for implementation but also naturally facilitates the data-driven learning required by our method.

2. Integrating Our Interconnection Approach with Prior Works

As demonstrated in the main paper, our method is modular and compatible with other learning-to-optimize frameworks as well. Specifically, we integrate our pre-trained model and corresponding interconnection generation strategy into the full Verilog synthesis pipeline of both RL-MUL and ArithTreeRL. RL-MUL is a Deep Q-Network (DQN)-based method that sequentially refines a pre-defined compression tree structure, such as a Wallace Tree, by making local decisions. In contrast, ArithTreeRL employs a Proxy-Policy Gradient approach to construct the entire compressor tree from scratch. In both methods, the original handcrafted sequential interconnection policy is replaced by our pre-trained interconnection generator. Notably, ArithTreeRL is already included as a baseline in our main paper.

To ensure fairness and tractability given limited compute resources, we evaluate both original frameworks and their integrated versions on two widely used multipliers, 16-bit and 32-bit AND multipliers. The results in the table above show that our interconnection design substantially improves the hypervolume (HV) for 16-bit designs, and notably enhances the 32-bit designs as well.

We attribute the larger gains in the 16-bit case to its smaller design space, where interconnection quality plays a more dominant role. In contrast, the 32-bit design space is much broader, and the relative impact of interconnect optimization is partially diluted by other factors. Nevertheless, the improvements are consistent across both scales, validating the generalizability and effectiveness of our method.

Question 2: Area Comparison with MUTE

Is there any difference between the two methods while searching compressor trees, or does the difference of area come from the stochasticity of the evolution-based method?

1. Reason for the Better Area Metric of ARITH-DAS

Our method leverages the MUTE framework as the compressor allocation search engine, and we do not alter its evolutionary search algorithm. The difference observed in the area metric is partially attributable to the inherent stochasticity of the evolution-based search, which relies on randomized mutation and selection operations. Small variations introduced at intermediate generations may propagate through the search process, ultimately leading to different final designs.

However, the major factor underlying the area difference lies in the objective setting. Both our method and MUTE adopt the same bi-objective optimization formulation:

where $\operatorname{area}(\mathcal{G})$ and $\operatorname{delay}(\mathcal{G})$ represent the synthesized area and delay of a compressor tree $\mathcal{G}$, and $w_1, w_2$ control the trade-off. Because the objective function is a weighted sum, a design with excellent area but suboptimal delay may be discarded during the search if its overall weighted cost is not competitive. In our method, the pre-trained interconnection generator performs targeted optimizations that directly improve the delay of the generated compressor trees. This delay improvement increases the likelihood that certain candidates are retained and refined in later generations. Over multiple iterations, this mechanism shifts the distribution of surviving designs and may result in final circuits that are superior in both delay and, indirectly, area metrics.

Compared with other methods that directly optimize the area metric alone, such as GOMIL and UFO-MAC, neither MUTE nor our ARITH-DAS is guaranteed to always favor the design with the smallest area. Instead, designs that strike a better trade-off between area and delay tend to be preserved and further refined by the evolutionary search.

2. Numerical Example

To illustrate this more concretely, suppose $w_1=w_2=0.5$, and consider two candidate designs $A$ and $B$:

• $\operatorname{area}(A) = 2, \operatorname{delay}(A) = 2, - R(A) = 2$.
• $\operatorname{area}(B) = 1, \operatorname{delay}(B) = 4, - R(B) = 2.5$.

Under the combined cost function, design $A$ would be the preferred candidate for both MUTE and ARITH-DAS, despite its slightly larger area, because its overall weighted cost is lower.

However, ARITH-DAS integrates a delay-aware interconnection generator, and the delay performance of candidate designs is further improved. For example, for the same compressor tree allocation with design $B$, ARITH-DAS optimized interconnection topology and produces a new design $B'$:

• $\operatorname{area}(B') = 1, \operatorname{delay}(B') = 2, - R(A) = 1.5$.

Now, the improved design $B'$ achieves a much lower combined cost than $A$. As a result, ARITH-DAS would preserve $B'$ in the evolutionary search, whereas MUTE would have previously discarded $B$ due to its high delay. Over multiple iterations, this mechanism enables ARITH-DAS to retain and refine higher-quality solutions that strike a better balance between area and delay, ultimately leading to superior final designs.

Reference

[1] Zuo D, Ouyang Y, Ma Y. Rl-mul: Multiplier design optimization with deep reinforcement learning[C]//2023 60th ACM/IEEE Design Automation Conference (DAC). IEEE, 2023: 1-6.

[2] Lai Y, Liu J, Pan D Z, et al. Scalable and effective arithmetic tree generation for adder and multiplier designs[J]. Advances in Neural Information Processing Systems, 2024, 37: 139151-139178.

Response to Reviewer CFYW

We sincerely thank you for your careful review and for your constructive, insightful, and valuable comments. Please find below our detailed responses to your inquiries.

Weakness 1: More Details About Compressor Allocation Matrix

Some details of ARITH-DAS are not fully explained. For example, the matrix of allocation $\mathbf{s}$ is mentioned without further demonstration.

Thank you for your valuable suggestion! We provide further demonstration of the compressor allocation matrix below, and we will add a dedicated subsection in the revised version of our paper to clarify its definition, role, and how it interacts with the rest of the framework.

1. Further Demonstration for Compressor Allocation Matrix $\mathbf{s}$ and Seach Space $\mathbb{S}$

For a compressor tree with bit-width $N$ and $T$ types of different compressors, where $N,T\in \mathbb{N} _+$, the allocation matrix $\mathbf{s}\in\mathbb{N} _ +^{T\times N}$ stands for the number of specific compressors allocated in the column:

Here, $s_{t,n}$ denotes the number of compressors of type $t$ allocated at bit column $n$. Different choices of $\mathbf{s}$ define different compressor tree configurations, and the collection of all valid allocation matrices forms the allocation-level search space $\mathbb{S} \subset \mathbb{N} _+^{T\times N}$.

In our case and all the baselines, we employ two different types of compressors and therefore $T=2$. Without loss of generality, $t=1$ stands for 3:2 Compressor, and $t=2$ stands for 2:2 Compressor. Let $\mathbf{p}\in\mathbb{N}_+^{N}$ denote the partial product array, which is a fixed matrix when given input bit-width and encoding circuit. For example, $\mathbf{p} = [1, 2, 3, 4, 3, 2, 1]^\top$ for a 4-bit AND multiplier as illustrated in Figure 1 in the main paper. All allocation matrices $\mathbf{s}\in\mathbb{S}$ should satisfy the following constraints to ensure valid compressor tree reduction:

These constraints guarantee that at each bit column, the number of remaining signals after compression is feasible for a prefix-adder.

2. How $\mathbf{s}$ Interacts with the DAG and the Rest of the Framework

In ARITH-DAS, the allocation matrix $\mathbf{s} \in \mathbb{S}$ defines the architectural backbone of the compressor tree and determines the search space for subsequent interconnection optimization.

Once a valid $\mathbf{s} \in \mathbb{S}$ is sampled by the Circuit Genetic Evolution (CGE) module, each compressor is assigned a stage number represented by $\mathcal{S}\in \mathbb{N} _{+}^{S\times T\times N}$, where:

The number of remaining partial products at stage $i$ and column $n$ is then updated as:

where $\mathbf{P} _{i,n}\in \mathbb{N} _+$ is the remaining partial products at stage $i$.

In our algorithm, we first greedily assign as many 3:2 Compressors as possible, and then assign 2:2 Compressors if needed. Since each compressor is associated with a specific stage number, we enforce that compressors may only connect to compressors in the subsequent stages, thus forming a DAG (directed acyclic graph) search space. This additional explanation will be added to Appendix C.3.2 in the revised version.

The DAG derived from $\mathbf{s}$ enumerates the valid connection candidates among instantiated nodes. The interconnection optimization module then predicts fine-grained edges on top of this DAG under legality constraints (acyclicity, stage order, and port compatibility). Therefore, $\mathbf{s}$ determines the node set and connection options, thus constraining the fine-grained search space of ARITH-DAS.

In summary, the allocation matrix $\mathbf{s}$ defines the coarse-grained search space (compressor allocation) and establishes the structural foundation for the fine-grained interconnection search. We will add this clarification in the revised version to make the explanation more intuitive.

Weakness 2: Missing Critical Reference

There is one paper: Reinforcement Learning for Combinatorial Optimization [1] which might be associated with this submission

We have carefully read the reference you provided and found it to be an excellent work that is highly relevant to our study. We have added a citation to this work in the revised version of our paper. Thank you again for bringing it to our attention!

Reference

[1] Darvariu, Victor-Alexandru, Stephen Hailes, and Mirco Musolesi. "Graph reinforcement learning for combinatorial optimization: A survey and unifying perspective." arXiv preprint arXiv:2404.06492 (2024).

Response to Reviewer B7rW

We sincerely thank you for your careful review and for your constructive, insightful, and valuable comments. Please find below our detailed responses to your inquiries.

Weakness 1 & Limitation 1: Plugging into the Full Design Flow

The proposed work is "proxy-free" in the sense of synthesis results. What about plugging into the full design flow?

We sincerely thank you for your valuable suggestions. We have integrated our framework, along with all baseline methods, into the complete design flow, and present the corresponding results in the table below.

1. Rationale for Using Post-Synthesis Metrics

Our framework can be seamlessly integrated into the full design flow, encompassing floorplanning, placement, clock tree synthesis, and routing. However, executing the complete flow is computationally intensive, and the resulting metrics are often highly sensitive to hyperparameter settings. Consequently, post-synthesis metrics have become the de facto standard in prior works [1,2,3], which we also adopt to ensure a fair and consistent comparison.

2. Integration into the Full Design Flow

We integrate our framework into the full design flow and summarize the results in the table above. Due to limited runtime and computation resources, we evaluate the full flow on 16-bit AND multipliers and 32-bit AND multipliers as representatives.

Specifically, we build upon the test/flow.tcl script from the OpenROAD project to complete the EDA backend workflow, which includes initialize_floorplan, tapcell, pdngen, place_pins, global_placement, detailed_placement, clock_tree_synthesis, global_route, and other essential stages. During the flow, the floorplan is initialized with $0.88$ utilization as suggested by the OpenROAD tool, and aspect_ratio is set to $1.0$. The global placement density is set to $0.3$ for a faster evaluation, as the default in the test/flow.tcl script.

3. Discussion on the Proxy-Gap

The longer and more complex the backend synthesis flow, the larger the proxy gap tends to be in proxy-based methods. This is primarily due to the intricate processing stages and optimization algorithms in the backend, which make it difficult to accurately approximate final outcomes using proxy objectives at the frontend, especially when the results are highly sensitive to backend parameters.

To further illustrate the impact of the proxy gap, we compute the average relative improvement of proxy-based and proxy-free methods with or without full design flow. Then we compare the relative gains before and after incorporating the full flow. As detailed in the table below, we observe that proxy-based methods exhibit smaller relative gains after applying the full design flow, highlighting the limitations of proxy objectives in capturing backend-accurate performance.

Weakness 2: Missing Large-Scale Computing Circuits Pareto/area Results

However, with the large-scale computing circuits, the results are limited to the delay reduction only. What is the main reason that area (or more generally, Pareto frontiers) are not shown here?

1. On the Omission of Area Metrics in the Main Paper

First, due to space constraints, we report the area metrics of the large-scale computing circuit in Table 10 of Appendix D, as our primary focus lies in interconnection optimization, where delay is the most relevant performance metric. Second, a complete computing system comprises not only arithmetic circuits but also control logic, I/O interfaces, memory blocks, and other components. Consequently, area optimization within arithmetic submodules has a limited impact on the overall area. For this reason, we present area-related results in the appendix rather than in the main text.

2. On the Absence of Full Pareto Frontier Results

First, evaluating complete Pareto frontiers requires extensive experimentation, but logic synthesis and simulation of large-scale computing circuits are extremely time-consuming and computationally expensive. To balance feasibility and thoroughness, we conduct a full Pareto frontier evaluation only on a commonly shared computational structure, the Processing Element (PE) array, following previous works [1, 2]. The corresponding results are presented in Figure 7 of Section 5.3.

Second, as noted earlier, large-scale computing circuits are composed of multiple heterogeneous substructures. Area optimization on arithmetic circuits alone often yields limited overall area improvement. Therefore, we focus on the delay metric and omit the full Pareto frontier analysis for the entire large-scale design.

Weakness 3: Runtime for Ablation Study

Can the authors add the runtime difference when these key modules are not considered, since the current total runtime is not outperforming certain baselines?

Thanks for your suggestion. We conclude the runtime for the ablation study, where several key modules are removed, in the following table. We will add those results in the revised version of our submission.

Weakness 4: Typos

Certain typos are found.

We appreciate your careful reading and helpful feedback. The typo has been corrected. We have also conducted a thorough proofreading to eliminate similar minor errors throughout the paper.

Reference

[1] Zuo D, Ouyang Y, Ma Y. Rl-mul: Multiplier design optimization with deep reinforcement learning[C]//2023 60th ACM/IEEE Design Automation Conference (DAC). IEEE, 2023: 1-6.

[2] Wang Z, Wang J, Zuo D, et al. A hierarchical adaptive multi-task reinforcement learning framework for multiplier circuit design[C]//Forty-first International Conference on Machine Learning. 2024.

[3] Xiao W, Qian W, Liu W. GOMIL: Global optimization of multiplier by integer linear programming[C]//2021 Design, Automation & Test in Europe Conference & Exhibition (DATE). IEEE, 2021: 374-379.