OASIS has become the default layout format for releasing integrated circuit layout data to mask making. Its 10-50x file size improvement over the GDSII format has proved compelling for this stage of integrated circuit design, and yet it is not the default format for other stages of integrated circuit design.
The challenges in OASIS adoption stem from the number of ways that data in an OASIS file can be represented. OASIS writers must analyze the data carefully to choose an optimal representation that achieves the promised file size improvement. This leads to complex code that can be difficult to optimize and debug.
Fully compliant OASIS readers and writers must also follow many rules and guidelines designed to ensure data integrity and reliable interpretation of the data. Companies for whom file readers and writers are not a core competency may choose to implement "just enough" of the standard to get by, omitting some features required by the standard, or else download open-source software that has not been qualified fully. Both scenarios have led to non-compliant OASIS implementations in the field. The resulting bad OASIS files have stopped design and mask manufacturing work flows across the industry.
Some OASIS developers have even chosen to create non-compliant files. When this occurs, the downstream tools, tool developers, and tool users are all affected. OASIS files with constructs explicitly forbidden by the OASIS specification force users to choose between enforcing quality standards and "getting the job done." Disabling error checks may seem to get the design through the pipeline, but what other errors are being hidden?
As more companies come on line with OASIS, there needs to be greater consideration for the tools downstream that may be impacted by bad OASIS writers. In many cases, the companies affected downstream are fierce competitors who tend not to communicate with each other as well as they should.
The users of OASIS need to be aware of the anti-competitive environment created when one or more EDA suppliers' non-compliant code causes downstream tools to fail. This is not a matter of low quality in downstream tools; it is a result of the violation of industry standards, intentional or not. Developers need to be more aware of the delays and unbudgeted costs caused by non-compliant or bad OASIS implementations that are not fixed in a timely manner.
Left unaddressed, bad OASIS writers force the remainder of the industry to accommodate the non-compliant OASIS files, leading to lower quality standards overall and the very sort of data ambiguity that the OASIS standard was meant to avoid. The industry has had enough trouble with variants of the GDSII format; it does not need to continue those battles.
The charter of the SEMI OASIS Working Group has been to work with OASIS developers and users when conflicts like this arise. The Working Group and the SEMI standards organization that owns and administers the OASIS standard cannot enforce strictly compliant usage of the OASIS standard. It can, however, help define best practices for those developing and using OASIS readers and writers.
Yotta's OASIS Compliance Management technology, source code and utilities can help reduce the risks and costs for both OASIS code development efforts and production-level OASIS and GDSII uses-models in the field at the Foundries, Mask Shops and IDMs.
"The Company's technology established a common expectation amongst suppliers and customers regarding matters of OASIS compliance, performance and interoperability"
Electronic Device Laboratory
Dai Nippon Printing Co., Ltd
* US Patents 9,122,825, 8,555,219, 8,266,571 and 7,685,545.
International Patents: China 200980129771.8, Japan 4768896, Korea 10-1580258