At which step should filler cells be added when metal 1 is used for routing

[titan73]

In my design, metal 1 is used for routing. If filler cells are added after detailed routing, their metal1 shapes will overlap metal 1 routing causing thus shorts.
It seems to me that in that case they should be added before gobal routing.

In ORFS, it's done after detailed routing:

# STEP 1: Run global route
#-------------------------------------------------------------------------------
$(eval $(call do-step,5_1_grt,$(RESULTS_DIR)/4_cts.odb $(FASTROUTE_TCL) $(PRE_GLOBAL_ROUTE_TCL),global_route))

# STEP 2: Run detailed route
#-------------------------------------------------------------------------------
$(eval $(call do-step,5_2_route,$(RESULTS_DIR)/5_1_grt.odb,detail_route))

$(eval $(call do-step,5_3_fillcell,$(RESULTS_DIR)/5_2_route.odb,fillcell))

The min layer for the open PDKs are:

flow/designs/asap7/aes-block/config.mk:export MIN_ROUTING_LAYER      = M2
flow/designs/asap7/mock-array/Element/config.mk:export MIN_ROUTING_LAYER = M2
flow/platforms/nangate45/config.mk:export MIN_ROUTING_LAYER = metal2
flow/platforms/sky130hs/config.mk:export MIN_ROUTING_LAYER = met1

I wonder how this could work for sky130hs since it uses metal 1 for routing.

[maliberty]

In sky130hs the fill cells only have vdd/vss shapes on m1 so there is no conflict. It is odd to route on layer where fill shapes would block it. If you put them in pre-grt then would there be any routing resource available?

[titan73]

Ah ok. In sky130hs, they are not decap cells.

Metal 1 is always used in Innovus for our designs & technos. I don't know how it is precisely handled though.

In OpenROAD, using metal 1 is mandatory, I tested 3 cases:

• Metal 1 with no filler (decap) cells => 5 violations (due to pins not aligned to tracks)
• No metal 1 => 300000 violations
• Metal 1 with filler (decap) cells => 3130 violations

I place the fillers just before global routing.
I'm wondering how they are handled after detailed routing when repair timing and antennas are done (basically OR should be able to remove filler cells before adding buffers or diodes).

[titan73]

Here are some pics with the metal 1 routing (with decap cells):

With the center area zoomed in:

[maliberty]

Are you suggesting leaving out the decap cells where you using metal1 for routing? Wouldn't you need some sort of cell there for well continuity?

[titan73]

I had some answers from a CAD designer:

• Apparently the Transparent Filler Cell Flow is mandatory for reconfigurable cell when using metal 1 for routing
• For classical cells (not reconfigurable), decap cells and filler cells can be mixed. Decap cells are added first with placement blockage on metal 1 then the filler cells are added with the blockages removed.
• Also decap cells may not have the smallest sizes which filler cells have

[maliberty]

I don't know "Transparent Filler Cell Flow" nor how it works. How are they "updated as needed across the rest of the flow"?

[titan73]

For what I've understood, a variable containing the masters (fillers, decaps and supply diodes) must be set to tell Innovus what it can remove when it needs adding buffers or resizing cells.
The kit adds fillers and decaps in several places. I'm not an expert but here's a grep:

route.tcl:    source ../SCRIPTS/fill.tcl
postRouteFixFromSignoff.tcl:    source ../SCRIPTS/fill.postRoute.tcl
postRouteFixFromSignoff.tcl:    source ../SCRIPTS/fill.tcl
postRouteFixFromSignoff.tcl:    source ../SCRIPTS/fill.tcl
postRouteSetupHold.tcl:    source ../SCRIPTS/fill.postRoute.tcl
postRouteSetupHold.tcl:source ../SCRIPTS/fill.tcl
postRouteSignoffOpt.tcl:    source ../SCRIPTS/fill.postRoute.tcl
postRouteSignoffOpt.tcl:    source ../SCRIPTS/fill.tcl
postRouteSignoffOpt.tcl:    source ../SCRIPTS/fill.postRoute.tcl

fill.tcl configures fillers variables and adds fillers
fill.postRoute.tcl only configures variables (same configuration as fill.tcl)

[maliberty]

The question was about routing not optmization. You want to route on the same layer as the decaps. If you remove the decaps to route then what ensures well continuity in those areas (there are no cells there).

[titan73]

Not sure I understand well the question. I'll try to explain better.

Our internal kit using innovus tool does:

• placement
• insert decaps cells (generally they don't have the smallest sizes)
• insert filler cells to fill small holes decap cells don't have size for
• at this point, there are no holes
• global + detailed routing
• specify to the tool the decap/filler masters
• during optimization, the tool (not the kit), picked up some space from the decaps/fillers area by:
  • removing the decap/filler cells that overlap the cell that will be place or resize
  • place or resize the cell
  • fill the holes with the decap/filler masters list specified above
  • incremental route

OpenROAD does not have such functionality. It's probably possible to do that with a script. It's very likely it'll be slow though.
Something like:

• before optimization, saves all cells (functional and decap/filller) and their positions
• remove all decap/filler cells
• do the optimization
• after optimization compare current functional cells and positions with the ones saved
• with the diff update the decap/filler list previously saved
• add filler one by one from the list
  I'll give it a try. repair_tming deos not work for me with my design (rsz: repair_timing says there are no violations while report_checks says the contrary #8075).
  Is there a way to manually add a buffer (repeater) or resize a cell so I can test?

[maliberty]

We do not support using a mix of fillers & decaps.

[titan73]

Ok. I'll live with that for now. Will it be supported in the future?

[maliberty]

Perhaps someday but there is no immediate plan. You can open an isssue to request it.

[titan73]

After some thoughts, it's not clear to me what is problematic with mixing decaps and fillers.
Assuming we don't route on metal 1. Considering something like the following mix:
filler_placement -prefix $prefix -verbose {DECAP_SIZE4 DECAP_SIZE3 FILLER_SIZE2 FILLER_SIZE1}
OR will place in priority decap cells when there is space and filler cells for small holes for which there are no decap cells.
This shouldn't be an issue, right?

Or maybe are your referring to something more elaborate like:
filler_placement -prefix $prefix -verbose -decap {DECAP_SIZE64 ... DECAP_SIZE3} -filler {FILLER_SIZE64 .. FILLER_SIZE1} -decap_ratio 50%
where decap ratio can be adjusted to get a compromise between capacitance and routability when we route on metal1?

[maliberty]

This whole discussion was started with " If filler cells are added after detailed routing, their metal1 shapes will overlap metal 1 routing causing thus shorts.". You didn't want to add them beforehand either as the decaps block most of m1. There is nothing wrong with adding them beforehand so long as you accept that m1 will be unusable for routing.

[titan73]

Oh ok. Sorry for the misunderstanding.

[titan73]

I tested the code:

proc bbox_to_rect {location dx dy} {
    lassign $location x y
    return [list $x $y [expr $x + $dx] [expr $y + $dy]]
}
proc check_overlap {rect1 rect2} {
    lassign $rect1 l1 b1 r1 u1
    lassign $rect2 l2 b2 r2 u2
    if {$l2 >= $r1 || $b2 >= $u1 || $r2 <= $l1 || $u2 <= $b1} {
        return 0
    }
    return 1
}

proc dump_cells {prefix filler_type} {
    set db [ord::get_db_block]
    set block [[$db getChip] getBlock]
    set all_cell_list [$block getInsts]
    set cell_list {}

    foreach cell $all_cell_list {
        set name [$cell getName]
        # FIXME: How do we filter macros?!
        if {$name == "NVM_512bE2LTa_H9A_i"} {
            continue
        }
        set master [[$cell getMaster] getName]
        set location [$cell getLocation]
        set orient [$cell getOrient]
        set bbox [$cell getBBox]
        set dx [$bbox getDX]
        set dy [$bbox getDY]
        set info [list $cell $name $master [bbox_to_rect $location $dx $dy] $orient]
        if {[regexp {^FILLERCELL_} $name] == $filler_type} {
            lappend cell_list $info
        }
    }
    return $cell_list
}

set filler_list {}

proc disable_fillers {prefix} {
    global filler_list

    puts "Saving fillers"
    set filler_list [dump_cells $prefix 1]

    puts "Remove [llength $filler_list] fillers"
    remove_fillers
    
    return $filler_list
}

proc update_fillers {prefix filler_cell_list} {
    global filler_list

    puts "Discard overlapping fillers"

    set new_cell_list [dump_cells $prefix 0]

    set i 0
    set l [llength $filler_list]
    set old_bar -1
    set new_filler_list {}
    foreach filler $filler_list {
        set bar [expr round (($i * 1.0) / $l * 100)]
        if {$bar != $old_bar} {
            puts "Processing fillers $bar%"
            set old_bar $bar
        }
        incr i
        lassign $filler cell1 name1 master1 rect1 orient1
        set overlap 0
        foreach cell $new_cell_list {
            lassign $cell cell2 name2 master2 rect2 orient2
            if {[check_overlap $rect1 $rect2]} {
                puts "Discard filler $name1 ($master1) which overlaps with cell $name2 ($master2)"
                set overlap 1
            }
        }
        if {$overlap == 0} {
            lappend new_filler_list $filler
        }
    }

    puts "Readding [llength $new_filler_list] fillers ([expr $l - [llength $new_filler_list]] discarded)"
    foreach filler $new_filler_list {
        lassign $filler cell1 name1 master1 rect1 orient1
        lassign $rect1 x y
        make_instance $name1 $master1
        place_inst -name $name1 -location [list [expr $x / 1000.0] [expr $y / 1000.0]] -orientation $orient1
    }

    puts "Fill holes with fillers"
    filler_placement -prefix $prefix -verbose $filler_cell_list
    check_placement
}

So I do:

    filler_placement -prefix FILLERCELL_ -verbose $filler_list
    global_route -verbose -allow_congestion
    detailed_route
    disable_fillers FILLERCELL_
    # Move cell from {0 13.53} to {0 9.02} where there is a filler
    place_inst -name U53 -location {0 9.02} -orientation R0
    update_fillers FILLERCELL_ $filler_list

It seems to work and does something similar to our internal flow. It's a bit slow although that's expected.
I haven't tested doing an incremental routing yet.