mimcap: build with extensions again

[carloscl03]

mimcap() raises with its default arguments, on both options:

File "src/glayout/primitives/mimcap.py", line 293, in mimcap
    appendix_pos[cord_ref] = appendix_pos[cord_ref] + appendix_size[cord_ref]/2 ...
TypeError: 'tuple' object does not support item assignment

Port.center is a tuple and the line below indexes into it to shift the
appendix. Take a list.

The branch is only reached when min_via_distance < 0.4, so whether it fires
depends on the requested size — 5x5 hits it. No CI cell caught this because
every tested cell goes through mimcap_array, which passes
with_extension=False and skips the path entirely. A direct
mimcap(pdk, size) — the obvious way to use the primitive — fails.

Verified on gf180 with the gdstk backend:

call	before	after
mimcap(pdk, (5,5), option="A")	TypeError	builds
mimcap(pdk, (5,5), option="B")	TypeError	builds
mimcap(pdk, (10,4), option="B")	TypeError	builds
mimcap_array(pdk, 2, 2, (5,5))	builds	builds

Layers written are as expected for each option — A: met2 / FuseTop / via2 /
met3; B: met4 / FuseTop / via4 / met5.

[LuighiV]

Hi @carloscl03

Thanks for catching this up. It is a bit strange as I remember tested the simple version of mimcap and it built without raising any issue.

Let me check again.

Can you please, add as part of the PR, an additional check for the individual mimcap?

Thanks,
Luighi

[carloscl03]

Thanks Luighi — added tests/test_mimcap_build.py.

Your recollection is right, and it is exactly why this went unnoticed. mimcap_array calls the primitive with with_extension=False, so the array path never reaches the appendix code. Anyone checking the primitive through the array — which is how every cell in the suite uses it — sees it build cleanly. It is the direct mimcap(pdk, size) that goes down the other branch and raises. On main today:

mimcap(pdk, size=(5.0, 5.0))                        TypeError
mimcap(pdk, size=(5.0, 5.0), with_extension=False)  builds, 0 DRC violations
mimcap_array(pdk, rows=2, columns=2, size=(5.0,5.0)) builds, 0 DRC violations

There is a second condition worth knowing: the appendix branch is only entered when the requested size leaves min_via_distance < 0.4, so it also depends on the size. 5x5 reaches it, which is why the default arguments fail.

The test covers four things:

• the default path, with extensions, on both options — the one that regressed;
• the array path;
• the no-extension path, kept deliberately so a future fix that repairs one branch by breaking the other does not read as a pass;
• that each option draws the stack it names — A on met2/met3, B on met4/met5 — read back from the written GDS so it does not depend on which backend is active. Building both options is not enough on its own, since they differ only in the metals they draw.

Verified it discriminates: against main it fails 6, with the fix 4 tests and 8 subtests pass.

[carloscl03]

One more data point on this, from measuring the notebook CI on the fork.

The bug here is not confined to a direct mimcap() call — it breaks a tutorial. Running the suite on the gdstk backend, GLayout_Cells raises at mimcap.py:293 with exactly this TypeError. With this PR applied it builds and passes in 14.2s.

That matters because the notebooks job is currently the reason six of the eight open PRs show red: GLayout_Cells and glayout_opamp sit on the 180s per-cell limit and cross it depending on which runner the job lands, so the check flips on identical content. Moving the job to gdstk takes the whole suite from 660s to 158s and off the limit entirely — but only with this PR in, otherwise GLayout_Cells raises here instead of timing out.

Measured on this fork's CI, same container and runners: gdsfactory baseline · gdstk. Full table in #116.

The test added earlier still discriminates: 6 failures against main, 4 tests and 8 subtests passing with the fix.