Tape-Out & Mask Data Prep

Tapeout Support Services for Clean Mask-Data Handoff

The final weeks before tape-out concentrate more schedule risk than any other phase of a chip project. SkyCadEda provides tape-out support that carries your design from block-level closure to a mask-ready database: automated signoff checklists, GDSII and OASIS merge, frame generation, chip-level dummy fill, seal ring insertion and verification, final full-chip DRC, and foundry format and layer-number conversion. We work inside your existing tool environment and against your foundry documentation, so the last mile to the fab is systematic, auditable, and repeatable rather than a scramble.

Engagement focus

  • A mask-ready GDSII or OASIS database assembled by scripted, re-runnable flows instead of manual edits.
  • Chip-level density, antenna, and full-deck DRC closure with waiver documentation the foundry accepts.
  • A signoff checklist that executes itself and produces an auditable evidence trail for every check.
  • Coordinated mask-data handoff with fewer foundry queries and faster tape-out acceptance.

Capabilities

Engineering scope

01

Signoff Checklist Automation

Every foundry publishes a tape-out checklist, and most design teams maintain internal signoff criteria on top of it. We convert those documents into executable automation: scripted checks that confirm DRC, LVS, antenna, density, and ERC runs used the correct rule deck versions, PDK release, and waiver files, that log files are free of unwaived errors, and that results are archived against the exact database being shipped. Dashboards summarize pass, fail, and waived status per block and at chip level, so program managers see actual state instead of verbal reassurance. The result is a signoff process that produces its own evidence trail, catches stale runs and mismatched deck versions, and survives engineer handoffs late in the schedule.

02

GDS/OASIS Merge, Frame Generation, and Seal Ring Insertion

Assembling the final database is more than a boolean merge. We build scripted flows that combine block-level GDSII or OASIS streams, hard IP, the IO ring, and top-level routing into a single hierarchy with consistent cell naming, resolved references, and no duplicate or conflicting structures. Frame generation places the die boundary, alignment and overlay marks, and mask text according to the foundry frame specification. Seal ring insertion follows the qualified foundry template for your process, sized to your exact die, and dedicated verification runs confirm ring continuity on every layer, correct corner construction, via stacking, and clearance to active circuitry. Each step is logged and re-runnable, so a late ECO means re-executing a tested flow rather than repeating manual edits.

03

Chip-Level Dummy Fill and Final Full-Chip DRC

Metal, poly, and diffusion density rules are chip-level problems that block-level fill cannot fully close, because density windows cross block edges, routing channels, and the pad ring. We run foundry-qualified fill utilities across the merged database, manage exclusion regions over sensitive analog, RF, and matched structures, and iterate window-based density checks until every layer meets minimum, maximum, and gradient requirements. Final full-chip DRC then executes the complete foundry deck — including antenna, latch-up, and manufacturing checks often skipped at block level — with results triaged into real violations, known waivers, and false positives. We prepare waiver documentation in the format your foundry expects, keeping the review cycle with the fab short and predictable.

04

Format Conversion and Mask-Data Handoff Coordination

Foundries and mask shops are precise about what they accept: OASIS or GDSII at a specific version, defined layer and datatype numbers, top-cell naming conventions, and mandatory text labels for mask identification. We script layer-number remapping and format conversion with verification passes that XOR the converted database against the source to prove geometric equivalence, and that flag any unmapped layers instead of silently dropping them. We then prepare the submission package — checklist evidence, density reports, DRC and LVS summaries, waiver documents, and frame data — and coordinate the handoff through the foundry portal, tracking fab queries through to mask order confirmation. Every submission artifact is versioned, so any question from the foundry maps back to a documented owner and a re-runnable flow.

Expected outcomes

A deployment-ready result

  • 01A mask-ready GDSII or OASIS database assembled by scripted, re-runnable flows instead of manual edits.
  • 02Chip-level density, antenna, and full-deck DRC closure with waiver documentation the foundry accepts.
  • 03A signoff checklist that executes itself and produces an auditable evidence trail for every check.
  • 04Coordinated mask-data handoff with fewer foundry queries and faster tape-out acceptance.
Request ConsultationView All Services

From Design Closure to Mask Order, Without the Scramble

Tape-out is where every earlier shortcut surfaces at once: a block streamed with the wrong layer map, a density window that fails only at chip level, a seal ring that shorts to the pad ring, a checklist item signed off against last Tuesday and not against the database being shipped. SkyCadEda treats the tape-out sequence as an engineering flow to be built and tested, not a checklist to be sprinted through. Every step — merge, frame, seal ring, fill, full-chip DRC, conversion — runs from version-controlled scripts that produce logs and reports as evidence.

That discipline pays off twice. The first tape-out is calmer because problems are found by automation days before the deadline instead of by a foundry engineer days after submission. And every subsequent tape-out — metal fixes, derivative die, shuttle respins — reuses the same flow, so the cost of doing it properly is amortized across the life of the product.

A Tested Flow Instead of a Heroic Effort

We build and rehearse the assembly flow against preliminary databases well before freeze. Dry runs expose merge conflicts, layer-map gaps, and frame errors while there is still schedule to absorb them. By the time the final blocks arrive, the tape-out itself is largely mechanical: stream in, execute, review the reports, submit. Engineers stay focused on judgment calls — waiver decisions, ECO triage — instead of typing commands at midnight.

Coordinating the Handoff to the Foundry

Submission is a dialogue, not an upload. We prepare the tape-out forms and supporting reports in the structure your foundry expects, submit through the foundry portal, and track technical queries from the fab through to mask order confirmation. Because every artifact in the package is versioned and every check is re-runnable, foundry questions get answered with evidence in hours rather than with archaeology over several days.

For a broader walkthrough of what happens between final DRC and mask order, read our overview of the tape-out support process. For the verification runs that feed into tape-out, see our physical verification services.

FAQ

Questions before engagement

What do tapeout support services actually cover?+

Tape-out support covers the work between design closure and mask order: assembling the final GDSII or OASIS database, generating the frame, inserting and verifying the seal ring, running chip-level dummy fill, executing final full-chip DRC with the complete foundry deck, converting formats and layer numbers to foundry requirements, and preparing the submission package. It also includes the process layer — automating the signoff checklist, tracking waivers, and coordinating questions from the foundry until the tape-out is accepted. Teams engage us for the full sequence or for specific gaps, such as fill closure or merge automation.

Why automate the signoff checklist instead of tracking it in a spreadsheet?+

A spreadsheet records what someone claims was done; automation verifies it. A scripted checklist confirms that each verification run used the correct deck version, PDK release, and waiver file, that logs contain no unwaived errors, and that the database checked is the same one being shipped. It also catches the classic late-schedule failure modes: a stale DRC run against an older database, a block re-streamed after its checks passed, or a waiver applied outside its approved scope. Because the checks re-execute in minutes, a last-minute ECO does not force a judgment call about which results remain valid — everything is simply re-verified.

Can you work with our existing DRC and fill tools, or do you require specific software?+

We work inside your licensed environment. Merge, fill, and verification flows are built around the tools you already run — Calibre, Pegasus, PVS, or IC Validator — and around the rule decks and fill utilities your foundry qualifies for the target process. Where the step permits it, we use open tooling such as KLayout for merge scripting, XOR comparison, and inspection, reserving signoff licenses for the checks the foundry requires them for. The deliverable is a documented set of scripts your CAD team owns afterward, not an ongoing dependency on us.

How is chip-level dummy fill different from the fill done inside each block?+

Block-level fill closes density inside a block boundary, but density rules are evaluated in windows that cross block edges, top-level routing channels, and the pad ring. Chip-level fill runs on the merged database to close those inter-block windows, manage gradients between dense digital regions and sparse analog areas, and respect exclusion zones around matched devices, inductors, and the seal ring. Done carelessly, top-level fill can also introduce new antenna or coupling issues, so affected checks are re-run after fill. Most projects need at least one chip-level fill iteration even when every block passed density individually.

What is involved in seal ring insertion, and why does it need separate verification?+

The seal ring is a continuous metal and via structure around the die that blocks moisture ingress and stops cracks from propagating during dicing. Foundries supply a qualified seal ring construction for each process, but it must be sized to your exact die dimensions, mitered correctly at the corners, and placed with the specified clearances to both the scribe line and active circuitry. Verification confirms ring continuity on every required layer, correct via stacking, and the absence of shorts to signal or power geometry. Because the ring is added after block signoff, it is a common source of last-minute DRC surprises when not checked deliberately.

What does foundry format and layer-number conversion involve?+

Design teams usually work in the layer numbering of the PDK, while the foundry mask-data system may expect different layer and datatype assignments, a specific GDSII or OASIS version, defined top-cell naming, and mandatory identification text. Conversion is a scripted remap of every layer-purpose pair per the foundry tape-out documentation, followed by proof: an XOR comparison between the source and converted databases to confirm zero geometric change, plus checks that no layers were silently dropped or merged. We keep the mapping tables under version control, so the identical conversion reproduces exactly for metal-fix respins and derivative tape-outs.

How long does tape-out support take, and when should we engage?+

The final assembly and signoff sequence — merge, fill, seal ring, full-chip DRC, conversion, and submission — typically runs two to six weeks, depending on die complexity and how many DRC iterations chip-level integration uncovers. The automation is most valuable when it starts earlier: engaging four to eight weeks before the planned freeze lets us script the merge and checklist flows against preliminary databases, so the actual tape-out is the execution of a tested flow rather than the debugging of a new one. These ranges are illustrative; a metal-fix respin using existing flows can complete in days.

Related capabilities

Physical VerificationLayout AutomationCAD Infrastructure