360 likes | 480 Views
Methodology from Chaos in IC Implementation. Kwangok Jeong * and Andrew B. Kahng *,** * ECE Dept., UC San Diego ** CSE Dept., UC San Diego. Outline. Motivation Assessment of “Chaos” Exploitation of “Chaotic” behavior Conclusion. Motivation.
E N D
Methodology from Chaos in IC Implementation Kwangok Jeong* and Andrew B. Kahng*,** * ECE Dept., UC San Diego ** CSE Dept., UC San Diego
Outline • Motivation • Assessment of “Chaos” • Exploitation of “Chaotic” behavior • Conclusion
Motivation • Chip implementation flow is a “Chaos Machine” (Ward Vercruysse, Sun Microsystems, ISPD97 talk) • Hard to predict behavior of back-end implementation • “Inherent noise” (Kahng/Mantik, ISQED-2001) • Equivalent inputs to tools result in different outputs • Algorithms and EDA tools are not deterministic or predictable • Most design optimization problems are NP-hard Heuristic-based approaches • Physical phenomena are too complex Simplified models How to exploit “chaotic behavior”
Scope of This Work • We assess “chaotic” behavior in design process • When it occurs in design processes • Post-synthesis vs. post-routing • Place- and-route tools’ view vs. signoff tools view • What user inputs affect it most • Input parameter sensitivity to synthesis tools • Input parameter sensitivity to place-and-route tools • We propose a practical method to exploit “chaos” in EDA tools, based on empirical analyses • Sensitivity of input parameters to outcomes Find safe/easy knobs that don’t change netlists/libraries • Best-of-k: multi-start, multi-run methodologies
Outline • Motivation • Assessment of “Chaos” • Exploitation of “Chaotic” behavior • Conclusion
Analysis 1: Synthesis vs. Place-and-Route • How strongly correlated are post-synthesis netlist quality and post-routing design quality? • Timing quality of synthesized netlists vs. timing quality after placement and routing, and signoff *AES design Worst quality netlist can result in best quality!
Analysis 2: Implementation Vs. Signoff • How strongly correlated are P&R and signoff ? • Timing miscorrelation • Delay calculation • RC parasitic Implementation Worst negative slack comparison from 29 testcases ~200ps underestimation Signoff
Beyond Miscorrelation Issues • Kahng and Mantik 2001 – “Noise” • Equivalent inputs result in different outputs • Changing seeds of random number generators • Changing cell/net ordering • Renaming cell instances • Perturbing design hierarchy • Injecting “noise” is practically difficult • Our focus – “Chaos” • Negligible change of inputs Large change in outputs • E.g., 0.1ps changes affect design quality significantly *JPEG design 89ps difference
What Inputs Can Be Perturbed? • Tool-specific options: command options to turn on/off • Not our concern, since these are tool-dependent • Design-specific constraints: • These knobs do not change design signatures easy and safe knobs to perturb
Testbed • Designs • Implemented with TSMC 65nm GPLUS library • Tools
Analysis 3: Noise in Synthesis – Timing • What chaotic behavior is associated with input parameters of vendor synthesis tools? • Ideally, results should not vary significantly However, worst negative slack can change by up to 52ps (DesignCompiler) WNS (ns)
Analysis 3: Noise in Synthesis – Area • What chaotic behavior is associated with input parameters of vendor synthesis tools? • Synthesized area can change by up to 6% (DesignCompiler) Normalized Area (%)
Analysis 4: Noise in P&R Tools • What chaotic behavior is associated with input parameters of vendor place-and-route tools? • Noise at place-and-route stage is even worse! • WNS and TNS can change by up to 165ps and 46ns Astro WNS (ns)
Analysis 4: Noise in P&R Tools • What chaotic behavior is associated with input parameters of vendor place-and-route tools? • Noise at place-and-route stage is even worse! • WNS and TNS can change by up to 190ps and 69ns • Area can change by up to 16.4% SOC Encounter WNS (ns)
Outline • Motivation • Assessment of “Chaos” • Exploitation of “Chaotic” behavior • Conclusion
Exploiting Noise in Design Flow • Multi-start and multi-run • When there are idle machines in the compute farm Multi-start: After running on k distinct machines with ignorable perturbations of inputs, choose best out of k different solutions • When there are remaining timing-to-market • Multi-run: After running k sequential jobs with ignorable perturbations of inputs, choose best out of k different solutions • Best-of-k method • Find the best solution from many trials • Larger k better best solution • How to determine k that produces predictably good results?
Best-of-k Using Sampling • Which k results in consistent, reasonably good solution? • To obtain statistics: “set of k trials” should be performed a large number (N) of times, for each value of k • Naive procedure: • for each k, • Perform k trials by N times • sk average of best solutions • For large N, sk is the expected (average) best solution, when we perform k trials • Example: • k = {1, 2, 3, 4, 5, 10}, N = 100 • 2,500 separate runs • Many runs are required! • Best-of-k sampling procedure: • // find “virtual” solution space • Perform N’ trials (N’ < N) • Record solutions set of solutions S • // best-of-k sampling • for each k • sample k solutions out of S, N different times • sk average of best solutions • Example: • N’ = 50 • (Sampling from S does not add cost)
Application of Best-of-k Sampling(1) • Find best input parameters to perturb using best-of-k sampling • k = 1, 2, 3, …, 10, and N =100 5,500 exp. in naive procedure • S = 7 solutions from each of T, S, B, A, U perturbations • Quality rank of input parameters in P&R • E.g.) AES: clock cycle (T) or input/output delay (B) perturbations result in best solution quality *AES design *EXU design
Application of Best-of-k Sampling (2) • Solution quality versus number of trials “k” (with N = 100) • Average solution quality approaches the best solution as “k” increases • Average solution quality is significantly better than worst possible solution quality best-of-k can avoid bad luck • Best-of-3 shows reasonably good solutions LSU AES EXU JPEG
Conclusion and Ongoing Work • Experimental assessment of “chaotic” behavior in commercial EDA tools • Miscorrelation issues between design stages are well-known • Exploiting chaos: Intentional negligible input perturbations can significantly change outputs • Proposed a methodology to exploit the chaotic tool behavior • “best-of-k”: multi-start / multi-run methodology • Efficient sampling method to determine the best number of trials • We also find best input parameters to perturb using best-of-k sampling • Ongoing work • Analysis of potential advantages of “chaos” in advanced physical synthesis tools to reduce miscorrelation-related issues • Evaluation of the benefits of chaos in more advanced signoff methodologies (signal integrity-enabled, path-based STA)
Potential Cause 1 • Miscorrelation between synthesis and place-and-route • Rank correlation of timing critical paths between synthesis and placement: 0.421 Not critical at synthesis, Critical at placement *AES design
Potential Cause 2: Parasitic Miscorrelation • Miscorrelation in delay calculation • With same RC parasitic file (.spef) • May not be a major problem: A few tens of picoseconds difference • Miscorrelation in RC extraction • Implementation tool can underestimate capacitance by 18.6% Implementation Signoff
Inherent Noise: Detailed Results • Noise is really random! Difficult to predict • Red texts are the best in each group