Handbook of algorithms for physical design automation part 26 ppt

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 const

5 4 3 2 1 0 6 4 2

2 4 6 8 10

a b

c

e f d

12

Width

Height

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 1

1 3 5

1 3

5

n d

n e

nb

n c

n c

n f

n f

n d

n d

n f

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/placement solution 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

• Because the relation between each pair of tasks is defined in the representation, the geometric 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 more suitable for handling various practical placement 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

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 Chor Cv We can also detect if a task starts at time step zero on an RFU by observing the in-degree/out-degree of its corresponding

node in Ct

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 BOUNDARYCONSTRAINTS

The boundary-constrained modules are modules that must be placed along boundaries in the final placement A module can be placed along the bottom (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 definition of a B∗-tree, the left child n j of a node n i represents the lowest adjacent module b jto

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 (Figure 11.30):

Leftmost branch n0 Rightmost branch

b1

b1

b0

b3

b4

b8

b9

b6

b5

b2

b2

b9

b7 b8

b4

b5

b3

b6

b7

Bottom-left branch Bottom-right branch

FIGURE 11.30 Boundary modules and their corresponding B∗-tree branches

• 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 simulated 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 RECTILINEARMODULES

First, we show how to apply B∗-tree to find a feasible placement with L-shaped modules Let bL

denote an L-shaped module bL can be partitioned into two rectangular submodules by slicing bL along its middle vertical boundary As shown in Figure 11.31a, b1and b2are the submodules of bL,

and we say b1, b2∈ bL

To ensure that the left submodule b1and the right submodule b2of an L-shaped module bLabut,

Wu, Chang, and Chang impose the following location constraint (LC for short) for b1 and b2 in Ref [26]:

LC: Keep b2as b1’s left child in the B∗-tree

The LC relation ensures that the x-coordinate of the left boundary of b2is equal to that of the right

boundary of b1

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 b1and b2are the respective left and right submodules of an

L-shaped module bL, and they are misaligned When processing b2, b1 must have been placed We can classify the misalignment into two categories and adjust them as follows:

b2

b2

b2

b2

b2

b2

b2

b2

b1

b1

b1

b1

b1

b1

FIGURE 11.31 Eight situations of an L-shaped module Each is partitioned into two parts by slicing it along

the middle vertical boundary

Top profile

Contour

Top profile Contour

b2

b2

FIGURE 11.32 Placing two submodules b1and b2of an L-shaped module (a) If the contour is lower than the

top profile sequence at b2, then we pull b2up to meet the top profile sequence (b) If the contour is higher than

the top profile sequence at b2, then we pull b1up to meet the top profile sequence

1 Basin: The contour is lower than the top profile sequence at the position of the current

submodule b2 (Figure 11.32a) In this case, we pull b2 up to conform to the top profile

sequence of the L-shaped module bL

2 Plateau: The contour is higher than the top profile sequence at the position of the current

submodule b2 (Figure 11.32b) In this case, we pull b1 up to conform to the top profile

sequence of bL (Note that b2 cannot be moved down because the compaction operation

makes b2be 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 Figure 11.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 between them Figure 11.31 shows the submodules after repartitioning As shown in the figure, an L-shaped module is 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 ican 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 Figure 11.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

b5

b5

b4

b4

b3

b3

b2

b2

b1

b1

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

Filled area b2

b1

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 bCcan be partitioned into a set of submodules

b1, b2, , b n ordered from left to right Considering the LC relation, we keep the submodule b i+1as

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 b1, b2, , b nare 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 ihas 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

Figure 11.34, the submodule b1is placed above the submodule b2, which cannot be characterized by

an LC relation 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 representations 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 information 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 placement 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 feasible cases (denoted by) for the general floorplan representations

TABLE 11.1

Comparisons between Various Packing Floorplan Representations

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 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].

For the packing time, SP and TCG require O (n2) 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 Section 11.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 the body of an automobile while the induced operations is like the wheels of the automobile and the solution structure is like the highway network An automobile with its body alone can go nowhere For a comprehensive study of floorplan representations, 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 Angeles, CA, 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, LA, pp 842–847,

2002

6 H Murata, K Fujiyoshi, S Nakatake, and Y Kajatani Rectangle-packing based module placement In

Proceedings of IEEE/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 Wu B∗-trees: A new representation for non-slicing

floorplans In Proceedings of ACM/IEEE Design Automation Conference, Los Angeles, CA, 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 Chang, and S.-P Lin Corner sequence: A P-admissible floorplan 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

Proceedings–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 Automation of Electronics Systems, 8(2):188–202, 2003.

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 Floorplanning 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/Microarchitecture Interactions 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 floorplanning focused 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

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 floorplanplan-ning are described in Section 12.4 Floorplanplan-ning for specialized architectures such as field programmable gate arrays (FPGAs) and analog integrated circuits (ICs) are discussed

in Section 12.5 Statistical floorplanning and floorplanning for manufacturability are described in Sections 12.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 VERSUSFIXED-OUTLINEFLOORPLANNING

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 criterion The fixed-outline model is considered to be more realistic because floorplanning is 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 formulation is an optimization problem (we are trying to minimize area) and the fixed-outline formulation is a decision problem (we are trying to meet area constraints) This relationship between an optimization and the deci-sion verdeci-sions 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-outline) This argument does not work here because of the two-dimensional (2D) nature 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

dimensions are (say) 15×6, this is still a failure because a 15×6 rectangle cannot fit inside a 10×10 rectangle

12.2.2 MODULESHAPE ANDFLEXIBILITY

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

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 been 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 problem For example, writing a program that merely figures out 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 approach to floorplanning 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 former) On the other hand, having malleable 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:TOMINIMIZE ORNOT TOMINIMIZE?

Whitespace is defined as the fraction of chip area that does not contain silicon devices Minimizing area (or whitespace) has traditionally been a key objective of floorplanning 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 floorplan design 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 for buffer insertion for high-performance designs (Buffer insertion is 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 bounds are 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 on 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 rectify this

by using more relevant criteria to judge the quality of the solution from an interconnect standpoint