Skip to content

via_stack argument shape diverges from gdsfactory generic via_stack #217

Description

@thanojo

Problem

ihp.cells.via_stack (ihp/cells/via_stacks.py) and gdsfactory's generic
gdsfactory.components.vias.via_stack (reused by most other PDKs) take
structurally different arguments for the same job:

  • gdsfactory: via_stack(size=(11,11), layers=("M1","M2","MTOP"), layer_offsets=None, vias=("via1","via2",None), layer_to_port_orientations=None, correct_size=False, slot_horizontal=False, slot_vertical=False, port_orientations=(180,90,0,-90))
  • IHP: via_stack(bottom_layer="Metal1", top_layer="Metal2", size=(10,10), vn_columns=2, vn_rows=2, vt1_columns=1, vt1_rows=1, vt2_columns=1, vt2_rows=1, layer_activ=..., ...20 layer_* kwargs)

Anyone porting code between IHP and other gdsfactory PDKs has to rewrite
every via_stack(...) call by hand.

Proposal

Rework IHP's via_stack (ihp/cells/via_stacks.py) to accept gdsfactory's
argument names/order as primary, keeping IHP's bottom_layer/top_layer/
vn_/vt_* convenience as keyword-only extras after them.

Mutually exclusive alternative

A companion issue/PR on gdsfactory/gdsfactory proposes the opposite
direction: teach the generic via_stack to accept bottom_layer/top_layer
IHP-style, with a deprecation fallback for the old positional call shape.
Only one of the two directions should ultimately land — see
gdsfactory/gdsfactory#4641

Metadata

Metadata

Assignees

Labels

enhancementNew feature or requestpdkPDK issuepdk:ihpPDK this issue belongs to

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions