Fractured Data

Fractured data is the mask writer's actual input format — the result of decomposing every complex, OPC-corrected layout polygon into simple rectangles and trapezoids a writer can physically expose one shot at a time. Every one of those simple shapes becomes a single shot, and the total shot count that fracturing produces is the single number that most directly determines how long the mask will actually take to write — making fracturing strategy, not just correctness, a genuine economic decision with real cost consequences.

Every single primitive a fracturing algorithm produces becomes one shot the mask writer has to physically execute, which is exactly why the relationship between fracturing strategy and total write time is so direct and unavoidable. A VSB e-beam writer, or any serial writing technology, has to expose each shot in sequence, one after another — meaning the total number of shots a fracturing pass generates sets, almost linearly, how long the complete write actually takes. This isn't an indirect or approximate relationship; it's close to a direct multiplication, which is exactly why fracturing strategy gets treated as a genuine engineering optimization problem rather than a simple, mechanical format-conversion step.

Naive fracturing, which simply decomposes a polygon into a straightforward grid of narrow strips without any real optimization, produces far more shots than the underlying shape geometrically requires. Splitting an irregular polygon into many thin, uniform-width slices is computationally simple but geometrically wasteful — most of those slices could be merged into fewer, larger rectangles that cover exactly the same area with far fewer total shots. This naive approach was historically common precisely because it was simple to implement, but it leaves real write-time savings on the table that smarter fracturing algorithms can capture without sacrificing any edge-placement accuracy.

Optimized fracturing algorithms specifically search for the minimum shot count that still represents a given polygon's shape with acceptable edge-placement accuracy, treating shot-count minimization as an explicit optimization target rather than an incidental byproduct. Modern fracturing software identifies larger rectangular or trapezoidal regions within a complex polygon that can be covered by a single shot, reserving finer, smaller shots only for the parts of the shape where precise edge control genuinely requires that extra precision. This selective approach — large shots where the geometry allows it, fine shots only where actually needed — is what lets advanced fracturing deliver meaningfully fewer total shots than a naive approach, directly translating into real write-time savings for every mask that uses it.

Data volume expansion from fracturing is a separate, independent challenge from shot-count optimization, and it's become a genuine infrastructure problem in its own right as design complexity has grown. Fractured data commonly expands to somewhere between ten and a hundred times the size of the original, unfractured design data, because every polygon's decomposition into primitives adds real data volume describing each individual shot's position, size, and dose. Advanced masks can generate several terabytes of fractured data per job, and simply moving, storing, and processing data at that volume fast enough to keep pace with mask-shop production throughput is its own substantial computing and data-infrastructure challenge, entirely separate from the algorithmic question of how to fracture efficiently in the first place.

Edge quality depends directly on how fracturing is done, not just on how many shots it produces, because the boundaries between adjacent shots can themselves introduce artifacts if the fracturing isn't handled carefully. Poor fracturing can leave visible stitching artifacts at the boundaries between adjacent shots — small discontinuities in the printed edge where one shot ends and the next begins — degrading the actual mask edge quality even when the overall shot count looks reasonable. This is exactly why fracturing quality control checks both shot count and resulting edge accuracy together, rather than optimizing shot count in isolation and simply assuming edge quality will follow automatically.