CHAPTER SIX

Planning I/Os and Flip-Chip Bumps: Filling the Strip the Floorplan Left Empty

By the end of this chapter you will be able to check that a library is fit for a flip-chip design before you run a single command; to build an I/O ring and know where the ordering on each side begins; to work out how many pad cells a side will hold and how much room to leave over; to say how often a power pad must appear and in what order the signal pads must sit; to lay out a bump field in the three documented patterns and count the bumps each one produces; to pair pads with bumps automatically or by hand and say which you would defend; to insert the corner, break and filler cells that nobody asks for and everybody needs; to route, optimise and shield the redistribution layer; and to run the two different checks — one before placement and one after — that between them catch the mistakes this chapter can make.

Why this chapter matters in a real project

Chapter 4 drew a boundary and reserved a strip of silicon 120 µm deep all the way round it, and then left that strip completely empty. This is the chapter that fills it. Everything that connects the design to the outside world lives in there or just above it: the driver cells that shift signals on and off the die, the power and ground pads that feed the whole chip, the corner cells, the filler, and — for a flip-chip design — the field of bumps that the package will actually solder to.

What makes it worth reading slowly is not difficulty. Almost every step is arithmetic you could do on paper, and this chapter does exactly that, twice, for every number it uses. What makes it worth reading slowly is that the arithmetic runs into two constraints you did not set and cannot change. The pad cell's width and height come from the library. The bump pitch, and often the bump positions themselves, come from the package — and the package is frequently signed off before your floorplan is. So this is not a chapter about deciding how big things are. It is a chapter about fitting what you were given into the space you have, discovering early that it does not fit, and saying so while there is still time to move something.

The other reason for care is that the failures here are quiet in a particular way. A wrong design_type in the library is not reported by any command in this chapter; it simply means bump assignment does not happen for that cell, and the cell sits there looking placed. A guide created on the wrong side puts its pads facing into the die. A filler run that leaves a two-micron gap is an error you can read, but a filler run that leaves no gap on a ring with no slack in it was a ring you should never have built. None of these is subtle once you know to look, and the whole of Section 6.6 is about knowing where to look.

Prerequisites

Chapter 4 above all: the die, the core, and the core offset that this chapter fills — including the fact that the offset defaults to the minimum I/O cell height, which is the first hint that the library was always going to have a say. Chapter 2: units, and the habit of reading a value back rather than trusting what you typed. Chapter 3: routing rules and application options. Chapter 5: matching types are new here, but the discipline is the one Chapter 5 taught — a number you type is a decision nothing downstream will question.

How to read the numbers and the notation in this chapter

Every length in this chapter is in microns, because microns are what the I/O and bump commands are typed in. That is a change from Chapter 4, which worked in millimetres, and it is the single most common source of confusion in the whole flow — so here is the notation, spelled out, before anything else.

Learning objectives

6.1 The beginner's mental model

Start with a terraced street

Picture a row of houses along one side of a street. They sit in a line, shoulder to shoulder, and what matters about any one of them is not its coordinates but its position in the row: third from the corner, next door to the substation. Where the row meets the next street there is a building on the corner that belongs to neither row.

Now look at the road itself. Set into it is a grid of service covers at a fixed spacing — not a spacing anybody on this street chose, but one the water company settled years ago. Every house needs a pipe from its own front wall down to one of those covers, and which cover it gets is a decision somebody has to make, house by house.

That is the whole chapter. The row of houses is an I/O guide: an ordered line of pad cells along one side of the die. The substation every few houses is a power pad, inserted at a ratio you specify. The corner building is a corner cell. The grid of covers is a bump array. The pipes are RDL routes. And the decision about which cover serves which house is pad-to-bump assignment, which is what matching types are for.

Now the engineering model

After the floorplan exists, you can instantiate the I/O drivers and the bump cells. The tool supports unconstrained and constraint-based placement of both, and it supports placement constraints that specify the ordering, the x-y coordinate and the placement side for each I/O. Both package-driven and die-driven flows are supported, and different driver styles — including pads with integrated drivers — are handled.

Two facts bound everything that follows. The first: chip I/Os can be placed along the chip periphery or in islands within the chip core. The periphery is the common case and the one this chapter builds, but nothing requires it. The second: the constraints come in exactly two kinds — signal constraints, which specify I/O adjacency requirements, and power constraints, which specify power requirements. Section 6.4.2 and Section 6.4.3 take one each, and the division between them is worth learning now because the two commands are easy to confuse.

The order of the work is fixed, and Figure 6.1's second panel gives it in full: rings or guides, then bump arrays, then power constraints, then signal constraints, then matching types, then place_io, then the physical-only cells, then the constraints written back out, then RDL routing, optimisation and shielding. Eleven steps. Only two of them — place_io and the RDL router — do anything you could call automatic; the other nine are you telling the tool what you have decided.

Do not confuse these

6.2 The concepts, from first principles

6.2.1 The library, before anything else

Before beginning a flip-chip design you must ensure that the reference library containing the flip-chip component cells is properly configured. That sentence is easy to skim past, and it is the most expensive sentence in the chapter to ignore, because the configuration in question is a single attribute on each of four kinds of cell and nothing later reports a wrong one.

The attribute is design_type, and the four values are these. Bump cells must have it set to flip_chip_pad. Driver cells must have it set to flip_chip_driver or pad — or to macro, if the flip-chip matching types are defined. Filler and break cells must have it set to pad_spacer, one value covering both. Corner cells must have it set to corner.

Two of those four need something more than design_type. On the library cell pin of a bump cell, the is_pad attribute must be set to true — and the reason is specific: you must set this attribute for the tool to automatically create terminals for top-level ports when bumps are connected or assigned to ports. On a driver cell, the terminal or pin shape that will be connected to an RDL route should have the class attribute set to bump; if there is no terminal with that setting, the RDL router chooses the topmost layer terminal of the port instead. That is not an error. It is a different route from the one you intended, chosen silently.

Where does the value come from? Often from the LEF file for the library cell, and the mapping is worth knowing because it explains most of what you will find already correct: a value of pad is created from the PAD macro class, and a value of flip_chip_pad from the COVER BUMP macro class. Property types and attribute settings on the frame view can be examined in the Library Manager, which is the first place to look. And some attributes of a library reference cell can be overridden with set_attribute in the tool — with one consequence stated plainly in the reference and worth repeating: attribute settings performed in the tool are not propagated to the reference library. Your override lives in this session and dies with it unless the script that set it is kept.

6.2.2 Rings, guides, and which end is the beginning

An I/O guide forms a placement area for I/O drivers. You can create an I/O ring by placing four guides along the periphery with four create_io_guide commands, or by using one create_io_ring command. Multiple rings are supported, and so are multiple guides on the same side of the die.

The ring is the convenient form, and it names its guides for you:

icc2_shell> create_io_ring -name outer_ring -corner_height 300
{outer_ring}
icc2_shell> get_io_guides
{outer_ring.left outer_ring.bottom outer_ring.right outer_ring.top}

Four guides, named by adding .left, .top, .right and .bottom to the ring name. If you do not name the ring it is called _default_io_ring followed by an index, which is why that name turns up in so many examples.

The four-command form gives you control of the exact geometry, and it is where the one genuinely confusing option lives:

icc2_shell> create_io_guide -name "ring_left" -line {{0 300} 3000} -side left
{ring_left}
icc2_shell> create_io_guide -name "ring_top" -line {{300 3640} 3000} -side top
{ring_top}

-line takes a starting point and a length, and it is required. -side is also required, and it does more than label the guide: it indicates the orientation by specifying the outer edge. Left and right lines must be vertical; top and bottom lines must be horizontal. And the pads of a left guide are aligned on the right side of the guide line — because the line is the outside of the die and the pads sit inward from it.

The clockwise rule is the thing to memorise, because every signal constraint you write depends on it. Signal ordering begins at the lower-left pad for the left edge, the upper-left pad for the top edge, the upper-right pad for the right edge, and the lower-right pad for the bottom edge. So the starting point of a left guide is the bottom end of its line, and the starting point of a right guide is the top point of its line. A constraint that lists three pads in order produces a different physical arrangement on the left side than on the right, and both are correct.

Guides may be placed anywhere in the hierarchy provided five rules are honoured, and they are worth reading as a checklist rather than as prose. All flip-chip bump cells must be placed at the top level. Guides are not allowed to cross block boundaries for a placed block. An I/O pad cell and its associated guide must be placed within the same physical block instance. Only pads in the same logical hierarchy as the guide can be constrained with set_signal_io_constraints. And guides must not overlap.

Twelve commands manage rings and guides, and they divide into four jobs. Two make them: create_io_ring and create_io_guide. Four populate them — add_to_io_guide adds pad cells to a guide, add_to_io_ring adds guides to a ring, and remove_from_io_guide and remove_from_io_ring undo each of those. Two find them: get_io_guides and get_io_rings return collections. And four report or remove them: report_io_guides and report_io_rings print them — both take -verbose and -significant_digits — while remove_io_guides and remove_io_rings delete them from the block. The four in the middle are the ones worth knowing early: a ring built with the wrong corner height is edited, not rebuilt, and editing it leaves every constraint that names a guide intact.

6.2.3 Nimbus-8's ring, and the arithmetic that fills it

Everything so far has been mechanism. Here is what it comes to on the design this book has been carrying.

Chapter 4 fixed Nimbus-8's die at a square 3,440 µm on each side and its core at a square 3,200 µm on each side, leaving a core offset — the strip this chapter fills — 120 µm deep on all four sides. The library offers pad cells 110 µm tall and 46 µm wide, and a corner cell that is a square 110 µm on each side. The 110 against the 120 is the first check to make and the easiest to forget: a pad taller than the offset does not fit in the strip at all, and 10 µm of margin is comfortable rather than generous.

The guide length follows from the die and the corner cells, because the corners belong to neither side:

3,440 − 2 × 110 = 3,220 µm of guide, on each of the four sides

How many pads is that? At 46 µm each, 3,220 ÷ 46 = 70 exactly. It is tempting, and it is the wrong answer, and the reason is worth stating as a rule: a ring filled to its exact length has no slack, and a ring with no slack cannot be adjusted. Seventy pads leaves nothing for filler cells, nothing for break cells, and nothing for the spacing a power constraint may ask for. So Nimbus-8 fills 56 slots per side and keeps the difference:

56 × 46 = 2,576 µm of pad cell
3,220 − 2,576 = 644 µm of gap, which is 20.0 per cent of the guide

Now the power pads. Section 6.4.2 gives the command; what matters here is the arithmetic it implies. A ratio of 6 means no more than six signal pads between successive power pads of that type, and with a VDD constraint and a VSS constraint both at 6 the repeating unit is six signal pads, a VDD, six more signal pads and a VSS — fourteen slots holding twelve signal pads and two power pads. Fifty-six divides by fourteen exactly four times, so each side carries

4 × 12 = 48 signal pads,  4 VDD,  4 VSS  =  56 slots
and the whole ring:  4 × 56 = 224 pads  =  192 signal + 32 power

Power and ground are 32 of 224, which is 14.29 per cent of the ring. Check it the other way: 192 ÷ 224 = 85.71 per cent signal, and the two shares sum to 100.

6.2.4 Bump arrays, and the three patterns

The tool supports bump cell placement for flip-chip designs, and there are two routes to it. You can place bump cells from coordinates in a DEF or AIF file — Section 6.2.6 — or you can create a bump array with create_bump_array, which is the die-driven flow: you create a region for bump placement and let the tool determine the locations. One sequencing rule governs both: you should place bump cells before placing I/O driver cells.

create_bump_array has two required options and they are the two that matter most. -delta gives the horizontal spacing between adjacent columns and the vertical spacing between adjacent rows — the bump pitch, which came from the package. And one of -lib_cell or -lib_cell_collection names the bump library cell; all bump instances in an array must have the same library cell.

The three patterns are the part worth drawing, because the names do not tell you how many bumps you get. inline places a bump at every point in the array defined by -delta. staggered_1 places bumps only where the sum of the column index and the row index is even. staggered_2 places them only where that sum is odd. On any grid, the two staggered patterns are complements of one another and each gives you about half as many bumps as inline — exactly half when the number of grid points is even, and one more or one fewer when it is odd.

Nimbus-8's bump field is five arrays, following the shape of the framework's own example: four peripheral bands for signal, and one central field for power and ground. The pitch is 150 µm, which came from the package. Twenty-two sites fit across the die, because twenty-one gaps of 150 µm span 3,150 µm and the remaining 290 µm splits into 145 µm at each edge.

The four signal bands are 3 columns × 20 rows on the left and right and 12 columns × 3 rows on the top and bottom, which gives

2 × (3 × 20) + 2 × (12 × 3) = 120 + 72 = 192 signal bumps

and 192 is exactly the number of signal pads the ring holds. That agreement is the point of the whole section, and it did not happen by itself — the band depths were chosen to produce it.

The central field is a 15 × 15 grid at the same pitch with -pattern staggered_1. Of its 225 points, the ones with an even column-plus-row sum number

8 × 8 + 7 × 7 = 64 + 49 = 113 bumps

because there are 8 even indices and 7 odd ones in 0 to 14, and an even sum needs both indices even or both odd. Total: 192 + 113 = 305 bumps, against 484 sites if the whole die were filled inline — 63.02 per cent of them used.

6.2.5 When the pads are not on guides: bump patterns from a file

Everything above assumes an I/O ring. In designs where the pad cells are not placed using guides — clusters of I/O cells in the core, area-array pads, an island — create_bump_pattern instantiates bump cells relative to named pads instead of relative to the die. It is the right tool when the requirement is that bump cells sit in rows or columns perpendicular to the I/O pad cells.

The command takes a file, and the file is where all the work is:

icc2_shell> create_bump_pattern -file_name bump_patterns.txt
12 bumps and 5 matching types are created successfully

Two things about that response are worth pausing on. It reports bumps and matching types — the pattern file creates both, so this one command does a job that would otherwise be create_bump_array plus several create_matching_type calls. And the matching types it creates are named from the matching-type prefix in the file plus the first I/O pad named, which is why the framework's own example produces names like g0_bus_3 from a prefix g0_ and a first pad bus_3.

The file's format is documented in full and is more than this chapter needs to teach in detail, but its shape is worth knowing: a bump_lib_cell line naming the bump cell, a bump_pitch line in microns, and one or more io_group blocks. Each group lists the I/O pad instance names, each in its own braces with an optional matching-type prefix — and if no prefix is given, the prefix s is used. Each group may also state an orientation of row, column or perpendicular, and then one or more ordering-and-spacing sections giving a centre-line offset, a first-bump spacing on the left or bottom, the matching-type prefixes for that side, a first-bump spacing on the right or top, and the prefixes for that side. Comments begin with a hash for a whole line or two forward slashes inline.

6.2.6 When the package has already decided: reading locations

If the locations of the bump cells are determined by the constraints of the package — which on a production design they usually are — you do not create an array at all. You read the positions in with read_aif:

icc2_shell> read_aif bumps.aif

The location information is typically held in a DEF or an AIF file containing x- and y-coordinates and bump cell names for the bumps in the block. An AIF file's [DIE] section gives a width and a height, its [PADS] section defines the bump cell outlines, and its [NETLIST] section lists one line per bump with a net name, a pad type and a pair of coordinates. The coordinates in the framework's example are negative as well as positive, which is the first clue that the file's origin is the die centre rather than a corner — a detail to check against your own file rather than to assume.

One option deserves naming: -hierarchy reads in bump cell and I/O pad locations and places the I/O pads in any level of physical hierarchy. On a flat design you will not need it. On the multi-level design of Section 6.2.7 it is the difference between a file that works and one that places everything at the top.

6.2.7 More than one level of hierarchy

The tool supports top-level and block-level flip-chip planning for designs with multiple levels of physical hierarchy, and the governing behaviour is a single sentence: performing top-level flip-chip routing connects bump cells at the top level and ignores bump cells within the blocks. Everything else follows from that.

Seven considerations apply, and they read as a set of constraints on how the design must be organised. Blocks which contain I/O bump cells or pad cells must be preplaced. I/O pad cells may be at the top level or the block level, and those at the block level are considered fixed. I/O guides are created at the top level. Matching types that assign top-level bumps to block-level I/O cells must be created at the top level. I/O pads are placed at the block level for blocks that contain them. Block-level I/O pads should be specified with create_matching_type. And for block-level pads not specified that way, the pin shapes should have their class attribute set to bump in the Library Manager.

That last pair is the same choice Section 6.2.1 offered for macros, appearing again in a different place: name the object in a matching type, or mark its terminal in the library. Naming it is more work and more explicit, and the reference recommends it both times.

6.3 Inputs, outputs and readiness

This chapter needs more from outside the tool than any chapter so far: a library that has been checked, and a package that has been decided. Both are other people's work, and both arrive on their own schedule.

Preflight checklist

6.4 The guided tool walkthrough

6.4.1 create_io_ring and create_io_guide — the placement area

Purpose. Create or group a related set of I/O guides used for I/O placement; or create one line-based I/O pad constraint for I/O placement. Guides must exist before I/O cells are placed.

Syntax in plain English. The ring form takes a name and a size and makes four guides. The guide form takes a line, a side, and optionally a name, offsets, pad cells and a minimum pitch. Table 6.3 has every option; the examples below are the four shapes you will actually type.

# The whole ring in one command, with the corner height stated.
icc2_shell> create_io_ring -name nimbus_ring -corner_height 110
icc2_shell> get_io_guides
{nimbus_ring.left nimbus_ring.bottom nimbus_ring.right nimbus_ring.top}

# Or four guides, when you want the geometry exactly.
icc2_shell> create_io_guide -name ring_left -line {{0 110} 3220} \
   -side left -offset {0 0}
icc2_shell> create_io_guide -name ring_top -line {{110 3440} 3220} \
   -side top -offset {0 0}

# A second ring inside the first, 200 um in.
icc2_shell> create_io_ring -name inner_ring -inside nimbus_ring \
   -offset 200

# A ring made by grouping guides that already exist.
icc2_shell> create_io_ring -name grouped -guides [get_io_guides]

Expected result. A ring holding four guides named after it, or one guide. An empty ring or guide is legal; pads can be added later.

Verification. get_io_guides and get_io_rings return collections, and report_io_guides and report_io_rings print them — both take -verbose and -significant_digits. Read the guide back and check its length against your arithmetic, because a -line length you typed is not a length the tool computed.

Common mistakes. Getting -side wrong, so the pads sit on the wrong side of the line and face into the die. Building a ring with -guides and then wondering why its corner height is zero — that form leaves it at zero until you set it. Assuming the ordering starts at the same corner on every side. Letting two guides overlap. And relying on the default corner height, which is the tallest pad assigned to the ring, on a ring that has no pads assigned yet.

Prerequisites. A floorplan, so that the die area exists to place the ring in.

Finding the rest. man create_io_ring and man create_io_guide; the Floorplan Task Assistant also builds both, under Floorplan Preparation, I/O Planning, I/O Ring and Guide.

6.4.2 set_power_io_constraints — how often the power pads appear

Purpose. Specify spacing and other requirements for power I/O drivers, so that place_io places them into the guides accordingly.

Syntax in plain English. Either a positional constraint description in braces, or four options that each take a list of value-and-reference-cell pairs. The two forms do the same job; the option form is easier to read and easier to diff.

# The positional form, as the framework writes it: a reference cell,
# a ratio, a name prefix, and the pin-to-net connections.
icc2_shell> set_power_io_constraints \
   -io_guide_object [get_io_guides "*left *right"] \
   {{reference: VDD_EW}
    {ratio: 6}
    {prefix: VDD}
    {connect: {VDDIO VDDIO} {VDD VDD1} {VSS VSS1}}}

# The option form, for two reference cells at once.
icc2_shell> set_power_io_constraints \
   -reference_cell {VDD_EW VSS_EW} \
   -ratio {{6 VDD_EW} {6 VSS_EW}}

# A maximum distance instead of a count, and a first-pad offset.
icc2_shell> set_power_io_constraints -reference_cell {VDD_NS VSS_NS} \
   -spacing {{100 VDD_NS} {100 VSS_NS}} \
   -offset {{100 VDD_NS} {100 VSS_NS}}

# Two VDD pads may drive one bump; three VSS pads may drive one.
icc2_shell> set_power_io_constraints \
   -reference_cell {VDD_NS VSS_NS} -share {{2 VDD_NS} {3 VSS_NS}}

Expected result. The constraint is recorded and reported set. Nothing moves until place_io runs.

Verification. The only real verification is after placement: check_io_placement -power_constraints. Before that, re-read the constraint you typed and check the arithmetic implies the pad count you expect — on Nimbus-8, a ratio of 6 on both cells means a repeating unit of 14 slots, and 56 divides by 14 exactly four times.

Common mistakes. Confusing -ratio with -spacing — one counts pads, the other counts microns. Setting a ratio whose repeating unit does not divide the pad count, so the four sides end differently. Forgetting -io_guide_object, so a constraint meant for two sides applies to all four. And assuming that setting no constraint means no behaviour: with none set, place_io places the power pads evenly throughout the guide.

Prerequisites. The guides must exist. The power pad cell references must be in the library.

Finding the rest. man set_power_io_constraints.

6.4.3 set_signal_io_constraints — in what order, and how far apart

Purpose. Specify the ordering and spacing for signal I/O drivers, for guides at the top level or within lower levels of the hierarchy.

Syntax in plain English. One of four sources: a constraint given inline, a constraint file, a CSV file, or a CSV file plus a map file that translates your column names into the ones the tool knows.

# Order only, inline. Spacing and other cells may still be inserted.
icc2_shell> set_signal_io_constraints -constraint {{order_only} \
   u_p/clk_pad_P1 u_p/sdclk_pad_P1 u_p/test_so_4_pad_P1} \
   -io_guide_object {_default_io_ring1.left}

# The same thing from a file, which is what you use in earnest.
icc2_shell> set_signal_io_constraints -file signal_io_constraints.txt

# From a CSV file, which only needs a "Pad Name" column.
icc2_shell> set_signal_io_constraints -csv iopads.csv \
   -io_guide_object io_guide_1

# From a CSV with your own column names, plus a map file.
icc2_shell> set_signal_io_constraints -csv ioconstraints2.csv \
   -io_guide _default_io_ring1.left -map_file map.txt

The CSV rules, because they are strict. The file must contain a header row defining the field order. Only the “Pad Name” field is required; “Offset Value” is optional. Any other fields are read and ignored — so a “Comment” or a “ref_cell” column is harmless. Fields may appear in any order, must not be repeated, and the number of fields must be the same in every row. If your columns have custom names, a map file of comma-separated pairs translates them, and the tool echoes each translation as it reads it.

Expected result. “Signal IO constraints set successfully”. Again, nothing moves until place_io runs.

Verification. check_io_placement -signal_constraints after placement, which checks order, pitch, spacing, offset of pads and boundary spacing. And write_io_constraints, which writes the constraints implied by the current placement — so writing them out and diffing against what you set is a direct check that the placer did what you asked.

Common mistakes. Forgetting that the ordering starts at a different corner on each side. Using order_only and then being surprised that gaps appeared. Repeating a field in a CSV file, or giving rows with different field counts. And expecting an absolute constraint to imply an order.

Prerequisites. The guides must exist, and only pads in the same logical hierarchy as the guide can be constrained.

Finding the rest. man set_signal_io_constraints and man write_io_constraints.

6.4.4 create_matching_type and place_io — pairing, then placing

Before routing flip-chip drivers to bump cells you must create assignments between them, and there are two ways.

Automatic. place_io -bump_assignment_only does only bump assignment: no pad placement, and I/O driver cells are not moved. It assigns bumps to drivers based on their current locations — and it is important to know what it ignores: all the signal I/O constraints and power I/O constraints are ignored in this mode. It also does not work with -pad_assignment_file, and it is mutually exclusive with -skip_bump_assignment.

User-specified. A matching type has two jobs: it provides driver-to-bump pairing, and it provides support for driver placement. The tool assigns flip-chip drivers to bump cells that have the same matching type.

# Four pads to four bumps, one pad per bump.
icc2_shell> create_matching_type -name match1 -uniquify 0 \
   {left_25_0 left_25_1 left_25_2 left_25_3 \
    pad_iopad_46 pad_iopad_47 pad_iopad_48 pad_iopad_49}

# Check the matching types before placing anything.
icc2_shell> check_pre_place_io -matching_types

# Then place. This is the command that applies the assignments.
icc2_shell> place_io

# Find the cells that carry a given matching type.
icc2_shell> get_cells -filter "matching_type.name == SIGNAL"
icc2_shell> get_cells -filter "matching_type.name =~ SIG*"

# Write out what the tool assigned by itself, and read it back.
icc2_shell> write_matching_types -from_existing_assignment \
   -file_name existing.tcl
icc2_shell> source existing.tcl

Six more commands manage matching types once they exist, and they are the reason a hand-written assignment is maintainable rather than a one-off. get_matching_types returns a collection of them by name. add_to_matching_type adds pads or bumps to one that already exists, and remove_from_matching_type takes them out again. report_matching_types lists each type with its uniquify number, object type and object names, which is the form to paste into a review. remove_matching_types deletes named types, or all of them with -all. And write_matching_types writes your own definitions to a file, or with -from_existing_assignment writes out what the tool decided on its own — a file you can read, edit and source back, which is what makes “automatic first, then correct by hand” a workable habit rather than a compromise.

Verification. check_pre_place_io -matching_types before, and after placement the RDL Flylines panel in the GUI or — better for a script — write_matching_types -from_existing_assignment and read the file. report_matching_types prints a matching type with its uniquify number, object types and object names.

Common mistakes. Running -bump_assignment_only and expecting the signal constraints to be honoured. Forgetting that place_io removes existing filler cells unless their physical_status is fixed — which happens when all pads are considered, and does not happen when only a fraction are incrementally replaced. Leaving a macro at its default design_type and wondering why no bump was assigned. And skipping check_pre_place_io, which finds matching-type conflicts in seconds that are tedious to unpick afterwards.

6.4.5 The three physical-only cells

After the I/O cells are placed, additional cells are inserted into the pad ring to fill the gaps between drivers and create more uniform density in the die. Three commands, and they go in a natural order: corners, then breaks, then filler — because filler fills whatever the first two leave.

Corner cells are placed at the intersection, or the projected intersection, of two perpendicular guides. -reference_cell inserts a new one from the library; -cell places an instance that already exists; and -force instantiates the cell within a named block, for a design with multiple levels of hierarchy and overlapping blocks.

Break cells create a space between the abutted connections of power nets in the ring, to allow for different voltages. A library might contain several, depending on the supply structure of the drivers and the requirements of the design. -location takes start, end or both to sit just outside one or both ends of a guide, or a distance in microns to move an existing instance that far from the start. Given two guides instead of one, the cell goes at their intersection.

Filler cells populate the empty spaces between driver cells and complete an abutted power connection. Many libraries contain several widths, and the rule that matters is this: when multiple filler references are specified with -reference_cells, the tool chooses the largest possible cell from the list that fills the space. So the list is written largest first, and Nimbus-8's 644 µm of gap per side resolves as

32 × 20 = 640 µm
 4 ×  1 =   4 µm
          644 µm in 36 cells, with nothing left over

Verification. check_io_placement -gap, which reports any space between two adjacent cells. And read the command's own output: if the smallest filler is still too big for a remaining gap, it says so and names the coordinate and the length — Error: In IO guide right, filler cells cannot cover the gap at (6500,6090) with length 2.

Common mistakes. Writing the reference list smallest first, so the tool fills a 640 µm gap with 640 one-micron cells. Running filler before break, so the break cell has nowhere to go. Running place_io again afterwards and losing the filler, because place_io removes existing filler cells whose physical_status is not fixed. And filling a ring with no slack in it, which is the Section 6.2.3 mistake arriving three steps late.

6.4.6 RDL: routing, optimising, shielding

After the bump and driver cells are placed, the redistribution layer nets can be routed. The documented procedure is five steps, and the first two are about the rule rather than the router.

# 1. The routing rule. Add -shield_spacings and -shield_widths now
#    if you intend to shield later; they belong on the rule.
icc2_shell> create_routing_rule rdlrule -widths {MRDL 3} \
   -spacings {MRDL 3}

# 2. Collect the RDL nets and apply the rule.
icc2_shell> set rdl_nets [get_nets -of_objects [get_pins \
   -of_objects [get_cells -filter "design_type==flip_chip_pad"]]]
icc2_shell> set_routing_rule [get_nets $rdl_nets] -rule rdlrule

# 3. The routing angle, per layer.
icc2_shell> set_app_options \
   -name flip_chip.route.layer_routing_angles \
   -value {{MRDL 90_degree}}

# 4. Route.
icc2_shell> route_rdl_flip_chip -layers {MRDL}

# 5. Check for open nets, and optionally write an error database.
icc2_shell> report_rdl_routes -open_nets true
icc2_shell> report_rdl_routes -create_error_data verification

Step 2 is worth reading twice. The RDL nets are found by their cells: the flip-chip pads are the cells whose design_type is flip_chip_pad, their pins give the nets, and those nets are the RDL nets. That is the one place in the chapter where the library attribute of Section 6.2.1 is used as a query rather than a requirement — and if a bump's design_type is wrong, this collection quietly comes back short.

The angle is worth arithmetic, not opinion. Nimbus-8's longest RDL route runs from a pad centred 60 µm in from the die edge to a bump 520 µm in and 2,850 µm along, so dx is 460 µm and dy is 2,850 µm. At 90 degrees the route is Manhattan and its length is the sum:

460 + 2,850 = 3,310 µm

At 45 degrees the diagonal absorbs the shorter leg, and the length is the longer leg plus 0.414214 times the shorter. That constant is the square root of two, less one, and it is worth keeping in your head: a 45-degree diagonal buys back about 59 per cent of the shorter leg, every time.

2,850 + 0.414214 × 460 = 3,040.5 µm
saving 3,310 − 3,040.5 = 269.5 µm, which is 8.14 per cent

Eight per cent of the wire length on the longest route, from one application option. Whether it is the right choice depends on the technology's rules for diagonal wiring and on whether the RDL is congested — but the size of the prize is arithmetic, and it is worth computing for your own longest route before the discussion starts.

6.4.7 check_io_placement — the nine checks

Purpose. Validate the I/O placement after place_io. The command writes a report listing violating cells and returns a collection of those cells, so it can be used in a script as well as read.

The checks divide into three groups. Three are about whether cells are where they should be at all: -unplaced, -overlap and -gap. Three are about whether the placement honours what you asked for: -signal_constraints, -power_constraints and -pad_to_guide_assignment. And three are about consistency with something else: -min_pitch against the guide, -flipping against each pad's is_flipped attribute, and -bump_assignment against the bumps.

Each check prints a bounded report with a start line, the violations, a total and an end line, which makes the output easy to parse and easy to diff between runs. -cells restricts the check to named cells, -io_guides to named guides, and -matching_types to named matching types. -filename writes everything to one file; -output_directory creates a directory and writes one file per violation type — the nine names in Figure 6.10.

Common mistakes. Confusing this command with check_pre_place_io, which runs before placement and checks guides, the pad assignment file and matching types. Reading a total of zero from a command that was given no check options. And treating -gap violations as cosmetic: a gap in the ring is a gap in the abutted power connection.

6.5 The worked example: Nimbus-8's I/O and bump plan

Eleven steps, in the order Figure 6.1 gave them, on the die Chapter 4 built. Every number has appeared already; this is where they are produced rather than quoted.

Step 0 — check the library, before anything else

# The six attributes of Section 6.2.1, read rather than assumed.
icc2_shell> foreach c {BUMP150 IOPAD46 FILLER20 CORNER110 BREAK20} {
   puts [format "%-12s %s" $c \
      [get_attribute [get_lib_cells */$c] design_type]]
}
BUMP150      flip_chip_pad
IOPAD46      flip_chip_driver
FILLER20     pad_spacer
CORNER110    pad_spacer
BREAK20      pad_spacer

# CORNER110 is wrong: pad_spacer, not corner. Fix it here and
# remember the fix is not propagated to the reference library.
icc2_shell> set_attribute [get_lib_cells */CORNER110] design_type corner

# And the two attributes that are not design_type.
icc2_shell> get_attribute [get_lib_pins */BUMP150/PAD] is_pad
true
icc2_shell> get_attribute [get_lib_cells */IOPAD46] design_type
flip_chip_driver

One of the five was wrong, and that is deliberately realistic. A corner cell delivered as pad_spacer is a plausible library error — corner cells and filler cells are both physical-only, and both sit in the ring — and no command later in this chapter would have told you. create_io_corner_cell would have placed it, and the ring would have looked complete.

Step 1 — the arithmetic, on paper, before the first command

# From Chapter 4, in this chapter's unit.
die                       = 3,440 um on each side
core                      = 3,200 um on each side
core offset (the strip)   =   120 um deep

# From the library.
pad cell                  =   110 um tall, 46 um wide
corner cell               =   110 um on each side

# Does the pad fit the strip?  110 < 120, with 10 um to spare.
guide length  = 3,440 - 2 x 110 = 3,220 um per side

# How many pads, and how much slack?
70 x 46 = 3,220 um  -> exactly full, no slack at all: rejected
56 x 46 = 2,576 um  -> gap of 3,220 - 2,576 = 644 um, 20.0 per cent

# The power pattern, from a ratio of 6 on both cells.
pattern = 6 signal + VDD + 6 signal + VSS = 14 slots
56 / 14 = 4 whole patterns per side
per side = 48 signal + 4 VDD + 4 VSS = 56
ring     = 4 x 56 = 224 pads = 192 signal + 32 power

# From the package.
bump pitch = 150 um
sites across the die: 21 x 150 = 3,150, so 22 sites,
   and (3,440 - 3,150) / 2 = 145 um of margin at each edge

Check each figure backwards before it goes anywhere. 2,576 + 644 = 3,220. 4 × 14 = 56. 192 + 32 = 224, and 32 ÷ 224 = 14.29 per cent while 192 ÷ 224 = 85.71 per cent, which sum to 100. And 145 + 3,150 + 145 = 3,440.

Step 2 — the ring

icc2_shell> create_io_ring -name nimbus_ring -corner_height 110
{nimbus_ring}
icc2_shell> get_io_guides
{nimbus_ring.left nimbus_ring.bottom nimbus_ring.right nimbus_ring.top}
icc2_shell> report_io_guides -verbose

The corner height is stated rather than defaulted, because the default is the tallest pad cell assigned to the ring and no pads are assigned yet. Read the guides back and confirm each is 3,220 µm long.

Step 3 — the bumps, five arrays

# Four signal bands, inline, at the package pitch.
icc2_shell> create_bump_array -lib_cell BUMP150 -delta {150 150} \
   -bbox {{220 220} {520 3070}} -repeat {3 20} -name left
icc2_shell> create_bump_array -lib_cell BUMP150 -delta {150 150} \
   -bbox {{2920 220} {3220 3070}} -repeat {3 20} -name right
icc2_shell> create_bump_array -lib_cell BUMP150 -delta {150 150} \
   -bbox {{895 220} {2545 520}} -repeat {12 3} -name bottom
icc2_shell> create_bump_array -lib_cell BUMP150 -delta {150 150} \
   -bbox {{895 2920} {2545 3220}} -repeat {12 3} -name top

# And one central power and ground field, staggered.
icc2_shell> create_bump_array -lib_cell BUMP150 -delta {150 150} \
   -bbox {{670 670} {2770 2770}} -pattern staggered_1 -name pg_bump

The counts, worked out rather than reported: the left and right bands are 3 × 20 = 60 bumps each, the top and bottom bands 12 × 3 = 36 each, so 2 × 60 + 2 × 36 = 192 signal bumps. The central field is a 15 × 15 grid; staggered_1 keeps the points whose column-plus-row sum is even, and with 8 even and 7 odd indices in 0 to 14 that is 8 × 8 + 7 × 7 = 113. Total 192 + 113 = 305, against 22 × 22 = 484 sites if the die were filled inline — 63.02 per cent of them.

And the number that matters: 192 signal bumps for 192 signal pads. That is the comparison Section 6.3's checklist item 6 asks for, and it comes out to zero difference because the band depths were chosen to make it so.

Step 4 — the constraints

# Power: a ratio of 6 on both reference cells, all four guides.
icc2_shell> set_power_io_constraints \
   -reference_cell {VDD_EW VSS_EW} \
   -ratio {{6 VDD_EW} {6 VSS_EW}} \
   -offset {{100 VDD_EW} {100 VSS_EW}}
Power IO constraints set successfully

# Signal: order from a file, which is the form that scales.
icc2_shell> set_signal_io_constraints -file nimbus_io_order.txt
Signal IO constraints set successfully

icc2_shell> sh cat nimbus_io_order.txt
nimbus_ring.left
{100}
{{order_only}
u_ddr/dq_pad_0 u_ddr/dq_pad_1 u_ddr/dq_pad_2 u_ddr/dq_pad_3}
{40}
{u_isp/pix_pad_0 20 u_isp/pix_pad_1}
;

Two things in that file are worth naming. The bare {100} is an offset — 100 µm from the start of the left guide, which on the left side means 100 µm up from the lower-left corner, because the ordering runs clockwise. And the DDR data pads are constrained order_only, which means their sequence is fixed and their spacing is not: additional spacing and other pad cells might be inserted between them, which is exactly what you want when a power pad has to land in the middle of a byte lane.

Step 5 — matching types, and the check that comes before placement

# Reserve the central field for power and ground: a matching type
# containing only bumps excludes them from signal assignment.
icc2_shell> create_matching_type -name pg_reserved -uniquify 0 \
   [get_cells pg_bump_*]

# Pair one byte lane explicitly, four pads to four bumps.
icc2_shell> create_matching_type -name ddr_byte0 -uniquify 0 \
   {left_0_0 left_0_1 left_0_2 left_0_3 \
    u_ddr/dq_pad_0 u_ddr/dq_pad_1 u_ddr/dq_pad_2 u_ddr/dq_pad_3}

# Check before placing. This is cheap; unpicking afterwards is not.
icc2_shell> check_pre_place_io -matching_types -io_guides
0

The first matching type is the reserved-bumps case from Figure 6.8's gold card, and it is the reason the 113 central bumps do not get signals assigned to them. The second is ordinary pairing. check_pre_place_io returning 0 means all six of its checks passed, including the one that matters most here — that each matching type has enough bumps for the pads in it.

Step 6 — place, then fill

icc2_shell> place_io

# Corners first, then breaks, then filler - filler fills what is left.
icc2_shell> create_io_corner_cell -reference_cell CORNER110 \
   {nimbus_ring.left nimbus_ring.bottom}
icc2_shell> create_io_corner_cell -reference_cell CORNER110 \
   {nimbus_ring.bottom nimbus_ring.right}
icc2_shell> create_io_corner_cell -reference_cell CORNER110 \
   {nimbus_ring.right nimbus_ring.top}
icc2_shell> create_io_corner_cell -reference_cell CORNER110 \
   {nimbus_ring.top nimbus_ring.left}

# Two I/O supply domains meet on the left side.
icc2_shell> create_io_break_cells -reference_cells BREAK20 \
   -location 1610 nimbus_ring.left

# Filler, largest first. The order of this list is the algorithm.
icc2_shell> create_io_filler_cells -prefix filler_ \
   -reference_cells {{FILLER20 FILLER10 FILLER5 FILLER1}}

# Write the placement back out as constraints, so it reproduces.
icc2_shell> write_io_constraints -filename nimbus_io_placed.txt \
   -format spacing

The break cell goes at 1,610 µm from the start of the left guide, which is the midpoint of a 3,220 µm side. The filler then resolves the 644 µm of gap per side as 32 cells of 20 µm and 4 of 1 µm — 36 cells, 644 µm, nothing left over. That remainder of zero is luck rather than a rule; if the library's smallest filler were 5 µm instead of 1 µm, 644 would resolve as 32 × 20 + 0 × 10 + 0 × 5 and leave 4 µm that nothing could cover, and the command would say so.

write_io_constraints -format spacing writes the spacing values between pads along with the pad names. The four documented formats are worth knowing apart: order_only writes only pad order, spacing writes the gaps, pitch writes locations as a cell pitch and requires that all pads be placed evenly in the guide, and fixed specifies that all pad cells are fixed at their current locations.

Step 7 — the RDL, and what the angle is worth

icc2_shell> create_routing_rule rdlrule -widths {MRDL 3} \
   -spacings {MRDL 3} -shield_widths {MRDL 2} -shield_spacings {MRDL 2}
icc2_shell> set rdl_nets [get_nets -of_objects [get_pins \
   -of_objects [get_cells -filter "design_type==flip_chip_pad"]]]
icc2_shell> set_routing_rule [get_nets $rdl_nets] -rule rdlrule

icc2_shell> set_app_options \
   -name flip_chip.route.layer_routing_angles \
   -value {{MRDL 45_degree}}
icc2_shell> report_app_options flip_chip.route.layer_routing_angles

icc2_shell> route_rdl_flip_chip -layers {MRDL} -nets $rdl_nets
icc2_shell> report_rdl_routes -open_nets true
icc2_shell> optimize_rdl_routes -layer MRDL -nets $rdl_nets

# Shields, on the net named by the application option.
icc2_shell> set_app_options -name flip_chip.route.shielding_net \
   -value VSS
icc2_shell> create_rdl_shields -layers {MRDL} -nets $rdl_nets \
   -shield_on_bump true -trim_floating true

The shield widths and spacings go on the routing rule at the moment it is created, not later — that is why they appear in step one of a sequence whose fifth step is the shielding. And report_app_options after setting the angle is the habit this book keeps insisting on: the option's documented values are 45_degree and 90_degree, and reading it back costs nothing.

The angle on Nimbus-8's longest route: from a pad centred 60 µm in from the die edge to a bump 520 µm in and 2,850 µm along the side, dx is 460 µm and dy is 2,850 µm.

at 90 degrees:  460 + 2,850                = 3,310 µm
at 45 degrees:  2,850 + 0.414214 × 460     = 3,040.5 µm
                saving 269.5 µm, which is    8.14 per cent

Step 8 — check what came out

icc2_shell> check_io_placement -output_directory io_checks \
   -unplaced -overlap all -min_pitch -gap -flipping \
   -signal_constraints -power_constraints \
   -pad_to_guide_assignment -bump_assignment
Writing IO placement checking reports to directory io_checks.
icc2_shell> ls io_checks/*

The filler count is worth a sentence, because 4 × 36 = 144 and the figure says 143. Three sides fill 644 µm each, as 32 twenties and four ones, for 36 cells apiece. The left side gave 20 µm of its gap to the break cell, so it fills 624 µm as 31 × 20 = 620 plus 4 × 1 = 4, which is 35 cells. So 3 × 36 + 35 = 143, and 143 + 4 corners + 1 break = 148. Small arithmetic, and exactly the kind that is easier to do now than to reconstruct in a review three weeks later.

Engineering judgement — the four calls that were not the tool's to make

Fifty-six pads and not seventy. The guide holds seventy pads exactly and that is the reason not to use seventy. Twenty per cent slack is a number to defend, not a number to derive; what cannot be defended is discovering at the filler step that there is nowhere to put a break cell.

Fixing the corner cell's design_type in the session. The right fix is in the reference library, and that means a request to whoever owns it. Fixing it here unblocks today's run and nothing more — so the set_attribute line belongs in the setup script with a comment saying why, and the library request belongs in the same commit message.

Choosing the band depths to make 192 equal 192. The first attempt used four bands of 3 × 20, which gives 240 signal bumps for 192 signal pads — 48 bumps with nothing to connect to. Shallower top and bottom bands fixed it. That is the reconciliation Figure 6.1's third panel promised, and it took two attempts because there is no command that does it.

Forty-five degrees rather than ninety. Eight per cent of the longest route is worth having, and the decision still depends on whether the technology's diagonal rules and the RDL congestion allow it. The arithmetic tells you the size of the prize; it does not tell you that you can collect it.

6.6 Failure modes and how to recognise them

Twelve ways this goes wrong. Four produce no message at all, and one of those four points at the wrong part of the design entirely.

6.7 Hands-on mini lab

Goal. Plan the I/O ring and bump field for Fornax-7 from the die outward, reconcile the pad and bump counts before running anything, and quantify what the routing angle is worth.

Tasks.

Expected observations.

6.8 Interview preparation

Sixteen questions, grouped by level. Answer each one out loud before reading the model answer. Flip-chip I/O planning is a favourite interview topic for a practical reason: it is the first part of the flow where a candidate has to reconcile two counts that came from two different organisations, and an interviewer can tell in one question whether you have ever had to do that.

Beginner

Intermediate

Senior

6.9 Chapter close

Sign-off checklist

Flashcards

Compact glossary

Five-question self-check

A new design, Vela-3. The die is a square 2,800 µm on each side. The corner cell is 100 µm high, the signal pad is 40 µm wide, the filler library holds 20, 10, 5 and 1 µm cells, and the package specifies a 180 µm bump pitch.

1. How long is each I/O guide, how many 40 µm pads would fit end to end, and if you decide to place 50 pads per side, how much gap is left and what fraction of the guide is that?
2. You set a power ratio of 4. Write out the repeating pattern of slots, say how many whole patterns fit into the 50 slots, and give the signal, VDD and VSS pad counts per side and the power share of the whole ring.
3. Fill that leftover gap largest-first from the 20, 10, 5 and 1 µm cells. How many cells, of which sizes, and how much is left over?
4. At a 180 µm pitch, how many bump sites fit across the 2,800 µm die, and how far is the outermost bump centre from the die edge? Then: how many bumps does staggered_1 place on an 11 by 11 grid?
5. A route has to cover 380 µm horizontally and 2,400 µm vertically. Give its length at 90 degrees and at 45 degrees, the saving, and the saving as a percentage.

Answers.

1. Guide length is the die side less two corner heights: 2,800 − 2 × 100 = 2,600 µm. Pads that fit end to end: 2,600 ÷ 40 = 65 exactly. At 50 pads: 50 × 40 = 2,000 µm of pad, leaving 2,600 − 2,000 = 600 µm, which is 600 ÷ 2,600 = 23.08 per cent of the guide. Check backwards: 2,000 + 600 = 2,600, and 2,600 + 200 = 2,800. Note that 65 is what fits, not what you would place — 50 is the number you chose, and the 600 µm is the slack you chose to keep.

2. A ratio of 4 means no more than four signal pads between successive power pads of that type, so the repeating pattern is four signal, VDD, four signal, VSS — ten slots. 50 ÷ 10 = 5 whole patterns, with nothing left over. Per side that is 5 × 8 = 40 signal, 5 VDD and 5 VSS, and 40 + 5 + 5 = 50. Round the ring: 4 × 50 = 200 pads, of which 4 × 10 = 40 are power. Power share 40 ÷ 200 = 20.00 per cent, signal 160 ÷ 200 = 80.00 per cent, and the two sum to 100.

3. 600 ÷ 20 = 30 exactly, so 30 cells of 20 µm, none of the others, and nothing left over. Worth noticing that this outcome depends entirely on the numbers: 600 happens to be a multiple of 20, whereas Nimbus-8's 644 µm needed 32 twenties and four ones. Neither result was designed. Both had to be checked.

4. Sites across: 2,800 ÷ 180 = 15.56, so 15 sites — each site takes a pitch-wide slot, and a sixteenth slot does not fit. Fifteen sites means fourteen gaps, spanning 14 × 180 = 2,520 µm of centre-to-centre distance, which leaves 2,800 − 2,520 = 280 µm to share between the two edges, so the outermost bump centre sits 140 µm from each die edge. Check: 140 + 2,520 + 140 = 2,800. On an 11 by 11 grid the indices 0 to 10 hold six even values and five odd ones, so staggered_1 places 6 × 6 + 5 × 5 = 36 + 25 = 61 bumps of the 121 grid points, which is 50.4 per cent — not half, because the grid is odd on both axes.

5. At 90 degrees the route is two orthogonal legs: 380 + 2,400 = 2,780 µm. At 45 degrees the diagonal part replaces the shorter leg: 2,400 + 0.414214 × 380 = 2,400 + 157.4 = 2,557.4 µm. Saving 222.6 µm, which is 222.6 ÷ 2,780 = 8.01 per cent. Close to Nimbus-8's 8.14 per cent, and for the same reason — in both cases one offset dominates the other by roughly six to one, so the diagonal has little room to help. The lesson is the one to carry: the saving is a property of the geometry of your worst net, not a property of the option, so measure it before you argue for it.

Where the next chapter goes, and why

The strip that Chapter 4 reserved is now full. Drivers sit in ordered positions inside four guides, power pads appear at a stated frequency, corner cells hold the four intersections, filler closes every gap in the abutted power connection, a field of bumps covers the die at the package's pitch, and every driver that needs one reaches a bump through a route you can measure. The design has an outside world for the first time.

What is still true is that it is one die. Everything so far — the boundary, the rows, the tracks, the blocks, the black boxes, the ring and the bump field — describes a single piece of silicon with a package on top of it. Chapter 7 removes that assumption. In a 3DIC design two or more die are stacked vertically to make one system, and in a 2.5D design one or more die are mounted on an interposer that connects them to each other and to the package, an interposer that may be silicon or glass.

The link back to this chapter is direct and worth holding on to. A bump is where one piece of silicon hands a signal to something outside itself, and this chapter was about planning that handover when the something outside is a package. Stacking changes what is on the other side, not the nature of the problem: there is still a grid of connections whose pitch somebody else fixed, still a count on each side that has to reconcile, and still an assignment that nothing downstream will tell you was wrong.