Layout-database file control: the missing link
The authors descirbe a new signature-based approach to resolving the content of layouts in GDSII, OASIS and other formats.
GDSII to MEBES to OASIS…
As exchanges of layout descriptions between teams involved in IC development and production increase in rate, value and size, so do the needs for control and reliability. Regular integrity controls (e.g., cyclic redundancy checks, cryptographic hash functions and error correcting codes) can be used but their limits quickly become apparent.
On many projects, there are two teams simultaneously manipulating the same layout, but each uses a different representation based on one of the proprietary, standard or semi-standard formats (e.g., GDSII, MEBES, OASIS and OASIS.MASK). Comparing and identifying differences between the two resulting databases is a complex and time-consuming process. It also requires that one of the parties possesses both files, yet for security reasons, concerns will frequently arise over transmitting “unnecessary” data to a partner.
A standard traceability process usually starts with the creation of a unique signature that accompanies the transfer of a product, and thus guarantees its authenticity to the recipient. A good traceability system must be reliable, secure and independent of any specific implementation technology. Rather, it must ensure interoperability between heterogeneous environments. And, it must not risk compromising confidential or proprietary information.
State of the art
There is not much on the market today to address these needs. Legacy formats, such as GDSII or MEBES, offer no integrity control. Newer formats, such as OASIS, include options like a cyclic redundancy check (CRC) checksum, but this still has several drawbacks:
- The use of the CRC algorithm turns reading and writing into a linear operation –– bytes of the file have to be read in order –– and this disables optimizations based on parallelism for large files.
- The CRC algorithm is an error-detection code. It does not guarantee security guarantee. By that measure, it is easy to create two files with different content, but the same CRC checksum.
- Since the checksum is not mandatory, many writers omit it. And some readers do not bother to check it.
Given all this, it is tempting to use other tools that are consdiered secure and efficient. A good example would be those that generate cryptographic checksums, such as the Secure Hash Algorithm (SHA) or the deprecated Message Digest 5 (MD5). Like the CRC checksum, they are byte-dependent, which means that a single bit change in the file causes a dramatic change in the checksum. Normally, this would be considered a useful feature. However for layout databases, it is a drawback: What needs to be secured and traced is not bytes in the file, but the actual design or geometric description.
The only way to check that two files implement the same geometric design is to run an exclusive OR (XOR) operation on them This is a complex and lengthy operation that requires expensive tools. Unlike a checksum, it requires the availability of both the original file and that to which it is being compared. Users cannot easily know if the designs are the same, though that is what they want to do.
Specific constraints for layout file control
In most cases, checking and validating the contents of a file is important, not the container by itself. This is mandatory in the EDA process flow because of the various ways that exist to describe the same thing. In addition to generic considerations for the file signature, microelectronics has specific needs and constraints.
On the design side, most layout files use the GDSII format, the de facto standard. Some companies are switching to OASIS, but this transition is taking place gradually because not all EDA tools yet support the OASIS format. So for the time being, the back-end flows need to manage both GDSII and OASIS files with some translation at defined steps.
Users are reluctant to switch due to a lack of quick and easy ways to verify that a layout description in OASIS is the same as in GDSII. This makes a format-independent signature necessary. Signing a layout described in GDSII and signing the same layout described in OASIS must yield the same result, as it must for other formats such as OASIS.MASK or MEBES.
Most chip layout formats offer a great deal of leeway in terms of how the structure is described. In GDSII, for example, the order of cells described in a file is totally arbitrary.
Even if lower-level polygon descriptions are identical and the hierarchies are identical, it is impossible to compare two files by using a file-level signature. Reading a GDSII file within an EDA tool and rewriting it without modifications breaks the signature, given that the signature also contains the creation date and other meta-data. This makes any checksum unusable. The problem is worse with OASIS because the format offers a number of different ways to save the same data. These include strict mode, by reference or by name. These non-geometric intricacies should not impact the signature.
The main geometric issue is that aspect of EDA tools and file formats that permits different ways being used to describe the same thing. For example a ‘wire’, can be drawn as a ‘path’ – that is as a succession of abutting segments with a given width or as a complex polygon that can be described as an assembly of basic trapezoids.
![Figure 1. Different EDA tools and file formats allow different ways to describe the same geometry (XYALIS)](https://www.techdesignforums.com/practice/files/2018/05/XYALIS_Figure-1.jpg)
Figure 1. Different EDA tools and file formats allow different ways to describe the same geometry (XYALIS)
Additionally, no constraint applies to the description of a polygon. It is a list of edges starting from one arbitrary point and turning either clockwise or counter clockwise, making the classical signature of a simple polygon description irrelevant. If the user does not care about polygon overlaps within the same layer, a meaningful signature must only consider the final envelope of the whole polygon with clear specifications on the vertex order.
When validating file integrity, a global checksum or signature is enough. But simple ‘go/no go’ information is useless in most cases on a huge layout file and it is important to know the number of differences as well as their position. For example, when comparing two text files, using “diff” gives more information than using a simple checksum because users can know how many lines there are and which ones contain differences.
In the same way, a layout file can be split into windows to compare two files. Comparisons take place window by window. This makes it possible to run more detailed XOR operations on reported windows, if needed.
The same mechanism can be used for the signature. Instead of reporting a single checksum for the entire layout, the signature can be a list of checksums –– one for each window. The signature becomes a file containing the window information and the checksum for each window.
Chip layout description files generally contain multiple layers. When a rework is required, it is generally achieved using a metal fix where only a few interconnection layers are changed. This reduces mask cost and accelerates delivery time by using wafers that have already been processed up to the interconnection layers. Mask data preparation teams need to be able to quickly check that all front-end layers are strictly identical while only expected metal layers have been changed. The signature of a layout database must be split by layers.
After reviewing the specific needs of chip layout files, we can see that a list of constraints that will underpin an efficient signature strategy is required. A signature file must validate content, not the container, and must also be:
- Independent of the file format and description strategy;
- Based on the final geometric envelope of polygons; and
- Split in windows and layers.
The solution: A new signature
Having identified the need for a list of constraints, how should we go about building it and, from that foundation, a new signature?
The standard must lead to a unique and universal way to sign any layout database. It will not be a single checksum, but a file containing checksums for each window and each layer, and contain additional information such as window size and column/row number.
As noted above, two identical layouts must give the same signature, despite the fact that they are described in different formats. To achieve this, it is mandatory to define a unique way to describe the geometries –– or more accurately, the geometrical envelope.
To guarantee its uniqueness, this description must meet multiple constraints. It must define an order for the vertices. It must define precisely which points are part of the description. Then, using standard algorithms such as SHA256 or SHA3, the uniqueness of the signature of the description can be guaranteed.
The signature file will be small compared to the original database and available for use as a reference at any time. Comparison between two layout databases will not be made by a full XOR, but by comparison of the signatures of the two databases. It will also be possible to compare a database with a previously computed signature file.
With such a signature based on the geometrical description, any physical change of the layout will be quickly detected, whether that change is intentional or accidental.
For example, as soon as a rework –– i.e. a metal fix –– is requested on a design, the new database is compared to the original to check that only the expected layers have been changed, and usually only in a few localized areas.
Until now, this has required recovering the original database archive. Using the signature file as a reference simplifies the process because it is small enough to be accessible. Yet at the same time, it contains enough information to guarantee the similarity between some layers and highlight the windows where differences have been found on other layers.
Thus armed, the design team can then still elect to run a detailed XOR but need only focus on those windows that contain differences.
Since the signature only depends on the physical layout, it is easy to check that a simple read/write with a tool or a format conversion such as GDSII to OASIS has not led to any geometric modification. And, because the signature will never change unless a geometrical transformation has been introduced in the layout, this technique is well suited to validating new tools and complex flows, such as hierarchy flattening or layer splitting.
Conclusion
The proposed signature is tailor-made for layout database file integrity control. It is secure, reliable and, most important, focuses on what really matters –– the geometric description. It enables the quick and easy comparison of huge databases, yet is based on a small signature file that does not need to contain sensitive information and can therefore safely be sent to any partner.
The adoption of such a signature will have a positive impact on the semiconductor industry if enabled as an open standard. A fair-use policy on the patent that covers the signature scheme can be enforced. As an open standard, the signature becomes even more useful. It can be embedded directly into OASIS or OASIS.MASK databases as a special property, for example.
About the authors
Dr. Philippe Morey-Chaisemartin is Chief Technology Officer at XYALIS. After managing different design projects at STmicroelectronics, he set up its mask data preparation team for advanced 300mm foundry projects. He received a Ph.D. and a Master of Science degree in Microelectronics and Computer Science from the Université Joseph Fourier in Grenoble, France, and teaches at the Institut National Polytechnique de Grenoble.
Frederic Brault is a Senior Engineer for EDA software at XYALIS. He previously worked on compiler optimization at INRIA and high-performance, massively multicore chips at Kalray. He holds a Masters degree in Advanced Computing from Imperial College London and a Bachelor of Science degree from Supelec in France. He also teaches at the Institut National Polytechnique de Grenoble.