QISLIB vs GDS_RIP - Performance

Some years ago Artwork developed a rasterizer for GDSII data called GDS_RIP. This program has been optimized over the years and used for both mask writers and mask inspection equipment.

GDS_RIP was designed using certain fundamental assumptions:

a) that the entire GDSII file was to be processed

b) that the main bottlenecks were in rasterizing polygons

For many applications these are valid assumptions and we optimized GDS_RIP by adding multi-threaded raster engines behind the single threaded layout explosion engine.

However in the last few years (2003 ...) we ran into applications where the GDSII/OASIS files were extremely large. The primary bottleneck moved to the single threaded explosion engine. When the GDSII files got so large they could not fit into RAM the explosion engine running inside of GDS_RIP completely bogged down.

Quad Tree to the Rescue

QISLIB (whose development started as far back as 2001) takes a much different approach to exploding GDSII data. During the loading process it actually creates a quad tree - a table indexing geometries and cell placements by their location. While this requires significant computation, once you have a quad tree you can access (or explode) small regions of data very efficiently.

For applications where GDS_RIP would have its main bottleneck during exploding, QISLIB runs much much faster. These applications are those where the layout data is very large and the size of the extracted windows is relatively small.

So which tool is better for your raster application?

GDS_RIP - when the GDSII data is small but the bitmap data is large

QISLIB - when the GDSII data is large and the bitmaps are small