CS137: Today Electronic Design Automation Routing Pathfinder - PDF document

CS137: Today Electronic Design Automation • Routing – Pathfinder • graph based Day 22: December 2, 2005 • global routing • simultaneous global/detail Routing 2 (Pathfinder) 1 2 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon Global → Graph Global Routing • Problem: Find sequence of channels • Graph Problem on routes through for all routes regions – minimizing channel sizes – minimize max channel size – meeting channel capacity limits w 3 4 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon Routing in Graph Global/Detail • With limited switching ( e.g. FPGA) • Find (shortest/available) path between source and sink – can represent routing graph exactly – search problem (e.g. BFS, Alpha-Beta) 5 6 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon 1

Easy? Example • Finding a path is moderately easy s1 s2 s3 All links capacity 1 • What’s hard? – Can I just iterate and pick paths? s i → d i d1 d2 d3 7 8 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon s1 s2 s3 Negotiated Congestion Challenge • Old idea • Satisfy all routes simultaneously – try once • Routes share potential resources – see where we run into problems d1 d2 d3 • Greedy/iterative – undo problematic/blocking allocation – not know who needs will need which resources • rip-up – i.e. resource/path choice looks arbitrary – use that information to redirect/update – …but earlier decisions limit flexibility for later costs on subsequent trials • like scheduling • retry – order effect result 9 10 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon Negotiated Congestion Basic Algorithm • Here • Route signals along minimum cost path – route signals • If congestion/overuse – allow overuse – assign higher cost to congested resources – identify overuse and encourage signals to • Repeat until done avoid • reroute signals based on overuse/past congestion 11 12 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon 2

Cost Function (1) Key Idea • PathCost= Σ (link costs) • Congested paths/resources become • LinkCost = base × f(#routes using, time) expensive • Base cost of resource • When there is freedom 3+1+4=8 – E.g. delay of resource – future routes, with freedom to avoid congestion – Encourage minimum resource usage will avoid it s1 s2 s3 1 1 • (minimum length path, if possible) • When there is less freedom 2 3 1 4 3 – minimizing delay = minimizing resources – must take congested routes • Congestion 1 1 1 • Routes which must use congested resources – penalizes (over) sharing 3 will, while others will chose uncongested – increase sharing penalty over time 1 1 paths 2 4 4 d1 d2 d3 13 14 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon Example Example (first order congestion) (first order congestion) s1 s2 s3 s1 s2 s3 1 1 1 1 2 2 3 1 3 3 1 3 4 4 1 1 1 1 1 Capacity 1 Capacity 3 3 1 1 1 1 2 4 2 4 Base costs (delays) Base costs (delays) 4 4 d1 d2 d3 d1 d2 d3 All, individual routes prefer middle; create congestion. 15 16 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon Example Example (need for history) (first order congestion) s1 s2 s3 s1 s2 s3 s4 1 1 1 1 1 2 3 1 3 2 2 1 4 1 1 1 1 1 1 1 Capacity Capacity 3 1 1 2 1 1 1 2 4 2 2 Base costs (delays) Base costs (delays) 1 4 d1 d2 d3 d1 d2 d3 d4 Reroute, avoid congestion. Need to redirect uncongested paths; how encourage? 17 18 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon 3

Example (need for history) Cost Function (2) • Cost = (base + history)*f(#resources,time) s1 s2 s3 s4 Local congestion alone 1 1 1 won’t drive in right 2 2 1 1 directions. • History 1 1 1 1 Both paths equal cost – avoid resources with history of congestion …neither resolves problem. 2 1 1 1 2 2 1 1 May ping-pong back d1 d2 d3 d4 and forth. Cannot route s3 � d3 (can imagine longer chain like this) 19 20 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon Example (need for history) What about delay? • Existing formulation uses delay to S3 � d3 and s4 � d4 s1 s2 s3 s4 reduces resources, but doesn’t directly 1 1 1 initially ping-pong 2 2 1 treat Builds up congestion history on 1 1 1 1 path 3 and 4 • Want: 2 1 1 1 Eventually makes path 3 and 4 – prioritize critical path elements for shorter 2 2 1 more expensive than path 1; delay d1 d2 d3 d4 …resolves conflict… – allow nodes with slack to take longer paths � Adaptive cost scheme. 21 22 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon Cost Function (Delay) Convergence • Cost= • Chan+Schlag [FPGA’2000] – W(edge)*delay + (1-W(edge))*congest – cases where doesn’t converge – congest as before – special case of bipartite graphs • (base+history)*f(#signals,time) • converge if incremental • W(edge) = D(edge)/Dmax • or if prefer uncongested to least history cost – 1 for edge on critical path critical path • theory (continuous) – <1 for paths with slack – only reroute overflow • Use W(edge) to order routes – converge in O(|E|) reroutes • Update critical path and W each round – But then have fractional routes… 23 24 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon 4

Rerouting Rerouting • Effect of only reroute congested? • Default: reroute everything – maybe more iterations • Can get away rerouting only congested • (not reroute a signal until congested) – less time nodes – ? Better convergence – if keep routes in place – ? Hurt quality? – history force into new tracks • (not see strong case for) • causing greedy/uncongested routes to be rerouted – …but might hurt delay quality • Maybe followup rerouting everything once clear up congesiton? 25 26 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon Run Time? Quality and Runtime Experiment • Route |E| edges • For Synthetic netlists on HSRA – Expect to be worst-case problems • Each path search O(|E graph |) worst case • Number of individual route trials limited – …generally less (measured) as multiple of nets in design • Iterations? – (not measuring work per route trial) 27 28 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon Quality: fixed runtime Quality Target 29 30 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon 5

Quality vs. Time Conclusions? • Iterations increases with N • Quality degrade as we scale? 31 32 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon Search: one-side vs. two-sides Search Ordering • Default: breadth first search for shortest • One-side vs. Two-sides – O(total-paths) – O(N p ) for HSRA • Alternately: use A*: – estimated costs/path length, prune candidates earlier – can be more depth first • (search promising paths as long as know can’t be worse) 33 34 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon Search: Oblivious vs. Directed Single-side, Directed (A*) (BFS vs. A*) Only expand search windows as prove necessary to have longer route. 35 36 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon 6

Searching Searching • In general: – greedy/depth first searching • Use alpha-beta like search • find a path faster • may be more expensive – Always expanded (deepen) along shortest – (not least delay, congest cost) …as long as can prove no other path will – tradeoff by weighting dominate • estimated delay on remaining path vs. cost to this – Uncongested: takes O(path-length) time point – Worst-case reduces to breadth-first • control greediness of router – More greedy is faster at cost of less optimal • O(total-paths) paths (wider channels) • O(N p ) for HSRA • 40% W � 10x time reduction [Tessier/thesis’98] 37 38 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon Mesh Expand Domain Negotiation 2 • For Conventional FPGAs (and many networks) 4 – path freedom 4 • bushy in middle • low on endpoints 2 1 39 40 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon Conventional FPGA Domains Multistage/Benes Called: subset disjoint Switches in all paths 0000 to 1111 41 42 CALTECH CS137 Fall2005 -- DeHon CALTECH CS137 Fall2005 -- DeHon 7