Tapeout of a chip is a collaboration between the design house and the foundry. Replacing manual error reporting with an automated reporting capability provides a number of benefits to both the report generator and the report recipient.
Efficiency, accuracy, and cost. Everyone—design houses, foundries, EDA tool vendors—is always looking for ways to streamline or automate the design verification process to eliminate human errors, reduce turnaround time, and ensure profitable production.
The process of taping out a chip is a continuous collaboration between the design house and the foundry. During a tapeout, there are constant exchanges of information between the design house and foundry. For example, the following types of data exchanges are routine during the physical verification flow:
- Design house sends selected design rule checking (DRC) violations to the foundry for waiver approval
- The foundry reviews and approves waived error results from intellectual property (IP) providers
- A foundry suggests changes to design layouts that design houses can implement to improve yield
- The foundry and design house both finalize and freeze the design database and archive the verification data
In addition, there are many points of internal information exchange within a company, such as between two or more different functional groups, where the same detailed data that might be provided to an external recipient must be sent between teams or divisions or physical office locations.
Manual report preparation and communication of these types of information have always been significant timesinks in the physical verification process, and subject to inconsistency. In most of these reports, the information transferred includes a visual “snapshot” of a specified layout area (with or without error markers), and a description of the pertinent details. Currently, this documentation is usually generated by hand, using snapshot tools to create the layout snapshot, and word processing or presentation tools to generate the accompanying explanation. Some companies do use in-house scripts or programs to automatically generate all or some of the report information, but even these programs still require additional time and resources to create and maintain them. The snapshot information, along with the GDSII or OASIS database for external recipients, must be delivered (typically using email) to the corresponding party. Figure 1 illustrates a conventional manual reporting flow to an external recipient.
Figure 1: Manual reporting flows require labor-intensive preparation of documentation and time-consuming data transfers.
As you would expect, the process is cumbersome, and can take a significant amount of time both in data preparation and transfer. In addition, the quality of the information provided is often dependent on the expertise and experience of the individual who prepares it. Security is also a constant concern, as emails can be misdirected, intercepted, or inadvertently deleted. On the recipient side, not only must the recipient have the same layout viewing tool, but the person reviewing the report must be familiar with that tool to correctly locate and analyze the issue.
New automated HTML reporting capabilities are improving the efficiency and accuracy of the DRC debugging process while eliminating the need for time-consuming document preparation. Let’s take a look at how that’s being done, using the automated reporting capabilities of the Calibre® RVE™ results viewing tool.
The Calibre RVE automated report function implements an HTML-based reporting flow that eliminates manual report preparation completely. The HTML batch report is run independently after the DRC verification run, and then published to a web server. No modification is required to the DRC deck, and different configurations can be specified for different DRC runs.
The user flow is transformed with automated reporting (Figure 2). Rather than generating all the documentation by hand, the sender simply initiates the HTML batch report run. Once the report is published to the web server, the sender can notify the recipient(s) that the report is available for access. The recipient simply accesses the HTML report on the web server, using whatever security measures the sender has installed. If the recipient decides design changes are required, the revised layout is sent back to the original sender.
Figure 2: An automated reporting process flow greatly simplifies the user’s workload for both the report generator and the report recipient.
Creating a report in HTML provides distribution flexibility and control, as well as customization opportunity. Placing the report on a web server allows the report generator to easily and securely control access to the report, while recipients can easily access the necessary information and coordinate reviews with multiple team members or other departments without emails or paper trails. The report generator can also create customized reporting for each recipient, based on that recipient’s information requirements.
There are two other significant advantages of using a server distribution model:
- The recipient does not have to have the same layout viewing tool as the report generator, eliminating the need for tool expertise and familiarity. All the information needed to analyze the error is contained in the report or accessible through the web server
- The GDSII/OASIS database does not need to be transferred with each snapshot distribution. Decisions can often be made with the information contained in the HTML report alone.
Figure 3 illustrates a report entry for a single error proposed for waiver consideration. All the information needed to analyze the error and layout geometry is provided, enabling faster analysis and waiver decisions.
Figure 3: Excerpt from an HTML report showing an error proposed for waiver consideration.