web page header logo


Distortion Correction Benchmarking

To give our OEM customers some idea as to the computation time required to implement distortion correction during rasterization, we have generated a "generic" 300 mm RDL mask and apply different amounts of distortion to the substrate.

We then measure the RIP times and determine how long the rasterizer takes to both correct the distortion and to produce the rasterized output.

What we are trying to simulate is the real-world requirement to write geometries on a wafer whose "dimensions" have been slightly altered from the ideal either due to temperature changes or some kind of processing.


How Much Distortion?

Our OEM partners who are involved in direct imaging on wafers tell us that one can expect distortions of up to 20 um from end to end of a 300 mm wafer. So we will use this number to investigate how the real time correction works. We will set our "tolerance" at a value of 0.25 um. This means that once we have corrected to within 0.25 um of the desired results we can stop further corrections.


Our Alignment Mark Geometry


Our assumption for this exercise is that we have 4 alignment targets at the coordinates (at least in the CAD data) shown in the illustration. After the substrate is loaded into the image writer, a camera finds these targets and records the measured locations.

Assuming one has used the lower left target as the reference point when loading the substrate, the other three targets will show some difference between the CAD data and the actual measured data. The locations and the measured differences at each location are the input to our distortion correction algorithm.


Name CADX CADY DeltaX DeltaY
LL -100000 -100000 0 0
UL -100000  100000 10 15
UR  100000  100000 14 5
LR  100000 -100000 9 -4

The NRTCR Command Line

To run the benchmark we are going to use the client provided with the NRTCR libraries and create the required command line and correction file. We'll use the log files to extract the timing.


RIP_TEST.BAT

C:\wcad\NRTCR\RTCRClient64.exe                                     the client that runs NRTCR libraries
   E:\cad_data\NRTCR\300MM_TEST_WAFER_W_SEAL_RING_REVB_OUT.GDS     the input GDSII file
     E:\cad_data\NRTCR\RASTEROUT_CORRECTED                         the directory for output bitmaps
        @E:\cad_data\NRTCR\300MM.CFG                               a configuration file

300MM.CFG

-log                                                               turns on logging
-job                                                               defines this as a job
-pxsize:0.2                                                        pixel size in um
-serialize                                                         run in single buffer mode
-tiff:none                                                         do not compress or write bitmap out
-enginethreads:4                                                   use max of 4 concurrent threads
-limitmemory:11262                                                 limit memory usage to 12 GB
-origin:LL                                                         raster stripe origin in in LL
-direction:right                                                   generate horizontal tiles from left to right
-correction:E:\cad_data\NRTCR\correction_data.cor,0.25             use this correct file with 0.25 um tolerance
-autotiles:-150000,-20000,150000,20000,ntiles:1,10                 generate 10 horizontal tiles across the full width of the wafer
                                                                   each tile will be 4000 um tall.                 

correction_data.cor

-100000, -100000,  0, 0
-100000,  100000, 10, 15
 100000,  100000, 14, 5
 100000, -100000,  9, -4

Results on First Run

Hardware

CPU i7 950 (3.05 GHz) 4 cores
12 GB of RAM installed
7200 RPM Hard Drive
Windows 7 64 bit

There is no bitmap output generated in the RASTEROUT_CORRECTED directory as I set tiff:none in my configuration file. However there are two separate log files produced. We are looking at pure rasterization times. Let's examine them.

rtcr.log

I'll skip the part where the log file repeats the commmand line and settings. We are interested in timing information which begins here: My comments are in green.
Running Job# 1 (0%)
  Setup Job Time [0h:0m:13.21s]  This amount of time, 13 seconds, is what the correction
                                 engine and other up front processing required; it includes
                                 the time to write the corrected GDSII to disk?)

Setting up Stitcher and Compressor modules (50%) The 50% mentioned here means nothing.

Ripping Tile 1/10 (55%)
  Time to RIP Tile [0h:0m:3.88s]    3.38 seconds to RIP the first stripe
  Tile Data: WxH: 1500000x20000 (px) Size: 3G 504M 285K 384b since our pixel = 0.2 um 
                                                             this is 300 x 4 mm and uses 
                                                             about 3.5 GB RAM

Ripping Tile 2/10 (60%)
  Time to RIP Tile [0h:0m:3.35s]
  Tile Data: WxH: 1500000x20000 (px) Size: 3G 504M 285K 384b

Ripping Tile 3/10 (64%)
  Time to RIP Tile [0h:0m:3.33s]
  Tile Data: WxH: 1500000x20000 (px) Size: 3G 504M 285K 384b

Ripping Tile 4/10 (69%)
  Time to RIP Tile [0h:0m:3.22s]
  Tile Data: WxH: 1500000x20000 (px) Size: 3G 504M 285K 384b

Ripping Tile 5/10 (73%)
  Time to RIP Tile [0h:0m:3.35s]
  Tile Data: WxH: 1500000x20000 (px) Size: 3G 504M 285K 384b

Ripping Tile 6/10 (78%)
  Time to RIP Tile [0h:0m:3.30s]
  Tile Data: WxH: 1500000x20000 (px) Size: 3G 504M 285K 384b

Ripping Tile 7/10 (82%)
  Time to RIP Tile [0h:0m:3.28s]
  Tile Data: WxH: 1500000x20000 (px) Size: 3G 504M 285K 384b

Ripping Tile 8/10 (87%)
  Time to RIP Tile [0h:0m:3.08s]
  Tile Data: WxH: 1500000x20000 (px) Size: 3G 504M 285K 384b

Ripping Tile 9/10 (91%)
  Time to RIP Tile [0h:0m:3.25s]
  Tile Data: WxH: 1500000x20000 (px) Size: 3G 504M 285K 384b

Ripping Tile 10/10 (96%)
  Time to RIP Tile [0h:0m:3.32s]
  Tile Data: WxH: 1500000x20000 (px) Size: 3G 504M 285K 384b

Waiting for Compressor to finish (99%)
  RIP Time [0h:0m:33.58s] 
End RIP (100%)
END JOB [0h:0m:46.79s]


END OF OPERATION [0h:0m:46.84s]

Latency?

From the image writer OEM's point of view the latency is the time from start of RIP to the completion of the first stripe of data. Only when the first stripe is available can the image writer start. In our test case this appears to be:

Setup Job Time + time to RIP first stripe = 13.21 + 3.88 = 17.09 seconds

Timing Comparison to No Distortion

If we run this same job again but remove the distortion directive in the config file we see the following timings:

Setup Time: 1.84 seconds
First Stripe RIP: 3.82 seconds
Latency: 5.66 seconds
Total Job Time: 34.91 seconds


Do Multiple Domains Slow Down the Correction?

The question has arisen - what if I have a large number of locations where measured vs. CAD data is available? If I enter a large number of domains does this measurably slow things down?

Go to this page to see some test results ...


Distortion Geometry

Go to the next page to see an overlay of the source data and corrected data at various locations on the chip

.





ARTWORK CONVERSION SOFTWARE, INC.                  Company Profile
417 Ingalls St.,     Santa Cruz, CA 95060         Tel (831) 426-6163     Fax 426-2824               email: info@artwork.com