|
With rapid increase in the number of geometries in a chip and aggressive RET carried out on layout data, it has
become very much imperative to address the issue of layout and EB data explosion during IC design. Currently,
the most widely used GDSII format for layout data as well as the widely used data formats for EB data, are
incapable of handling the huge amount of data prevalent in the UDSM regime. The new non-proprietary
standardized formats of OASIS for layout data and OASIS.VSB for EB data are the way the industry is likely to
go in the near future to address the issue of data explosion. But, the process of adoption of these new formats is
too slow as it takes a long time for new design flows to mature. The speed of adoption is especially slow in the
post-layout domain as it is very close to manufacturing and the cost of error is too high. However, the issue of
layout and EB data explosion is real and immediate and hence, it should be addressed in short term without
waiting for the long term solution to arrive.
This paper discusses about an alternative approach of employing format-specific lossless reversible layout and
EB data compression schemes to compress the layout and EB data. The performance and the advantage of this
approach are compared with the currently prevalent approach of using OASIS primarily and solely for on-disk
file size reduction. It is argued that the reversible compression techniques could be a better approach for on-disk
data file size reduction as they would not only reduce the file sizes but could also almost seamlessly get integrated
into the current tool flow without necessitating major changes in the tool flow. The possibility of using OASIS
itself as a format for lossless reversible compression of GDSII and MEBES data is also discussed. It is also
argued that for successful adoption of OASIS formats by the industry mere on-disk file size reduction may not be
sufficient. Higher value additions such as reduction in in-core database size, enabling higher performance in data
processing etc. may have to be addressed by the tool flows which adopt OASIS based formats natively.
|
