In software development, the idea that code should be tested automatically on every commit is so foundational that a project without a CI pipeline is treated as technically undisciplined. The CI pipeline runs the test suite, reports failures, and blocks merges when tests fail — before any human reviewer sees the change. This discipline exists because software bugs compound: untested changes accumulate, and debugging problems in a heap of mixed changes is far more expensive than catching each problem at the moment of introduction.
PIC design has an analogous problem. A design team iterates through layout revisions over weeks or months. At each revision, new cells are placed, routing is adjusted, PDK cell versions change. Verification checks that were run on an earlier revision are stale — the layout has changed, and no one has confirmed that the new revision still passes all checks. The tape-out submission is the functional equivalent of a software release, and it happens with far less automated testing than any equivalent software release would tolerate.
Applying CI/CD principles to PIC tape-out doesn't require replacing existing EDA tools — it requires wiring them into an automated pipeline that runs on every significant design revision.
What a PIC Design Review Pipeline Looks Like
A practical CI/CD pipeline for PIC tape-out has three mandatory gates and several optional ones. The mandatory gates are the checks that should block tape-out if they fail; the optional ones generate warnings that are reviewed but don't necessarily block submission.
Gate 1: Geometric DRC
Standard geometric DRC against the PDK rule deck. This is the baseline check that most teams already run, though not always in a fully automated pipeline. DRC must complete with zero violations to pass this gate. Any warning-class violations must be reviewed and explicitly waived with documentation. This gate is already supported by KLayout's DRC engine and by commercial EDA platforms — the CI integration piece is making it run automatically and report structured results.
Gate 2: Photonic LVS
Layout-versus-schematic comparison between the GDS-II layout and the reference schematic or netlist. This verifies that optical connectivity matches intent — that the circuit that was designed is the circuit that was drawn. Unlike CMOS LVS, photonic LVS must account for optical port attributes (width, layer, polarization) in addition to connectivity. A mismatch here blocks tape-out. This gate is less commonly automated than DRC in current PIC flows, representing the main gap that photonic EDA tools like Photoniq address.
Gate 3: Optical rule checks
The photonic-specific checks: mode mismatch at junctions, coupling gap compliance, taper length and angle compliance, proximity cross-talk risk, fiber coupler geometry. These checks go beyond what LVS verifies (connectivity) and validate that the geometric parameters of optical components satisfy the PDK's optical performance specifications. Violations with high severity block tape-out. Low-severity violations generate warnings that require engineer sign-off.
Version Control as the Foundation
A CI pipeline requires a versioned artifact to run against. For PIC design, this means the GDS-II file and the reference schematic must be committed to version control on each design iteration. This is not common practice in all design teams, partly because GDS-II files are binary format with poor diff readability, and partly because EDA environments don't always integrate naturally with Git.
The practical solution: treat each tape-out-candidate revision as a tagged release in the version control system. The CI pipeline triggers on new tags. The GDS-II file is stored in the repository (binary files in Git LFS if needed); the schematic is stored as a text-format netlist (SPICE format, or an open-text optical schematic format). The pipeline reads both files, runs all three gate checks, and produces a structured report.
Even without full continuous integration (running checks on every commit), periodic automated verification runs on tagged revisions provide substantially better coverage than manual pre-tape-out checks. A team that verifies every weekly snapshot of the layout catches design drift before it accumulates into a complex-to-debug multi-revision problem.
Structuring the Pipeline: A Practical Example
A GitHub Actions workflow for a PIC tape-out pipeline might look like this:
name: PIC Tape-Out Verification
on:
push:
tags:
- 'tape-out-candidate-*'
jobs:
verify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
lfs: true
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: '3.11'
- name: Install KLayout and verification tools
run: |
pip install klayout photoniq-sdk
- name: Run DRC
run: |
klayout -b -r drc/pdk_drc.py \
-rd input=layout/chip_rev3.gds \
-rd pdk=pdk/imec_isipp50g.json \
-rd output=reports/drc_report.xml
- name: Run Photoniq verification
run: |
photoniq verify \
--gds layout/chip_rev3.gds \
--netlist schematic/chip_rev3.spi \
--pdk pdk/imec_isipp50g.json \
--output reports/photoniq_report.json
- name: Check for blocking violations
run: |
python scripts/check_violations.py \
--report reports/photoniq_report.json \
--fail-on severity=HIGHThe check_violations.py script reads the structured JSON report and exits with a non-zero status if any high-severity violations are present — which causes the GitHub Actions job to fail, blocking merge or tagging. Low-severity violations produce warnings but don't block. The pipeline uploads the full report as an artifact, so engineers can review all violations, not just the blocking ones.
Report Structure for Pipeline Integration
For CI integration to work effectively, the verification report must be machine-readable. A JSON report with a consistent schema enables automated parsing, historical tracking, and comparison between revisions. The report should include, for each violation:
violation_id— unique identifier for this check typeseverity— HIGH / MEDIUM / LOW / INFOcell— GDS cell path where the violation occurscoordinate— GDS coordinates of the violation pointcheck_type— the rule that was violated (e.g.,MODE_MISMATCH,COUPLING_GAP_VIOLATION)message— human-readable descriptionpdk_version— the PDK rule deck version the check was run against
With this structure, a team can build a dashboard that shows violation trends across design revisions — how many violations of each type existed at each revision tag, and whether the count is trending toward zero as the design approaches tape-out readiness. Violation counts that are stable or increasing over multiple revisions indicate a systemic issue that needs direct intervention, not just incremental layout cleanup.
Where CI/CD Doesn't Translate Directly
We're not saying PIC design CI is equivalent to software CI in all dimensions. Several important differences limit how directly software testing paradigms apply.
First, PIC verification is not unit-testing. You cannot test each optical component in isolation the way you unit-test a function. Optical components interact with their context — the mode they receive, the coupling gap to their neighbors, the path length before them — in ways that only manifest at the circuit level. A component that passes all individual checks can still produce poor circuit-level performance due to coherent interference effects or cascaded loss accumulation.
Second, the "test suite" is not developer-authored for each design. The verification rule deck is the PDK's specification, maintained by the foundry, not the design team. Adding design-team-specific checks (e.g., "this design requires all coupling gaps to be above 200 nm, not just the PDK minimum of 180 nm") requires explicitly extending the rule deck for the specific design's requirements — a layer of customization that most teams don't currently maintain.
Third, the GDS-II file is not always cleanly versioned. Binary format, EDA tool-specific hierarchies, and the friction of committing large files to version control create practical barriers to full continuous integration. Teams that work around these barriers — using text-format schematic representations, GDS-diff tools, or periodic (rather than per-commit) automated verification — still get most of the benefit at lower infrastructure cost.
Starting Without Full Automation
The most important principle from CI/CD applied to PIC tape-out is not automation per se — it's systematic verification at defined checkpoints, with results that gate progression. A team that manually runs three verification checks at each weekly design review, records the results, and treats violations as blocking items for the next revision has implemented the substance of the CI principle, even without a GitHub Actions pipeline.
Full automation — scripted pipeline, JSON reports, violation trending dashboard — is the endpoint worth building toward. But the discipline of "verification runs before every significant design decision, not just before tape-out" is the behavioral change that captures most of the value. The automation makes that discipline sustainable at scale and across team members with varying attention to verification detail.
For teams running 2–4 tape-outs per year on multi-project wafer slots, the investment in a semi-automated pipeline pays back on the first tape-out that passes cleanly because a coupling gap violation was caught and fixed three revisions before submission, rather than discovered at characterization.