Reference for QckRip for Nikon
Copyright 2014 Artwork Conversion Software, All Rights Reserved
QckRip is a high speed rasterizer for GDSII layout data that is repetitive - i.e. microelectronic circuits that have been arrayed on a substrate or panel. It takes advantage of the repetition to avoid "brute force" rasterization of every geometry.
QckRip assumes the layout data can be subdivided into two groups:
Users of QckRip may need to make small adjustments to the bitmap to account for stretching or distortion in the substrate. These adjustments can include different scaling in X and Y and a shear transformation.
Normally appying these types of corrections would force the "explosion" of all the repeating circuits so that they could each be individually transformed and then rasterized. However QckRip tries to minimize this by comparing the needed correction to a tolerance value. If the amount of correction over the small area covered by the repeating circuit is less than the tolerance set by the user, no explosion is needed. Because this assumption is very often true for small circuits arrayed on a large panel, QckRip can still produce a raster output quickly, even when some correction is applied.
The input data can be transformed. This is normally done to accommodate small changes to the substrate that occur during the manufacturing process.
In order to show how the transformations work, we supply this simple GDSII file. We can then run it through the RIP with different transformation settings.
transform_test_case.gds 500,000 x 610,000 um centered at 0,0
The output shown below has been rotated by 12 degrees. [Note that the data extents is increased by this transformation.]
The output below has been set to Mirror X
The output below has been set to Mirror Y
Scale (Y only)
The output is transformed by scaling the Y axis by 0.819.
Shear (X only)
The output is transformed by setting ShearX = 6.
Shear (Y only)
The output is transformed by setting ShearY = 6.
Shear X and Y
The output is transformed by setting ShearX = 3 and ShearY=6
A single large bitmap is often not useful. Therefore the program allows the user to define one or more (typically more than one) "tiles." Each tile covers a portion of the entire image area.
Manual Tile Assignment
If Manual is selected, then the user can define one or more tiles areas by specifying the extents of the data that the tile should cover. This is made more complicated by the fact that the use must take into account any changes to the extents which were produced by transformations.
The program assists the user by presenting both the initial extents of the data and the transformed extents.
In the example dialog above, the user has specified two tiles. The first covers the left had side of the layout and the second covers the right hand side of the database. When this is rasterized, the results will be two separate tiles as shown below:
When Automatic tiling is selected, the user specifies both the tile size and any overlap. The program will generate the tiles positions automatically to cover the extents it has been provided.
For example, assume our equipment wants to see bitmaps that are 1024 pixels wide and the whole height of the image. If our maximum image are is 630 mm x 520 mm and our pixel size = 100 um then we would define our tile size to be 1024 x 6300.
We also must decide on a reference corner -- in this case let us set the reference at the upper left of the
image area.The dialog box would look like this:
And the results would be 6 tiles arranged like this.
Each tile is 1024 pixels wide by 630 pixels tall as specified.
Our tiling starting point was set to the upper left corner.
The final tile, tile6.tif, is "empty" because the the portion of it that covered the data was empty.
Span length is a parameter used by QckRip to more efficiently process layouts that have a large number of small repeating elements.
Consider a panel layout that has 5000 x 5000 small geometries on the order of 20 x 20 um in size. Without the span length operation, QckRip would create a bitmap of 20 x 20 um (at a pixel size of say 0.5 um) and use a bitmap copy operation 25 million times on a bitmap of only 1600 pixels.
From a computational point of view this is not the most efficient approach - there are various computational costs to each bitmap copy that add up. With 25 million bitmap copies, even a small amount of overhead adds up.
It turns out that it would be much faster to spend a little more time up front and combine say, 250 x 250 of these tiny elements into a "super-block" -- a single geometry covering 5,000 x 5,000 um, rasterize that into a single bitmap of 100 megapixels, and then do a bitmap copy only 400 times.
Basically we are trading off some up front computation to combine and rasterize a larger area against time spent on a large number of bitmap copies.
Unfortunately it is not easy to predict the optimal size of the super block. It will depend on the complexity and hierarchy of the layout, the overall size of the layout and so on.
The span length entered by the user is an estimate of the super-block size; i.e. the length of an edge.
What are the limitations on setting the span length?
On the low side setting it to a value smaller than the smallest repeating geometry size essentially results in no creation of a super-block. In our example above, the repeating geometry is 20 x 20 um. So any span length less than 20 um does not result in creating a super block.In practice such small values are ignored by the program and the value is set to an internal minimum.
On the high side you do not want the span length to exceed the extents of your repeating data -- again you will not get a repeating super-block. In our example above the layout is 100,000 um on a side so any setting above 100,000 um is also not helpful.
Also on the high side, the span length should not be set to produce a super-block whose bitmap cannot fit into the raster buffer. Say for our example we have a raster buffer size of 128 MB and our pixel size = 0.5 um.
the absolute maximum span length would be 16,000 um.
Even though the max allowed value for span length is constrained by the raster buffer size it is generally not helpful to select a span length so large.
As a starting point one should select a span length that is between 25% and 30% of the smaller of:
a) the layout extents
b) the raster buffer size limit (by converting back to an area based on the DPI)
In our example above the layout extents are 100,000 x 100,000 um which would give us a starting point for span length of of 25,000 to 30,000 um. The raster buffer is 128 MB which yields a max span length of 16,000 um. So this would give a starting point of 4000 to 5300 um. Since this is the smaller value one should start in the range of 4000 to 5000 um.