한국어로 보기

Method

1. Method Overview

This page explains the calculation concept and interpretation flow used in GeoSignal Preview.

GeoSignal Preview is not intended to be a production-level lithography simulator or a calibrated wafer prediction model. Instead, it is a preview workflow that first identifies candidate regions from layout geometry, then reviews selected ROIs using a simplified optical model and multi-threshold contour visualization.

The basic method flow is:

Layout Geometry
    -> Geometry-based Candidate Filtering
    -> ROI Selection
    -> ROI Rasterization
    -> Abbe-based Aerial Image Calculation
    -> Multi-threshold Contour Extraction
    -> Hotspot-like Shape Review

This method does not run optical simulation on every layout location. It narrows down potentially useful review regions first, then calculates optical-response visualizations only for selected ROIs.

Version-specific implementation details are separated into Release Notes so this page can stay focused on the method concept.

The public service currently uses Abbe as its validated default. v0.9 also implements an exact full-rank Hopkins/TCC/SOCS formulation for cross-validation, but no approximate SOCS truncation policy is enabled by default. See the v0.9 milestone notes for the equivalence gates and measured tradeoffs.


2. Candidate ROI Selection

The first step is to select candidate ROIs from layout geometry.

In the current demo, candidate regions are first identified from a minimum width / space viewpoint. A limited number of ROIs are then selected for optical contour review.

This step should be understood as:

Final hotspot decision
    X

First-stage geometry-based filtering for optical contour review
    O

The important point is not that the current candidate-selection rule is optimal. The important point is the structure:

Find potentially weak locations from layout geometry
    -> Calculate optical response at those locations
    -> Review shape behavior through threshold contours

Specific rule thresholds, ordering heuristics, backend changes, and benchmark results are documented in v0.5 and v0.6 release notes.


3. ROI Rasterization

After a candidate ROI is selected, layout polygons inside the ROI are converted into a rasterized mask image.

In the rasterized mask:

inside polygon  -> 1
outside polygon -> 0

This means that layout geometry is represented as a binary mask on a regular pixel grid.

Layout polygons in ROI
    -> Pixel grid
    -> Binary mask image

The rasterized mask becomes the input for the optical imaging calculation.

In the current preview, the mask is treated as a binary mask rather than a PSM-aware mask model. Phase-shift mask effects, attenuated mask transmission, and detailed mask-stack effects are not included in the current public preview workflow.

Pixel size controls the trade-off between resolution and computation. A smaller pixel size can represent layout details more accurately, but it increases image-array size and FFT-based calculation cost. A larger pixel size reduces runtime but may lose small geometry details.

The ROI may include a margin around the candidate location because optical response is influenced not only by the candidate polygon itself, but also by neighboring layout structures.


4. Abbe-based Aerial Image Calculation

GeoSignal Preview currently uses a simplified Abbe-based imaging approach.

The aerial image is an optical intensity map calculated by applying a simplified optical imaging model to the rasterized mask.

It should be interpreted as:

optical response image

not as:

final wafer contour
calibrated resist contour
production CD prediction

The conceptual calculation flow is:

Rasterized mask
    -> Mask spectrum
    -> Source point sampling
    -> Shifted pupil filtering
    -> Coherent image per source point
    -> Partially coherent aerial image

More specifically:

  1. Transform the rasterized mask into the frequency domain.
  2. Shift the pupil position according to each source point.
  3. Filter the mask spectrum using the shifted pupil.
  4. Transform the filtered spectrum back to the image domain.
  5. Calculate a coherent intensity image for each source point.
  6. Accumulate the coherent intensity images to form the final aerial image.

The following image shows a debug example of the Abbe-style aerial-image calculation flow using a 9-point source condition.

Abbe debug example with 9-point source

The following image shows the same calculation flow under a denser source-sampling condition.

Abbe debug example with dense source

These images are kept as visual references for understanding the method. They are not intended as calibrated scanner-model validation.

The aerial image can qualitatively show effects such as:

  • edge blur
  • corner-rounding-like response
  • line-end-pullback-like response
  • intensity degradation around narrow regions
  • optical interaction between neighboring patterns
  • response differences between dense and isolated structures

5. Source Sampling and Pupil Filtering

The illumination source is approximated by sampling multiple source points.

Each source point represents one illumination direction. For each source point, the pupil is shifted in the frequency domain, and only spatial-frequency components passing through the shifted pupil are used to reconstruct the image contribution.

Conceptually:

Source point
    -> Shifted pupil
    -> Filtered mask spectrum
    -> Coherent image contribution

The final aerial image is obtained by accumulating image contributions from all sampled source points.

Using more source points can make the illumination approximation smoother, but it also increases calculation time. Using fewer source points reduces runtime, but the result may depend more strongly on the sampling condition.

The following image compares source-sampling conditions.

Source sampling comparison

The following image compares how aerial-image and contour behavior may change depending on source-sampling conditions.

Source result comparison

In the current preview, the source-sampling condition is selected by considering both visual stability and computational cost. The detailed rationale for recent default choices is recorded in the release notes.

The current result should be interpreted as qualitative optical-response visualization, not as a scanner-calibrated lithography model.


6. Multi-threshold Contour Extraction

After the aerial image is calculated, threshold contours are extracted from the intensity image.

A threshold contour is the curve where aerial-image intensity crosses a selected threshold level.

Aerial image
    -> Intensity threshold
    -> Threshold contour

In GeoSignal Preview, the threshold contour is used as a printed-shape-like visual indicator. It is not a calibrated resist contour.

The current demo commonly compares the following threshold levels:

0.20 / 0.30 / 0.40

These threshold values are used for qualitative comparison only. They should not be interpreted as process-calibrated thresholds or wafer CD references.

Multi-threshold contour comparison helps visualize how the aerial image appears as contour behavior under different threshold levels.

This is useful for reviewing:

  • threshold-dependent contour shift
  • weak image-contrast regions
  • necking-like behavior
  • bridge-like behavior
  • line-end-pullback-like behavior
  • corner-rounding-like behavior
  • locations with large contour movement

If a contour moves significantly across threshold levels, the region may have relatively weak or unstable optical response. If a contour remains relatively stable, the region may be more robust from a contour-behavior viewpoint.

Metric implementation changes and convergence checks are summarized in the v0.6 Release Notes.


7. Hotspot-like Shape Review

The final step is hotspot-like shape review.

This step combines geometry-based candidate selection with contour-based optical-response review.

The reviewed signals include:

  • narrow width or narrow space detected by geometry screening
  • visible mismatch between mask and contour
  • large contour movement across threshold levels
  • bridge-like response around narrow gaps
  • necking- or pinch-like response around narrow lines
  • line-end-pullback-like response
  • corner-rounding-like response

The output of this step is not a final pass/fail result. It is a visual guide for quickly identifying locations that may deserve additional review.

Geometry candidate
    + Aerial image behavior
    + Threshold contour behavior
    -> Lithography-aware review point

8. Current Scope and Limitations

GeoSignal Preview is currently a qualitative visualization workflow for public preview.

It has the following assumptions and limitations.

  • The public preview repository does not include the core implementation code.
  • The candidate-selection logic is not an optimized hotspot-ranking method.
  • The mask is treated as a binary mask; PSM-aware mask modeling is not included.
  • The imaging model is a simplified Abbe-based model.
  • Wafer-data-based calibration is not included.
  • Resist and etch models are not included.
  • Threshold contours are qualitative visual indicators.
  • The current result should not be used for production CD prediction.
  • Optical parameters are simplified for preview and learning purposes.
  • Public or synthetic layout examples are used.
  • Optical analysis is mainly performed at the ROI level.

Therefore, the current method should be understood as:

layout-to-optical-response visualization

rather than:

production lithography verification

9. Relation to Demo Page

The Demo page shows visual outputs generated through this method.

Demo Output Method Step
Geometry-based candidate Candidate ROI Selection
Rasterized mask ROI Rasterization
Aerial image Abbe-based Aerial Image Calculation
Multi-threshold contour Multi-threshold Contour Extraction
Hotspot-like annotation Hotspot-like Shape Review

Recommended reading order:

  1. Review the Demo page to understand the visual flow.
  2. Read the Method page to understand the calculation flow.
  3. Check Technical Notes if additional optical background is needed.
  4. Check Release Notes if implementation history is needed.