Manufacturing Digital's Alpha AXP: Rapid Applications

Development to Assure Critical Success Through Quality

Dr Ian Cox Digital Equipment Scotland Ltd.

Abstract

Adrian Reynolds SASUK

Digital's Alpha AXP product range is at the leading edge of microprocessor technology. Fabrication of such microprocessors requires the routine use of the most advanced manufacturing technology known to man. Similarly, the object oriented technology in SAS is at the forefront of applications development. This paper describes how OOAD was used to support the rapid development of an application that, through the use of simple quality control methods, can give an objective measure of the performance of the fabrication process via its final yield, a key business metric and critical success factor. The paper also traces the history of the software project, as well as describing the project deliverable, in order to convey how rapid applications development can be. The wider implications for information delivery to support quality decision making in a data­rich environment are briefly considered.

Introduction

The concept, if not the reality, of quality improvement is endemic in business life today. In order to meet or exceed customer expectations of our products or services, we are invited to focus attention on the processes which give rise to them: This is as true in software engineering as it is in manufacturing.

It is widely-held that the best paradigm for quality improvement is an adaptation of the scientific method, in which we organise and empower individuals to sustain process improvement through greater process understanding (paying due regard to the

377

business costs involved) [1,2]. A critical success factor in this strategy is the effectiveness of the information delivery systems that help to transform process data into actions, and this paper details one such system that has been engineered within SAS. We consider the business need for the system, its broad functionality, the manner in which it was built, and planned extensions to it.

Digital's Alpha AXP Technology

Digital is the world's leader in the provision of network computer solutions: Alpha represents Digital's commitment to be the technology and solutions leader in open computing through the 1990s and beyond. Alpha is Digital's 64-bit Reduced Instruction Set (RISC) computing architecture designed to provide high levels of performance and reliability [3].

South Queensferry (SQF) , Scotland, is the volume manufacturing plant for the Alpha AXP microprocessors. SQF uses Digital's fourth generation of complementary metal oxide semiconductor chip technology (CMOS-4). This process technology is state of the art, a completed microprocessor having of the order of 1.7 million transistors on an area 2 cm2 (Figure 1). Indeed, the manufacturing process can justifiably claim to be one of the

Figure 1: A packaged Alpha AXP chip. South Queensferry manufactures the device at the centre.

most advanced known to man, involving as it does several hundred process steps, many of which have tolerances almost one hundred times smaller than the thickness of a human hair.

I

Object-Oriented Technology

The 'software crisis', in which most software systems are delivered late and over budget has been well documented [4,5]. There are many parallels with manufacturing industry from the viewpoint of quality improvement, but there is an additional complication in that strategies and technologies for resolving this crisis are still being developed. Object­oriented design and programming methods offer great potential benefits in terms of the reusability, interoperability, maintainability, and extensibility of software [6]. Whilst it is true that to maximise these benefits designers must address more far reaching decisions than simply which programming language to use, it is also true that ready availability of this technology is pre-requisite for its success. In this respect, the SAS system took a major step forward with the release of version 6.08 which provided support for object-oriented applications development through SAS/AF and SAS/EIS technology.

Semiconductor Manufacturing

Within the CMOS-4 technology there are several types of chips or devices which belong to the Alpha AXP family. One example is known internally by the product code DC290, which is fabricated with fifty-eight die in a regular arrangement on a six-inch silicon wafer. Material is tracked and dispositioned through the manufacturing process in lots consisting of twenty-four wafers, each lot being a paJ1icular device type (Figure 2). The final operation at SQP after wafer fabrication is complete is called wafer probe, or simply probe.

One lot = 24 wafers

The Probe Operation

At probe, each die on every wafer is subjected to a series of pass/fail tests to assess its level of functionality. The detailed test flow is a function of the device type. Whenever a device fails a test it is assigned a particular 'bin code': A device that passes all tests is given a special bin code of '$$' to indicate that a one percent yield increase can generate considerable additional revenue (measured in units of $100,000 per year for a high volume product). Clearly probe yield by device type is a key business metric for SQP, and a coherent programme of yield improvement is critical to success.

The DC290 has seventy-five bin codes, which are more or less specific in determining the root causes for failure. In the short term, monitoring of bin codes can identify one-off problems with a particular lot or wafer, whilst monitoring over time can lead to increased yield through appropriate changes to either the manufacturing process or device design.

Statistical Technology

Statistical QUality Control (SQC) has a long history, and aims to advance process understanding by putting limits on the variability that is intrinsic to any process [7,8]. These control limits are obtained by studying historical process data, and, if the limits are appropriate, any limit violation is a signal that the last oulput of the process was unusual. In Statistical Process Control (SPC), repeated determination and removal of the special causes flagged by limit violations gives improved predictability of the process oulput. However, even if no immediate action is possible, control charts can have a wider role to play in directing process improvement

One wafer One device

Figure 2: Possible Experimental Units in Wafer Fabrication

378

- -. - -----------•• __ 'r.;..~'._:::c.·~·~ _.~, .. J~_ . ..;~._._~.'.; _ _ ,._ ..

,

"

, "

f

activity: In a data-rich environment like semiconductor manufacturing, important patterns of variation can go unnoticed simply because of the large volumes of data generated. In such an environment, hypothesis generation tends to be at least as important as hypothesis testing.

From a statistical point of view, the bin codes are die-level attribute data. Data from all wafers from all lots for all device types dating back over a period of six months is held in a single RdB database.

To obtain an objective measure of the probe process, we consider the number of die failing a particular test (N_Fail) in relation to the number of die being presented to that test (N_In). Note here that we can compute N_In in two ways, either grouping by lot or by wafer (ignoring lots). In either case, N_In will, in general, vary from group to group, either because of a differential fall-out at earlier tests or because of some wafers being scrapped prior to being probed. The statistical assumption made is that each test can be characterised by a constant failure rate and a certain level of variability about this (expressed in terms of a PO value between zero and one), and because of the variability in N_In from group to group, we use a p chart to detect special causes.. On this type of chart, subgroups with smaller values of N_In will have wider limits than those with larger values, reflecting the fact that smaller samples give a less precise estimate of the underlying defect rate.

In normal production, the control limits would be determined by fixed PO values that were pre-computed. To make this computation possible, we need to allow the option of calculating new limits from the current set of data.

Finally, we may also wish to consider all bin codes other than $$ as failures, in order to give SQC on the overall yield of the probe process.

The Goal for the Probe sac System

The precise functionality of the SQC at probe application was defined through consultation with the various user groups at SQF. It was agreed that this application should form the

379

definitive tool for accessing, analysing and reporting data held in the RdB database. Naturally, various systems were already in use, and the challenge was to deliver a new application that was so superior that users would want to use it in preference to those which already existed. To this end, critical success factors for the application were considered to be:

The Probe sac System

The menu tree for the interactive SQC system is shown in Appendix 1.

A typical interactive session would proceed as follows:

FiIe/OpenlNew WMDB Data: Select device type, lot type (Production and/or Engineering) and lots required. Lot selection is possible in three ways - the last n lots tested, all lots tested in a certain time period, or a list of lots (which can be imported from an operating system flat file). A sample dialogue box is shown in Figure 3. Entries are used to build up a query, which is then used to extract data from RdB via pass-through SQL. Once the data is available to SAS, it is automatically summarised to allow more rapid generation of p charts and other graphical entries when these are requested. All objects are managed through SAS catalog entries which are originally saved in the work library. As the interactive session proceeds, new objects are created, whilst objects that were created earlier are simply redisplayed as required. The option File/Save allows the current session to be saved to a shared library, from where it could be recovered via File/Open/Existing Saved Extract. The data summarisation step carries out certain data integrity checks: If problems are detected, the user has the option to save the data to a special shared library, where it can be post-processed as required. Such data can be recovered via File/Open/Cleaned Data. Once the data has

:~

,i '., ~.

!'.

.'

,.

.~ x ~ :,;l , :i: [ .;

~~ ~Ij'

.;~

:~~, :-t. l; ~~ ,

.;.

f, ~~ 1~ ~ r f, J~ ~; :; ~i ·t:· }5 }t ~.

~ t.. ,~. '~":

~ ~f

}~

~ ~~ I' ¥: ~.

I ~ , !~

t ~: f; f.·

\. \ ..

been summarised, the display changes to show a simple trend chart of the overall yield by lot, for all lots. The trend chart may actually require several graphical objects, in which case the display shows appropriate navigation arrows to move between these.

Select/Bin Code Listing: Produces a Pareto chart of the total number of failing die in each bin code, shown in Figure 4. In general, the displays produced by the application are sensitive to the current position in the data hierarchy; in this case, the Pareto chart will include all lots in the current dataset (as displayed on the trend chart of overall yield). Clicking on the legend of one of the bars will generate a trend chart for the selected bin code for all lots.

View/Control by Wafer: Produces a graphical summary of the level of control for the current bin code, grouping by wafer ignoring lots (Figure 5). The graph has either a bar or a legend ('OK') fOr each lot. OK indicates no control limit violation for any wafer within the corresponding lot, whilst a bar indicates the presence of one or more special causes within the lot (the number on the bar shows the number of wafers with a control limit violation, whilst the extent of the bar shows the maximum deviation beyond the control limit for these violations). Unless the user has declared otherwise through an option in System/System Administration, the PO values used for all control charts will be assigned rather than computed. Assigned limits are stored by device type in shared catalog entries (as are bin codes, die colours and die coordinates), and only the designated system administrator has write access. Clicking on the an x axis legend displays the p chart for all wafers in the selected lot (Figure 6). Once the p chart is displayed, it is possible to move directly through the dataset at this level by using navigation arrows. Using the menu option Select/Bin Code (Listing) at this point would produce the Pareto chart described above, but only for the devices in the current lot. Clicking on an x axis legend on the p chart produces a wafermap of bin code failures for the selected wafer (Figure 7).

View/Control by Lot: Produces a graphical summary of the level of control for the current bin code, grouping by lot. This is similar to View/Control by Wafer, except that any bars can only contain the number one (Figure 8). Selecting View/Composite Wafermap will

produce a wafermap that pools the number of failures for all wafers in all lots. The colour scale indicates the total number of failures for the current bin code at a particular die location, and such displays can be useful for

. detecting failure modes with systematic within-wafer patterns. Selecting View/Composite Wafermap when a p chart is displayed would produce a composite wafermap for all wafers within that lot.

Building the Probe sac System

The Probe SQC System presented several challenges for the SAS system. These can be classified as follows:

Data access Data management SQC analysis Presentation.

A brief explanation follows of how each area was addressed and how control was given to the user of the application:

Data Access -

The data is held across several different tables in an RdB database. SAS/ACCESS for RdB was used to make the data available and, as mentioned earlier, the pass-through facility was used for efficiency. This ensured that the views to combine the appropriate tables were resolved by RdB (which was running on its own dedicated machine).

The user needed the flexibility to query the data in a number of different ways as explained earlier. As the underlying queries to the database are similar, the same frame was used to prompt for all queries to reduce the amount of code and maintenance required. To ensure that the user is only prompted for what is required for their particular query, the _IllDE_ and _UNHIDE_ methods were used. Figure 3 shows one of the three possible formats for this screen.

Data Management -

This area presented perhaps the largest challenge to the application. As explained in the Statistical Technology section, the number of die being presented to each test is not explicitly present in the data and has to be calculated from the appropriate test flow. The

380

P,-· ~"' ~ __ ,_ ~

~."' .'~-:..,' -~'': -"

application allows the test flow for each device type to be input. verified and maintained. The use of this test flow is facilitated by rapid access to a flexible data structure. and this was made possible by the use of lists within SCL (Screen Control Language). These lists are used to generate data steps which are then used with the raw data to provide a second dataset that holds the information required to make the p charts.

This second dataset is structured to increase the efficiency of report generation and must be permanently associated with the raw data from which it came when it is stored. To achieve this. and to allow easy selection of saved extracts. the dataset label was used to tag extracts with the device type and an optional description that defaults to the creation date­time. The SQL (System Query Language) Dictionary functions were used to present this information to the user to aid retrospective selection of the required extract

SQC Analysis -

This area was made simple by the use of the in-built procedures within SASIQC. To allow graphics to be customised and exceptions to be reported, the SHEWHART procedure was run against the data to produce data summaries and exception tables as well as the charts. This data was then used to build and annotate the VBAR charts used to report exceptions to the user (see Figure 5).

Clicking on the legend of the chart allows drill down to the next data level. This is achieved by checking that the text clicked on by the user is a valid lot ID and then applying a where clause to the data before executing the next run of proc SHEWHART to produce p chart based on the subset of data. Because it is easy to apply pre-calculated limits to the data using proc SHEWHART, it was straightforward to pass this control onto the user.

Presentation -

The graphs shown in this paper and much of the underlying analysis was done using three procedures: PARETO (Figure 4), GCHART with annotate (Figure 5) and SHEWHART (Figure 6). The exception is the wafer map for which no SAS procedure exists. This challenge was met using the Data Step Graphics Interface (DSGI) to produce the

381

wafer maps for· this application. In addition. by incorporating the D~GI code into an OBJECT, the wafer mapping functionality could be made available to future applications. This code was also built into an EIS object to make it available to a much wider selection of data via the metabase within SAS/EIS. The DSGI code represented a considerable coding effort. but through the Object Orientated Application Development (OOAD) technology within SAS/AF and SAS/EIS. this critical functionality has been encapsulated in a way that makes it very easy to use in the future.

The probe SQC system, as detailed so far, is now regarded as Phase I of a more generic probe data analysis system which will be briefly outlined in the next section under 'Future Plans'. Phase 1 was actually commissioned from SAS UK in order to demonstrate the utility of SAS as an applications building environment, since, at the time, the SAS system had been recently acquired by SQF. With the exception of the batch oriented processing for Production, all of the critical success factors for the application were met within a total budget of thirty-five man-days, which included the clarification of requirements and addressing several unforeseen data management problems.

The Probe Data Analysis System: Future Plans

Batch oriented processing of RdB data is regarded as essential: Indeed, this is true for Engineering as well as Production since our experience has been that. due to the large volumes of data, summary reporting will considerably facilitate ad hoc analyses by drawing attention to promising avenues of investigation. The functionality of Phase II of the probe data analysis system has already been defined and is being delivered now. There will be daily, weekly and monthly summary reporting of the predictability of failure rates by bin code by device type, with statistical comparison of summary Pareto charts from the present and previous report .

In addition, Phase III of the project has been defined, with the objective of encompassing the measurement data that underlies the attribute data considered here, to produce a definitive probe data analysis system. Phase III is scheduled for completion within six

months, and, like Phase II, is being undertaken by SQF with consultancy support and training from SAS UK. Further extensions to in-line and electrical test data are also envisaged.

Summary

This paper considered the delivery and functionality of a SAS application that was developed for Digital South Queensferry. A key theme has been technology, in manufacturing, engineering, applications development and statistics, and more particularly, the marriage of these technologies to meet a strategic business plan.

Information delivery in semiconductor manufacturing poses a unique challenge. Given an appropriate level of commitment and expertise from all those involved, it seems that the SAS system will be readily able to meet this challenge.

References

[1] Box, G: International Statistical Review (1993) 61, 3.

[2] Demming, W: Quality, Productivity and Competitive Position, Centre for Advanced Engineering Study, MIT, Cambridge MA.

[3] Alpha AXP Architecture and Systems, Digital Technical Journal (1992) 4, 4.

[4] Boehm, B: Software Engineering Economics, Prentice Hall (1988).

[5] Brooks, F: The Mythical Man Month: Essays on Software Engineering, Addison­Wesley (1975).

[6] Taylor, D: Object-Oriented Technology­A Manager's Guide, Servio (1990).

[7] Shewart, W: Statistical Method, Dover (1938).

[8] Wheeler, D and Chambers, D: Understanding SPC, SPC Inc. (1986).

382

Figures 3 to 8

Figure 3: Specifying a list of lots of device type DC290

Figure 4: Pareto chart of bin codes.

383

~ ., '/ .. '

:~:

j. , '"

L:·.··

Figure 6: A p chart for bin code CS for the wafers in a particular lot.

384

Figure 7: A Wafermap of an Individual Wafer

Figure 8: Control by Lot Exception Reporting

385

·t: ,; ~;

Appendix 1

EXIT

YIELD

CONTROL BY WAFER

SUMMARY STATISTICS

COMPOSITE WAFERMAP

LOG

EXISTING SAVED

EXTRACT

CLEANED DATA

BIN CODE LISTING

BIN CODE PARETO

DIE COORDINATES

SYSTEM

SAMPLE PROGRAM

HELP

Menu structure of the current Probe SQC System.

386