ThVerg 1123f733bd sky130: use special_nfet_01v8 model for sub-0.42um nfets
The sky130 magic techfile splits nfet extraction on device width:

  device msubcircuit sky130_fd_pr__nfet_01v8 nfet,scnfet ... w>=0.42
  device msubcircuit sky130_fd_pr__special_nfet_01v8 scnfet ... w<0.42

ptx always emitted spice["nmos"], so every gate built from a
minimum-width device (drc["minwidth_tx"] = 0.36) was netlisted as
sky130_fd_pr__nfet_01v8 while magic extracted it as
sky130_fd_pr__special_nfet_01v8. netgen then reported a device class
mismatch in each such cell:

  Circuit 1: sky130_fd_pr__special_nfet_01v8 (1) | Circuit 2: (no matching element)
  Circuit 1: (no matching element)               | Circuit 2: sky130_fd_pr__nfet_01v8 (1)

The signed-off macros shipped in sky130A/libs.ref/sky130_sram_macros use
special_nfet_01v8 at this geometry, so this restores the naming those
were built with.

ptx now asks the technology for a narrow-device model, keyed by width.
Technologies that declare no such model are unaffected, and there is no
equivalent split for pfets so only the nmos is declared.

After this change pinv and pinv_dec report "Netlists match uniquely"
where they previously mismatched. Verified with ngspice that
special_nfet_01v8 resolves through sky130.lib.spice, so characterization
is unaffected.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01FcKSuKSchDEd7MqT8AffpN
2026-08-11 14:56:13 +02:00
2026-05-11 10:44:24 -07:00
2023-03-08 14:35:03 -08:00
2024-02-03 12:15:11 +01:00
2018-11-16 08:56:44 -08:00
2019-04-29 10:26:39 -07:00
2021-04-21 14:15:24 -07:00
2021-10-08 09:11:43 -07:00
2024-01-03 14:32:44 -08:00
2026-01-16 15:05:30 +01:00
2019-12-07 09:50:05 +10:30
2023-03-30 11:30:50 -07:00
2023-04-26 14:31:41 -07:00
2023-02-07 10:30:48 -08:00
2025-06-26 21:21:06 +02:00
2024-01-03 14:32:44 -08:00
2023-10-31 23:24:21 -07:00
2026-05-11 10:44:24 -07:00
2024-01-03 14:32:44 -08:00
2024-01-03 14:32:44 -08:00
2024-01-03 14:32:44 -08:00
2025-06-26 21:21:13 +02:00

OpenRAM

Python 3.5 License: BSD 3-clause PyPI - Downloads Open In Colab

An open-source static random access memory (SRAM) compiler.

What is OpenRAM?

OpenRAM is an award winning open-source Python framework to create the layout, netlists, timing and power models, placement and routing models, and other views necessary to use SRAMs in ASIC design. OpenRAM supports integration in both commercial and open-source flows with both predictive and fabricable technologies.

Documentation

Please see our documentation and let us know if anything needs updating.

Get Involved

Further Help

License

OpenRAM is licensed under the BSD 3-Clause License.

Publications

Contributors & Acknowledgment

  • Matthew Guthaus from VLSIDA created the OpenRAM project and is the lead architect.
  • James Stine from VLSIARCH co-founded the project.
  • Many students: Hunter Nichols, Michael Grimes, Jennifer Sowash, Yusu Wang, Joey Kunzler, Jesse Cirimelli-Low, Samira Ataei, Bin Wu, Brian Chen, Jeff Butera, Sage Walker

If I forgot to add you, please let me know!

S
Description
An open-source static random access memory (SRAM) compiler.
Readme BSD-3-Clause
79 MiB
Languages
Python 85%
Spice 7.3%
HCL 3.2%
HTML 3%
Makefile 0.5%
Other 0.7%