[AP] Add Nesterov Placer Option

[WilliamZhang20]

Description

Adds a Nesterov-style nonlinear analytical global placer for AP, selectable with:

--ap_global_placer nonlinear-nesterov

(alongside the existing simpl global placer). The placer optimizes a smooth nonlinear objective over movable AP block coordinates:

$$ \min_{x,y}; W_\gamma(x,y) + \lambda\ D(x,y) $$

where $W_\gamma$ is a smooth weighted-average wirelength approximation and $D$ is a continuous, primitive-vector-aware electrostatic bin-density penalty. The optimizer:

• seeds itself from a short B2B/QP warm-start solve so it starts from a wirelength-aware placement,
• runs accelerated first-order Nesterov updates with restart/step-shrink behavior over a small number of density-continuation epochs, partially legalizing between epochs to anchor the result, then
• hands the placement to the existing AP partial legalizer.

It supports timing-aware smooth wirelength weighting:

$$ w_n = \alpha \cdot \mathrm{crit}(n) + (1 - \alpha) $$

where $\alpha =$ --ap_timing_tradeoff and $\mathrm{crit}(n)$ is the pre-cluster setup criticality of the atom net. For designs with long direct I/O-chain nets, it additionally applies a light chain-cohesion term to keep pad/obuf/OCT/termination chains coherent through the AP-to-APPack handoff; this term is gated off automatically for designs without such chains.

Related Issue

Issue #3634

Motivation and Context

This provides a nonlinear first-order alternative to the existing QP/B2B analytical solvers, reusing the existing AP netlist, density manager, and legalization infrastructure. It explores a placer structure closer to modern smooth-wirelength + electrostatic-density formulations while remaining a drop-in --ap_global_placer option.

How Has This Been Tested?

Full paired head-to-head vs the default simpl + lp-b2b AP flow over 69 circuits (VTR, Koios, Titan, Titanium suites, fixed channel widths). Geomean nonlinear-nesterov / b2b (< 1 = nesterov better):

metric	ratio
routed wirelength	0.986
critical-path delay	0.993
total flow runtime	0.964

Nesterov is at or ahead of b2b on all three axes at the geomean; the residual per-circuit CPD outliers are dominated by a single virtual-I/O-clock timing artifact (LU_Network), where core-logic timing is already at parity.

Types of changes

• Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

[AlexandreSinger]

Looks very interesting @WilliamZhang20 !

There are a few things I want to see in order to bring this in.

The most important thing is documentation. I am really not following the algorithm as it is written. I can see and understand the log-sum-exp model used to estimate the smooth-wirelength object, but the way you are modeling density is not clear to me. The overall optimization algorithm is also not very clear to me. I am familiar with Nesterov's method, but the exit condition for the overall algorithm is not very well defined. Most importantly, I would like to see clear documentation on the algorithm that you are using for modeling density. Modelling density in heterogenous FPGAs (which is the common target of VTR) is the most difficult part of AP. This needs to be documented so it can continue to be built on in the future.

The next important thing I need to see is if this algorithm is working and is scaling on more-modern heterogenous FPGAs and benchmarks. The results you mentioned in your comment are from 4 very small circuits from MCNC (which is a benchmark we do not use for quality of results since they are too simple). I am interested to see how the results look on the VTR benchmarks: https://docs.verilogtorouting.org/en/latest/vtr/benchmarks/#vtr-benchmarks

A task list for the VTR benchmarks can be found here: https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/dcaa711dcc615ae999ef37003637d4b3f4148616/vtr_flow/tasks/regression_tests/vtr_reg_nightly_test3/vtr_reg_qor_chain/config/config.txt

I would like to see the wirelength, CPD, and runtime for these circuits and how they compare to the default flow on your machine. This will give us a better understanding of the algorithm.

Feel free to reach out if you have any questions.

[AlexandreSinger]

@vaughnbetz FYI

[vaughnbetz]

Thanks @WilliamZhang20 . To build on what Alex said, I'd want to see more extensive QoR data before merging into master. In addition to the VTR designs, you should run on the Titan designs so you are checking on more than one architecture, and because the Titan designs are larger. Another important suite is Koios, but results on two large suites would be enough to get a good sense of where the algorithm stands and to tune it for now.

You can find the steps to run Titan and check QoR at https://docs.verilogtorouting.org/en/latest/README.developers/#example-titan-benchmarks-qor-measurement . Reading the whole QoR section (just before that) would be a good idea too, to get a sense of the data we watch closely.

[WilliamZhang20]

Latest algorithmic changes include:

• Electrostatic density formulation + DCT Poisson Solve
• Dynamic Fillers + DC Removal
• B2B Warm Start Cycles

QoR results as of July 3, 2026 (TLDR: WL slightly better on all benchmarks; CPD and runtime are the same or slightly worse)
geomean_ratios.csv
ap_headtohead_vtr.xlsx
ap_headtohead_titanium.xlsx
ap_headtohead_titan.xlsx
ap_headtohead_koios.xlsx
ap_headtohead_ALL.xlsx
per_circuit_ratios.csv

[vaughnbetz]

Thanks @WilliamZhang20 . Are crit_path_delay and total_wirelength both post routing?

[WilliamZhang20]

All of Alex's comments have been resolved. Some algorithmic adjustments have resulted in better-than-baseline QoR and runtime geometric mean across all benchmarks tested.

However, some outliers are likely an obstacle to further improvement without extending the scope, LU_Network being one of the worst (apparently due to I/O Chains). However, for those outliers and other examples, the WL and CPD are actually better than B2B after full legalization, but the gains get eroded by packing and/or detailed placement.

Overall Table (ratios wrt B2B): - updated 7/10/2026

Benchmark suite	Circuits	Routed WL	Critical-path delay	Total VPR runtime	AP runtime	Pack + place runtime	Routing runtime
VTR	8	0.990	1.009	0.980	0.969	1.088	1.065
Koios	29	0.994	0.987	0.975	0.968	1.022	1.028
Titan	22	0.993	1.020	0.947	0.941	1.031	0.999
Titanium	16	0.985	0.990	0.966	0.963	1.020	0.978
All	75	0.991	0.999	0.965	0.959	1.031	1.012

Omitted Benchmark Circuits:

• From Titan:
  • gaussianblur
• Koios:
  • bwave_like.fixed.large (apparently hit a VPR error on both B2B and nesterov)

Post Full-Legalization Ratios: (out of date, from 7/9/2026)
titan_cpd_erosion.xlsx

Raw Data: (out of date, from 7/9/2026)
ap_headtohead_vtr.xlsx
ap_headtohead_titanium.xlsx
ap_headtohead_titan.xlsx
ap_headtohead_koios.xlsx
ap_headtohead_ALL.xlsx

[vaughnbetz]

Thanks William. Can you also add the runtime ratios to the summary (e.g. total flow, ap, total pack + place).VaughnOn Jul 9, 2026, at 10:24 AM, William Zhang ***@***.***> wrote:WilliamZhang20 left a comment (verilog-to-routing/vtr-verilog-to-routing#3641) All of Alex's comments have been resolved. Some algorithmic adjustments have resulted in better than baseline QoR and runtime geometric mean across all benchmarks tested. However, some outliers are likely an obstacle to further improvement without extending the scope, LU_Network being one of the worst (apparently due to I/O Chains). However, for those outliers and other examples, the WL and CPD are actually better than B2B after full legalization, but the gains get eroded by packing and/or detailed placement. Overall Table: Benchmark suite Circuits Routed WL Critical-path delay VTR 8 0.992 1.029 Koios 24 0.979 0.963 Titan 21 0.993 1.018 Titanium 16 0.985 0.990 All 69 0.986 0.993 Post Full-Legalization Ratios: titan_cpd_erosion.xlsx Raw Data: ap_headtohead_vtr.xlsx ap_headtohead_titanium.xlsx ap_headtohead_titan.xlsx ap_headtohead_koios.xlsx ap_headtohead_ALL.xlsx —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[AlexandreSinger]

@WilliamZhang20 Why were those circuits ommited? Many of those are some of the larger circuits. You ommited 6 of the around 30 koios benchmarks. Ommiting sparcT1_chip2 seems a bit random to drop out?

Also in you major summary, I am interested to see the post-GP WL and CPD estimates for the different benchmarks. I want to know if the gains are coming from the global placer or if they are coming from the interaction with the full-legalizer and detailed placer.

Edit: Can you also report the device width. This is just a curiosity on my part. If you are not fixing the device widths, you may get different device widths; making the two algorithms less comparable. The device width is calculated from the packing (full legalization solution), so it can change based on the global placement.

[WilliamZhang20]

Added runtime ratios to the previous comment above. A table showing where the gains come from is below via ratios wrt. B2B. For CPD (the weak point), I see that gains come from full legalization and are weakened after detailed placement & routing.
Fixing the device width ended up changing VTR, as reflected below. The table below also accounts for sparcT1_chip2.

Wirelength (HPWL est. through post_dp, routed WL at final)

Suite	N	post_gp	post_fl	post_dp	final (routed)
VTR	8	1.010	0.957	0.990	0.990
Koios	24	1.000	0.982	0.993	0.994
Titan	22	1.041	0.987	0.991	0.993
Titanium	16	1.038	0.988	0.984	0.984
All	70	1.023	0.982	0.990	0.991

Critical-path delay (estimated through post_dp, routed at final)

Suite	N	post_gp	post_fl	post_dp	final (routed)
VTR	8	0.978	1.024	1.006	1.009
Koios	24	1.001	0.972	0.982	0.979
Titan	22	1.001	0.985	1.016	1.020
Titanium	16	1.021	0.958	0.965	0.990
All	70	1.003	0.979	0.991	0.997

[vaughnbetz]

Thanks. Looks like it might be a 5% faster AP stage with roughly the same QoR.

[WilliamZhang20]

@AlexandreSinger @vaughnbetz Thank you. What would be the conditions for merging this PR? I believe that modifying later stages to account for the downstream degradation of QoR would be done in a separate PR.