CHAPTER SEVEN

Creating a 3DIC Design: Three Pieces of Silicon and a Plan That Is Never Built

By the end of this chapter you will be able to say what a 3DIC design is and how a 2.5D design differs from it; to set the one application option that has to be right before the first library is opened, and to work out its value from the libraries you were given; to prepare an active die for mounting, and to know why a fully placed design is not needed; to create a silicon interposer from an empty netlist, populate it with package-facing bumps and give each one a through-silicon via; to assemble a top-level design that places every die at a coordinate and a z level, and to explain why that design is never manufactured; to copy microbumps from a die onto the interposer rather than designing them twice, and to propagate the connections and matching types that make the copies mean something; to read and write the whole bump and via floorplan as a comma-separated file, including the pseudo-bump form used for early planning and the three-file flow used for changes; to build a power mesh under each die; to work out whether the channel between two die is wide enough before anybody agrees the interposer's size; and to run the one check that, unlike every other check in this book, does everything by default.

Why this chapter matters in a real project

Six chapters have planned one die. This chapter plans how three of them meet.

The reason that matters is not novelty. It is that a system built from several die has several owners, and the interfaces between them are agreed long before anybody can check them. The memory die comes from one team or one vendor; the logic die is yours; the interposer is a third design that exists only to join them; and the package sits underneath all of it with a bump map that was probably signed off first. Every one of those handovers is a number in a document, and this chapter is about turning those numbers into a floorplan that closes.

What makes it worth reading slowly is the same thing that made Chapter 6 worth reading slowly, one level up. In Chapter 6 the pad width came from a library and the bump pitch came from a package, and the arithmetic ran into both. Here the die sizes come from other designs, the microbump pitch comes from the attach process, the C4 pitch and the interposer outline come from the package, and the arithmetic runs into all four. There is a great deal of tooling in this chapter — a dozen commands whose names begin with the same three characters — but almost none of it makes a decision. It records decisions you have already made, and it does so faithfully, including when they were wrong.

The other reason for care is a specific reversal. Chapter 6 ended on a command that checks nothing unless you tell it what to check. This chapter ends on a command that checks everything unless you tell it not to — and which, run at the wrong moment, buries you in errors about work you have not done yet. Two check commands, two opposite defaults, one chapter apart. That is not a trap the tool set out to lay; it is what happens when two commands are written years apart for different jobs. But it is exactly the kind of thing that costs an afternoon, and it is worth knowing before it costs you one.

Prerequisites

Chapter 4, for the die and core boundary and how initialize_floorplan creates one. Chapter 6, for bump cells, bump arrays, matching types and redistribution-layer routing — this chapter reuses all of them and assumes you can read a create_bump_array command without looking it up. Chapter 8 covers design blocks and the library structure in earnest; here you need only to know that a design lives in a library, that a library can reference other libraries, and that a block has to be editable before you can change it.

Nothing in Chapters 3 or 5 is needed. If you have read them, one thread does carry over: a black box was a module whose contents were unknown but whose interface was fixed, and an active die that somebody else owns is the same idea with a boundary instead of a netlist.

How to read the numbers and the notation in this chapter

This is the same table that opens every chapter, with the entries this chapter actually needs. Nothing in it is difficult; it is here so that no symbol on the page is ever a puzzle.

Learning objectives

7.1 The beginner's mental model

Start with a power strip

Put a kettle and a radio on a desk, and plug both into a power strip whose lead runs to a socket in the wall.

The kettle and the radio do the work. The strip does none: it carries current, and that is all it is for. It has a face covered in sockets, one set for each appliance, and a single thick lead with one big plug on the end of it going off to the wall. Nobody designed the socket holes from scratch — they are a mirror image of the pins on the plugs that go into them, and if the pin pattern changes the hole pattern has to change with it.

Now the engineering model

A 3DIC design is one in which two or more die are directly stacked vertically to create a complete design or system containing multiple die. A 2.5D design is one in which one or more die are mounted on an interposer, and the interposer connects the die to each other and to the package. The interposer can be manufactured from various materials, including silicon and glass.

Both styles are supported, and the die can be placed separately on a silicon interposer or stacked upon each other and connected with through-silicon vias. The flow this chapter follows is the 2.5D one — active die placed side by side on a passive silicon interposer — because it is the one the framework works through end to end, and because everything it teaches transfers to the stacked case.

Two pieces of vocabulary come from that definition and are worth fixing now. An active die is a die containing active devices: logic, memory, radio-frequency circuitry, anything with transistors in it. The interposer is the silicon die that mounts and connects the active die, and it is not required to contain active components or logic at all. In the flow below it contains none: its netlist is literally empty when you create it.

Do not confuse these

Ten pairs that get mixed up, and the one-line difference in each case. This table is worth a second read after Section 7.5, when the pairs have names attached to them.

7.2 The concepts, from first principles

7.2.1 The seven words, and where each one is

This chapter has more new vocabulary than any other in the book, and almost all of it is spatial. That makes it easy — you can point at every term on a single cross-section — and it makes it dangerous, because a term you can only half place is worse than one you cannot place at all.

So here are all seven, on one drawing, with the reference's own definition of each beside it.

Two of the seven repay a second look.

Front side and back side are not top and bottom of the assembly. They are properties of a die. The front side is the top side of a silicon die, opposite the substrate and device layers, where most of the standard-cell metal routing is performed. The back side is the bottom side, containing the substrate and device layers, where the back metal layers are created. So “front” means the metal-stack face and “back” means the substrate face, whichever way up the die happens to be sitting. An interposer's front side faces up towards the die; an active die, mounted face down, has its front side facing down towards the interposer. The two front sides meet.

The pitch ratio is the whole shape of the problem. A microbump joins a die to the interposer; a C4 bump joins the interposer to the package. In the worked example the microbump pitch is 55 µm and the C4 pitch is 150 µm — a ratio of about 2.727 to 1 — so a given area of interposer holds roughly seven times as many microbumps as C4 bumps. That is why 505 microbumps sit on the front side and only 164 C4 bumps on the back, and why the back side of an interposer always looks empty next to the front. It is also why the interposer exists: something has to fan out from a coarse package pitch to a fine die pitch, and that something is metal on silicon.

7.2.2 The flow, and the commands each step owns

The flow for a 2.5D design with active die placed separately on a passive silicon interposer has five steps: prepare the designs for the active die; create the interposer library and design; create the top-level design; create the interposer power grid; and route the interposer.

Five steps is an unusually honest number for a flow diagram, because each of the five is a genuinely separate piece of work with its own inputs and its own owner. The first step is done once per die and can be done in parallel. The second creates a design that does not exist yet. The third is the only one that sees the whole system. The fourth and fifth are ordinary physical design done on an unusual object.

Table 7.3 is the same information as a list you can scan while writing a script, with the section that treats each command in full.

7.2.3 Libraries, scale factors, and the number to get right first

A 3DIC design contains multiple subdesigns, and each subdesign can reference unique libraries and use a different technology. Those libraries might have different scale factors, and they still have to be used together in the complete design.

A library's scale factor is the number of database units it uses per micron. A library with a factor of 4,000 stores coordinates in units of a quarter of a nanometre; one with 10,000 stores them in units of a tenth of a nanometre. Neither is wrong, and a design assembled from both has to pick a single resolution fine enough to represent every coordinate in either exactly.

That resolution is design.session_scale_factor, and there are two rules about it. It must be specified before the first design library is opened or created. And the scale factors for the various libraries in a 3DIC design must be a multiple of the scale factors of all the libraries — so the option's value has to be the least common multiple of them all, or an even multiple of that.

# Set this first. Before create_lib, before open_lib, before anything.
icc2_shell> set_app_options -name design.session_scale_factor \
   -value 20000

Where does 20,000 come from? Not from anywhere; you work it out. The Nimbus-8 system has three libraries:

# From the three library owners.
logic die library        scale factor  4,000
memory die library       scale factor 10,000
interposer library       scale factor  2,000

# The smallest number all three divide into exactly. Start at the
# largest factor and step through its multiples.
10,000  ->  10,000 / 4,000 = 2.5      no
20,000  ->  20,000 / 4,000 = 5        yes
            20,000 / 10,000 = 2       yes
            20,000 / 2,000 = 10       yes

# So the session scale factor is 20,000, and an even multiple of it
# would also be legal: 40,000, 60,000 and so on.

The framework gives the same shape of example with two libraries: if one library has a factor of 4,000 and another has 10,000, the option must be set to the least common multiple, 20,000, or an even multiple of it. Adding a third library at 2,000 does not change the answer here, because 20,000 was already a multiple of 2,000 — which is worth noticing, because it means adding a library sometimes costs nothing and sometimes changes the whole session.

There is a second scaling mechanism for half-node libraries. The half-node scale factor of a library is specified by the half_node_scale_factor attribute on the library. If design.is_3dic_mode is set to true on the top design, the coordinates in the library are scaled by the half_node_scale_factor setting when the library is read. That is the whole mechanism: an attribute on the library, an application option to enable it, and the scaling happens at read time.

7.2.4 Preparing an active die

Each active die has an initial floorplan and contains the bump cells used to connect it to the interposer or to another active die. Preparing one is a short flow, and it is deliberately shorter than you would expect:

# 1. The netlist.
icc2_shell> read_verilog logic.v

# 2. A floorplan, created or read.
icc2_shell> read_def logic.def

# 3. The bump cells.
icc2_shell> create_bump_array -lib_cell UBUMP -name ubump_hbm \
   -delta {55 55} -bbox {{2900 640} {3285 1520}}

The framework is explicit about why that is enough: it is not necessary to create a fully placed design, since the critical pieces of information for placing the active die on the interposer are the bump cell locations and the active die size. Those two things are the interface. Everything else about the die — where its blocks sit, how its clock is built, whether it meets timing — is the die owner's business and invisible from the interposer.

Bump cell locations can come from three places, exactly as in a flip-chip design: a DEF file, an AIF file, or the create_bump_array command. And the redistribution-layer routes from pad cell to bump cell can be created during a later design stage — so a die can be handed over with its bumps placed and nothing routed to them yet.

7.2.5 The silicon interposer design

Creating the interposer means creating its library, creating its netlist, initialising its floorplan and creating its power and ground connections. Six commands, and the second one is the surprising one.

# 1. The library, naming every reference library the interposer needs.
icc2_shell> create_lib nimbus_interposer.ndm \
   -technology interposer.tf \
   -ref_libs {c4_bump.nlib front_ubump.nlib physicalonly.nlib}

# 2. An empty netlist. Yes, empty.
icc2_shell> sh cat interposer.v
module interposer (dummypin);
input dummypin;
endmodule
icc2_shell> read_verilog interposer.v

# 3. The boundary, in the tool's unit.
icc2_shell> initialize_floorplan -control_type die \
   -boundary {{0 0} {10000 6000}}

An interposer's netlist is empty because the interposer has nothing in it to describe. Its content is bumps, vias and metal, all of which are physical objects created by later commands, and its connectivity comes from above: the top-level netlist contains the connections, and the tool automatically updates the interposer netlist with ports and all connections and creates feedthroughs as needed.

That is a genuinely unusual arrangement and worth sitting with for a moment. Every other design in this book was created from a netlist that described it. This one is created from a stub, and is filled in by a command that runs in a different design. If you have ever wondered what “physical only” really means, this is the extreme case of it.

Then the package-facing bumps and their vias:

# 4. C4 bumps, to the package. The pitch came from the package.
icc2_shell> create_bump_array -lib_cell C4_BUMP \
   -name c4_sig_bottom -origin {125 75} -delta {150 150} \
   -repeat {8 8}

# 5. One TSV for each of the bump cells just added.
icc2_shell> derive_3d_interface -from [get_cells c4_sig_bottom*] \
   -to_object_ref [get_via_defs -tech [get_techs *] VIA_TSV] \
   -name_prefix TSV_c4_sig_bottom

# 6. Matching types, for the RDL routing that comes later.
icc2_shell> create_matching_type \
   -name Signal [all_connected [get_nets *SIG*]]

derive_3d_interface is the command that repays study, because its name is doing something unusual. It creates new 3DIC structures based on the properties of existing structures in the design. You do not tell it where to put the vias; you tell it which existing objects to derive from with -from, and what to make with -to_object_ref, and it places one new object per source object, inheriting position from the source. Options let you shift the result with -x_offset and -y_offset, choose which corner or centre the offsets are measured from with -coord_spec, decide whether the new object is connected with -connect, name the results with -name_prefix, set an orientation, and give a bond pad a width and height.

7.2.6 The top-level design

A 3DIC design contains two or more active die and a silicon interposer, and both are instantiated into a top-level design. That design also contains the connections between the package, the interposer and the die, as well as the ports that represent connections to the package.

And then the sentence that defines the whole object: the top-level design specifies only the physical and logical connectivity between the actual die and the interposer; the top-level design is never actually manufactured in silicon.

What you can do with it is a five-item list worth memorising, because it is also a list of everything in this chapter that requires a whole-system view: specify the coordinates and orientation of the die on the interposer; copy or mirror bumps between the interposer and the die; perform 3D physical and logical design checks of the entire system; assign bumps to signals based on the shortest paths; and report information about valid 3D chips.

Building it takes the sequence below. Steps 1 to 4 are ordinary; step 5 is the one this section is about.

# 1. A library that references the interposer and every active die.
icc2_shell> create_lib nimbus_top.ndm -technology top.tf \
   -ref_libs {nimbus_logic.ndm nimbus_mem.ndm nimbus_interposer.ndm}

# 2 and 3. The netlist and a boundary the size of the interposer.
icc2_shell> read_verilog nimbus_top.v
icc2_shell> initialize_floorplan -boundary {{0 0} {10000 6000}}

# 4. Mark this block as a top level or container hierarchy level.
icc2_shell> set_attribute [current_block] design_type 3dic

# 5. Place the interposer and the die, with a z level each.
icc2_shell> set_cell_location interposer_inst \
   -coordinates {0 0} -z_offset 0 -orientation N
icc2_shell> set_cell_location logic_die_inst \
   -coordinates {400 1280} -z_offset 1 -orientation FN
icc2_shell> set_cell_location mem_die_inst \
   -coordinates {4100 600} -z_offset 1 -orientation FN

The z level is the new idea, and it is simpler than it sounds: it is a stack order, not a height. Chips with the same z value are considered to be at the same elevation and are checked for chip overlaps. Chips with adjacent z values are considered to be neighbouring chips and are checked for physical contact. So giving both active die -z_offset 1 declares that they sit side by side and must not overlap, and giving the interposer -z_offset 0 declares that it is underneath both and touches both.

Reading the placement back is one command, and the report is worth keeping:

icc2_shell> report_3d_chip_placement -chips \
   {logic_die_inst mem_die_inst interposer_inst}
chip_name        design_type  stack_z  location       orientation  scaling_factor
logic_die_inst   die          1        (400 1280)     FN           1
mem_die_inst     die          1        (4100 600)     FN           1
interposer_inst  die          0        (0 0)          N            1

The command reports only block instances at the top level unless you add -hierarchical, which reports all hierarchical die. -application reports each chip's level-layer map information and thickness attributes; where that map has not been set by the user, the command reports the chip's highest front-side metal layer and lowest back-side metal layer instead, in the same format and beginning with an asterisk. The z ordering can also be queried directly as the z_order attribute on a die instance.

7.2.7 Virtual interface blocks

A 3DIC design contains capacitance due to cross-coupling between two die, and that capacitance affects nets at the top level. Extraction tools capture it and store it in a virtual interface block added to the design database — but the block has to exist first, and creating it is a command in this tool.

A virtual interface block contains the ports, nets, shapes and vias at the interfaces between two stacked die, and between a die and the interposer. Three forms of the command cover the cases:

# Between two named blocks, with a layer count for each.
icc2_shell> create_3d_virtual_blocks \
   -blocks {{mem_die_inst:4} {interposer_inst:2}}

# Between two blocks, with the same layer count for both.
icc2_shell> create_3d_virtual_blocks \
   -blocks {logic_die_inst mem_die_inst} -layers 4

# Between every die and the interposer, based on the z offsets,
# and connected into the top-level netlist.
icc2_shell> create_3d_virtual_blocks -in_netlist

The first two add the interface information; -in_netlist modifies the netlist and connects it, creating the blocks between all die and the interposer based on the z-offset attribute setting for each block. There is also a -die_separation option for the separation value between die.

On the Nimbus-8 system that gives two virtual interface blocks — logic die to interposer, and memory die to interposer — because those are the two die pairs at adjacent z levels. The two active die are at the same z level and do not face each other, so no block is created between them.

7.3 Inputs, outputs and readiness

A 3DIC design has more prerequisites than any other step in this book, and most of them belong to other people. This section is the list, in the order things are needed.

7.4 The guided tool walkthrough

7.4.1 create_3d_mirror_bumps — copying, not designing

Purpose. Copy bump cells from one die onto another die, or onto the interposer, so that the two faces have matching connection points. When the source and target die are stacked vertically, the command copies and places bump cells, bump clusters and bond pads from the source die to the target die.

Syntax in plain English. Name a source chip with -from, a target chip with -to, and the library cell to instantiate on the target with -ref_cell. Both -from and -to are required, and -ref_cell is required when you are mirroring bumps. Add -prefix so the new instances are identifiable.

# Once per die. The interposer gains a microbump for every
# microbump on the die that faces it.
icc2_shell> create_3d_mirror_bumps -from mem_die_inst \
   -to interposer_inst -ref_cell UBUMP -prefix mem
icc2_shell> create_3d_mirror_bumps -from logic_die_inst \
   -to interposer_inst -ref_cell UBUMP -prefix logic

The options that matter. Table 7.6 covers the ones that change what gets copied and what it is called. The command has more, and the pattern is worth seeing: almost every option is either “copy this subset instead of everything” or “name the results this way instead of that way”.

Prerequisites. The source die must have its bumps placed. The target block must be editable — which is why set_editability appears in the flow immediately before this command — and the library must be open with -ref_libs_for_edit. And unless -skip_physical_check is given, the source and target die must be vertical neighbours, which on this design means adjacent z levels.

# Save, close, reopen for edit, and unlock the blocks.
icc2_shell> save_block
icc2_shell> save_lib
icc2_shell> close_lib
icc2_shell> open_lib nimbus_top.ndm -ref_libs_for_edit
icc2_shell> set_editability \
   -blocks nimbus_logic.ndm:nimbus_logic.design
icc2_shell> set_editability -blocks nimbus_mem.ndm:nimbus_mem.design
icc2_shell> set_editability \
   -blocks nimbus_interposer.ndm:interposer.design

Expected result. The interposer gains one microbump per source microbump. On Nimbus-8 that is 305 from the logic die and 200 from the memory die, for 505 in total. The count is the check: if the interposer ends up with fewer microbumps than the two die have between them, some were not copied, and the usual reason is that they do not face the target.

Verification. Count them. sizeof_collection [get_cells -filter "design_type==flip_chip_pad"] on the interposer should equal the sum of the two die's fields, and get_cells logic* and get_cells mem* should split cleanly along the prefixes you gave. Then look at the layout: a mirrored field that is offset from its source by a constant, or flipped left-to-right when you did not expect it, is visible immediately and invisible in a count.

Common mistakes. Forgetting set_editability, which produces a failure rather than a wrong answer and is therefore the good kind. Omitting -prefix, so the two mirrored fields are indistinguishable. Running the mirror before the die's bump field is final, so the copy is of a draft. And assuming the direction is fixed: the tool also supports 3DIC flows that copy the bump locations from the interposer to the die, which is the right direction when the interposer is the constrained party.

Finding the rest. man create_3d_mirror_bumps. It is a long page, and the option list rewards a slow read once.

7.4.2 The four commands that make the copies mean something

Purpose. A mirrored bump is a cell in a place. It is not yet on a net, not yet paired with anything, and not yet reachable from the top level. Four commands close that gap, and they run in a fixed order.

The order, and what each one adds.

# 1. Connect the copies to what they were copied from.
icc2_shell> propagate_3d_connections

# 2. Matching types on the interposer.
icc2_shell> current_design interposer
icc2_shell> add_to_matching_type Signal [get_cells *ubump*]
icc2_shell> create_matching_type -name Power \
   [get_pins *VDD_log*/PAD]

# 3. Matching types at the top level, naming objects in each die.
icc2_shell> current_design nimbus_top
icc2_shell> create_matching_type -name Signal \
   {logic_die_inst/dq_out[0] logic_die_inst/dq_out[1]}
icc2_shell> add_to_matching_type Signal \
   {interposer_inst/dq_0 interposer_inst/dq_1}
icc2_shell> add_to_matching_type Signal \
   {mem_die_inst/dq_in[0] mem_die_inst/dq_in[1]}

# 4. Copy the matching types between die, then assign.
icc2_shell> propagate_3d_matching_types
icc2_shell> assign_3d_interchip_nets

propagate_3d_connections creates the logical connections between the bump cells or pseudo bumps on the interposer and the bump cells on the active die. It reports how many new nets it created after splitting the inter-chip nets, and how many it propagated, and those two counts are the first thing to compare against what you expected. Its options are few and each removes a behaviour rather than adding one: -no_port_punching if you do not want new ports created, -port_naming_style and -net_naming_style to control the names it does create, -set_terminals_for_updated_ports to set terminals for any ports it updates, -nets to restrict it to a subset, and -check_only to see what it would do without doing it.

propagate_3d_matching_types copies the matching types of cells, pins and terminals to other pins. It prints what it is about to propagate and between which die, which makes its output the most readable in the chapter. -from and -to restrict the die, -matching_types restricts the types, -check_only reports without acting, and -force proceeds where it would otherwise stop.

assign_3d_interchip_nets is the one that decides things. It logically connects TSVs, bump cells and pseudo bumps to nets, creates ports and nets in the interposer based on the top-level connectivity, creates feedthroughs for signals that connect the package to the die, and creates die-to-die net connections in the interposer. Its output names each pair of chips it worked between and how many nets it assigned.

The rest of assign_3d_interchip_nets: -bumps, -nets and -matching_types restrict what it considers; -bump_regions and -pseudo_bumps bring pseudo bumps into the logical connection propagation; -bond_pads names bond pad terminals; -no_port_punching forbids new ports; -include_pg_nets includes the power and ground nets, which are excluded otherwise; and -port_naming_style and -net_naming_style control names.

Expected result. Every die-to-die signal has a net that runs from a driver on one die, through a microbump, through the interposer, through another microbump, to a receiver on the other. On Nimbus-8 that is 128 nets — one per channel signal — plus the package-facing signals that reach a C4 bump through a TSV.

Verification. report_matching_types after the propagation, to see the types the command assigned. Then the connectivity and matching-type categories of check_3d_design, which exist for exactly this.

Common mistakes. Running assign_3d_interchip_nets before the matching types are propagated, so the assignment is made without them. Forgetting -include_pg_nets and then wondering why the power bumps are unassigned. And assuming the counts in the command's output are a pass: a line reporting that some number of nets was successfully assigned is a count of what the command did, not a statement that the number was the right one.

7.4.3 read_design_io and write_design_io — the whole floorplan as a file

Purpose. Instead of setting placement constraints and matching types to place and connect bump cells and TSVs, you can specify location and connection information in one or more comma-separated files. read_design_io reads the placement and connection information and places the cells; write_design_io writes the location information out.

This is the most practical section in the chapter, because it is how a bump floorplan is actually exchanged between organisations. A package house does not send you a Tcl script.

Syntax in plain English. Writing takes a file name; reading takes a list of file names. Both accept a map file if your column headings are not the standard ones.

# Write the whole bump and TSV floorplan out.
icc2_shell> write_design_io -file_name nimbus_bump_tsv.csv
icc2_shell> sh head -4 nimbus_bump_tsv.csv
Reference_name,C4_inst,Ubump_inst,TSV_inst,X_origin,Y_origin,
  Orientation,Port_name,Net_name,Comments
C4_BUMP,nim_C4_SIG_0_0,,,125,75,R0,,nim_C4_SIG_0_0_net,
C4_BUMP,nim_C4_SIG_0_1,,,275,75,R0,,nim_C4_SIG_0_1_net,
VIA_TSV,,,TSV_nim_C4_SIG_0_0,125,75,R0,,,

The file has a header row and a row of data for each cell instance. The header row is required and describes the keyword for each column. After it, each row describes a cell instance or a connection: cell rows specify the instance name, reference name, location and orientation; connection rows specify connections between terminals; and port rows create a port. You can specify multiple input files and provide different fields in each, and not all fields are required for each cell instance or connection.

What the reader does with a row. Six behaviours, and it is worth reading them as a group because four of the six end in something being skipped or ignored.

• If a cell instance does not exist, the tool creates it.
• If the cell instance already exists, it is moved to the specified location.
• If the cell instance overlaps an existing instance, it is skipped.
• If a row is invalid, the tool issues a warning message and skips the row.
• If a port does not exist, the tool ignores it — unless you pass -create_ports.
• If a port or net already exists, it retains the current setting of its port_type or net_type attribute — unless you name it in -power or -ground, which set the attribute and create the port or net if it does not exist.

The overlap rules. By default the tool performs these checks when creating new cell instances: cells of the same type cannot overlap; a C4 bump can overlap an existing microbump, TSV or standard cell; a microbump can overlap an existing C4 bump, TSV or standard cell; and a TSV can overlap an existing C4 bump or microbump. That set of rules is the nominal setting of -overlap_check, and it is the default. none means no checking is done and a new object is created even if something else exists at that location. strict means no overlap with any existing cell of any type is allowed.

Verification. Write, read back into a fresh session, and write again: the two files should agree. That round trip catches unit errors, origin-convention errors and skipped rows in one step, and it is worth doing once on any new interface before trusting it.

Common mistakes. A file whose length unit is not the library's, read without -units, so every coordinate is out by a constant factor. A file whose coordinates are cell centres, read without -cell_origin_type center, so every cell is out by half its own size. And treating warnings as noise: a run that skipped forty rows is a run that placed forty fewer cells than you think.

Finding the rest. man read_design_io and man write_design_io.

7.4.4 Bump regions, pseudo bumps, and changing a plan

Purpose. Bump planning using the concepts of bump patterns, regions and pseudo bumps offers a way to rapidly develop 3DIC designs. The point is to lay out and rearrange a bump field before the cells exist — a plan you can argue about, not a placement you have to undo.

A bump region is an area with a pattern: a boundary, a pitch in each direction, an optional offset and stagger, a default shape and a default radius. A pseudo bump is one bump inside such a region, with a row and column index, an optional net and port, and its own shape and radius if it differs from the region's.

# A region, and one bump in it.
icc2_shell> create_bump_region -name hbm_plan \
   -boundary {{2900 640} {3285 1520}} -content_type bump \
   -pattern {55 55} -array_size {8 16}
icc2_shell> create_pseudo_bump -region hbm_plan -offset {0 0} \
   -shape octagon -radius 20 -net dq_0

# Write the whole plan out, and read it back in a new session.
icc2_shell> write_design_io -pseudo_bumps -file_name nimbus_plan.csv
icc2_shell> read_design_io -pseudo_bumps -file_name nimbus_plan.csv

The file has two sections with their own column sets. In the bump-region section, Name, Boundary, Pitch_X, Pitch_Y and Bump_radius are mandatory and a value is required for each. Pattern_offset_X and Pattern_offset_Y give the delta from the region's lower-left corner to the start of the pattern. Row_stagger_X and Column_stagger_Y give cyclical deltas for the start of each row or column. Orientation takes the eight rotation values and defaults to R0 when blank. Bump_shape takes triangle, square, pentagon, hexagon, septagon, octagon or circle, and defaults to octagon. Is_backside defaults to false. Port_pattern and Net_pattern hold two-dimensional patterns of port and net names.

In the pseudo-bump section: Region_name says which region the bump lives in; X_origin and Y_origin give the centre of the bump; Row and Column are index numbers starting from zero; Net_name and Port_name give the connections; Shape and Radius override the region's defaults; and Is_hole, Is_probe_pad, Is_dummy and Is_default are true-or-false flags that default to false.

Adding a column of your own. To carry an attribute the standard columns do not cover, define it first, then name it when you write and again when you read. The attribute can be Boolean, double, float, int or string, and for a string type the value must not contain a comma — which is the sort of restriction that is obvious once stated and unfindable at three in the afternoon.

# Define, write, and in a new session define again before reading.
icc2_shell> define_user_attribute -type string -classes cell \
   -name owner_team
icc2_shell> write_design_io -file_name nimbus_plan.csv \
   -attribute {owner_team}
icc2_shell> read_design_io -file_name nimbus_plan.csv \
   -attribute {owner_team}

The tool reads only those user attributes that are defined; if an attribute is undefined it is ignored. So the definition has to be repeated in the reading session, and a plan file carrying a column nobody has defined loses that column silently.

Changing a plan. Three commands, in order. compare_design_io takes two files with the I/O elements of two versions of a design, compares them and generates the differences, either shown in the graphical interface as a table or written to a file. read_design_io -eco then reads that difference file.

# Compare two versions of the plan, and apply the difference.
icc2_shell> compare_design_io -pseudo_bumps -golden nimbus_plan_v1.csv \
   -v2 nimbus_plan_v2.csv -output nimbus_plan_eco.csv
icc2_shell> read_design_io -pseudo_bumps -eco \
   -file_name nimbus_plan_eco.csv

Four rules govern the change flow. Only one change file can be specified. There must be a current design when the command runs. The read supports undo and redo. And three options cannot be combined with -eco: -map_file, -comment_char and -units. Giving -eco a file that is not a change file, or omitting -eco for a file that is, produces an error either way.

7.4.5 The interposer power mesh

Purpose. The interposer mounts the active die and connects them, and in addition to signals, power and ground are routed through it to power the die. To provide adequate power and minimise voltage drop, you build a mesh inside the interposer to distribute power from the package to the die.

The path is worth stating once, because it explains the whole structure: interposers connect to the package through C4 bumps on the back side, then distribute power to the microbumps on the front side, which connect to the flip-chip bumps on the die. A mesh on the intermediate routing layers helps minimise the voltage drop the extra routing would otherwise cause.

Syntax in plain English. Standard power-planning commands, used on an unusual object. Define a pattern; associate it with a region and a pair of nets; compile.

# 1. The pattern: two layers, two nets, and four numbers each.
icc2_shell> create_pg_mesh_pattern mesh_int \
   -layers {{{vertical_layer: M4} {width: 10} {spacing: 90} \
             {pitch: 200} {offset: 50}} \
            {{horizontal_layer: M3} {width: 10} {spacing: 90} \
             {pitch: 200} {offset: 40}}}

# 2. One strategy per die, over that die's own footprint.
icc2_shell> set_pg_strategy strat_logic \
   -pattern {{name: mesh_int} {nets: VDD_log VSS_log}} \
   -polygon {{400 1280} {3840 4720}}
icc2_shell> set_pg_strategy strat_mem \
   -pattern {{name: mesh_int} {nets: VDD_mem VSS_mem}} \
   -polygon {{4100 600} {9600 5400}}

# 3. Compile both.
icc2_shell> compile_pg -strategies {strat_logic strat_mem}

Reading the pattern's four numbers. A width of 10 and a spacing of 90 put the two straps of a pair 100 µm apart, centre to centre of their gap. A pitch of 200 puts the next pair 200 µm after the first. An offset of 50 starts the first pair 50 µm inside the region. Two nets in the strategy means two straps per pitch — one per net — so a 200 µm pitch over a 3,440 µm die gives seventeen pairs and therefore thirty-four straps.

# The logic die's polygon, vertical direction.
region        400 to 3,840 um, so 3,440 um wide
first pair    400 + 50 = 450 um
pair spacing  200 um
last pair     450 + 16 x 200 = 3,650, and its second strap at 3,750
              which is inside 3,840 - 10, so 17 pairs fit
straps        17 x 2 = 34

# Checked the other way: metal used.
metal         34 x 10 = 340 um of 3,440 = 9.88 per cent

Prerequisites. Every die placed, so its footprint is a polygon. And the polygon has to be the die's real footprint: {{400 1280} {3840 4720}} is the logic die's placement plus its size, and getting it from the placement rather than typing it is how it stays right when the die moves.

Expected result. A mesh beneath each die, on the two named layers, on that die's own nets. On Nimbus-8 that is 172 straps in total: 68 under the logic die and 104 under the memory die.

Verification. Count the straps and compare with the arithmetic. Then look at the channel between the die: if the mesh has spilled into it, one of the polygons is wrong, and the channel is where the die-to-die signals have to run.

Common mistakes. One strategy over the whole interposer, which puts power metal in the channel and shorts the two die's supplies onto one pair of nets. A polygon typed by hand and then not updated when a die moved. And forgetting that the step exists at all: an interposer with no mesh routes and passes every check in this chapter, and fails in an analysis nobody in this chapter runs.

Finding the rest. man create_pg_mesh_pattern, man set_pg_strategy and man compile_pg. Chapter 10 treats power planning properly; this is the interposer-shaped corner of it.

7.4.6 Routing the interposer, and the channel arithmetic that comes first

Purpose. After the bumps are placed, the TSVs created and the power grid built beneath the die, the interposer can be routed. Three methods are supported: routing with Zroute, routing with the redistribution-layer router, and combining both.

But first, the arithmetic. This is the part of the chapter with no command in it, and it is the part that decides whether the rest works.

Nimbus-8's logic die and memory stack exchange 128 signals. The interposer has two redistribution layers available for them. The routing rule gives each route a width of 2 µm and a spacing of 2 µm, so a track occupies 4 µm. The question is how wide the gap between the two die has to be.

# First attempt: the gap the outline happened to leave.
channel                200 um
track pitch            2 + 2 = 4 um
tracks a layer         200 / 4 = 50
layers                 2
tracks in total        50 x 2 = 100
signals to carry       128
shortfall              28

# What the signals actually need.
tracks a layer         128 / 2 = 64
channel                64 x 4 = 256 um, rounded up to 260
tracks a layer         260 / 4 = 65
tracks in total        65 x 2 = 130
spare                  130 - 128 = 2
used                   128 / 130 = 98.46 per cent
paid for from          (260 - 200) / 2 = 30 um off each margin

Sixty microns is not much. But it is sixty microns that had to come from somewhere, and the somewhere was the margin between each die and the interposer edge, which went from 430 µm to 400. Had the interposer outline already been fixed with the dies at their original spacing, those sixty microns would have had to come out of the interposer, and the interposer size is a package decision.

The route plan. When routing an interposer for high-bandwidth memory you want finer control over where the vias and nets go, and create_interposer_routeplan provides it. The command analyses an interposer containing pre-placed and pre-assigned front-side and, optionally, back-side bumps; based on their configuration it creates and places vias connecting the bumps to a second layer for routing, and creates routing guidance in the form of wire-stub pre-routes called route guides. It also routes the centre section between the bump arrays. The placed bump vias and the route guides together are the route plan.

-interposer_style takes default, fpga, single_hbm or vertical_routing. By default the command inserts vias only; to insert vias and route guides, specify single_hbm or fpga. The tool processes different types of pattern file depending on the style, and -pattern_file names the file. The pattern file is an ASCII file of one or more sections, each beginning with a keyword followed by constraints inside curly brackets, and the tool uses a default file unless you supply one.

# Set the design style, then create the plan.
icc2_shell> set_app_options -name flip_chip.route.design_style \
   -value 3dic_interposer
icc2_shell> create_interposer_routeplan -interposer_style single_hbm \
   -pattern_file nimbus_hbm.pat
icc2_shell> set_attribute [get_vias *] shape_use user_route

That last line matters more than it looks. Setting the shape type of the pre-placed vias to user_route preserves them until the routing stage; without it, a later step is free to remove work the route plan just did.

Routing the channel. With the plan in place, the rules and the nets:

# The rule, for the channel's two layers.
icc2_shell> create_routing_rule rdl_chan \
   -widths {MRDL 2 M9 2} -spacings {MRDL 2 M9 2}
icc2_shell> set_routing_rule [get_nets $chan_nets] -rule rdl_chan

# Bumps to their landing vias first.
icc2_shell> set_app_options \
   -name flip_chip.route.bump_via_landing_mode -value true
icc2_shell> route_3d_rdl -nets [get_nets $chan_nets] -layer MRDL \
   -coordinates {{3840 600} {4100 5400}}

# Then the via-to-stub nets, with the point-to-point file the
# route plan produced.
icc2_shell> set_app_options \
   -name flip_chip.route.bump_via_landing_mode -value false
icc2_shell> set_app_options \
   -name flip_chip.route.point_to_point_connection_file_name \
   -value nimbus_p2p.txtM9
icc2_shell> route_3d_rdl -nets [get_nets $chan_nets] -layer M9 \
   -coordinates {{3840 600} {4100 5400}}

The -coordinates option takes a list of rectangles and speeds routing up by routing inside them only. On this design the rectangle is the channel: {{3840 600} {4100 5400}} is exactly the 260 µm gap, from the logic die's right edge to the memory die's left, spanning the memory die's height.

Point-to-point routing. After routing bumps to landing vias you can specify point-to-point connections between bumps, landing vias and wire stubs, by providing a line per connection in a route plan file: a net name, a layer, and two points. Four requirements apply to the points. They must fall inside the same net shapes — a wire, a via or a pin shape. For wire shapes the point must be exactly at the endpoint of the wire, although the router does not necessarily connect to pins and vias exactly at the point specified. They must be on the minimum grid. And they must be on coordinates that do not have design-rule violations, meaning that routing a wire to the specified point creates no violation with neighbouring shapes. Routing pairs with violations are left unrouted.

Verification. report_rdl_routes -open_nets true for the opens, and report_rdl_routes -create_error_data verification to write an error database covering opens and shorts. Then the connectivity category of check_3d_design.

Common mistakes. Routing before the channel arithmetic, and discovering the shortfall as congestion. Omitting -coordinates on a channel route, so the router works on the whole interposer and takes an hour to tell you the same thing. Leaving bump_via_landing_mode true for the second pass, so the via-to-stub routing behaves like the bump-to-via routing. And forgetting shape_use user_route, which is invisible until the vias are gone.

7.4.7 check_3d_design — ten categories, all on by default

Purpose. Validate the whole system. In a 3DIC design, multiple chips are stacked vertically or placed side by side on an interposer; at the top level the entire stack is modelled as a virtual top-level design and the individual chips as cells. This command checks that model.

The one thing to know before anything else. The command should be used at the last step of the 3DIC design flow, and run at the top level. And unlike Chapter 6's check_io_placement, running it with no options performs all the checks.

# Everything, which is the default.
icc2_shell> check_3d_design

# Or one category, when you are iterating on that category.
icc2_shell> check_3d_design -chip_placement

# Or everything except one, when a category is not ready yet.
icc2_shell> check_3d_design -exclude {pg}

The options that are not checks. -dies, -die_pairs and -exclude_dies narrow which die the violations are shown for, and each expands a hierarchy die into its leaf die. -no_probe_pad hides violations involving probe pads. -verbose prints the detail; without it the command prints only part of the messages and a summary. -error_view names the file for the graphical error browser, defaulting to check3dDesign.err. -group_by_id reports by message identifier. -exclude takes a category list and must not be given together with the category options themselves. And -flyline_analysis takes all, signal or pg and writes a net-based flyline report of total length, crossings and dangling or out-of-box sources — and when it is used, all other checking items are disabled.

Prerequisites. The command's own page lists four: create_3d_mirror_bumps, propagate_3d_connections, propagate_3d_matching_types and set_cell_location. That list is the honest reason the command belongs at the end: three of the four are step-three commands, and running the check before them means checking a system that does not exist yet.

Expected result. Warning and error messages that indicate potential problems, which might need correcting before manufacturing. The full list of conditions it looks for runs to more than twenty items, and reading it once is worth the ten minutes — it is the most complete statement anywhere of what a valid 3DIC assembly is.

Common mistakes. Running it early, which is the misleading one and gets its own row in Table 7.11. Giving -exclude alongside a category option, which is not allowed. Using -flyline_analysis and reading the clean result as a pass, when every other check was disabled. And reading “0” without -verbose: the command prints only part of the messages otherwise.

Finding the rest. man check_3d_design, and then the man page for each error message it reports, which is where the guidance for fixing each one lives.

7.5 The worked example: Nimbus-8 becomes a 2.5D system

Ten steps, in the order Figure 7.4 gave them, starting from the die Chapter 6 finished. Every number has appeared already; this is where they are produced rather than quoted.

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

# What we were given, and by whom.
logic die     = 3,440 um on each side       (Chapter 4, then Chapter 6)
memory die    = 5,500 x 4,800 um            (the memory vendor)
interposer    = 10,000 x 6,000 um           (the package)
C4 pitch      = 150 um                      (the package)
microbump pitch = 55 um                     (the attach process)
die-to-die signals = 128, on 2 RDL layers   (the memory interface)
RDL width/spacing  = 2 um / 2 um            (the interposer technology)
library scale factors = 4,000 / 10,000 / 2,000

# The session scale factor, first, because nothing runs without it.
lcm(4,000, 10,000, 2,000) = 20,000
check: 20,000 / 4,000 = 5, / 10,000 = 2, / 2,000 = 10  -> all whole

# The channel. Two attempts.
track pitch    = 2 + 2 = 4 um
attempt 1      200 um gap -> 200 / 4 = 50 a layer x 2 = 100 tracks
               128 signals - 100 = 28 short: rejected
attempt 2      128 / 2 = 64 a layer -> 64 x 4 = 256, round up to 260
               260 / 4 = 65 a layer x 2 = 130 tracks
               130 - 128 = 2 spare, 128 / 130 = 98.46 per cent used

# Which fixes every placement number on the interposer.
margin each side = (10,000 - (3,440 + 260 + 5,500)) / 2 = 400 um
logic die at     (400, (6,000 - 3,440) / 2) = (400, 1,280)
memory die at    (400 + 3,440 + 260, (6,000 - 4,800) / 2) = (4,100, 600)
check            400 + 3,440 + 260 + 5,500 + 400 = 10,000

Check each figure backwards before it goes anywhere. 1,280 + 3,440 + 1,280 = 6,000, and 600 + 4,800 + 600 = 6,000, so both die are vertically centred. 4,100 + 5,500 = 9,600, and 10,000 − 9,600 = 400, so the two margins agree. And the two die areas, 11.8336 mm² and 26.40 mm², sum to 38.2336 mm² = 38,233,600 µm², which is 63.72 per cent of the interposer's 60.00 mm² = 60,000,000 µm², leaving 21.7664 mm² — 36.28 per cent — of interposer with no die on it.

Step 1 — prepare each active die

# The logic die: Chapter 6's netlist and floorplan, a new bump field.
icc2_shell> set_app_options -name design.session_scale_factor \
   -value 20000
icc2_shell> read_verilog nimbus_logic.v
icc2_shell> read_def nimbus_logic.def

# The channel band, facing the memory die.
icc2_shell> create_bump_array -lib_cell UBUMP -name ub_chan \
   -delta {55 55} -repeat {8 16} \
   -bbox {{2900 640} {3285 1520}}

# The package band, facing the other way.
icc2_shell> create_bump_array -lib_cell UBUMP -name ub_pkg \
   -delta {55 55} -repeat {4 16} \
   -bbox {{155 640} {320 1520}}

# The power and ground field, in the middle.
icc2_shell> create_bump_array -lib_cell UBUMP -name ub_pg \
   -delta {55 55} -repeat {15 15} -pattern staggered_1 \
   -bbox {{1335 1335} {2105 2105}}

# Where those three shapes come from.
sites across the die   3,440 / 55 = 62 sites
                       61 x 55 = 3,355, so 42.5 um each edge
signal microbumps      channel band  8 x 16 = 128
                       package band  4 x 16 =  64
                       total                = 192
power microbumps       15 x 15 staggered_1, 8x8 + 7x7 = 113
logic die total        192 + 113 = 305

# And the check that it was done honestly.
Chapter 6 gave this die 305 bumps. It still has 305.

That last line is the whole point of the step. The pitch changed from 150 µm to 55 µm and the arrangement changed from four peripheral bands plus a central field to two bands plus a central field, but the count did not, because the count came from the netlist and the power budget rather than from the geometry. If a rearrangement changes the count, something was dropped.

The memory die is prepared the same way and arrives with 128 channel microbumps — matching the logic die's channel band exactly — plus a 12 × 12 staggered field giving 6 × 6 + 6 × 6 = 72 power and ground microbumps, for 200 in total.

Step 2 — the interposer

icc2_shell> create_lib nimbus_interposer.ndm \
   -technology interposer.tf \
   -ref_libs {c4_bump.nlib front_ubump.nlib physicalonly.nlib}
icc2_shell> read_verilog interposer.v
icc2_shell> initialize_floorplan -control_type die \
   -boundary {{0 0} {10000 6000}}

# C4 bumps, on the back side, at the package's pitch.
# The signal band first: 64 of them, one per package signal.
icc2_shell> create_bump_array -lib_cell C4_BUMP -name c4_sig \
   -delta {150 150} -repeat {8 8} -origin {125 75}

# Then a power field under each die.
icc2_shell> create_bump_array -lib_cell C4_BUMP -name c4_pg_log \
   -delta {150 150} -repeat {8 8} -origin {875 1875}
icc2_shell> create_bump_array -lib_cell C4_BUMP -name c4_pg_mem \
   -delta {150 150} -repeat {6 6} -origin {5675 1875}

# One TSV per C4 bump. Every one of them.
icc2_shell> derive_3d_interface -from [get_cells c4_*] \
   -to_object_ref [get_via_defs -tech [get_techs *] VIA_TSV] \
   -name_prefix TSV_c4
icc2_shell> create_matching_type \
   -name Signal [all_connected [get_nets *SIG*]]

# The back-side arithmetic.
C4 sites across   10,000 / 150 = 66,  65 x 150 = 9,750, margin 125 um
C4 sites up        6,000 / 150 = 40,  39 x 150 = 5,850, margin  75 um
inline sites      66 x 40 = 2,640
C4 bumps placed   64 signal + 64 + 36 power = 164
site use          164 / 2,640 = 6.21 per cent
TSVs created      164, one per C4 bump

# The contrast that explains the interposer.
front side  505 microbumps at  55 um pitch
back side   164 C4 bumps   at 150 um pitch
ratio       505 / 164 = 3.08 to 1, against a pitch ratio of 2.727 to 1

Six per cent site use on the back side, against Chapter 6's 63.02 per cent on the die. That is not slack — it is what a 150 µm pitch looks like on a piece of silicon a centimetre wide, and it is the reason the interposer exists.

Step 3 — the top-level design

icc2_shell> create_lib nimbus_top.ndm -technology top.tf \
   -ref_libs {nimbus_logic.ndm nimbus_mem.ndm nimbus_interposer.ndm}
icc2_shell> read_verilog nimbus_top.v
icc2_shell> initialize_floorplan -boundary {{0 0} {10000 6000}}
icc2_shell> set_attribute [current_block] design_type 3dic

icc2_shell> set_cell_location interposer_inst \
   -coordinates {0 0} -z_offset 0 -orientation N
icc2_shell> set_cell_location logic_die_inst \
   -coordinates {400 1280} -z_offset 1 -orientation FN
icc2_shell> set_cell_location mem_die_inst \
   -coordinates {4100 600} -z_offset 1 -orientation FN

icc2_shell> report_3d_chip_placement -chips \
   {logic_die_inst mem_die_inst interposer_inst}
chip_name        design_type  stack_z  location      orientation  scaling_factor
logic_die_inst   die          1        (400 1280)    FN           1
mem_die_inst     die          1        (4100 600)    FN           1
interposer_inst  die          0        (0 0)         N            1

icc2_shell> check_3d_design -chip_placement

That last line is the one exception to “run the check at the end”, and it is a deliberate one: -chip_placement is the only category whose prerequisites are satisfied at this point, since it depends on nothing but set_cell_location. Running it here catches an overlap or a z value that does not start at zero while the fix is still one command.

Step 4 — mirror the microbumps

icc2_shell> save_block
icc2_shell> save_lib
icc2_shell> close_lib
icc2_shell> open_lib nimbus_top.ndm -ref_libs_for_edit
icc2_shell> set_editability \
   -blocks nimbus_interposer.ndm:interposer.design

icc2_shell> create_3d_mirror_bumps -from logic_die_inst \
   -to interposer_inst -ref_cell UBUMP -prefix logic \
   -use_port_names
icc2_shell> create_3d_mirror_bumps -from mem_die_inst \
   -to interposer_inst -ref_cell UBUMP -prefix mem \
   -use_port_names

# Count them, because the count is the check.
logic 305 + memory 200 = 505 microbumps on the interposer front side
get_cells logic*  -> 305
get_cells mem*    -> 200

Step 5 — connect, match and assign

icc2_shell> propagate_3d_connections

icc2_shell> current_design interposer
icc2_shell> add_to_matching_type Signal [get_cells logic_dq* mem_dq*]
icc2_shell> create_matching_type -name Power \
   [get_pins *VDD_log*/PAD *VDD_mem*/PAD]
icc2_shell> create_matching_type -name Ground \
   [get_pins *VSS_log*/PAD *VSS_mem*/PAD]

icc2_shell> current_design nimbus_top
icc2_shell> propagate_3d_matching_types
icc2_shell> assign_3d_interchip_nets -include_pg_nets \
   -set_port_terminals incremental

Two options on that last command are decisions, not defaults. -include_pg_nets is there because the power and ground bumps have to be assigned too and are excluded otherwise. -set_port_terminals incremental is there because the channel nets each reach more than one bump, and without it the ambiguity is resolved silently — with it, the choice is recorded in the preferred_pin attribute where a reviewer can read it.

Step 6 — the virtual interface blocks

icc2_shell> create_3d_virtual_blocks -in_netlist

Two blocks, because there are two adjacent die pairs: the logic die against the interposer, and the memory die against the interposer. The two active die are at the same z level and face each other edge-on rather than face-to-face, so no block is created between them.

Step 7 — the power mesh

icc2_shell> create_pg_mesh_pattern mesh_int \
   -layers {{{vertical_layer: M4} {width: 10} {spacing: 90} \
             {pitch: 200} {offset: 50}} \
            {{horizontal_layer: M3} {width: 10} {spacing: 90} \
             {pitch: 200} {offset: 40}}}
icc2_shell> set_pg_strategy strat_logic \
   -pattern {{name: mesh_int} {nets: VDD_log VSS_log}} \
   -polygon {{400 1280} {3840 4720}}
icc2_shell> set_pg_strategy strat_mem \
   -pattern {{name: mesh_int} {nets: VDD_mem VSS_mem}} \
   -polygon {{4100 600} {9600 5400}}
icc2_shell> compile_pg -strategies {strat_logic strat_mem}

# The straps, counted before and after.
logic die   3,440 um each way, 17 pairs each way -> 68 straps
memory die  5,500 um wide, 28 pairs             -> 56 straps
            4,800 um tall, 24 pairs             -> 48 straps
total       68 + 104 = 172 straps on two layers
metal       34 x 10 = 340 um of 3,440 = 9.88 per cent of the logic die

Step 8 — route the channel, then the rest

icc2_shell> set_app_options -name flip_chip.route.design_style \
   -value 3dic_interposer
icc2_shell> report_app_options flip_chip.route.design_style

icc2_shell> create_interposer_routeplan -interposer_style single_hbm \
   -pattern_file nimbus_hbm.pat
icc2_shell> set_attribute [get_vias *] shape_use user_route

icc2_shell> create_routing_rule rdl_chan \
   -widths {MRDL 2 M9 2} -spacings {MRDL 2 M9 2}
icc2_shell> set_routing_rule [get_nets $chan_nets] -rule rdl_chan

icc2_shell> set_app_options \
   -name flip_chip.route.bump_via_landing_mode -value true
icc2_shell> route_3d_rdl -nets [get_nets $chan_nets] -layer MRDL \
   -coordinates {{3840 600} {4100 5400}}
icc2_shell> set_app_options \
   -name flip_chip.route.bump_via_landing_mode -value false
icc2_shell> route_3d_rdl -nets [get_nets $chan_nets] -layer M9 \
   -coordinates {{3840 600} {4100 5400}}

icc2_shell> set_ignored_layers -min_routing_layer M1 \
   -max_routing_layer M4
icc2_shell> route_group -nets [get_nets $pkg_nets]
icc2_shell> report_rdl_routes -open_nets true

The rectangle in -coordinates is the channel and nothing else: {{3840 600} {4100 5400}} is 3,840 (the logic die's right edge, 400 + 3,440) to 4,100 (the memory die's left edge), spanning 600 to 5,400 (the memory die's height). Restricting the router to it is the difference between a two-minute run and a two-hour one.

Step 9 — check the whole system

icc2_shell> check_3d_design -verbose -error_view nimbus_3d.err

No category options, because all ten are wanted. -verbose, because without it the command prints only part of the messages and a summary. And an error view name, because the next person to look at this will want the browser rather than the log.

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

Two hundred and sixty microns, not two hundred. The gap the two die happened to leave was 200 µm and it held 100 tracks for 128 signals. The fix cost 60 µm of channel, taken 30 µm from each margin. Nothing in the flow raises this; the routing step would simply have failed to route 28 nets, three weeks later, after the interposer outline had been agreed.

Two spare tracks, not twenty. Having widened the channel, 300 µm would have given 150 tracks and 22 spare. It was not chosen, because the margin those 40 microns came from is what the C4 bumps and the mesh reach-out need. Ninety-eight per cent utilisation is uncomfortable, and it is what the reference says these designs run at. The defensible position is not “98 per cent is fine” but “the alternative was worse, and here is the arithmetic”.

Rearranging the logic die's bumps rather than keeping Chapter 6's field. The 150 µm field was designed for a package. Keeping it would have meant an interposer whose microbumps sat at 150 µm — legal, and a waste of the attach process. The count stayed at 305 and the area shrank by roughly a factor of seven. This is the one step in the chapter that changes an earlier chapter's output, and it is worth saying out loud in a review rather than letting somebody discover it.

-set_port_terminals incremental, not all and not omitted. Omitted, the ambiguity is resolved without a record. all resets every preferred pin on every run, so two runs can differ. incremental records a choice once and leaves it alone, which is the behaviour you want from something a reviewer may have already signed off.

Running -chip_placement early, and nothing else. The check belongs at the end of the flow. One of its ten categories depends only on set_cell_location, so running that one alone after step 3 is free information. Running the whole command there is not: it would report nine categories' worth of errors about work not yet done, and the honest response to a report like that is to stop reading it.

7.6 Failure modes and how to recognise them

Twelve ways this goes wrong. Three produce no message at all, one ends the session outright, and one produces so many messages that the right response is to ignore all of them.

7.7 Hands-on mini lab

A new system, Carina-4, on the same shape of problem with different numbers. Do the arithmetic on paper before you write a command; that is the whole exercise.

Tasks

Expected observations

7.8 Interview preparation

Sixteen questions, grouped by level. Answer each one out loud before reading the model answer. 3DIC questions come up more often than the number of 3DIC designs would suggest, for a reason worth knowing: they are a fast test of whether a candidate can hold a system in mind while working on one part of it, and that is a general skill an interviewer will pay for whether or not they are building an interposer this year.

Beginner

Intermediate

Senior

7.9 Chapter close

Sign-off checklist

Flashcards

Compact glossary

Five-question self-check

A new system, Lyra-2. The interposer is 8,000 × 5,000 µm, from the package. The logic die is a square 2,800 µm on each side; the memory die is 4,000 × 3,600 µm. The two die exchange 96 signals on two redistribution layers, at a 4 µm track pitch, and 48 signals leave the system to the package. The microbump pitch is 50 µm; the C4 pitch is 200 µm. The logic die's microbump bands are 6 × 16 facing the memory, 3 × 16 facing the package, and a 13 × 13 power field with staggered_1; the memory die's are 6 × 16 facing the logic die and a 10 × 10 power field, also staggered_1. The C4 power fields are 7 × 7 under the logic die and 5 × 5 under the memory. The three library scale factors are 4,000, 20,000 and 2,500.

1. What is the session scale factor, and what is unusual about the answer?
2. The two die are placed with a 200 µm gap. How many tracks does that channel hold, how many does it need, and what utilisation does that give?
3. Compute the margin at each side of the interposer and the coordinates of both die, both vertically centred, and check the width and both heights back to the interposer's size. Then give the interposer area and the total die area, each in mm² and in µm², and the percentage of the interposer that has a die on it.
4. At a 50 µm microbump pitch, how many sites fit across the logic die and how far is the outermost site from its edge? Then count the microbumps on each die and the number the interposer gains from mirroring.
5. Count the C4 bumps and TSVs, the C4 sites the interposer holds at 200 µm, the margin at each edge, and the site utilisation.

Answers.

1. Start from the largest factor, 20,000, and step through its multiples. 20,000 ÷ 4,000 = 5, 20,000 ÷ 20,000 = 1, 20,000 ÷ 2,500 = 8 — all whole on the first try, so the session scale factor is 20,000. What is unusual is that the answer equals one of the inputs: the memory library's own factor was already a multiple of the other two. That is worth noticing because it is the case in which adding a library to a system costs nothing, and the case people generalise from when it does not hold. Compare Carina-4, where 8,000, 20,000 and 2,500 required 40,000 — larger than any of them.

2. A 200 µm channel at a 4 µm track pitch holds 200 ÷ 4 = 50 tracks a layer, so 50 × 2 = 100 tracks. It needs 96 ÷ 2 = 48 a layer, so 48 × 4 = 192 µm — which fits inside 200. Utilisation 96 ÷ 100 = 96.00 per cent, with 4 tracks spare. Four spare tracks on a 96-signal channel is tight but not closed: it is one late signal, or one place where a route has to jog around an obstacle. Better than Carina-4's zero and worse than you would choose if the interposer were yours.

3. Margin: (8,000 − (2,800 + 200 + 4,000)) ÷ 2 = (8,000 − 7,000) ÷ 2 = 500 µm. Logic die at (500, (5,000 − 2,800) ÷ 2) = (500, 1,100). Memory die at (500 + 2,800 + 200, (5,000 − 3,600) ÷ 2) = (3,500, 700). Check the width: 500 + 2,800 + 200 + 4,000 + 500 = 8,000. Check the heights: 1,100 + 2,800 + 1,100 = 5,000 and 700 + 3,600 + 700 = 5,000. Areas: interposer 8,000 × 5,000 = 40.00 mm² = 40,000,000 µm²; die 7,840,000 + 14,400,000 = 22.24 mm² = 22,240,000 µm², which is 22.24 ÷ 40.00 = 55.60 per cent of the interposer, leaving 44.40 per cent free.

4. Sites across the logic die: 2,800 ÷ 50 = 56 sites. Fifty-five gaps of 50 µm span 55 × 50 = 2,750 µm, leaving 2,800 − 2,750 = 50 µm to share, so the outermost site centre sits 25 µm from each edge. Check: 25 + 2,750 + 25 = 2,800. Microbumps on the logic die: 6 × 16 = 96 facing the memory, 3 × 16 = 48 facing the package, so 144 signal; the 13 × 13 power field with staggered_1 has seven even and six odd indices in 0 to 12, so 7 × 7 + 6 × 6 = 49 + 36 = 85; total 229. On the memory die: 6 × 16 = 96 facing the logic die, which agrees with the logic die's facing band exactly; the 10 × 10 power field has five even and five odd indices, so 5 × 5 + 5 × 5 = 50; total 146. The interposer gains 229 + 146 = 375 microbumps.

5. C4 bumps: 48 signal, plus 7 × 7 = 49 and 5 × 5 = 25 power, so 48 + 74 = 122 — and therefore 122 TSVs, one each. Sites: 8,000 ÷ 200 = 40 across and 5,000 ÷ 200 = 25 up, so 40 × 25 = 1,000 sites. Margins: 39 × 200 = 7,800, leaving (8,000 − 7,800) ÷ 2 = 100 µm each side; 24 × 200 = 4,800, leaving (5,000 − 4,800) ÷ 2 = 100 µm top and bottom — the same both ways, which is luck rather than design. Utilisation 122 ÷ 1,000 = 12.20 per cent. Higher than Nimbus-8's 6.21 per cent and Carina-4's 8.37 per cent, and for the obvious reason: a smaller interposer holds fewer sites while still needing roughly the same number of package connections. The back side of an interposer is always sparse, and how sparse depends on how much silicon the package asked for.

Where the next chapter goes, and why

The system is planned. Two active die have boundaries, bump fields and a pitch they agree on. An interposer created from an empty netlist carries 505 microbumps on its front side, 164 C4 bumps and 164 through-silicon vias on its back, a power mesh under each die and routes between them. A top-level design that will never be manufactured holds all three at coordinates and z levels, and ten check categories say the assembly is consistent.

What has been assumed throughout is that each die is one design — a thing with a boundary that somebody hands you. Chapter 8 stops assuming that. It is about managing design blocks: partitioning a design and committing a logical hierarchy cell to a physical hierarchy block early in the flow, and then creating multiple optimised abstract views for those blocks, containing only the information needed for placement, timing and other tasks. Its flow is four steps — explore the design hierarchy, create module boundaries with explore_logic_hierarchy, commit the blocks with commit_block, and create the placement abstracts with create_abstract.

The link back to this chapter is the same idea at a smaller scale, and it is worth holding on to. An active die in this chapter was a boundary plus an interface, with its contents invisible and irrelevant to the system that mounted it. A committed block in Chapter 8 is a boundary plus an interface too, with an abstract view that deliberately contains only what the level above needs. One is a piece of silicon and the other is a piece of a netlist, and both exist so that the thing above them can be planned without knowing what is inside.