Nextgen Raster is Artwork's third generation set of rasterizer libraries for GDSII/OASIS layout data. It is intended for OEM's who need to integrate a powerful RIP into their own software -- typically an application that controls either an image writer or inspection machine. By wrapping the rasterizers three separate, but tightly integrated, libraries we enable OEMs to achieve both fine control of the results and without the need to manage three separate libraries and their interactions.

Library Flow

The basic data flow is shown above. The Nextgenraster64.dll encapsulates or wraps three libraries:

Layout data is opened by the QISLIB library. The user has specified a structure and a layer to open as well as a window of the layout to extract into polygons. These are stored in memory.

The calling application then tells the rasterizer library where to find these polygons and at what pixel size to rasterize them. The resulting bitmap is directed to another piece of memory. The rasterizer library is thread safe and many threads can be launched limited only by the number of CPU cores available to do the work.

Finally, the formatting library is called and told how to compress and format the raw bitmap for its final use.

Working Assumptions

The working assumption for this set of libraries is that the the layout size and DPI is such that one will have to subdivide the processing into stripes or bands in order to fit into the available memory. A simple calculation will bear this out.

Imagine that you have a layout size of 610 x 500 mm and you wish to represent this region with monochrome pixels arrayed on of 0.5 um centers. The amount of RAM one would need to hold the entire layout is:

[610 mm x 500 mm x 2000 pixels/mm x 2000 pixels/mm]/[8 bits/byte] = 152.5 GByte

If you happen to have a workstation equipped with 192 GByte of RAM then you can run this in a single pass. However you can still rasterize this layout with a workstation equipped with only 16 GBytes of RAM. One merely has to subdivide the problem into narrow stripes, or tiles or windows who size can be accommodated with whatever RAM is available.

Where's the Bottleneck?

When rasterizing a large complex layout into a large bitmap there are several key steps:

Extracting the polygons in any given tile or window

Rasterizing those polygons

Formatting and compressing the bitmap

These are serial operations - you must first extract polygons, then rasterize into bits, then compress or format the bits. Unfortunately, for any given input file, layout size and bitmap density, the throughput of one of these stages will be the limiting factor.

Fortunately, in most scenarios, the rasterization step is the most compute intensive. I say fortunately because this step can also be parallelized by applying multiple raster threads, each running on an independent CPU core, to spread the compute load.

With 6 cores available on a single chip and new versions of the Intel processors arriving with 8 and even 12 cores, a dual socket workstation with 16-24 cores is not outrageously expensive to build. It can be equipped with 64-128 GBytes of RAM to give those cores enough memory to work with. The price and speed of solid state drives is also dropping rapidly and 500 GBytes of SSD mounted directly on the PCIe bus can deliver a GByte per second physical IO.

By breaking out the polygon extractor, rasterizer and format separately, the calling program can allocate cores and memory where they are put to best use for maximum throughput.