going with the flow bridging the gap between theory and
play

Going with the Flow: Bridging the Gap between Theory and Practice - PowerPoint PPT Presentation

Going with the Flow: Bridging the Gap between Theory and Practice in Physical Design Patrick Groeneveld, Chief Technologist, Magma Design Automation ISPD 2010 San Francisco Overview: Physical Design Flows The Nature of the PD problem


  1. Going with the Flow: Bridging the Gap between Theory and Practice in Physical Design Patrick Groeneveld, Chief Technologist, Magma Design Automation ISPD 2010 San Francisco

  2. Overview: Physical Design Flows • The Nature of the PD problem • Objectives • Algorithms • How to build a flow • ABC • Tough problems: • Crosstalk-induced delay • Proof of efficacy March 15, 2010 – Patrick Groeneveld - ISPD 2010- 2

  3. Physical Design Flow: from logic to physical Placement CDFG Net list of Hyper Cells March 15, 2010 – Patrick Groeneveld - ISPD 2010- 3

  4. Synthesis is from Mars, Analysis is from Venus • Sign-off • Implementation tools: tools: • Verification, • RTL synthesis, Extraction, Placement, STA, Routing, spice, DRC, Optimization, LVS Humans • Highly accurate • Poor accuracy • Big and slow • Lean, mean • Parallelizable • Tough • Is the ‘whiner’ • Is the ‘hacker’ Need to make this work March 15, 2010 – Patrick Groeneveld - ISPD 2010- 4

  5. Making this work in a Physical Synthesis Flow Formal Mapping Iterate: Verification Buffering Global-level Global placer timer Global router Congestion Gate resizing prediction Clock Tree S. Timer & Gate rewiring Extractor • Avoid loops: Gate buffering • Gradual, Stepwise refinement Detailed placer • ABC flows Sign-off • Speed up loops: Track router DRC checker • Reducing analysis accuracy Detailed router • Tricks: incremental analysis Sign-off Timer • Running tasks in parallel Detailed Finesim- • Tight tool integration optimization Spice March 15, 2010 – Patrick Groeneveld - ISPD 2010- 5

  6. Physical Design: Trade-offs between conflicting objectives March 15, 2010 – Patrick Groeneveld - ISPD 2010- 6

  7. The nature of the Physical Design ‘beast’ Pushing all objectives simultaneously costs: • Human design effort, • Run time Runtime, design effort quality Speed, power, etc. March 15, 2010 – Patrick Groeneveld - ISPD 2010- 7

  8. Building a Physical Design Flow Observation 1: Need gradual refinement flow Formal Mapping Verification using many algorithms Buffering Global-level Global placer timer Observation 2: Global router Synthesis algorithms need Gate resizing highly simplified models of reality Clock Tree S. Timer & Gate rewiring Extractor Observation 3: Gate buffering Synthesis algorithms cannot deliver Detailed placer good multi-objective trade-offs Sign-off Track router DRC checker Detailed router Sign-off Observation 4: Timer Detailed opt. Finesim- Optimizing a single objective often Spice makes other objectives worse. March 15, 2010 – Patrick Groeneveld - ISPD 2010- 8

  9. The ABC of a Physical Design Flow March 15, 2010 – Patrick Groeneveld - 9

  10. Example ABC: Combating crosstalk delay • A void: using ‘pessimism’: • Size up all drivers: Costs cell area and power • Force double spacing NDR on many nets: Costs congestion = area • B uild: Wire cap: • Some routing tricks to spread & jog wires 50fF , of which 30-80% is to • C orrect using ECO: neighbors • gate re-sizing, buffering Gate input • Re-routing cap: 4fF March 15, 2010 – Patrick Groeneveld - 10

  11. A voidance vs. C orrection: masks Physical Synthesis System Floorplanning Logic Synthesis • A void: Placement • DRC deck with ‘hard’ rules Global routing • B uild: Optimization Routing • Dijkstra grid expansion + hacks • C orrect: GDS2 • Analyze using DRC, CAA, LPC • Fix incrementally using R&R • How many failures are acceptable? • < 100 violations: Manual fixes are feasible • 1000-10000 violations: Automatic ECO-style fixes, rip-up and reroute • > 10,000 violations ??????? CMP CAA LPC March 15, 2010 – Patrick Groeneveld - ISPD 2010- 11

  12. Controlling the amount of c orrection Objectives P robability Needs C orrection D istribution F unction Physical Design Flow Run flow designer fail pass • Relax the objective • More A voidance (pessimism) • Which might deteriorate other objectives March 15, 2010 – Patrick Groeneveld - ISPD 2010- 12

  13. Local Optima in a Physical Design Flow Floorplanning Logic Synthesis Placement Global routing Optimization Routing Cost Solution March 15, 2010 – Patrick Groeneveld - ISPD 2010- 13

  14. The Physical Design Flow as a Pachinko Machine • Run flow: • End up an one of the local optima. • Re-run: • typically get same results • (Multi-processing alert!!) • Re-run with small change • Could be significant difference • Changes: • Irrelevant order changes • Additional steps/algorithms • Changing constraints, tuning, etc. • Good/bad results depend on: • ‘ease’ of the design • Flow set-up/tuning • Design structure (e.g. data paths) • Coincidence March 15, 2010 – Patrick Groeneveld - ISPD 2010- 14

  15. How to tune the flow? • Tuning of the TCL script • First time: Design run.tcl • Poor local optimum, bugs, data mistakes • Tune flow+data Run tool • Better local optimum. flow • But: Analyze results • Loop is slow • Tool talks gibberish Timing • Result depend on experience report of engineer. • Hacks are design-specific March 15, 2010 – Patrick Groeneveld - ISPD 2010- 15

  16. PD Flow tuning for best out-of-the-box results • Goal: • Improving the chance of ending up in a good local optimum. (that is: move the mean for better QOR) • That requires: • Good understanding of cause, actions, side-effects • Statistical evidence of efficacy • Issue: • Effects and side-effects are hard to predict • How to distinguish design-specific noise from real improvements? March 15, 2010 – Patrick Groeneveld - ISPD 2010- 16

  17. Medical tools vs. Physical design tools • New drug • New flow component • Biological model of cause, • Based on electrical/ actions and side-effects physical plausability • Develop it • Program it (C++/TCL) • Test tube test • Unit test • Test on animals • Test on small testcases • Efficacy, • Debug program • side effects • Efficacy, side effects • Clinical trials • Beta test • Large double-blind placebo • Hope that customers use it -controlled tests • Deployment • FDA-approval • Go for it! “Engineers: think it, build it, demo it, declare victory” March 15, 2010 – Patrick Groeneveld - ISPD 2010- 17

  18. Lack of evidence = quackery Physical Design is not exempt`: • Structured placement • Thermal-driven placement • Plug ‘n play tool interoperability • Running PD tools in parallel on a GPU. • Gridless routing • X-Architecture March 15, 2010 – Patrick Groeneveld - ISPD 2010- 18

  19. Apply skeptical wisdom • “Humans are amazingly good at self-deception” • This looks soooo good, therefore this must work • “If it has no side effects, it probably has no effects either” • Example: improving temperature gradients will cost timing you! Are you really willing to pay based on the evidence? • “Do not confuse association with causation” • “I took this airborne pill, and I did not get sick” • “I used this DFM optimizer, and the chip yields! • “The plural of ‘anecdote’ is ‘anecdotes’, not data” • Result could be a random effect, or another side effect • No substitute for unbiased placebo-controlled tests • Only large data sets are statistically relevant March 15, 2010 – Patrick Groeneveld - ISPD 2010- 19

  20. Coarse-grain partitioning to speed up place Assemble Partition/budget Build each block in parallel March 15, 2010 – Patrick Groeneveld - ISPD 2010- 20

  21. Summary: it’s the flow, not the algorithm! • Need to deal with conflicting objectives • Careful tuning of: • Clever A voidance (as little as surgical as needed) • Incremental C orrection. • Need to focus on the dominant issues: • Timing: very poor delay predictability • Design scale: keeping up with Moore’s law • Be skeptical and honest! • Negative results are as important and positive! March 15, 2010 – Patrick Groeneveld - ISPD 2010- 21

Recommend


More recommend