1. On Mismatches Between Incremental Optimizers and Instance Perturbation in Physical Design Tools Andrew B. Kahng and Stefanus Mantik UCSD CSE & ECE Depts., La Jolla, CA UCLA CS Dept., Los Angeles, CA abk@ucsd.edu, stefanus@cs.ucla.edu Supported by MARCO GSRC and Cadence Design Systems, Inc.

2. Emerging Need for Incremental Optimizers Design size , complexity , time-to-market  –reuse of design IP –timing closure (layout-logic synthesis unifications) Construct-by-correction flow –placement  timing analysis  timing optimization –netlist changes (repeaters, resizing, clock) = ECO’s Incremental optimization is needed –use previous solution as the starting point –ideally, next solution remains similar while maintaining quality

3. Incremental Optimization An original instance, I 0, is solved by a full algorithm to yield solution S 0 Perturbed instances, I 1, …, I n,are generated one by one in sequence (I i = I i-1 +  I i, i = 1, …, n; |  I i | = perturbation size) Each perturbed instance is solved by an incremental algorithm which uses S i-1 as the starting point for finding solution S i, i = 1, …, n

4. Related Works Physical Design Roadmap [itrs99] –incremental optimization has been a stated need in the roadmap (NTRS, ITRS) since 1997 –incremental optimization is needed for future technology (www.itrs.net) Incremental optimization –incremental optimization formulations in physical design [CongSarrafzadeh00] Problem-space metaheuristic –idea: change objective function to escape local minima [Hajek88, StorerWuVaccari92, OsmanKelly96]

5. Outline Potential mismatch: instance perturbation vs. optimizer strength Experimental design Experimental results –partitioning –placement –routing Conclusions and future work

6. Does the Size of  I Matter? S0S0 S1S1 I1I1 S2S2 S1S1 I2I2 Size of  I matters!

7. Potential Mismatch: Instance Perturbation vs. Optimizer Strength Consider the sequence of instances I 0, I 1, …, I n and solutions S 0, S 1, …, S n : Can the quality of solution S n be worse than that of solution S 0 ? If so, can the decrease in solution quality be attributed to: –aspects of the sequence I 0, I 1, …, I n (in particular, the “distance” between successive instances)? –aspects of the incremental algorithm (in particular, its “strength” or “weakness”)?

8. Experimental Hypotheses: Perturbation Size vs. Optimizer Strength A strong incremental algorithm + small changes  maintain good solution quality but waste computational resources A weak incremental algorithm + large changes  steadily worsening solution Instance changes must be compatible with the strength of the incremental algorithm –must escape basins of attraction to find good solutions –but, should not waste extra computational resources

9. Experimental Design Are current incremental algorithms capable of escaping from a basin of attraction? –Reversal-based experiment construct a series of instances I 0, …, I k-1, I k, I k+1, …, I 2k where I 0 = I 2k, I 1 = I 2k-1, etc. S 2k is better than S 0 ? Does the size of perturbation  I have any effect on the quality of the solution? –Dicing-based experiment break  I into smaller perturbations (  I =  1 +  2 + … +  m, I  = I 0 +  I, I  1 = I 0 +  1, I  2 = I  1 +  2,..., I  m = I  m-1 +  m ) S  m is better than S  ?

10. Instance: netlist hypergraphs Perturbation: weight changes for hyperedge weights Incremental optimizer: UCLA MLPartitioner Experiments in Partitioning Domain Near best-known quality Problem-space metaheuristic approach is very effective

11. Instance: circuit netlists Perturbation: random deletion of cells Incremental optimizer: Cadence QPlace in incremental mode (optimization level = 3) Experiments in Placement Domain Incremental placement algorithm is too strong

12. Experiments in Routing Domain Instance: placed circuit netlists Perturbation: changes in cell orientations Incremental optimizer: Cadence WarpRoute in incremental mode Incremental routing seems difficult!

13. Dicing Experiment Results for Routing Perturbation size should be sufficiently large before applying incremental optimization 3.54+e06 3.52+e06 3.50+e06 3.48+e06 3.46+e06 3.44+e06 3.42+e06 020040060080010001200 # Flipped Cells Wirelength One big perturbation Multiple small perturbations

14. Conclusions and Ongoing Work Current design tools may not be correctly architected to handle incremental optimizations –problem-space metaheuristic approach may be very effective for partitioning –incremental placement algorithms are too strong –perturbation size should be large before attempting incremental routing Ongoing research: –finding incremental algorithms that are sensitive to perturbation size and that preserve solution structure –V-cycling based incremental partitioning and top-down placement –distinguish incrementality w.r.t. objective from incrementality w.r.t. instance structure