View in English

v0.5 릴리즈 노트

주요 내용

v0.5에서는 기존 gdstk backend와 함께 선택 가능한 KLayout Python API backend를 도입했습니다.

목표는 downstream workflow를 바꾸지 않은 상태에서 pya가 동일한 layout extraction 동작을 재현할 수 있는지 확인하는 것이었습니다.

GDS/OAS
    -> layout backend
    -> polygon extraction
    -> existing width / space, raster, aerial image, contour, and preview flow

구현 요약

v0.5에서는 layout loading과 polygon extraction을 위한 backend 경계를 추가했습니다.

주요 변경 사항은 다음과 같습니다.

• gdstk는 기본 backend로 유지했습니다.
• pya를 선택 가능한 비교 backend로 추가했습니다.
• Downstream contract는 계속 list[gdstk.Polygon]을 사용했습니다.
• 이 단계에서는 width/space check, rasterization, aerial-image 생성, contour 추출, preview rendering, GDS writing을 다시 작성하지 않았습니다.
• Backend는 LAYOUT_BACKEND 환경 변수로 선택했습니다.

평가 요약

공개 예제 tt04_pwm.gds의 layer/datatype 68/20에서 gdstk와 pya가 추출한 polygon set은 수치 오차 범위 내에서 일치했습니다.

Downstream ROI 선택은 순서에 민감하고 pya traversal order가 gdstk와 반드시 같지는 않으므로 service ROI 위치는 달라질 수 있었습니다. 이는 추출된 target geometry가 아니라 sampling된 ROI 위치의 차이입니다.

Runtime 및 Render 검토

로컬 비교에서는 테스트한 사례의 raw extraction에 gdstk가 더 빨랐으며, pya는 compatibility 및 validation 경로로 유용했습니다.

독립 klayout package가 gdstk보다 큰 native wheel을 추가하므로 Render compatibility도 검토했습니다. 이에 따라 build time과 slug size 증가 가능성을 고려했습니다.

v0.5 권장 Backend

이 단계의 권장 backend는 gdstk였습니다.

이유는 다음과 같습니다.

• 테스트한 geometry에서 pya와 결과가 일치했습니다.
• 로컬 extraction 비교에서는 gdstk가 더 빨랐습니다.
• gdstk는 이미 배포된 상태였습니다.
• pya를 optional backend로 유지하면 비교 경로를 보존하면서 배포 위험을 줄일 수 있었습니다.

남은 한계

• 로컬 비교에서 pya raw extraction이 더 느렸습니다.
• Backend 간 polygon traversal order가 달랐습니다.
• Downstream contract가 gdstk.Polygon을 기대하므로 hole이 있는 복잡한 polygon은 주의가 필요했습니다.
• OAS는 pya.Layout.read를 통해 연결했지만 sample에서 충분히 비교하지 않았습니다.

관련 페이지

• 릴리즈 노트
• v0.4 릴리즈 노트
• v0.6 릴리즈 노트
• 방법론