Creating a Floorplan With Overlapping I/O, Macro and Standard Cell Areas

Version F-2011.09, November 2011

Copyright Notice and Proprietary Information

Copyright 2011 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and proprietary information that is the property of Synopsys, Inc. The software and documentation are furnished under a license agreement and may be used or copied only in accordance with the terms of the license agreement. No part of the software and documentation may be reproduced, transmitted, or translated, in any form or by any means, electronic, mechanical, manual, optical, or otherwise, without prior written permission of Synopsys, Inc., or as expressly provided by the license agreement.

Right to Copy Documentation

The license agreement with Synopsys permits licensee to make copies of the documentation for its internal use only. Each copy shall include all copyrights, trademarks, service marks, and proprietary rights notices, if any. Licensee must assign sequential numbers to all copies. These copies shall contain the following legend on the cover page: This document is duplicated with the permission of Synopsys, Inc., for the exclusive use of __________________________________________ and its employees. This is copy number __________.

Destination Control Statement

All technical data contained in this publication is subject to the export control laws of the United States of America. Disclosure to nationals of other countries contrary to United States law is prohibited. It is the readers responsibility to determine the applicable regulations and to comply with them.

Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

Registered Trademarks ()
Synopsys, AEON, AMPS, ARC, Astro, Behavior Extracting Synthesis Technology, Cadabra, CATS, Certify, Chipidea, CHIPit, CODE V, CoWare, CoMET, Confirma, Design Compiler, DesignSphere, DesignWare, Eclypse, EMBED-IT!, Formality, Galaxy Custom Designer, Global Synthesis, HAPS, HapsTrack, HDL Analyst, HSIM, HSPICE, Identify, Leda, LightTools, MAST, MaVeric, METeor, ModelTools, NanoSim, NOVeA, OpenVera, PathMill, Physical Compiler, PrimeTime, SCOPE, SiVL, SNUG, SolvNet, Sonic Focus, STAR Memory System, Syndicated, Synplicity, Synplify, Synplify Pro, Synthesis Constraints Optimization Environment, TetraMAX, the Synplicity logo, UMRBus, VCS, Vera, and YIELDExplorer are registered trademarks of Synopsys, Inc.

Trademarks ()
AFGen, Apollo, ASAP, Astro-Rail, Astro-Xtalk, Aurora, AvanWaves, BEST, Columbia, Columbia-CE, Cosmos, CosmosLE, CosmosScope, CRITIC, CustomExplorer, CustomSim, DC Expert, DC Professional, DC Ultra, Design Analyzer, Design Vision, DesignerHDL, DesignPower, DFTMAX, Direct Silicon Access, Discovery, Encore, EPIC, Galaxy, HANEX, HDL Compiler, Hercules, Hierarchical Optimization Technology, High-performance ASIC plus Prototyping System, HSIM , i-Virtual Stepper, IICE, in-Sync, iN-Tandem, Intelli, Jupiter, Jupiter-DP, JupiterXT, JupiterXT-ASIC, Liberty, Libra-Passport, Library Compiler, Macro-PLUS, Magellan, Mars, Mars-Rail, Mars-Xtalk, Milkyway, ModelSource, Module Compiler, MultiPoint, ORAengineering, Physical Analyst, Planet, Planet-PL, Polaris, Power Compiler, Raphael, RippledMixer, Saturn, Scirocco, Scirocco-i, SiWare, Star-RCXT, Star-SimXT, StarRC, System Compiler, System Designer, Taurus, TotalRecall, TSUPREM-4, VCSi, VHDL Compiler, VMC, and Worksheet Buffer are trademarks of Synopsys, Inc.

Service Marks (SM)

MAP-in, SVP Caf, and TAP-in are service marks of Synopsys, Inc. SystemC is a trademark of the Open SystemC Initiative and is used under license. ARM and AMBA are registered trademarks of ARM Limited. Saber is a registered trademark of SabreMark Limited Partnership and is used under license. All other product or company names may be trademarks of their respective owners.

ii

Contents
Using the I/O Area for Macro and Standard Cell Placement ................................. 4 Initializing the Floorplan ......................................................................................... 5 Initializing the Floorplan With Spacing Along the Edge of the Die ......................... 6 Creating Space Along the Edge of the Die Using Placement Blockages .............. 6 Inserting Space Between I/O Pads and Macros and Standard Cells .................... 7 Preventing Routing Over the I/O Pads .................................................................. 8 Power Routing ....................................................................................................... 9

iii

Using the I/O Area for Macro and Standard Cell Placement
This document describes the steps necessary to create a floorplan that uses the I/O placement area for the placement of I/Os, macros and standard cells. The placement and the power routing commands operate only in the core area, so changes to the default floorplanning flow are necessary to implement this type of layout. An example floorplan using this methodology is shown in Figure 1:
Figure 1 Floorplan with Overlapping I/O and Macro Placement Areas

Initializing the Floorplan

A default floorplan contains a core area enclosed by a die area. The space between the core area and die area is reserved for I/O pads as shown in Figure 2.
Figure 2 Core and Die Area with I/O Pad Spacing

The -left_io2core, -right_io2core, -top_io2core, and -bottom_io2core options to the create_floorplan command specify the spacing between the die area and core area. When you specify a positive value to these options, the spacing becomes larger and the core area becomes smaller. To create a floorplan that uses the I/O area for macro and standard cell placement, as well as I/O pad and driver placement, you must specify a negative value for the -left_io2core, -right_io2core, -top_io2core, and -bottom_io2core options. Specifying a negative value for these options allows you to create a floorplan with the same core and die area size. The following script sets a negative value for the I/O to core spacing options.
01 02 03 04 05 06 07 08 09 10 set iopad_width 345.565 set io2core -$iopad_width set die_width 2291.900 set die_height 2291.490 source pads.tcl create_boundary -coordinate \ [list [list 0 0] [list $die_width $die_height]] create_floorplan -control_type boundary \ -left_io2core $io2core -right_io2core $io2core \ -top_io2core $io2core -bottom_io2core $io2core

Note the minus sign in front of $iopad_width on line 2. This script creates a floorplan with the same die and core area sizes. If you are using an IC Compiler version older than F-2011.09, replace the create_floorplan command with initialize_floorplan.

Initializing the Floorplan With Spacing Along the Edge of the Die
You might want to reserve space along the die boundary and avoid placing standard cells at the die edge. Cells that are too close to the edge might cause DRC violations. You can create additional spacing by reducing the I/O-to-core spacing. The following example script creates a die edge that is offset from the core area by 3.6 m:
01 02 03 04 05 06 07 08 09 10 set iopad_width 345.565 set io2core [expr 3.6 - $iopad_width] set die_width 2291.900 set die_height 2291.490 source pads.tcl create_boundary -coordinate [list [list 0 0] \ [list $die_width $die_height]] create_floorplan -control_type boundary \ -left_io2core $io2core -right_io2core $io2core \ -top_io2core $io2core -bottom_io2core $io2core

Note the change to line 2 of the script. This script creates a core area that is slightly smaller than the die area. If you plan to place your macros beyond the core boundary and abut the die edge, the IC Compiler check_legality command will produce warning messages. The check_legality command is run at the end of any placement-related commands.

Creating Space Along the Edge of the Die Using Placement Blockages
To avoid warnings created by the check_legality command, you can create a hard placement blockage around the entire die. You should block only a certain number of standard cell sites to prevent wasted die area and optimize the blockage. The following example creates a blockage of the same size as the 3.6 m io2core offset used in the previous example. The script uses polygon commands to compute the dimensions of the placement blockages and avoids manual calculation.
01 02 03 04 05 06 07 08 09 set die_poly [get_attribute [get_die_area] boundary] set place_block_poly [compute_polygons -boolean not $die_poly \ [resize_polygon -size -3.6 [convert_to_polygon $die_poly]]] set n 0 foreach rectangle [convert_from_polygon $place_block_poly] { create_placement_blockage -type hard \ -name fp_boundary_keepout_$n -bbox $rectangle incr n }

For the example floorplan, the command on line 1 defines the starting polygon bounding box as {0.000 0.000} {2291.900 0.000} {2291.900 2291.490} {0.000 2291.490} {0.000 0.000}. The compute_polygons command on line 2 calculates a polygon that corresponds to the die area that is shrunk by 3.6 m on each side. The loop beginning
6

on line 5 converts the polygon to rectangles, which are used to create the placement blockages.

Inserting Space Between I/O Pads and Macros and Standard Cells
You may want to insert additional space between the I/O pads and the standard cells and macros. The easiest way to insert space is to create a keepout margin around all I/O pads. The following example uses the get_flat_cells command. This command should work for most designs. Note that $margin_width is the width of the keepout margin.
01 02 03 set m [expr 2 * $margin_width] set_keepout_margin -type hard -outer [list $m $m $m $m] \ [get_flat_cells -all -filter "is_io == true"]

You can also use the [get_cells -all -filter "mask_layout_type == io_pad"] command to filter the I/O pad cells. The preceding commands create a floorplan similar to the floorplan shown in Figure 3. The illustration shows the top left corner of the die containing one I/O pad with a margin and a placement blockage along the die edge.
Figure 3 Floorplan with Placement Blockages at the Die Edge

A different and more portable approach is to use placement blockages to create space between the I/O pads and the standard cells and macros in the design. This approach is useful if you are exporting the floorplan to DEF file later in the flow. Use the compute_polygons and resize_polygon commands to create new boundaries for the placement blockages.

The following example script adds placement blockages to the design. The script creates a polygon around each I/O cell and increases the size by 3.6 m on each side. Next, the script subtracts the core polygon from the die polygon. The result is used to create the placement blockages.
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 set core_poly [get_attribute [get_core_area] boundary] foreach_in_collection iopad [get_flat_cells -all \ -filter "is_io == true"] { set core_poly [compute_polygons -boolean not $core_poly \ [resize_polygon -size 3.6 [convert_to_polygon $iopad]]] } set die_poly [get_attribute [get_die_area] boundary] set place_block_poly [compute_polygons \ -boolean not $die_poly $core_poly] set n 0 foreach rectangle [convert_from_polygon $place_block_poly] { create_placement_blockage -type hard \ -name fp_boundary_keepout_$n -bbox $rectangle incr n }

Preventing Routing Over the I/O Pads

If the FRAM views of the I/O pads are not completely blocked, you must create route guides to prevent commands such as create_power_straps from creating straps over the I/O pads. The following example adds route guides over all I/O pads and around the edges. The script allows routing 0.5 m into the I/O pads and 0.5 m in from the die edges.
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 set route_poly [resize_polygon -size -0.5 $die_poly] foreach_in_collection iopad [get_flat_cells -all \ -filter "is_io == true"] { set route_poly [compute_polygons -boolean not $route_poly \ [resize_polygon -size -0.5 [convert_to_polygon $iopad]]] } set route_block_poly [compute_polygons \ -boolean not $die_poly $route_poly] set n 0 foreach rectangle [convert_from_polygon $route_block_poly] { create_route_guide \ -name fp_route_block_$n \ -no_preroute_layers {METAL METAL2 METAL3 METAL4 \ METAL5 METAL6} \ -no_signal_layers {METAL METAL2 METAL3 METAL4 \ METAL5 METAL6} \ -zero_min_spacing \ -coordinate $rectangle incr n }

Power Routing
To use some power routing commands, you must consider the negative io2core offset described in the previous sections. For example, to put VDD and VSS rings around the new core, use the following command:
create_rectilinear_rings -nets {VDD VSS} -offset {-360 -360} \ -width {5 5} -layers {METAL5 METAL6}

By default, when you specify -offset {0 0}, IC Compiler places the power rings around the perimeter of the core area, However, if you are using the I/O area for cell and macro placement, the -offset {0 0} option places the power rings outside of the die area. To place the rings correctly, specify a negative offset that is larger than the width of the I/O pads. You can use the route guides added in the previous steps to create power straps in xand y-directions. The route guides prevent straps from routing over the I/O pads. Since the straps are not surrounded by the rings, the tool places some straps outside the die area. These straps are later removed by default. The following syntax retains the horizontal floating pieces; the second create_power_straps command connects the pieces to the vertical straps.
create_power_straps -direction horizontal -num_placement_strap 40 \ -increment_x_or_y 60 -nets {VDD VSS} -layer METAL5 -width 2 \ -keep_floating_wire_pieces create_power_straps -direction vertical -num_placement_strap 40 \ -increment_x_or_y 60 -nets {VDD VSS} -layer METAL6 -width 2

Figure 4 shows a screenshot of the bottom-left corner of the design. The core rings surround the main core area and the power straps cross the entire chip.

Figure 4 Floorplan with Power Rings and Straps

10