Distortion Correction BenchmarkingTo 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.
The NRTCR Command LineTo 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 RunHardware CPU i7 950 (3.05 GHz) 4 cores12 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 DistortionIf 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 Distortion GeometryGo to the next page to see an overlay of the source data and corrected data at various locations on the chip . |