Two bandgap voltage references are public now: gf180-bandgap and sky130-bandgap, each targeting a 1.20 V reference on an open PDK, GlobalFoundries' gf180mcu and SkyWater's sky130, designed end to end by AI agents. Not "AI-assisted." The agents wrote the spec, argued over it in decision records, sized the circuit against measured device data, and are now running it through temperature and process corners. Every step lives in the repo, so instead of asking you to trust the summary below, treat the summary as a set of pointers to where you can check it yourself.
The evidence trail is the point
gf180-bandgap's target spec is ratified: 1.20 V ±2% untrimmed and under 50 ppm/°C, both pinned to named process corners across −40 to 125 °C, plus PSRR above 60 dB from DC to 1 kHz. That last row is pinned to no corner: its load condition is TBD until the output stage is designed, and the table carries it as open amendment A4. It didn't start there.
The first draft claimed ±1% untrimmed. An expert-review pass measured the actual MOS-pair offset in this PDK (σ(ΔVgs) ≈ 1.12 mV), ran it through the amplifier's own gain, and showed that ±1% was arithmetically impossible given the circuit this design uses. The spec moved to ±2%, the correction recorded in a decision record with the math attached to the issue that forced it. That isn't a story about a number changing; it's a story about a spec agents can't quietly cheat.
sky130-bandgap's target spec is headed DRAFT, and the row it carries is 1.20 V ±1% untrimmed. That is gf180's pre-amendment number, the row the mismatch numbers above will not support. Its ratification is deliberately stuck open, but not for a missing number: the PNP-pair mismatch data it was deferred on landed on 2026-07-31, σ(ΔVBE) ≈ 0.480 mV at 1σ. What holds the ratification issue open is an operator ruling on whether that number can carry a ±1% row, the same rigor that caught gf180's arithmetic. A block that hasn't earned its own numbers yet doesn't get to claim them.
Below the spec, sim/suite/spec.py maps seven of the ratified table's twelve rows onto five testbenches. Each runs through a shared PVT-corner harness and lands an append-only record under sim/. Six carry an explicit numeric limit. The seventh, startup, deliberately does not: it wires in its own bench by slug and reports that bench's verdict rather than reimplementing the check. Running sim/run_suite.py prints pass or fail per spec line, so nothing above is a claim we're asking you to take on faith. sky130-bandgap is one step behind, six device-characterization testbenches in and building toward the same per-line suite before its own ratification.
The tool and the design argue with each other
Neither repo works alone. Both depend on klayout-tools, the open-source layout, DRC, and LVS driver underneath the whole flow. When gf180-bandgap's sim harness, schematic editor, and layout tooling each needed to know where the PDK was installed, and each had quietly reimplemented that lookup differently, that became a public friction issue against the tool instead of a private workaround. When the design needed a second opinion on its own spec, klayout-tools grew a spec-review capability to provide one, and that review is what produced the ±1%-to-±2% correction above: the tool improves because a block hit a wall, and the block improves because the tool grew past it.
Where things actually stand
Both blocks are in schematic and simulation, not layout. gf180-bandgap just closed out its error-amplifier offset budget and its Monte Carlo mismatch analysis; sky130-bandgap is still characterizing devices toward its own ratification. DRC, LVS, an actual GDS: none of that has started on either block. The klayout-tools gallery carries both as simulation-evidence cards rather than finished layouts, because that is what exists today.
Read the repos yourself: gf180-bandgap and sky130-bandgap. Watch the work land in real time on the fleet feed on the 2amlogic.com homepage. The next wave of blocks is already moving through the same audit gate behind these two; we'll write about it when it clears the same bar this one did.
Update, 2026-08-04
The section above was true when this note went out and stopped being true the next day. gf180-bandgap's block layout landed on 2026-08-01, DRC clean on the commit that drew it. Its DRC report from 2026-08-03 reads status: clean with violation_count: 0 over twelve checked layers. Eleven more drawn layers carry no rule at all. The LVS run ten seconds after it matches 156 of 156 devices and 92 of 92 nets under fourteen warnings.
sky130-bandgap drew its first layout on 2026-08-03. Its routed core, record 20260804-113412-4fb2a3a, is DRC clean with 9 of 12 schematic inter-block nets fully drawn and an LVS mismatch_count: 92. Device correspondence came back when #72 closed on 2026-08-04.
On 2026-08-04, twenty-four bench directories on gf180 hold 113 append-only records. sky130's six device-characterization benches have become nineteen, holding 34. The ratification gate has not moved with them: #1 and #32 are open on the same operator ruling, not on a missing number.
On 2026-08-04, sky130-bandgap's own README describes layout as not started, over a tree that carries a routed core. Status prose goes stale faster than the tree it describes. This note went stale in a day.