feat: add inline schematic functions for all 23 device cells

[ThomasPluck]

Summary

• Adds DSchematic functions inline in each cell file, linked via @gf.cell(schematic_function=...) decorator
• Each schematic function populates tags, symbol, ports (directional mapping), and models (SPICE metadata with sections, port_order, and computed params)
• Removes c.info["vlsir"] blocks from layout cell bodies — metadata now lives exclusively in the schematic layer

Cells updated (23 across 7 files)

• fet_transistors.py: nmos, pmos, nmos_hv, pmos_hv
• rf_transistors.py: rfnmos, rfpmos, rfnmos_hv, rfpmos_hv
• bjt_transistors.py: npn13G2, npn13G2L, npn13G2V, pnpMPA
• resistors.py: rsil, rppd, rhigh
• capacitors.py: cmim, rfcmim
• passives.py: svaricap, esd_nmos, ptap1, ntap1
• antennas.py: dantenna, dpantenna

Test plan

• Verify @gf.cell(schematic_function=...) decorator is forwarded once upstream fix lands
• Run pytest tests/ -x to confirm no regressions
• Validate SPICE model params match original vlsir metadata for each device

🤖 Generated with Claude Code

Summary by Sourcery

Introduce inline schematic definitions for IHP device cells and migrate simulation metadata from layout components to the schematic layer.

New Features:

• Add DSchematic-based schematic functions for core MOSFET, BJT, varicap, ESD, resistor, capacitor, antenna, tap, and bondpad cells, wired through the gf.cell schematic_function hook.
• Define schematic functions for fixed GDS cells to provide tags, symbols, ports, and SPICE model metadata without embedding it in the layout components.

Enhancements:

• Centralize device SPICE model metadata in schematic definitions and remove legacy vlsir blocks from component.info across the library.
• Simplify the codebase by deleting the primitives schematic-only module and the VLSIR export bridge, and by updating documentation to reflect the new schematic-based flow.
• Update the gdsfactory dependency to a newer compatible version and adjust internal helper scripts to align with the removal of VLSIR primitives.

Build:

• Adjust project dependencies in pyproject.toml by dropping vlsir and vlsirtools and bumping the minimum gdsfactory version.

Documentation:

• Update the README to remove references to the deprecated VLSIR bridge and primitive schematic-only elements, describing models as SAX-only.

Tests:

• Remove VLSIR-specific tests and fixtures, including validation and export tests, and simplify YAML snapshots now that vlsir metadata is no longer stored on components.

[sourcery-ai]

Reviewer's Guide

Introduce DSchematic-based inline schematic functions for all device and fixed cells, wire them through the gf.cell(schematic_function=...) decorator, and remove legacy vlsir-based simulation metadata and tests in favor of schematic-layer SPICE models.

Sequence diagram for creating a cell with gf.cell and DSchematic-based schematic

sequenceDiagram
  actor User
  participant GFCellDecorator as gf_cell_decorator
  participant LayoutCell as nmos
  participant SchematicFn as nmos_schematic
  participant DS as DSchematic
  participant LayoutComp as gf_Component
  participant Simulator as spice_simulator

  User->>GFCellDecorator: call nmos(width, length, nf, m)
  GFCellDecorator->>LayoutCell: invoke layout body
  LayoutCell-->>GFCellDecorator: return LayoutComp (GDS layout)

  Note over GFCellDecorator,SchematicFn: When schematic is needed (netlisting/schematic view)
  GFCellDecorator->>SchematicFn: call nmos_schematic(width, length, nf, m)
  SchematicFn->>DS: DSchematic()
  SchematicFn->>DS: set info.tags, info.symbol
  SchematicFn->>DS: set info.ports (directional mapping)
  SchematicFn->>DS: set info.models (SPICE metadata)
  SchematicFn->>DS: create_port(D, G, S, B)
  DS-->>SchematicFn: DSchematic instance
  SchematicFn-->>GFCellDecorator: DSchematic instance

  GFCellDecorator-->>User: LayoutComp (with associated schematic_function)

  User->>Simulator: request simulation for nmos instance
  Simulator->>DS: read models, port_order, params
  Simulator-->>User: SPICE results based on schematic-layer metadata

Loading

Class diagram for gf.cell-decorated layout cells and DSchematic-based schematics

classDiagram
  class GFCellDecorator {
    +schematic_function: function
    +__call__(cell_function)
  }

  class DSchematic {
    +info: dict
    +create_port(name, cross_section, x, y, orientation)
  }

  class LayoutCell_nmos {
    +width: float
    +length: float
    +nf: int
    +m: int
    +__call__(width, length, nf, m) gf.Component
  }

  class Schematic_nmos {
    +width: float
    +length: float
    +nf: int
    +m: int
    +__call__(width, length, nf, m) DSchematic
  }

  class LayoutCell_rfnmos {
    +width: float
    +length: float
    +nf: int
    +m: int
    +__call__(width, length, nf, m, cnt_rows, met2_cont, gat_ring, guard_ring) gf.Component
  }

  class Schematic_rfnmos {
    +width: float
    +length: float
    +nf: int
    +m: int
    +cnt_rows: int
    +met2_cont: bool
    +gat_ring: bool
    +guard_ring: str
    +__call__(width, length, nf, m, cnt_rows, met2_cont, gat_ring, guard_ring) DSchematic
  }

  class LayoutCell_cmim {
    +width: float
    +length: float
    +__call__(width, length) gf.Component
  }

  class Schematic_cmim {
    +width: float
    +length: float
    +__call__(width, length) DSchematic
  }

  class SchematicModels {
    +language: str
    +name: str
    +spice_type: str
    +library: str
    +sections: list
    +port_order: list
    +params: dict
  }

  class LegacyVlsirMetadata {
    -model: str
    -spice_type: str
    -spice_lib: str
    -port_order: list
    -port_map: dict
    -params: dict
  }

  GFCellDecorator --> LayoutCell_nmos : decorates
  GFCellDecorator --> LayoutCell_rfnmos : decorates
  GFCellDecorator --> LayoutCell_cmim : decorates

  GFCellDecorator --> Schematic_nmos : schematic_function
  GFCellDecorator --> Schematic_rfnmos : schematic_function
  GFCellDecorator --> Schematic_cmim : schematic_function

  Schematic_nmos --> DSchematic : returns
  Schematic_rfnmos --> DSchematic : returns
  Schematic_cmim --> DSchematic : returns

  DSchematic "1" o-- "*" SchematicModels : models

  LayoutCell_nmos .. LegacyVlsirMetadata : c.info.vlsir removed
  LayoutCell_rfnmos .. LegacyVlsirMetadata : c.info.vlsir removed
  LayoutCell_cmim .. LegacyVlsirMetadata : c.info.vlsir removed

Loading

File-Level Changes

Change	Details	Files
Add DSchematic-based schematic factory functions for MOSFET, RF MOS, BJT, passive, ESD, tap, resistor, capacitor, antenna, and bondpad cells and connect them via gf.cell(schematic_function=...).	Import DSchematic and define a shared metal1_routing cross-section constant in each updated cell module. Implement parameterized schematic_* or *_fixed_schematic functions that construct DSchematic objects with info tags, symbols, directional port groupings, and SPICE model metadata including library, sections, port_order, and param expressions. Create DSchematic electrical ports with standardized naming and orientation for each device family. Annotate existing layout cell factories with gf.cell(schematic_function=...) to bind layout and schematic views while leaving geometry generation unchanged.	ihp/cells/fet_transistors.py ihp/cells/rf_transistors.py ihp/cells/bjt_transistors.py ihp/cells/passives.py ihp/cells/resistors.py ihp/cells/capacitors.py ihp/cells/antennas.py ihp/cells/bondpads.py ihp/cells/fixed.py
Migrate simulation metadata from Component.info['vlsir'] to schematic-layer models and remove the legacy VLSIR bridge and tests.	Delete all c.info['vlsir'] assignments from layout cell implementations and fixed GDS wrappers; equivalent SPICE model names, port orders, libraries, and parameters now live in DSchematic.info['models']. Remove vlsir and vlsirtools dependencies and the models/to_vlsir.py bridge plus schematic-only primitives in ihp/cells/primitives.py. Drop vlsir-focused tests, including metadata validation and to_proto/to_spice tests, and update YAML golden files to no longer assert on vlsir info blocks (info now mostly empty or adjusted). Tighten the .github/write_cells.py exclusion list and README to reflect removal of schematic-only primitives and the VLSIR export path.	ihp/models/to_vlsir.py ihp/cells/primitives.py tests/test_cells.py tests/test_cells/test_settings_*.yml README.md .github/write_cells.py pyproject.toml

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• Several schematic functions accept a model argument (e.g., nmos_schematic, cmim_schematic, esd_nmos_schematic) but ignore it and hardcode the SPICE name field; either use the parameter to select the model or drop it to avoid confusion.
• The _XS = "metal1_routing" constant is duplicated across multiple modules; consider defining this once in a shared place (or pulling from TECH if appropriate) to avoid divergence between files.
• There is a lot of nearly identical boilerplate in the new *_schematic functions (tags/symbol/ports/model structure/port creation); consider introducing small helpers or factories for MOS/BJT/passive schematics to reduce repetition and the chance of inconsistent metadata.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Several schematic functions accept a `model` argument (e.g., `nmos_schematic`, `cmim_schematic`, `esd_nmos_schematic`) but ignore it and hardcode the SPICE `name` field; either use the parameter to select the model or drop it to avoid confusion.
- The `_XS = "metal1_routing"` constant is duplicated across multiple modules; consider defining this once in a shared place (or pulling from `TECH` if appropriate) to avoid divergence between files.
- There is a lot of nearly identical boilerplate in the new `*_schematic` functions (tags/symbol/ports/model structure/port creation); consider introducing small helpers or factories for MOS/BJT/passive schematics to reduce repetition and the chance of inconsistent metadata.

## Individual Comments

### Comment 1
<location path="ihp/cells/fet_transistors.py" line_range="511-520" />
<code_context>
 # Public cell functions
 # ---------------------------------------------------------------------------
-@gf.cell
+def nmos_schematic(
+    width: float = 0.15,
+    length: float = 0.13,
+    nf: int = 1,
+    m: int = 1,
+    model: str = "sg13_lv_nmos",
+) -> DSchematic:
+    s = DSchematic()
+    s.info["tags"] = ["transistor", "mos", "lv"]
+    s.info["symbol"] = "nmos"
+    s.info["ports"] = {"left": ["G"], "right": ["D", "S"], "bottom": ["B"]}
+    s.info["models"] = [
+        {
+            "language": "spice",
+            "name": "sg13_lv_nmos",
</code_context>
<issue_to_address>
**suggestion (bug_risk):** The `model` parameter is not reflected in the schematic model definition, which can cause mismatches when users override it.

In `nmos_schematic` (and the other new `*_schematic` helpers), the `model` argument is accepted but the SPICE model is still hard-coded to `"sg13_lv_nmos"` in `s.info["models"]`. Any non-default `model` passed by callers is therefore ignored.

To make the API consistent, either:
- use `model` for the `name` field (with the current value as the default), or
- remove `model` from the signature if overriding it is not supported.

The same fix should be applied consistently to the other schematic helpers (PMOS, HV devices, RF MOS, varicap, ESD, resistor, capacitor, etc.).

Suggested implementation:

```python
    s.info["models"] = [
        {
            "language": "spice",
            "name": model,

```

Apply the same pattern to all other `*_schematic` helper functions in this file (and related files if present):

1. Ensure each helper that accepts a `model: str = "..."` parameter uses that parameter for the SPICE model name, i.e. replace any hard-coded `"name": "some_model_name"` with `"name": model`.
2. Confirm the default value of `model` in the function signature matches the existing hard-coded model name to preserve current behavior for callers that do not override it.
3. If any schematic helper does not intend to support model overriding, remove the unused `model` parameter from its signature instead of wiring it through.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[ThomasPluck]

@sebastian-goeldi to fix schematic_function kwarg in cell decorator issue

[pepijndevos]

I don't think these are the right library and corners for many of these models

[pepijndevos]

In my PR I started a guide for LLMs to do this accurately
https://github.com/gdsfactory/IHP/pull/116/changes#diff-7ea36bdf0b626bbbb77c515d561cc9c23dca190060d7de12920ebebf5ac9719e

In particular for IHP you need the corner files as the top level to set up the properties correctly and you need to use whatever section is actually in that file eg mos_tt

[ThomasPluck]

Probably not, point is to lay the foundation, get everyone on the same page about PDK modifications.

[ThomasPluck]

@pepijndevos please review that you're happy with corner data and then merge.

[ThomasPluck]

As per gdsfactory/gdsfactory#4455 - this seems to be the way to go, going to close out #116 and work to get this inline with GF 9.39.3 and tests/pre-commit passing

[ThomasPluck]

Latest push: VLSIR removal + schematic metadata cleanup

Building on the initial schematic function work, the latest commit (78c4f03) completes the migration:

Removed

• ihp/cells/primitives.py — schematic-only elements (R, L, C, sources, controlled sources, tline, subckt) are now handled in the schematic editor
• ihp/models/to_vlsir.py — VLSIR bridge no longer needed
• vlsir and vlsirtools dependencies dropped from pyproject.toml
• All associated tests (test_vlsir_to_proto, test_vlsir_to_spice, TestVlsirValidationErrors), regression YAMLs, and GDS refs for primitives cells

Updated

• gdsfactory pinned to >=9.39.3 (the minimum version that correctly exposes schematic_function kwarg)
• ~32 deprecated fixed.py cells and bondpads.py migrated from c.info["vlsir"] to @gf.cell(schematic_function=...) pattern
• write_cells.py and README.md cleaned of primitives/VLSIR references
• Test regression YAMLs regenerated

Verification

• 888 tests pass, 0 failures
• All 11 pre-commit hooks pass

[sourcery-ai]

Hey - I've left some high level feedback:

• Several schematic factories have mismatches between info['ports'], the ports created on the DSchematic, and the models[...]['port_order'] (e.g. svaricap_schematic defines a BN port but omits it from ports, and rsil_schematic/rppd_schematic/rhigh_schematic include bn in port_order but never create a corresponding port); please align the declared ports and port_order for all devices so layout/schematic/export stay consistent.
• The D/G/S/B (and some other) ports use orientations that don't match their geometric positions in several schematics (e.g. D at y=1 with orientation 180, S at y=-1 with orientation 0); it would be clearer and less error‑prone to standardize orientations (e.g. top=90, bottom=270, left=180, right=0) across all DSchematic definitions.
• In bondpad_schematic (and a few others) model parameters are encoded as Python expressions in strings (e.g. "shape": '{"octagon": 0, "square": 1, "circle": 2}[shape]'); consider normalizing these to concrete values inside the schematic function so downstream consumers of the SPICE metadata don't need to evaluate Python code embedded in strings.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Several schematic factories have mismatches between `info['ports']`, the ports created on the DSchematic, and the `models[...]['port_order']` (e.g. `svaricap_schematic` defines a `BN` port but omits it from `ports`, and `rsil_schematic`/`rppd_schematic`/`rhigh_schematic` include `bn` in `port_order` but never create a corresponding port); please align the declared ports and `port_order` for all devices so layout/schematic/export stay consistent.
- The D/G/S/B (and some other) ports use orientations that don't match their geometric positions in several schematics (e.g. D at y=1 with orientation 180, S at y=-1 with orientation 0); it would be clearer and less error‑prone to standardize orientations (e.g. top=90, bottom=270, left=180, right=0) across all DSchematic definitions.
- In `bondpad_schematic` (and a few others) model parameters are encoded as Python expressions in strings (e.g. `"shape": '{"octagon": 0, "square": 1, "circle": 2}[shape]'`); consider normalizing these to concrete values inside the schematic function so downstream consumers of the SPICE metadata don't need to evaluate Python code embedded in strings.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[ThomasPluck]

Addressed Sourcery feedback

All three items from the second Sourcery review are resolved in 387c20c:

1. Port mismatches — aligned info["ports"], create_port, and port_order

• BJTs (npn13G2, npn13G2L, npn13G2V): Added missing "top": ["BN"] to info["ports"]
• svaricap: Added "top": ["BN"] to info["ports"], fixed port_order case "bn" → "BN"
• rfcmim: Added BN port creation + "bottom": ["BN"] to info["ports"], fixed port_order case
• Resistors (rsil, rppd, rhigh): Added BN port + "right": ["BN"] to info["ports"], aligned port_order to DSchematic names (["P1", "P2", "BN"])

2. Orientations standardized: top=90, bottom=270, left=180, right=0

All 8 FET/RF-FET schematics corrected (D, G, S, B had swapped orientations).

3. Bondpad shape param normalized

Replaced embedded Python dict expression with concrete evaluation: str({"octagon": 0, "square": 1, "circle": 2}[shape]) → produces "0", "1", or "2".

---

The first review items were already addressed in earlier commits:

• model param: Removed from all schematic function signatures (kept only in layout functions where it's used)
• _XS duplication / boilerplate: Noted, will consider consolidation in a follow-up

[joamatab]

docs still fail

[pepijndevos]

We need to change the ports to the new format i can do it tomorrow morning and maybe look at what's up with the docs

[ThomasPluck]

Got off a call with JKU today, it seems to a pretty common complaint that the pcells are directional. There is a solution to this in kf.Pin() - idk if there's time or bandwidth for this, however.

[pepijndevos]

Wdym directional?

[ThomasPluck]

Ports have an orientation in GDSFactory, this is enforced by gdsfactory's own routers which causes headaches.