Advances in chip manufacturing processes continue to increase the number of vertices to deal with in Optical Proximity Correction (OPC) and Mask Data Preparation (MDP). In order to manage the processing time, OPC in sub-nanometer now requires employing tens of thousands of CPU cores. A slight mishap can force the job to be re-run. Increased complexity in the computing environment, along with the length of time a job spends in it, makes a job more susceptible to various sources of failures, while the re-run penalty is also growing with the design complexity. Checkpointing is a technique that saves the state of a system that continuously transitions to another state. The purpose of creating a checkpoint for a job is to make it possible to restart an interrupted job from the saved state at a later time. With checkpointing, if a running job encounters termination before its normal completion, be it due to a hardware failure or a human intervention to make resources available for an urgent job, it can resume from the checkpoint closest to the point of termination and continue to its completion. Checkpointing applications can include 1) resume flow where a terminated job can be resumed from the point close to the termination, 2) repair flow to fix OPC hotspot areas without having to process the entire chip and 3) cloud usage where job migration may be necessary. In this paper, we study the runtime and storage impact with checkpointing and demonstrate virtually no runtime impact and very minimal increase in filer storage. Furthermore, we show how checkpointing can significantly reduce runtime in OPC hotspot repair applications
KEYWORDS: Design for manufacturing, Databases, Rule based systems, Semiconducting wafers, System identification, Visualization, Photomasks, Lutetium, Microelectronics, Design for manufacturability
In this paper we combined the hotspot pattern library and the rule-based scoring system into a modularized hotspot-checking rule deck running on an automatic flow. Several DFM (design for manufacture) properties criteria will be defined to build a “score board” for hotspot candidates. When hotspots in the input design are highlighted, the scoring system can identify whether a hotspot is a high risk hotspot or not, and define the severity of the hotspots by extracted DFM properties. The automatic flow will detect which layers are contained in the design then generate a modular rule deck with several corresponding hotspot check modules. The flow also takes snapshots of the high risk hotspots according to the score board automatically. After all the essential hotspot data is collected, the flow will automatically create an HTML-format report which has histograms of properties and overview graph that shows the distribution of hotspots. The aforementioned HTML report containing scored DFM properties and snapshots can help result-viewers to identify the high risk hotspots on the design quickly; namely, users can examine hotspots by snapshots without loading the whole design into layout viewer tools. By comparing the hotspot checking result with real defects from wafer data, a true hotspot’s values of DFM properties can be obtained. We believe this is helpful for users to improve their hotspot rules in accuracy.
The Mask Data Correctness Check (MDCC) is a reticle-level, multi-layer DRC-like check evolved from mask rule
check (MRC). The MDCC uses extended job deck (EJB) to achieve mask composition and to perform a detailed check
for positioning and integrity of each component of the reticle. Different design patterns on the mask will be mapped to
different layers. Therefore, users may be able to review the whole reticle and check the interactions between different
designs before the final mask pattern file is available. However, many types of MDCC check results, such as errors from
overlapping patterns usually have very large and complex-shaped highlighted areas covering the boundary of the design.
Users have to load the result OASIS file and overlap it to the original database that was assembled in MDCC process on
a layout viewer, then search for the details of the check results. We introduce a quick result-reviewing method based on
an html format report generated by Calibre® RVE. In the report generation process, we analyze and extract the essential
part of result OASIS file to a result database (RDB) file by standard verification rule format (SVRF) commands.
Calibre® RVE automatically loads the assembled reticle pattern and generates screen shots of these check results. All the
processes are automatically triggered just after the MDCC process finishes. Users just have to open the html report to
get the information they need: for example, check summary, captured images of results and their coordinates.
Access to the requested content is limited to institutions that have purchased or subscribe to SPIE eBooks.
You are receiving this notice because your organization may not have SPIE eBooks access.*
*Shibboleth/Open Athens users─please
sign in
to access your institution's subscriptions.
To obtain this item, you may purchase the complete book in print or electronic format on
SPIE.org.
INSTITUTIONAL Select your institution to access the SPIE Digital Library.
PERSONAL Sign in with your SPIE account to access your personal subscriptions or to use specific features such as save to my library, sign up for alerts, save searches, etc.