Fixed-outline Floorplanning Through Better Local Search Saurabh Adya Igor Markov (University of Michigan) Thank You Dr. Blauw. The title of the paper is Fixed-Outline floorplanning through better local search. This work was done jointly with Prof Igor Markov at the University of Michigan, Ann Arbor.

Outline Classical floorplanning vs. Modern hierarchical floorplanning Motivation for new methods Better local search Slack-based moves Fixed-outline floorplans using slack-based moves Results Conclusion The outline of the talk is as follows. We first look at the differences between Classical Flooplanning and Modern Heirarchichal floorplanning. We then look at the motivations for new methods I will then explain slack based moves and using these moves to achieve a fixed outline floorplan. This is our main contribution in the paper. I will summarize the results and then conclude the talk.

Classical Floorplanning Objectives: Min Area & Wirelength No fixed-outline constraints Assumes a variable-die layout and “flat” floorplanning instance Representations: O-Tree, B*-Tree, Sequence Pair, TCG, CBL, ECBL etc The Floorplanning problem consists of a collection of blocks and the objective is to pack the blocks to minimize a certain objective. Classical Floorplanning has traditionally had two objectives to minimize, the Area of the packing, to increase the manufacturing yield and a certain measure of the wirelength of the design . Classical floorplanning formulation assumes a variable die layout and a flat floorplanning instance. There are no fixed out-lines and the objective is to minimize the area of the floorplan without considering the shape of the layout. Recent research in floorplanning has focussed on developing new representations for floorplans and faster algorithms to evaluate these representations to a floorplan. These include O-tree, B*-tree, Sequence Pair, Transitive closure Graphs etc.

Need For Hierarchical Floorplanning I will go over the need for having a heirarchical floorplanning paradigm. VLSI designs are growing larger and it is common to see multi-million gate designs. The picture on the left represents a modern chip. If we look carefully then we can make out the internal floorplan structure of the chip. This chip has clearly been floorplanned by a human designer. The picture on the right corresponds to the internal floorplan structure of the chip. For eg. This line on the lower left corresponds to this line. The floorplan can be reconstructed similarly. By looking at this floorplan structure we can look at the levels of hierarchy that are present. For eg. The 3 solid horizontal lines represent the top level of hierarchy. The second level is represented by the lighter lines. There is also a 3’rd level of hierarchy as seen by the dotted lines. The objectives for the top level floorplan can be minimum area to increase yield. But once we have floorplanned at the top level, then there are implicit fixed outline constraints for floorplanning at lower levels. For eg. The block on the right

Fixed Outline Constraints Not a minimization problem Rather a constraint satisfaction problem   Fixed-outline constraints consist of predetermined x-span and y-span of the required layout. The problem is to fit all the blocks of the design into this area without any overlaps while minimizing the wirelength. In out experiments we fixed the maximum whitespace of our designs to be 15% and calculated the fixed outlines for different aspect ratios of the required layout Thus the problem is now changed from being a pure minimization problem to that of being a constraints satisfaction problem. y-span x-span

Modern Hierarchical Floorplanning Target designs: large ASICs, SOCs E.g. multi-million gate designs like graphics cards Hierarchical floorplanning  Fixed outline constraints Fixed-die layout [Kahng, ISPD ‘00] Classical floorplanning still important at top level Fixed-outline required at lower levels Stronger neighborhood structures helpful Better guide search I will summarize the points I discussed in the previous slide. The target designs for a hierarchical floorplanning paradigm are large ASIC’s and SOC’s like graphics card designs or network processor design. Hierarchical floorplanning implies fixed-outline constraints.As pointed out by Kahng fixed-outline floorplanning also makes sense in the fixe-die layout context. We also realize that inorder to satisfy these extra constraints imposed by fixe-outline, we need stronger neiborhood structures to better guide our search in the simulated annealing framework.

Motivation For New Methods Existing floorplanners use simulated annealing framework Floorplanning with constraints Pre-placed constraints [Young et al, ICCAD ‘98] Range constraints [Young et al, ISPD ‘99] Boundary constraints [Young et al, ASPDAC ‘99] Abutment constraints [Hong et al, DAC ‘01] Additionaly need to handle fixed-outline constraints [ Kahng, ISPD ‘00] Most of the existing floorplanner use the simulated annealing framework to solve the floorplanning problem. Simulated Annealing is a minimization approach which is stochastic in nature. We start off from a random solution and apply random incremental moves to the solution. Any good move which improves the objective function is accepted and any bad move which worsens the objective function is rejected with a certain probability. The hope is to achieve a global minima while allowing certain degrees of hill climbing. There have been works which impose certain constraints on the floorplanning solutions which are handled very well within the SA framework. These include pre-placed constraints, range constraints, boundary constraints and abutment constraints. From earlier discussion we conclude that additionally we need to handle fixed-outline constraints.

Sequence Pair (SP) Representation Proposed by Murata, Fujiyoshi, Nakatake, Kajitani [TCAD ’97] Two permutations of N blocks capture the geometric relation between each pair of blocks (<…a…b…>,<…a…b…>)  a is to the left of b (<…a…b…>,<…b…a…>)  a is above b Horizontal (Vertical) constraint graphs Edge ab iff a is to the left of b (a is above b) Compute block locations by topological traversal O(n2) complexity Slow We use the well known Sequence pair representation in out floorplanner. This was proposed by Murata, Fujiyoshi, Nakatake and Kajitani. It consists of 2 permutations of N blocks. The order of the blocks in the 2 sequences capture the geometric relation between each pair of blocks. Specifically for any 2 blocks say a and b, if they are in the same relative order in both the sequences then there is a horizontal constraint between the 2 blocks. Similarly if the relative order of the 2 blocks is reversed then there is a vertical constraint between the 2. From these relations we can build horizontal and vertical constraint graphs. For eg. In the vertical constraint graph there is a directed edge from a to b iff a is above b as specified by the sequence pair. After building this graph and adding the sources and sinks we can topologically traverse the graph to compute the block locations as represented by the sequence pair. This algorithm has an O(n2) complexity and is slow because the constraint graphs need to be computed explicitly. Top A Right Left B C <ABC, BCA> Bottom

SP Evaluation Via Longest Common Subsequence Proposed by Tang, Tian, Wong [DATE ‘00] Longest Common weighted Subsequence (LCS) Weights are copied from block widths (heights) Length of LCS equals x-span (y-span) Floorplan evaluation reduces to LCS computation LCS computation algorithms O(n2) complexity : fast for small floorplans Very little work in inner loop O(n log n) complexity O(n log log n) complexity [ASPDAC ’01] Tang Tian and Wong proposed a fast evaluation algorithm to evaluate sequence pairs to floorplans. They showed that the span of the floorplan reduces to Longest Common Weighted subsequence computation where the weights are copied from the widths or the heights of the blocks. Thus the floorplan evaluation reduces to a series of LCS computations. Tang et al. proposed 3 algorithms to efficiently compute the LCS and thus evaluate the floorplan. The first one has O(n2) complexity, but performs better than the O(nlogn) algorithm for small floorplans, mainly because of simple data structures used and a very tight inner loop. They have recently proposed O(n log logn) algorithm which they claim is faster than O(n2) in practice. But our techniques are not dependent on the particulars of the evaluation algorithm.

Variables in LCS computation Sequence Pair <X, Y> MatchX : indices of blocks in X seq MatchY : indices of blocks in Y seq Length : lower bound on right edges of blocks (at some point can become invalid) Position : left edges of each block

SP Evaluation Using LCS

Evaluation of x-locations by LCS computation 4 D 8 Evaluation of x-locations by LCS computation 2 E C B 6 1 Sequence Pair <X,Y> = <FEDBCA, ABFECD> A 10 14 Length Array Block Positions A B F E C D A B C D E F Init F E D B C A 0 0 0 0 0 0 0 0 4 4 4 4 This slide shows the O(n2) algorithm proposed by Tang et al. to evaluate a sequence pair. The blocks have their widths marked in the figure. We are only considering the horizontal packing of the floorplan. Vertical computation is similar. The sequence pair is shown. There are 2 arrays. One is the length array which keeps track of the LCS and the block position array which records the position of each block. The algorithm start with all values in length array = 0. There are 2 nested loops which update these 2 arrays. At the end of the algorithm the last value of length array gives the span of the floorplan. As seen this algorithm works left to right. We can easily modify this algorithm to evaluate the floorplan right to left instead. 0 0 4 6 6 6 4 0 0 0 4 6 6 14 6 4 0 0 6 6 6 6 14 0 6 4 0 0 6 6 6 7 14 0 6 6 4 0 10 10 10 10 10 14 0 0 6 6 4 0

Floorplan “Slack” x-Slack Computation F D F D E E C C B <FEDBCA, ABFECD> B A A <FED> is the LCS I will now introduce the notion of Floorplan slack. Slack for a particular block corresponds tp the whitespace around that block. For eg for block A the x-slack is given by the x –whitespace around it. If we have an algorithm which can pack left to right and right to left, we can easily calculate the individual slack of each block as follows. Note that blocks F E and D lie on the critical path as their x-slacks are 0. Thus any movements to these blocks with this ordering would result in an increase in the span of the floorplan We also note that blocks cannot have –ve slack as that would result in an overlap between blocks. This is similar to static timing analysis in which –ve slacks mean that we have violated the timing constraints. Left Packing Right Packing x-slack for block A = x(Aright) – x(Aleft) x-Slack Computation

Better Local Search Floorplan “Slack” Computation Applicable to any evaluation method which packs left to right and right to left x-slack for a block represents the x-whitespace Analogy with Static Timing Analysis Blocks with zero slack lie on “critical paths” Observation : Only moves of blocks with zero x-slack (y-slack) can reduce the floorplan span Slack-based moves helpful for : Satisfying a fixed-outline (this work) Handling soft blocks (see source code) How do we use the concept of slacks to better guide our local search? We observe that blocks with zero slack lie on the critical path. We also observe that only moves of blocks with zero slack in one dimension can reduce the floorplan span. By a move I mean a reordering in the sequence pair which breaks the critical path. For eg FED is the critical path. If we want to reduce the horizontal span then we can try moving say block E to the right of block A which has large horizontal slack. Slack based moves are helpful for satisfying fixed-outlines which is a topic of this work. We have also successfully used this concept to handle soft blocks in the floorplanning instance. Soft blocks have variable aspect ratios but a fixed area. F D E C B A

Example: A Slack-based Move Block with y-slack = 0

Fixed-outline Floorplanning Find target aspect ratio of fixed outline During annealing track current aspect ratio Apply slack-based moves if current aspect ratio too far from target aspect ratio (targetAR – currAR)/targetAR > 0.005 A sample slack-based move Find block A with zero slack in one dimension Find block B with large slack in other dimension Place A close to B Different slack-based moves are possible How do we use slack-based moves to achieve fixed outline floorplanning.

Fixed-outline Floorplanning (contd.)  Current floorplan y-viol  x-yiol Required floorplan

Objective Functions Main framework : Simulated Annealing (SA) Need an objective Classical min-area objective appears inadequate Choose one of 3 objective functions Min area Min (excessive length+ excessive width) Min (max of excessive(length,width)) Empirical winner (shown later)

Implementation Implementation is in C++ Hardware Compiled with g++ 2.95.2 –O3 Hardware 800 MHz PC/Intel system Min area results competitive with latest reported Circuit Min/Avg Area (mm2) Min/Avg deadspace (%) Avg Time (sec) Apte 47.07/48.14 1.08/3.28 4 Xerox 19.83/20.73 2.42/6.65 3 Hp 9.14/9.49 3.39/6.95 Ami33 1.19/1.23 2.85/6.01 9 Ami49 37.27/38.01 4.91/6.76 16

Results Without slack-based moves With slack-based moves Not able to satisfy fixed-outline constraints With slack-based moves Fixed-outline success rates for ami49

Conclusion Fixed-outline floorplanning harder than min area floorplanning Known algorithms cannot address fixed-outline constraints Slack-based moves help New objectives help Source code available at: http://www.vlsicad.eecs.umich.edu/BK/parquet Ongoing work : Fixed-outline floorplanning with wirelength minimization