gt2n: add 2nm BSPDN platform with gcd and aes designs#4277
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces support for the GT2N PDK platform, a 2nm GAAFET technology with backside power distribution. It adds configuration and constraint files for the AES and GCD designs, platform-specific files (including LEF, layer maps, KLayout technology, PDN, and RC scripts), and updates the OpenROAD and Yosys submodules. The review feedback highlights minor typos in the README documentation and points out an inconsistency in the backside metal label layer mapping within the KLayout technology file (gt2.lyt).
mguthaus
force-pushed
the
bspdn-gt2n-pr
branch
5 times, most recently
from
c34583b to
2f2d14e
Compare
|
Very interesting! We're using asap7 today, is this something that is worth looking at now or is it too early? Can you say something to manage my expectations w.r.t. using this as a drop-in replacement for asap7? Wiring this up to bazel-orfs (which I use) should be easy enough. |
|
With only 71 std cells it isn't a very rich library. |
I see. asap7 can't do Kogge Stone because half adder variants aren't available, so buffers are used instead defeating the Kogge Stone optimization. |
|
There is one size of half-adder HAxp5_ASAP7_75t_R, do you mean the lack of size variants? |
Yes: so you get lots of buffers, which eats into the Kogge Stone advantage, which means that all those adder carry chain propagation tricks cluster around the same performance in graphs... Vt mitigates this a bit in a sense. |
|
@mguthaus You've played around with bazel-orfs, I had Claude create idiomatic support in GT2N azadnaeemi/GT2N#13 |
mguthaus
force-pushed
the
bspdn-gt2n-pr
branch
2 times, most recently
from
7ae1f3f to
d732616
Compare
|
@maliberty @oharboe You are correct that it is a functionally small library. One dimension that I did not include are the 10 different VTh variants in the library. While there aren't that many sizes, FinFETs are better off using VTh instead of multiple discrete fins. This would increase the commit by ~1MB+ to include those files, so I opted to just do the baseline. Should I add this? |
|
@mguthaus Perhaps you could try out my PR? If it is accepted, we could expand it to use everything in the gt2n repo without worrying about size, it is all there already, I suppose. |
|
@mguthaus it's the estimated routing congestion heatmap that triggered this, I suspect there are a few more places that needs to be aware of the backside metals. I should also clarify I'm not using ORFS. |
|
@gadfort Very possible. I'll check it out and fix when I can recreate it. |
|
@maliberty How do I fix this "Scan Code with pre commit triger" check fail? It seems it doesn't like the config.mk files for the new designs. |
I had to white-list the new platform |
|
Have you run these designs? gcd fails for me. At a minimum you need to add the platform but even then |
maliberty
left a comment
maliberty
left a comment
There was a problem hiding this comment.
Any reason to import just one Vt?
I did. They renamed this cell when I updated the LEF files, but I failed to update the GDS file. It did not give me an error though, which is interesting. I'll try to see why. |
Trying to keep the changes simple to start. |
|
@maliberty I made a boneheaded move after I updated a "fix" in the PDK (which split the tap cell into a fs and bs variant). The PDK has a bug and no GDS as you point out. I filed an issue with them azadnaeemi/GT2N#16 The second time I tested, I mistyped "DESGIN_CONFIG" so it defaulted to the nangate45 tech which unsurprisingly worked :) The CI didn't flag it because it wasn't added to CI yet. I'm now reverting to the old PDK until it can be fixed and adding the platform to the PUBLIC variable. After it is fixed, I also plan to add support for hybrid front- and back-side supply networks using the two tap cell variants. In this case, the power supply would come from the top-level IOs rather back-side bumps. It will also require some consideration of tap cell placement for the supply which is not yet done. |
Brings up the GT2N 2nm GAAFET PDK with buried-power-rail (BSPDN) and
runs gcd through it end-to-end with the OpenROAD changes on the
bspdn branch of tools/OpenROAD.
* flow/platforms/gt2n/ new platform:
config.mk top-level platform variables.
fastroute.tcl, pdn.tcl, setRC.tcl, tapcell.tcl, cells_clkgate.v
ORFS step config; PDN is BPR followpins
only (backside rails come from elsewhere).
lef/, lib/, gds/ copy of the GT2N tt w31 LVT collateral.
gt2.lyt, gt2.lyp KLayout tech + per-layer colors (rainbow
for front-side M0..M13 + RDL, warm/red
shades for backside BPR/BM*/BRDL).
gt2.layermap LEF layer -> GDS layer mapping.
LICENSE, README.md upstream attribution.
The local copy of gt2_6t_w31_lvt.lef carries a small authoring fix
on the gt2_6t_tap_w31_lvt cell: BPR shapes that were declared as
OBS are moved into a second PORT on each PG pin so the LEF
correctly encodes the M1<->BPR bridge. Suggested upstream as
azadnaeemi/GT2N#12.
* flow/designs/gt2n/gcd/ new design:
config.mk, constraint.sdc
* tools/OpenROAD bump to bspdn tip (0e7eabb59d) which adds
isBackside()/LEF58_BACKSIDE support and
filters backside layers out of DRT.
* tools/yosys pin to v0.64 release (6d2c445a) which
works around the Ubuntu 24.04 / glibc 2.39
yosys-abc pipe deadlock in newer SHAs.
* .gitignore whitelist flow/platforms/gt2n.
Verified: gt2n/gcd produces 6_final.{def,gds,odb,sdc,v}.
Signed-off-by: Matthew Guthaus <mrg@ucsc.edu>
Signed-off-by: Matthew Guthaus <mrg@ucsc.edu>
BPR followpins on their own do not stitch the per-row vdd/vss rails together, so the backside grid was a chain of disconnected horizontal strips. Add a two-layer perpendicular mesh (BM1 vertical, BM2 horizontal) plus BV0/BV1 connects, modeled on asap7's M5/M6 over M1/M2 followpin pattern. Top of the standard-cell grid is now BM2. Also adds resistance values for the backside cut layers (BV0..BV4) to setRC.tcl so PSM's analyze_power_grid does not error out with PSM-0021 when the PG network includes backside vias. Calls out that every RC value in this file is a placeholder, not silicon-calibrated. Verified end-to-end on gt2n/gcd: 873s wall time, 0 DRC violations, 0 ANT violations. Signed-off-by: Matthew Guthaus <mrg@ucsc.edu>
Upstream commit 42e1034 ("Update gt2_6t_w31_lvt.lef") moves the BPR
shapes on the tap cell from OBS to PORT (the issue The-OpenROAD-Project#12 fix we
needed), but in the same commit it also renames the macro
`gt2_6t_tap_w31_lvt` into a split `gt2_6t_tapfspdn_w31_lvt` /
`gt2_6t_tapbspdn_w31_lvt` pair in the LEF and lib. The matching GDS
cells for the new names were not added upstream
(azadnaeemi/GT2N#16), so the post-rename PDK is internally
inconsistent: the LEF/lib advertise two new tap-cell names, but
neither exists in the GDS, only the original `gt2_6t_tap_w31_lvt`
does. KLayout GDS-merge at the end of the flow cannot resolve the
tap instances and the final GDS is incomplete.
Keep the BPR PORT geometry from the upstream commit (this is the
fix we wanted) but undo the rename here: collapse the LEF macros
and lib cells back into a single `gt2_6t_tap_w31_lvt`, point
TAP_CELL_NAME and DONT_USE_CELLS at it, and update the README to
explain the situation and link to the upstream issue tracking the
GDS gap. Revisit once upstream The-OpenROAD-Project#16 is resolved.
Smoke: gt2n/gcd 2_3_floorplan_tapcell clean (110 endcaps + 28
tapcells inserted).
Signed-off-by: Matthew Guthaus <mrg@ucsc.edu>
Signed-off-by: Matthew Guthaus <mrg@ucsc.edu>
M5 was a conservative bring-up cap so routing did not have to deal with the full GT2N stack while we were stabilising the platform. The tech has frontside routing layers M0..M13 + RDL; M13 is the topmost regular routing layer (RDL is the redistribution / top-metal). Open up MAX_ROUTING_LAYER to M13 so larger designs can use the full BEOL. Verified end-to-end on gt2n/gcd: full flow through 6_final clean, final GDS produced, no DRC / antenna violations. Signed-off-by: Matthew Guthaus <mrg@ucsc.edu>
The platform was bringing up a single (w31, lvt) corner. Upstream 308b221 ships ten W/Vt combinations at tt 0.7V/25C: w13 (13 nm nanosheet) and w31 (31 nm), each in hvt / svt / lvt / ulvt / elvt. All ten use the same gt2_6t site (0.042 x 0.144) and the same tech LEF, so any subset of (W, Vt) tuples can coexist in a single block and synthesis can size + W/Vt-trade across the full menu. Vendor the nine new (W, Vt) triplets directly from upstream 308b221 (LEF + lib + GDS, all with the tap-cell split intact), and parameterise the platform config on two ordered lists modelled on asap7's ASAP7_USE_VT pattern: GT2N_USE_W nanosheet-width families to load. Default: 'w31'. GT2N_USE_VT Vt flavors to load. Default: 'lvt hvt svt ulvt elvt'. The first word of each list is the primary value. The (primary W, primary Vt) tuple drives canonical single-cell references (tap, tiehi/tielo, buffer, ABC driver); the rest of the Cartesian product rides along as additional LEF / lib / GDS so Yosys + ABC see every loaded sizing option. Includes the upstream lib refresh (default_operating_conditions, voltage_map, pg_pin annotations on every cell). Smoke: gt2n/gcd full flow clean, EXIT=0. Signed-off-by: Matthew Guthaus <mrg@ucsc.edu>
The platform ships both nanosheet widths (w13 = 13 nm sheet, w31 = 31 nm sheet) and they share the same gt2_6t site, so loading both into a single block costs nothing in placement and lets ABC pick across the full 2 W x 5 Vt = 10 (W, Vt) menu. Default GT2N_USE_W to "w31 w13" so every gt2n design sees the menu without having to override the list in each per-design config.mk. Single-width builds still work by setting GT2N_USE_W to "w31" or "w13" in the design config. Signed-off-by: Matthew Guthaus <mrg@ucsc.edu>
The C values in setRC.tcl were placeholders ("the ICT shipped with the
PDK does not contain extracted C ... should be replaced with values
from a calibrated RCX/QRC model before treating any C-derived quantity
as physical"). The R values were derived from Fig 1(b) of the GT2N
paper and were already grounded, but the via R was a fake "scaled
roughly by cut size" stand-in.
The PDK's StarRC ITF file (GT2N/nxtgrd/GT2.itf) carries enough physical
data to derive both R and C analytically: per-layer RPSQ, dielectric
thickness and permittivity above and below each conductor, conductor
thickness, WMIN, SMIN, and per-VIA RPV. Use those to compute:
R/um = RPSQ / WMIN
C/um = (Ca + Cb) * fringe_factor + 2 * Cc (fF/um, then to pF/um)
Ca = eps0 * eps_above * W / d_above
Cb = eps0 * eps_below * W / d_below
Cc = eps0 * eps_side * T_wire / SMIN
fringe_factor = 1.5x coarse fringe-field correction
Via R = RPV (single via, from ITF VIA entries)
itf_to_rc.py drops next to the platform so the derivation is
reproducible; setRC.tcl is its output rendered into set_layer_rc
commands plus the existing set_wire_rc selections.
These numbers are still approximate -- the proper fix is real RCX
extraction (run a 3D solver, e.g. FasterCap, against OpenRCX's pattern
DEFs and feed the resulting SPEF to OpenRCX generate_rules.tcl). The
ITF/NXTGRD/QRC files in GT2N/ carry everything that pipeline needs.
The analytical table is the working stand-in until those rules exist.
Smoke (gt2n/gcd full flow): clean, EXIT=0. Achieved core_clock period
moves from 373.6 ps (placeholder C) to 344.6 ps (analytical C); slack
goes from 106.8 ps to 137.3 ps. Lower C reduces wire delay, so timing
reports tighter -- consistent with the analytical C being ~33-60%
below the placeholder, which itself had no physical grounding.
Signed-off-by: Matthew Guthaus <mrg@ucsc.edu>
Default tapcell.tcl was using `-distance 5` (5 um between taps along each row), which is loose enough that small designs end up with a single tap column. The gt2n tap cell does double duty: it is both the well/body-bias tap (the conventional purpose) and the per-row M1<->BPR or sole BPR riser for the BSPDN power network -- each tap is the only hard via from the cell row's BPR rail into the BSPDN power source. Tap density therefore directly sets per-row BPR resistance and the worst-case BSPDN IR drop, which is not true in flows where taps only exist for latchup avoidance. Drop `-distance` to 2 um. On gt2n/gcd (4-5 um core side, 55 rows): -distance 5 2 tapcells 28 114 (+4x) vdd worst 10.9 mV 8.49 mV (-22%) vdd avg 2.62 mV 2.59 mV vss worst 7.25 mV 7.35 mV (essentially same, already well distrib) vss avg 2.27 mV 2.27 mV (IR numbers from analyze_power_grid on 6_final.odb with leakage-only currents -- absolute drop is small at this design size, but the worst-case-vdd improvement is what we expect from more BPR risers.) Detail-route runtime goes up roughly 3x because of the denser obstacle field, but converges cleanly to 0 DRC + 0 antenna. Signed-off-by: Matthew Guthaus <mrg@ucsc.edu>
Adds jpeg_encoder as a larger reference benchmark alongside gcd and aes -- representative of designs that meaningfully exercise the upper-stack routing layers and the multi-W / multi-Vt library menu. config.mk mirrors the asap7 / nangate45 jpeg configurations (ABC_AREA=1, TNS_END_PERCENT=100, conservative CORE_UTILIZATION). constraint.sdc uses a 1500 ps clock as a first-pass loose target; period_min lands around 950 ps so the design has substantial headroom to tighten once OpenRCX rules replace the analytical RC. Signed-off-by: Matthew Guthaus <mrg@ucsc.edu>
The platform exposes metal up to M13, but the reference designs route well below that (gcd uses up to M5, jpeg M9, aes M10; layers above carry no wire). Pinning MAX_ROUTING_LAYER at the platform M13 top forced detailed routing to build its grid graph, via stack, and DRC checks across the full layer range for every design, inflating runtime and memory. Move MAX_ROUTING_LAYER out of the platform config (leaving a comment) and set it per design at the highest layer each actually uses. gcd@M5 was verified to route DRC-clean; aes/jpeg caps only drop layers that carry zero wire. Signed-off-by: mrg <mrg@ucsc.edu>
4 participants
Adds the GT2N 2 nm GAAFET PDK to ORFS as a new platform, with two reference designs (
gcd,aes) routed end-to-end.GT2N is an open-source process-aware 2 nm nanosheet PDK developed at Georgia Tech / Synopsys / Samsung (Jang et al., IEEE APCCAS 2024, https://github.com/azadnaeemi/GT2N). The collateral here is the
tt 0.7 V 25 Ccorner of the W31 LVT 6T library, used unchanged except for one authoring fix on the tap cell (gt2_6t_tap_w31_lvt): BPR shapes that were declared asOBSare moved into a secondPORTon each PG pin so the LEF correctly encodes the M1↔BPR bridge (suggested upstream asazadnaeemi/GT2N#12).What's in the PR
flow/platforms/gt2n/— config, LEF/Lib/GDS, KLayout.lyp/.lyt,.layermap, PDN/RC/tapcell scripts, LICENSE/README.flow/designs/gt2n/gcd/,flow/designs/gt2n/aes/— config + SDC.tools/OpenROAD→a44e99193f(= upstream master HEAD, includes the merged LEF58_BACKSIDE / BSPDN support from The-OpenROAD-Project/OpenROAD#10547).Platform architecture
BSPDN-style: every standard cell's
vdd/vsspin lives onBPR(backside, markedLEF58_BACKSIDE). The PDN is therefore backside-only:BPRfollowpins (pitch 144 nm) sit directly under each row, overlapping the cell's BPR pin → power gets to the device through the cell's intrinsic nano-TSV / WAC structure modelled in the PDK (per Jang et al. §II.A).BM1mesh perpendicular to BPR, connected viaadd_pdn_connect BPR BM1.BM2mesh perpendicular to BM1, declared as the grid's top pin, connected viaadd_pdn_connect BM1 BM2.All three
add_pdn_connectrules are backside-only by design; the PDN-1200 cross-side guard added in OpenROAD#10547 stays silent. There are no chip-level TSVs or bridge cells in this configuration — that's intentional, matching the paper's architecture.Signal routing is the frontside stack
M2..M5(MIN_ROUTING_LAYER/MAX_ROUTING_LAYER); frontside metals aboveM5and the entire backside stack are excluded from signal routing.Verification
make … 5_2_routeclean (13 min wall, 2.2 GB peak, 0 violations, 0 antenna violations).make … 5_2_routeclean (1 h 39 min wall, 10.7 GB peak, 0 violations).make … 2_4_floorplan_pdnongcdruns clean (2 s, BPR followpins + BM1/BM2 mesh inserted by PDN without warnings).Notes
.liband 4 802-line.lefare the upstream GT2N library payload, not authored here. Licensing matches the upstream (BSD-style; seeflow/platforms/gt2n/LICENSE).setRC.tcluses placeholder values for the backside layers and vias — the upstream PDK does not ship extracted backside RC. The values are scaled like the frontside (V0..V4) so timing isn't pathologically off.gcdandaes.