A Resource-level Parallel Approach for Global-routing-based Routing

Congestion Estimation and a Method to Quantify Estimation Accuracy

Wen-Hao Liu, Zhen-Yu Peng,Ting-Chi Wang

ICCAD '14

Outline

• Introduction• Preliminaries• Global Routing Instance Partitioning• Quantifiying the Similarity between Two

Congestion Maps• Experimental Results• Conclusions

Introduction

• Routability has become a challenging issue with designs scaling down.

• Considering routability in the placement stage is common to see in recent publications.

• In order to yield placement solutions with better routability, many state-of-the-art placers integrate a global-routing-based routing congestion estimator (GRCE) into their placement flows.

Introduction

• There are two feasible ways to realize fast GRCEs.

• The first way is to develop faster routing algorithms and design more efficient routing flows.

• Another way is to exploit multithreading techniques.

• This paper presents a resource-level parallel approach (RPA) to accelerate GRCEs.

• The bad dispatching will make computation effort among threads unbalanced to limit the speedup.

• This paper also presents a method to quantify the estimation accuracy of GRCEs.

Global Routing Instance for GRCEs

• Let S(G(V, E), N) denote a global routing instance.

• G(V, E) denotes a grid graph and N denotes a set of nets.

• V denotes a set of grid nodes, E denotes a set of grid edges (g-edges), and each g-edge e connects two adjacent grid nodes.

• The capacity c(e) indicates the maximum number of nets that can legally pass through e.

• The demand d(e) denotes the number of routing paths passing through e

• The overflow of e is defined to be max(d(e)- c(e), 0).

Requirements for GRCEs

• A more practical requirement for GRCEs is to get accurate estimation results rather than high-quality results.

• The most intuitive way to measure the accuracy of a GRCE is to see whether the congestion distribution in the congestion map generated by the GRCE is similar to that generated by a real router.

Problem Formulation

• Input: A global routing instance S(G(V, E), N), and a constant k.

• Output: Sub-instances ((, ), ), 1≤i≤k. • Constraints: Each net in N belongs to one of ,

1≤i≤k. For each g-edge in G(V, E), c()= c() hold, where denotes the corresponding edge of in (, ).

Global Routing Instance Partitioning

• This paper solves the instance partitioning problem by three stages:

• routing resource allocation• net dispatching• routing effort balancing

Routing Resource Allocation

Net Dispatching

• The task of this stage is to dispatch each net of N to one of , …, .

• In order to predict where each net will pass through, this stage first performs a quick prerouting step to get the routing path of each net in N, and then dispatches nets guided by the prerouting result.

Net Dispatching

Routing Effort Balancing

• This stage consists of the net migration and routing resource relocation steps to further improve the load balancing between sub-instances.

• The net migration step moves some nets from the harder-to-route to easier-to-route sub-instances, and the routing resource relocation step relocates the routing resource from the easier-to-route to harder-to-route sub-instances.

Net Migration

• The net migration step checks each net in N one by one again according to the original sorted order to see whether migrating the net from its original sub-instance to one of the other sub-instances can get a lower cost of Eq. (1).

Routing Resource Relocation

• The total overflow in the duplicate graph relates to the routing effort of , so the routing resource relocation step attempts to reduce the total overflow in each graph.

Routing Resource Relocation

• The available capacity of a g-edge is defined to be the amount of its capacity exceeding its demand. Moreover, we define the total available capacity TACCE() and total overflow TOFCE() of the corresponding edges of

Case 1: TACCE() TOFCE()

Case 2: TACCE() < TOFCE()

• This case means that the total available capacity is not enough to reduce TOFCE() to zero, but we try to proportionally relocate the available capacity to the overflowed g-edges based on their congestion level.

• The amount of the partial capacity allocated to an overflowed g-edge is

Quantifiying the Similarity between Two Congestion Maps

• After a routing result is obtained by a routing tool such as a GRCE or a real router, a congestion map can be formed by the ratio of the routing demand to the capacity on each g-edge in the grid graph.

• presents a congestion map similarity (CMS) metric to quantify the similarity between two congestion maps according to their congestion distributions.

• The value returned by the CMS metric is a real number between 0 and 1; a larger value implies that these two congestion maps are more similar.

• CMS(t, d) denotes the distribution similarity of the top t% congested g-edges between two congestion maps, say and , where d is the tolerant offset of the congestion locations and the unit of d is a g-edge long.

• set t={0.5, 1, 2, 5, 10} for the CMS metric.

• um((t), (t), d) when d=1, in which (t)={, , , } and (t)={, , , }.

Experimental Results

• The proposed algorithms were implemented in C++ on a linux server with two Intel Xeon 2.4GHz E5654 CPUs and 96GB memory.

• The following experiments adopt [8] and BFGR [16] to be the tested GRCEs, and then accelerate and BFGR by RPA to see whether they can point out congestion regions as accurate as those without the acceleration.

Experimental Results

• ISPD11 placement solutions are harder to route and have more congestion regions, so ISPD11 placement solutions are the better test cases to evaluate GRCEs.

• we select 7 most hard-to-route placement solutions to be our test cases.

• the maximum variations of TOF, WL, and CPU will respectively become 15%, 13%, and 21% on average for each circuit.

Conclusions

• This paper presents a resource-level parallel approach (RPA) to accelerate GRCEs. RPA partitions a global routing instance into sub-instances.

• RPA is easy to implement and does not change the routing kernel of the GRCE.

• Presents a CMS metric to quantify the similarity between two congestion maps.