OpenROAD

Metal fill¶

This module inserts floating metal fill shapes to meet metal density design rules while obeying DRC constraints. It is driven by a json configuration file.

Commands¶

% density_fill -rules <json_file> [-area <list of lx ly ux uy>]

If -area is not specified, the core area will be used.

Example scripts¶

The rules json file controls fill and you can see an example here.

The schema for the json is:

{
  "layers": {
    "<group_name>": {
      "layers": "<list of integer gds layers>",
      "names": "<list of name strings>",
      "opc": {
        "datatype":  "<list of integer gds datatypes>",
        "width":   "<list of widths in microns>",
        "height":   "<list of heightsin microns>",
        "space_to_fill": "<real: spacing between fills in microns>",
        "space_to_non_fill": "<real: spacing to non-fill shapes in microns>",
        "space_line_end": "<real: spacing to end of line in microns>"
      },
      "non-opc": {
        "datatype":  "<list of integer gds datatypes>",
        "width":   "<list of widths in microns>",
        "height":   "<list of heightsin microns>",
        "space_to_fill": "<real: spacing between fills in microns>",
        "space_to_non_fill": "<real: spacing to non-fill shapes in microns>"
      }
    }, ...
  }
}

The opc section is optional depending on your process.

The width/height lists are effectively parallel arrays of shapes to try in left to right order (generally larger to smaller).

The layer grouping is for convenience. For example in some technologies many layers have similar rules so it is convenient to have a Mx, Cx group.

This all started out in klayout so there are some obsolete fields that the parser accepts but ignores (e.g., space_to_outline).

Regression tests¶

Limitations¶

FAQs¶

Check out GitHub discussion about this tool.

License¶

BSD 3-Clause License. See LICENSE file.

Table Of Contents

Metal fill

TritonRoute

Flute3