gf180: add metal density fill rules (fill.json)

[lanserge]

Summary

The gf180 platform shipped FILL_CELLS (std-cell filler) but no metal density fill: there was no FILL_CONFIG, so the density_fill step (6_1_fill) inserted nothing. gf180mcu's density deck enforces ">30% metal coverage per layer, die-wide" (rules M2.4 / M3.4 / M5.4 / ...), which sparse designs cannot meet without metal fill.

This adds flow/platforms/gf180/fill.json (Metal1–Metal5) and points FILL_CONFIG at it.

Details

• Layer/datatype numbers match the platform's own KLayout layer properties (flow/platforms/gf180/KLayout/gf180mcu.lyp): Metal1 34/0 … Metal5 81/0, with fill geometry placed on the *_Dummy datatype 4 (Metal1_Dummy 34/4 …).
• Fill shapes use a 3-size pattern [2.0, 1.0, 0.5] alternating H/V direction. Metal5 uses a tighter space_to_fill (0.5) because the top routing layer carries the PDN stripes and leaves less fillable area.

Opt-in / no behavior change

USE_FILL still defaults to 0, so density_fill remains a no-op and no existing design's results change. A chip/top-level design opts in with USE_FILL=1. Metal fill is intentionally a chip-level (die-wide) step — block / hard-macro builds keep USE_FILL=0 so fill is inserted once at the top, not per block.

Verification

Ran OpenROAD density_fill -rules flow/platforms/gf180/fill.json on a routed gf180mcu design: the rules parse and fill inserts cleanly on Metal1–Metal5 (non-metal/via layers skipped as expected), no errors. On the source design this took the failing density-DRC count to zero and brought all of M1–M5 above the 30% coverage floor.

Note: per docs/contrib/GettingInvolved.md, a new platform feature ideally ships with a design that exercises it. This PR keeps the change as opt-in platform capability only (so CI metrics are unaffected); enabling USE_FILL=1 on a gf180 CI design + regenerating its golden metrics can follow as a separate change.

[gemini-code-assist]

Code Review

This pull request introduces metal density fill rules for the gf180 platform by adding a new fill.json configuration file and referencing it in config.mk. Feedback suggests increasing the minimum fill size and spacing for Metal5 from 0.5 to 0.6 to ensure compatibility with both the 9K and 11K thick metal options and prevent DRC violations.

[gemini-code-assist]

The current minimum fill size and spacing of 0.5 for Metal5 is valid for the default 9K thick metal option (KVALUE=9, where min width/spacing is 0.44 um). However, the gf180 platform also supports the 11K thick metal option (KVALUE=11), which has a minimum width and spacing requirement of 0.6 um. Using 0.5 will result in DRC violations (rules MT.1 and MT.2) when KVALUE=11 is selected.

Changing the minimum size and spacing to 0.6 makes these rules robust and compatible with both 9K and 11K metal stack options without significantly impacting density fill coverage.

Suggested change

	"width": [2.00, 1.00, 0.5],
	"height": [2.00, 1.00, 0.5],
	"space_to_fill": 0.5,
	"space_to_non_fill": 0.5
	"width": [2.00, 1.00, 0.6],
	"height": [2.00, 1.00, 0.6],
	"space_to_fill": 0.6,
	"space_to_non_fill": 0.6

[lanserge]

Thanks for the review. I looked into the Metal5 0.5 → 0.6 suggestion and I'd like to keep it at 0.5. The concern appears to conflate Metal5 with MetalTop:

• In the 5LM_1TM stack, this fill is inserted on Metal5 (GDS 81/4), a thin routing layer. Per the gf180mcu KLayout DRC deck, Metal5 minimums are M5.1 = 0.28 µm width and M5.2a = 0.28 µm spacing. 0.5 clears both with large margin.
• The MT.1/MT.2 rules quoted apply to MetalTop (the thick top metal, GDS 53), which this fill.json deliberately does not fill. Even MetalTop's thick variant is 0.44/0.46, not 0.6.
• KVALUE (9K vs 11K) sets the MetalTop thickness, not Metal5. The 9K and 11K tech LEFs carry identical Metal5 rules (MINWIDTH 0.440 / SPACING 0.460), and 0.5 clears even that stricter LEF value. So there's no 9K-vs-11K Metal5 difference to guard against.

0.5 (vs the 1.0 used on M1–M4) was chosen on purpose: Metal5 carries the PDN stripes and is the coverage-tight layer against M5.4 (">30% metal5 coverage die-wide"). Relaxing it to 0.6 reduces that margin without any DRC need. Verified on a routed gf180mcu design — Metal5 fill inserts with no width/spacing violations.

[lanserge]

Update after checking the primary spec (GF180MCU DRM) rather than relying on the open KLayout deck:

• The 0.6 is MT.2b — spacing between wide (>10 µm) MetalTop — so it doesn't govern small fill shapes. The fill-relevant minimums are MT.1 = 0.44 µm width / MT.2a = 0.46 µm spacing, identical for 9K and 11K, both cleared by 0.5.
• More importantly: in the default 5LM_1TM stack, Metal5 is the thick top metal, so the open gf180mcu_fd_pr deck (which checks GDS 81 as thin M5, 0.28 µm) under-checks it. Against the real rules, fill on Metal5 also has to respect MT.4 (min area 0.5625 µm²) and the dummy-metal rules in DRM §13.3 (DM.1 ~2.0 µm shapes, DM.2 ≥0.98–1.2 µm fill-to-fill, DM.3 2.0 µm fill-to-circuit-metal). The current values predate that and would not be foundry-DM-compliant.

So I'm reworking fill.json to be DM-compliant and re-validating that the >30 % coverage floor still holds (Metal5 is PDN-stripe-tight, so sparser fill needs a coverage check). Will push an update. Thanks — the Metal5 comment pointed at a real gap, just not the 0.6 one.