Mask Data Preparation

Mask data preparation (MDP) is the pipeline that takes an OPC-corrected design layout and converts it into the exact set of instructions a mask writer can actually execute — fracturing complex polygons into simple exposable shapes, correcting for electron-scattering dose effects, applying systematic bias, and packaging everything into the mask writer's native format. It's the translation layer between "what the design should look like" and "what a physical writing tool can actually draw," and every error introduced here propagates directly into a real mask defect.

MDP: From Corrected Design to Writer Instructions Every stage below can introduce an error that becomes a real mask CD defect. THE PIPELINE 1 · Fracture complex polygon split into rectangles / trapezoids 2 · PEC corrects dose for electron scattering between shapes 3 · Bias offsets edges for etch bias and resist shrinkage 4 · Format MEBES / VSB / multi-beam packaged into the writer's own native job deck DATA VOLUME EXPLOSION design data fractured data — 10-100x larger advanced mask data can exceed several terabytes WHY ERRORS HERE ARE EXPENSIVE A bad bias or wrong fracture setting doesn't fail quietly — it writes a real, physical CD error into every copy of the mask, caught only at inspection or, worse, only once wafers come back from fab. QC on MDP output is mandatory, not optional — the mask shop checks every job. MDP is the last software step before a mask writer physically commits ink to glass — there is no undo after this.

Fracturing exists because a mask writer can't directly expose an arbitrary polygon — it can only fire a sequence of simple, predefined shapes, so every complex OPC-corrected feature has to be decomposed into rectangles and trapezoids the writer actually understands. A corrected layout polygon, after OPC and inverse lithography have reshaped it to compensate for diffraction, can have a genuinely irregular, many-sided outline. Fracturing software splits that irregular shape into a set of non-overlapping simple primitives — each one becomes a single "shot" the writer will expose — and how cleverly that decomposition is done directly determines how many shots the final write job needs, which in turn directly sets how long the mask actually takes to write.

Proximity effect correction (PEC) exists specifically to counteract a physical side effect of electron-beam writing itself: electrons don't stay exactly where they're aimed, and nearby shots influence each other's effective dose. When an electron beam exposes resist on the mask blank, some electrons scatter sideways into neighboring regions rather than staying confined to their intended shot — meaning a densely-patterned area effectively receives more total dose than an isolated feature would from the identical nominal exposure. PEC compensates by adjusting the dose applied to each individual shot based on how much scattered dose it's likely to receive from its neighbors, so the final developed pattern comes out at its intended size regardless of local pattern density.

Biasing deliberately builds known downstream process effects into the mask pattern before it's ever written, rather than leaving the mask shop to discover and correct for them after the fact. Etching the mask pattern into chrome, and the resist's own behavior during mask processing, both shift feature edges slightly in predictable, well-characterized ways — and biasing intentionally offsets the mask pattern's edges in the opposite direction, so that after etch bias and resist shrinkage both happen, the finished mask feature lands exactly on its intended target dimension rather than systematically off by a known, correctable amount.

Format conversion packages everything MDP has produced into the specific native instruction format whichever mask writer will actually run — MEBES, Variable Shaped Beam, or multi-beam format — because different writer technologies expect genuinely different input structures. A VSB e-beam writer expects shot data describing variable-sized rectangular apertures; a multi-beam writer expects data structured for its massively parallel beamlet-array exposure scheme. Getting this format conversion wrong doesn't produce a subtle error — it produces a mask writer that simply can't run the job at all, or runs it incorrectly in a way that may not be obvious until the finished mask is inspected.

Data volume at advanced nodes has become a genuine engineering challenge in its own right, independent of the actual algorithmic complexity of fracturing, PEC, or biasing. Fractured mask data commonly expands to ten to a hundred times the size of the original design data, and advanced masks can generate several terabytes of fractured data per job — simply moving, storing, and processing data at this volume, fast enough to keep up with mask-shop throughput requirements, is itself a substantial infrastructure problem that mask data preparation software and hardware have had to scale to meet as design complexity and data volume have both grown generation over generation.

Take mask data preparation further

Ask the copilot about this term, or have our engineers assess it against your process.

Ask CFSGPT about this → Request a technical assessment → Open the CFS app