Qckvu3 supports the OASIS (Open Artwork System Interchange Standard) database layout standard which was developed to address some of the deficiencies in GDSII stream format. A copy of the standard, SEMI-P39, can be purchased from semi here.
What is OASIS, how does it differ from GDSII and what are the benefits and issues surrounding its adoption?
64 Bit - GDSII was created in the early 1980's and is a 32 bit integer based database. At that time no one could imagine that chip layout databases could need more dynamic range than 32 bits could accommodate.
Built In Compression - Much of the data within OASIS cells is compressed using an open source zlib compression algorithm. While GDSII files are routinely compressed using gzip (and other proprietary formats) it makes sense to include basic compression within the scope of the database definition. Key parts of the database are kept outside of the compressed sections making it easy to access that data without need to do a decompression.
Modal Coordinates - For designs that use Manhattan data (i.e. 90 degree edges) modal coordinates eliminates the need to repeat the same X or Y coordinate if its value has not changed. This enables smaller amounts of data to describe a polygon.
Unlimited number of layers - The GDSII specification originally allowed for 64 layers. This was an arbitrary limitation and the industry quickly began supporting GDSII files with 1024 and then up to 4026 layers.
Compact Polygon Description - GDSII's boundary definition is very simple but also very inefficient. OASIS included many ways of defining polygons that use less data for "small" polygons. Since most large IC layouts include a large number of small polygons (by small, we mean that their length or width could be expressed in a single integer) the net result is less data required to describe the same number of polygons. This also allows OASIS to efficiently describe trapezoids so that it could eventually replace formats such as MEBES and other proprietary VSB mask writer formats.
Repetitions - If the same polygon (or cell or text) is used in many different locations (within a cell) OASIS allows the user to define it once and then list the various instances. This can increase efficiency in describing files that have been processed through OPC and which are often partially flattened during that processing.
Of course, "there is no such thing as a free lunch" and many of the benefits of the new OASIS specification are accompanied by implementation issues and costs. We'll only examine some of them here. Generally, to take full advantage of OASIS you will pay a large computational penalty in both producing and opening the files. Most viewers are greatly dependent on being able to randomly access data in a layout file as the user pans and zooms through the layout. Anything that makes it more difficult (and hence time consuming) to open a file, sort it out or access data by location hurts the performance of the viewer.
Compression/Decompression - It takes computing power and time to compress (and decompress) large amounts of data. It also makes it difficult to randomly access data in a file that is compressed. If you uncompress it and store an uncompressed version on disk you will see I/O limitations and large disk space requirements.
Interpreting Modal Coordinates - The use of modal coordinates makes reading data randomly from a file very difficult as one may have "roll" backwards through the file to compute the actual coordinates of the geometry.
Compact Polygon Description - software to interpret polygons is much more difficult to write if you have 16 different ways of describing a polygon. In general, the complexity of writing software tools to use OASIS efficiently is delaying its acceptance. There are twenty years of tools based on GDSII that would have to be re-written.
Repetition - The user of repetition in describing a large number of polygons requires additional processing when randomly accessing the database. Either the repetition must be "flattened" in a local copy of the database or more complex programming must be used to "roll" backwards in the file to access a polygon. Also the computing power required to produce repetition information when writing an OASIS file can be very significant as it may depend on pattern recognition if the layout software does not mark repetitive geometries when generating them.
While the OASIS spec allows a very large chip layout to be efficiently packed into a file, users will find that a) it takes significantly longer to write an OASIS file from a native IC layout database and b) it can take significantly longer to open such a file for viewing or for other database manipulations.
What we find "interesting" is that one feature that could have made OASIS files faster to open was made optional and not mandatory. This is the computation of each cell's extents and storing that value at the beginning of the cell. Because GDSII and OASIS are hierarchical databases, much of the computational energy in opening a file for the intial view is related to computing the extents of each cell in an initial pass.
If the extents computation were mandatory when producing an OASIS file, any software for opening OASIS files could skip that step. By making it optional, the developers of the OASIS specification insured that such a step cannot be skipped and also insured that most OASIS writers would not go to the trouble of producing the extents information.