Alpert/Handbook of Algorithms for Physical Design Automation AU7242_C011 Finals Page 232 29-9-2008 #31 232 Handbook of Algorithms for Physical Design Automation 5 4 3 2 1 0 6 4 2 0 0 2 4 6 8 10 a b c e f d 12 Width Height Duration FIGURE 11.28 3D placement. The corresponding 3D-subTCG is given in the Figure 11.29. (From Yuh, P H., Yang, C L., Chang, Y W., and Chen, H L., Proceedings of Asia and South Pacific Design Automation Conference, 2004. With permission.) 3 3 2 2 2 2 2 2 4 3 4 1 1 3 5 1 3 5 n d n c n b n e n a n b n b n c n c n f n f n a n a n d n d n e n e n f C h C v C t FIGURE 11.29 Corresponding 3D-subTCG of Figure 11.28. (From Yuh, P H., Yang, C L., Chang, Y W., and Chen, H L., Proceedings of Asia and South Pacific Design Automation Conference, 2004. With permission.) On the basis of previous works [22,23], the T-tree and 3D-subTCG outperform sequence triplet. Further, the T-tree outperforms the 3D-subTCG in terms of packing efficiency and volume optimiza- tion, due to its relatively simpler tree representation and good neighborhood structure. Nevertheless, the 3D-subTCG has the following three advantages over the T-tree: • 3D-subTCG is a fully topological representation that can represent the general topological modeling of tasks, and thus contains a complete solution structure for searching the optimal floorplan/placementsolution. In contrast, T-tree is a partially topological representation and can only represent part of the compacted 3D floorplans where each task must be compacted to the origin. • Becausetherelation between eachpairoftasksisdefinedintherepresentation,thegeometric relation of each pair of tasks is transparent to both the 3D-subTCG representation and its induced operations. Thus, we can perform the feasibility detection before perturbation to guarantee the satisfaction of precedence constraints. In contrast, T-tree is a partially topological representation where some geometric relations among tasks cannot be obtained directly from representation. Thus, it is harder to detect the violations of the precedence constraints before packing and a postprocessing is required to guarantee the feasibility of the solutions after packing. • Because the geometric relations among tasks can be directly obtained from the representa- tion, 3D-subTCG may be moresuitablefor handlingvariouspracticalplacement constraints. For example, because the input/output blocks are on the boundary of the reconfigurable devices, such as the Xilinx Virtex, some tasks are desired to be placed on the boundary Alpert/Handbook of Algorithms for Physical Design Automation AU7242_C011 Finals Page 233 29-9-2008 #32 Packing Floorplan Representations 233 of a device. We can easily detect if a task is on the boundary of the device by observing the in-degree/out-degree of its corresponding node in C h or C v . We can also detect if a task startsattime step zero on an RFU by observing thein-degree/out-degreeofits corresponding node in C t . 11.12 APPLICATION IN HANDLING OTHER CONSTRAINTS IN FLOORPLAN DESIGN A few floorplan constraints have been studied in the literature, and the B ∗ -tree representation has been shown to be successful for handling these constraints. As it is not our intension here to exhaust all floorplan constraints, we shall in the following subsections give the handling of two example popular floorplan constraints: boundary constraints [24] and rectilinear modules [25] based on the B ∗ -tree representation. 11.12.1 BOUNDARY CONSTRAINTS The boundary-constrained modules are modules that must be placed along boundaries in the final placement. A module can be placed along the botto m (left) boundary if there exists no module below (left to) the module in the final placement. Similarly, a module can be placed along the top (right) boundary if there exists no module above (right to) the module in the final placement. By the d efinition of a B ∗ -tree, the left child n j of a node n i represents the lowest adjacent module b j to the right of b i (i.e., x j = x i + w i ). The right child n k of n i represents the lowest visible module b k above b i and with the same x coordinate as b i (i.e., x k = x i ). Therefore, we have the following four properties [24] to guarantee that there exists no module below, left to, right to, and above the module along the bottom, left, right, and top boundaries, respectively. 1. Node corresponding to a bottom boundary module cannot be the right child of others 2. Node corresponding to a left boundary module cannot be the left child of others 3. Node corresponding to a right boundary module cannot have a left child 4. Node corresponding to a top boundary module cannot have a right child The aforementioned properties must be satisfied to guarantee a feasible B ∗ -tree with boundary- constrained modules. However, they only describe the necessary conditions for a B ∗ -tree with the boundary constraints, that is, a module may not be placed along the designated boundary if the corresponding property is satisfied. To guarantee that modules are placed at designated boundaries, sufficient conditions are studied in Ref. [25] for a B ∗ -tree with boundary constraints. The following conditions show the feasibility conditions of a B ∗ -tree with the bottom, left, top, and right constraints (Figure11.30): Leftmost branch Rightmost branch n 0 b 1 b 1b 0 b 3 b 4 b 8 b 9 b 6 b 5 b 2 b 2 b 9 b 7 b 8 b 4 b 5 b 3 b 6 b 7 Bottom-left branch Bottom-right branch FIGURE 11.30 Boundary modules and their corresponding B ∗ -tree branches. Alpert/Handbook of Algorithms for Physical Design Automation AU7242_C011 Finals Page 234 29-9-2008 #33 234 Handbook of Algorithms for Physical Design Automation • Bottom-boundary condition: The nodes corresponding to the bottom boundary modules must be in the leftmost branch of a B ∗ -tree. • Left-boundary condition: The nodes corresponding to the left boundary modules must be in the rightmost branch of a B ∗ -tree. • Right-boundary condition: For the right boundary modules, their corresponding nodes are in the bottom-left branch of a B ∗ -tree with the left child for each node in the path being deleted. • Top-boundary condition: For the top boundary modules, their corresponding nodes are in the bottom-right branch of a B ∗ -tree with the right child for each node in the path being deleted. Given an initial B ∗ -tree, the simu lated annealing algorithm perturbs the B ∗ -tree to get a new one. Then, the four feasibility conditions of B ∗ -trees are checked. If any condition is violated, it transforms an infeasible B ∗ -tree into a feasible one. As a result, a placement satisfying the boundary constraints can be obtained. 11.12.2 RECTILINEAR MODULES First, we show how to apply B ∗ -tree to find a feasible placement with L-shaped modules. Let b L denote an L-shaped module. b L can be partitioned into two rectangular submodules by slicing b L along its middle vertical boundary. As shown in Figure 11.31a, b 1 and b 2 are the submodules of b L , and we say b 1 , b 2 ∈ b L . To ensure that the left submodule b 1 and the right submodule b 2 of an L-shaped module b L abut, Wu, Chang, and Chang impose the following location constraint (LC for short) for b 1 and b 2 in Ref. [26]: LC: Keep b 2 as b 1 ’s left child in the B ∗ -tree. The LC relation ensures that the x-coordinate of the left boundary of b 2 is equal to that of the right boundary of b 1 . The contour data structure is kept carefully to solve the misalignment problem. When transforming a B ∗ -tree to its corresponding placement, it updates the contour to maintain its top profile sequence as follows. Assume that b 1 and b 2 are the respective left and right submodules of an L-shaped module b L , and they are misaligned. When processing b 2 , b 1 must have been placed. We can classify the misalignment into two categories and adjust them as follows: (a) (c) (d)(b) (e) (g) (h)(f) b 2 b 2 b 2 b 2 b 2 b 2 b 2 b 2 b 1 b 1 b 1 b 1 b 1 b 1 b 1 b 1 FIGURE 11.31 Eight situations of an L-shaped module. Each is partitioned into two parts by slicing it along the middle vertical boundary. Alpert/Handbook of Algorithms for Physical Design Automation AU7242_C011 Finals Page 235 29-9-2008 #34 Packing Floorplan Representations 235 Top profile Contour (a) (b) Top profile Contour b 2 b 2 b 1 b 1 FIGURE 11.32 P lacing two submodules b 1 and b 2 of an L-shaped module. (a) If the contour is lower than the top profile sequence at b 2 , then we pull b 2 up to meet the t op profile sequence. (b) If the contour is hi gher t han the top profile sequence at b 2 , then we pull b 1 up to meet the top profile sequence. 1. Basin: The contour is lower than the top profile sequence at the position of the current submodule b 2 (Figure11.32a). In this case, we pull b 2 up to conform to the top profile sequence of the L-shaped module b L . 2. Plateau: The contour is higher than the top profile sequence at the position of the current submodule b 2 (Figure11.32b). In this case, we pull b 1 up to conform to the top profile sequence of b L . (Note that b 2 cannot be moved down because the compaction operation makes b 2 be placed right above another module.) It is clear that each of the adjustment can be performed in constant time with the contour data structure. For each L-shaped module b i , there are eight orientations by rotation and flip, as shown in Figure11.31. To preserve the LC relation and keep it in the B ∗ -tree, we repartition b i into two submodules after it is rotated or flipped and keep the LC relation b etween them. Figure 11.31 shows the submodulesafterrepartitioning.As shown in the figure, an L-shapedmoduleis always partitioned by slicing it along the middle vertical boundary.After repartitioning, we should update the top profile sequence for the module. To handle general rectilinear module blocks, a rectilinear module can be partitioned into a set of rectangular submodules. Let b i denote an arbitrarily shaped rectilinear module. b i can be partitioned into a set of rectangular submodules by slicing b i from left to right along every vertical boundary of b i , as shown in Figure 11.33a. Figure11.33b shows the module of Figure 11.33a after rotating by 90 ◦ clockwise; there are six submodules in it after the repartition. There are two types of rectilinear modules: convex and concave modules. A rectilinear module is convex if any two points within the module can be connected by a shortest Manhattan path, which also (a) (b) b 5 b 5 b 4 b 4 b 3 b 3 b 2 b 2 b 1 b 1 FIGURE 11.33 (a) Partition a convex module along every vertical boundary from left to right. (b) Repartition the module of (a) after it rotates. Alpert/Handbook of Algorithms for Physical Design Automation AU7242_C011 Finals Page 236 29-9-2008 #35 236 Handbook of Algorithms for Physical Design Automation Filled area b 2 b 1 FIGURE 11.34 Filling approximation for a rectilinear module. lies within the module; the module is concave, otherwise. Figures 11.33 and 11.34 show two convex and a concave modules, respectively. A convex module b C can be partitioned into a set of submodules b 1 , b 2 , , b n ordered from left to right. Considering the LC relation, we keep the submodule b i+1 as b i ’s left child in the B ∗ -tree to ensure that they are placed side by side along the x-direction, where 1 ≤ i ≤ (n −1). To ensure that b 1 , b 2 , , b n are not misaligned, we modify the processing for basin and plateau as follows: • Basin: The contour is lower than the top profile sequence at the position of a submodule. We pull the submodule up to conform to the top profile sequence. • Plateau: The top boundary of a submodule b i (1 ≤ i ≤ n) in the contour is higher than the top profile sequence at the position of b i . Assume that b i has the largest top boundary. We pull all submodules, except b i , up to conform to the top profile sequence. For a concave module, there might be empty space between two submodules. As shown in Figure11.34, the submodule b 1 is placed above the submodule b 2 , which cannot be characterized by an LC r elation in the B ∗ -tree. Nevertheless, we can fill the concave holes of a concave module and make it a convex module. This operation is called a filling approximation for the rectilinear module. For any concave module, we treat it as a convex module after applying appropriate filling. 11.13 SUMMARY Table 11.1 summarizes the sizes of the solution spaces, packing times, perturbation properties, and flexibility of the floorplan repr esentations discussed in this chapter. Among the representations, SP, TCG, TCG-S, and ACG are fully topological representations and can represent the general floorplans; in contrast, O-tree, B ∗ -tree, and CS are partially topological representations and can model only compacted floorplans. Therefore, SP, TCG, TCG-S, and ACG are intrinsically more flexible than O-tree, B ∗ -tree, and CS because they keep more in formation in their representations (i.e., data structures). On the other hand, because SP, TCG, TCG-S, and ACG keep more information in their representations, they are typically less efficient than O-tree, B ∗ -tree, and CS. As a result, SP, TCG, TCG-S, ACG have larger solution spaces than O-tree, B ∗ -tree, and CS. Further, for the compacted floorplan representations, O-tree, B ∗ -tree, and CS, their representation might change after packing, which will not occur for the general floorplan representations. For example, given a B ∗ -tree, the resulting p lacement might not correspond to the original B ∗ -tree due to the compaction operation during packing. We thus denote this situation by ⊗ to distinguish it from the purely f easible cases (denoted by ) for the general floorplan representations. Alpert/Handbook of Algorithms for Physical Design Automation AU7242_C011 Finals Page 237 29-9-2008 #36 Packing Floorplan Representations 237 TABLE 11.1 Comparisons between Various Packing Floorplan Representations Represent. Solution Space Size Packing Time Generate Feasible Perturbations Flexibility O-tree O(n!2 2n /n 1.5 ) O(n) ⊗ Compacted B ∗ -tree O(n!2 2n /n 1.5 ) O(n) ⊗ Compacted CS ≤ (n!) 2 O(n) ⊗ Compacted SP (n!) 2 O(n 2 ) a General BSG O(n!C(n 2 , n)) O(n 2 ) General TCG (n!) 2 O(n 2 ) General TCG-S (n!) 2 O(n lg n) General ACG O((n!) 2 ) O(n 2 ) General a Note that O(n lg lg n) packing time for SP is known in Ref. [15]. Also, given a TCG, a TCG-S, or an ACG, it can first be transformed i nto an SP in linear time, and then p erforms the packing with the corresponding SP in O(n lg lg n) time b y using the method in Ref. [15]. For the packing time, SP and TCG require O(n 2 ) time to generate a floorplan, where n is the number of modules. (Note that SP can reduce its packing time to O(n lg lg n) time based on the longest common subsequence technique, as mentioned in Section11.5.) With an additional packing sequence, TCG-S can reduce its packing time to O(n lg n ). For the partial topological representations (the tree-based representations—O-tree and B ∗ -tree—and CS), the packing time is only linear time because they keep relatively simpler information in their data structures. (It should also be noted that, given a TCG, a TCG-S, or an ACG, it can first be transformed into an SP in linear time, and then performs the packing with the corresponding SP in O(n lg lg n) time by using the method in Ref. [15].) As a final remark for floorplan representation, the evaluation of a floorplan representation should be made from at least the following three aspects: (1) the definition/properties of the representation, (2) its induced solution structure (not merely its solution space), and (3) its induced operations. We shall avoid the pitfall that judges a floorplan representation by only one of the aforementioned three aspects alone; for example, claiming a floorplan representation A is superior to another floorplan representation B simply because A has a smaller solution space and a faster packing time. Here is an analogy:the representation itself is like thebodyofan automobilewhile the induced operationsis like the wheels of th e automobile and the solution structure is like the highway network. An automobile with itsbodyalone can gonowhere. For acomprehensivestudy offloorplanrepresentations, similarly, we shall evaluate them from at least all the aforementioned three aspects. REFERENCES 1. R.H.J.M. Otten. Automatic floorplan design. In Proceedings of ACM/IEEE Design Automation Conference, pp. 261–267, 1982. 2. D.F. Wong and C.L. Liu. A new algorithm for floorplan design. In Proceedings of ACM/IEEE Design Automation Conference, Las Vegas, NV, pp. 101–107, 1986. 3. X. Hong, G. Huang, T. Cai, J. Gu, S. Dong, C K. Cheng, and J. Gu. Corner block list: An effective and efficient topological representation of non-slicing floorplan. In Proceedings of ACM/IEEE Design Automation Conference, Los A ngeles, C A, pp. 8–12, 2000. 4. J M. Lin and Y W. Chang. TCG: A transitive closure graph-based representation for non-slicing floorplans. In Proceedings of ACM/IEEE Design Automation Conference, Las Vegas, NV, pp. 764–769, 2001. 5. J M. Lin and Y W. Chang. TCG-S: Orthogonal coupling of P ∗ -admissible representations for general floorplans. In Proceedings of ACM/IEEE Design Automation Conference, New Orleans, L A, pp. 842–847, 2002. Alpert/Handbook of Algorithms for Physical Design Automation AU7242_C011 Finals Page 238 29-9-2008 #37 238 Handbook of Algorithms for Physical Design Automation 6. H. Murata, K. Fujiyoshi, S. Nakatake, and Y. Kajatani. Rectangle-packing based module placement. In Proceedings of I EEE/ACM International Conference on Computer-Aided Design, San Jose, CA, pp. 472– 479, 1995. 7. S. Nakatake, K. Fujiyoshi, H. Murata, and Y. Kajitani. Module placement on BSG-structure and IC layout applications. In Proceedings of IEEE/ACM International Conference on Computer-Aided Design, San Jose, CA, pp. 484–491, 1996. 8. H. Zhou and J. Wang. ACG-adjacent constraint graph for general floorplans. In Proceedings of IEEE International Conference on Computer Design, San Jose, CA, pp. 572–575, 2004. 9. Y C. Chang, Y W. Chang, G M. Wu, and S W. W u. B ∗ -trees: A new representation for non-slicing floorplans. In Proceedings of ACM/IEEE Design Automation Conference, Los Angeles, C A, pp. 458–463, 2000. 10. P N. Guo, C K. Cheng, and T. Yoshimura. An O-tree representation of non-slicing floorplan and its applications. In Proceedings of ACM/IEEE Design Automation Conference, New Orleans, LA, pp. 268–273, 1999. 11. J M. Lin, Y W. C h ang, and S P. Lin. Corner sequence: A P-admissible f loorplan representation with a worst case linear-time packing scheme. IEEE Transactions on Very Large Scale Integration (VLSI) Systems, 11(4):679–686, August 2003. 12. J M. Lin and Y W. Chang. TCG: A transitive closure graph based representation for general floorplans. IEEE Transactions on Very Large Scale Integration (VLSI) Systems, 13(2):288–292, February 2005. 13. J M. Lin and Y W. Chang. TCG-S: Orthogonal coupling of P ∗ -admissible representations for general floorplans. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 24(6):968– 980, June 2004. 14. X. Tang, R. Tian, and D. F. Wong. Fast evaluation of sequence pair in block placement by longest com- mon subsequence computation. In Proceedings of IEEE/ACM Design, Automation and Test in Europe Conference, Paris, France, pp. 106–111, 2000. 15. X. Tang and D. F. Wong. FAST-SP: A fast algorithm for block placement based on sequence pair. In Proceedings of IEEE/ACM Asia South Pacific Design Automation Conference, Yokohama, Japan, pp. 521– 526, 2001. 16. T C. Chen, Y W. Chang, and S C. Lin. IMF: Interconnect-driven multilevel floorplanning for large- scale building-module designs. In Proceedings of IEEE/ACM International Conference on Computer-Aided Design, San Jose, CA, pp. 159–164, 2005. 17. H C. Lee, Y W. Chang, and H. Yang. MB ∗ -tree: A multilevel floorplanner for large-scale building-module design. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 26(8):1430– 1444, 2007. 18. H C. Lee, J M. Hsu, Y W. Chang, and H. Yang. Multilevel floorplanning/placement for large-scale modules using B ∗ -trees. In Proceedings of ACM/IEEE Design Automation Conference, Anaheim, CA, pp. 812–817, 2003. 19. T. Cormen, C. Leiserson, R. Rivest, and C. Stein. Introduction to Algorithms, 2nd edn. The MIT Press/McGraw-Hill Book Company, Cambridge, MA, 2001. 20. H. Yamazaki, K. Sakanushi, S. Nakatake, and Y. Kajitani. The 3D-packing by meta data structure and packing heuristics. IEICE Transcations on Fundamentals, E82-A(4):639–645, 2003. 21. H. Kawai and K. Fujiyoshi. 3D-block packing using a tree representation. In Proceedings of the 18th Workshop on Circuits and Systems in Karuizawa, pp. 199–204, 2005. 22. P H. Yuh, C L. Yang, and Y W. Chang. Temporal floorplanning using the T-tree representation. In Pro- ceedings of IEEE/ACM International Conference on Computer-Aided Design, San Jose, CA, pp. 300–305, 2004. 23. P H. Yuh, C L. Yang, Y W. Chang, and H L. Chen. Temporal floorplanning using 3D-subTCG. In Pro- ceedings of IEEE Asia-Pacific Conference on Circuits and Systems, Yokohama, Japan, pp. 725–730, 2004. 24. J M. Lin, H E. Yi, and Y W. Chang. Module placement with boundary constraints using B ∗ -trees. IEE Pr oceedings–Circuits, Devices and Systems, 149(4):251–256, 2002. 25. M C. Wu and Y W. Chang. Placement with alignment and performance constraints using the B ∗ -tree representation. In Proceedings of IEEE International Conference on Computer Design, San Jose, CA, pp. 300–305, 2004. 26. G M. Wu, Y C. Chang, and Y W. Chang. Rectilinear block placement using B ∗ -trees. ACM Transactions on Design Auto mation of Electronics Systems, 8(2):188–202, 2003. Alpert/Handbook of Algorithms for Physical Design Automation AU7242_C012 Finals Page 239 24-9-2008 #2 12 Recent Advances in Floorplanning Dinesh P. Mehta and Yan Feng CONTENTS 12.1 Introduction 239 12.2 Reformulating Floorplanning 240 12.2.1 Outline-Free versus Fixed-Outline Floorplanning 240 12.2.2 Module Shape and Flexibility 240 12.2.3 Whitespace: To Minimize or Not to Minimize? 241 12.2.4 Interconnect 241 12.2.5 Module Locations: Known or Unknown? 242 12.2.6 Human Intervention 242 12.3 Fixed-Outline Floorp lanning 242 12.3.1 Automated Floorplanning with Rectangular Modules 242 12.3.2 Incremental/Interactive Floorplanning with Rectilinear Modules 243 12.4 Floorplanning and Interconnect Planning 245 12.4.1 Congestion Considerations during Floorplanning 245 12.4.2 Integrated Buffer Planning and Floorplanning 246 12.4.3 Bus-Driven Floorplanning 247 12.4.4 Floorplan/MicroarchitectureInteractions 247 12.4.5 Floorplan and Power/Ground Cosynthesis 249 12.5 Floorplanning for Specialized Architectures 249 12.5.1 FPGA Floorplanning 249 12.5.2 3D Floorplanning 250 12.5.3 Analog Floorplanning 250 12.6 Statistical Floorplanning 251 12.7 Floorplanning for Manufacturability 252 12.8 Concluding Remarks 253 Acknowledgments 253 References 253 Bibliography 256 12.1 INTRODUCTION Conversations with industry practitioners suggest that there is currently a disconnect between the practice of floorplanning in industry and classical academic floorplanningfocused on area minimiza- tion. There is, however, a significant and growing body of literature in floorplanning that attempts to bridge this divide. The goal of this chapter is to collect and present some of these efforts in a unified manner. Much of this work builds on one or more of the representations discussed in the three preceding chapters. We refer the reader to these chapters for a comprehensive review of these representations and to the original papers for a more detailed study. The chapter is organized as 239 Alpert/Handbook of Algorithms for Physical Design Automation AU7242_C012 Finals Page 240 24-9-2008 #3 240 Handbook of Algorithms for Physical Design Automation follows. Section 12.2 presents the latest trends in floorplanning problem formulations. Fixed-outline floorplanning is discussed in Section 12.3. Several approaches for considering interconnect plan- ning during floorplanning are described in Section 12.4. Floorplanning for specialized architectures such as field programmable gate arrays (FPGAs) and analog integrated circuits (ICs) are discussed in Section 12.5. Statistical floorplanning and floorplann ing for manufacturability are described in Sections12.6 and 12.7, respectively. Section 12.8 concludes this chapter. 12.2 REFORMULATING FLOORPLANNING Recall that in classical floorplanning, the input consists of a set of modules and module connectivity information. The objective is to minimize the area and the estimated wirelength. Kahng [1] was the first to explicitly question the assumptions made in classical floorplanning in 2000 and argued that several of these are not relevant to industrial floorplanning.We begin this chapter by examining these and other issues below. 12.2.1 OUTLINE-FREE VERSUS FIXED-OUTLINE FLOORPLANNING This first issue pertains to the floorplan or chip boundary.Classical floorplanning operates under the outline-free model wherein no bounding rectangle is specified. Instead, the floorplanning algorithm typically based on simulated annealing (SA) attempts to minimize chip area subject to (usually fairly generous) aspect ratio constraints. In contrast, in the fixed-outline version, the dimensions of the bounding chip rectangle are fixed before floorplanning; in other words, the chip boundary is an input constraint rather than an optimization c riterion. The fixed-outline model is considered to be more realistic because floorplanningis only carried out after the die size and the package have been chosen in most design methodologies. How does this change in formulation impact floorplanning technology? Because the dimensions of the bounding rectangle are now part of the input, the modules have to be organized so that they fit inside this rectangle. Does this make the problem easier or harder? It depends on the bounding rectangle. If this is much larger than necessary, it makes the problem easier. If the bounding rectangle is tight, it makes the problem harder. Another way to look at the two formulations is that the outline-free formulationis an optimization problem (we are trying to minimize area) and the fixed-outline formu lation is a decision problem (we are trying to meet area constraints). This relationship between an optimization and the d eci- sion versions of a problem arises in the study of NP-completeness in theoretical computer science. NP-completeness theory is based on decision problems, whereas real-world problems are usually optimization problems. The argument that is made in this context is that the two versions are essen- tially equivalent; specifically, one can solve the constrained version of the problem by running an optimizer and returning a “yes” or a “no” depending on whether the value returned by the optimizer (e.g., the chip area) is respectively less or greater than the constraint (e.g., the available area in the fixed-outlin e). This argu m ent does not work here because of the two-dimensional ( 2D) natu re of the constraint. Fixed-outline floorplanning does not merely require the floorplan to meet a single (area) constraint; rather, it requires the floorplan to meet both width and height criteria. It is precisely the trade-off between height and width that makes the problem challenging when the bounding rectangle is tight. We make this more concrete with an example. Suppose the desired outline is 10 × 10 and a classical floorplannning optimizer obtains a solution with area 90 < 100. If the resulting floorplan dimensionsare (say) 15×6, this is still a failure because a 15×6 rectangle cannot fit inside a 10×10 rectangle. 12.2.2 MODULE SHAPE AND FLEXIBILITY Classical floorplanning has mostly used rectangular modules and sometimes other simple shapes such as L- and T-shapes. We are not aware of a technical reason for shapes to be restricted to Alpert/Handbook of Algorithms for Physical Design Automation AU7242_C012 Finals Page 241 24-9-2008 #4 Recent Advances in Floorplanning 241 rectangles and believe that this arose because rectangles are easier to work with than other rectilinear shapes. (Imagine how much easier it would be to play Tetris if all shapes were rectangles.) Classical floorplanning does allow flexible modules (modules whose dimensions are not fixed); however, in the context of rectangular modules, this is limited to allowing a module to have any aspect ratio in a range. Current designs consist of a mixture of blocks and cells. Blocks are components that have typically already b een designed and therefore have fixed shapes and dimensions. Cells can be grouped together to form flexible blocks that can take on arbitrary rectilinear shapes. How does this impact floorplanning? Clearly, having fixed nonrectangular shapes complicates the pr oblem. For example, writing a program that merely figures o ut whether two arbitrary rectilinear polygons intersect or not is more complex than asking the same question for a pair of rectangles. Literature that considers the graph dualization appro ach to floorplannin g with simple rectilinear shapes confirms this as does work on extending corner stitching to simple rectilinear shapes. The use of arbitrary rectilinear polygons also clearly increases the solution space relative to solely using rectangles (the latter is a special case of the f ormer). On the other hand, having malleab le rectilinear shapes increases the opportunity for obtaining better solutions: intuitively, this is because flexible rectilinear shapes can be massaged and squeezed in between fixed-shape blocks. However, if this flexibility is taken too far, it could result in long stringy shapes that may not be suitable for routing (assuming that interconnections connecting cells within a block must stay within the block boundary). In short, the use of flexible, arbitrary rectilinear shapes is a bit of a double-edged sword. 12.2.3 WHITESPACE: TO MINIMIZE OR NOT TO MINIMIZE? Whitespace is defined as the fraction of chip area that does not contain silicon devices. Minimizing area (or whitespace) has traditionally been a key ob jective of flo orplanning. Hennessy and Patterson point out in their classic computer architecture text that die cost is proportional to the square of die area [2, p. 24]. Although area minimization is still an important cost-metric, it alone is no longer sufficient in modern floorplandesign. One reason is that true chip area depends on both the area used for logic and the area used for interconnect.Module areas represent area used for logic and short interconnects, but do not account for area needed by power and ground lines, nor for longer and wider interconnects, nor space between interconnects, etc. Thus, area minimization should also take into account sources of area that have traditionally been ignored. A second reason is the realities of deep-submicron design: timing requirements and routing congestion are becoming more problematic, both of these are exacerbated by insufficient area. Therefore, the floorplan must contain some whitespace by design to alleviate these problems so that feasible solutions can be obtained. We also need to reserve whitespace forbufferinsertionforhigh-performancedesigns.(Bufferinsertionis discussed separately in Chapters 26 through 28.) Finally, we note that in the fixed-outline formulation, the provided outline essentially determines the amount of whitespace available, transforming whitespace minimization to a constraint. However, the floorplanning algorithm’s strategy may depend on how much whitespace is provided. If the bounds are tight, the algorithm can declare victory if it manages to fit the blocks in the outline. If the boundsare loose and there is plenty of whitespace, the floorplanning algorithm can reasonably be expected to do more (e.g., optimize other criteria such as wirelength). 12.2.4 INTERCONNECT Classical floorplanning algorithms focus o n minimizing wirelength estimates (in addition to area). This does not take into account the actual routes of long-distance connections and therefore (some- what) ignores timing and congestion. More recent floorplanning algorithms attempt to r ectify this by using more relevant criteria to judge the quality of the solution from an interconnect standpoint. . Alpert /Handbook of Algorithms for Physical Design Automation AU7242_C011 Finals Page 232 29-9-2008 #31 232 Handbook of Algorithms for Physical Design Automation 5 4 3 2 1 0 6 4 2 0 0 2 4 6 8 10 a b c e f d 12 Width Height Duration FIGURE. B ∗ -tree branches. Alpert /Handbook of Algorithms for Physical Design Automation AU7242_C011 Finals Page 234 29-9-2008 #33 234 Handbook of Algorithms for Physical Design Automation • Bottom-boundary. representations for general floorplans. In Proceedings of ACM/IEEE Design Automation Conference, New Orleans, L A, pp. 842–847, 2002. Alpert /Handbook of Algorithms for Physical Design Automation AU7242_C011