Introduction

In the fast-paced semiconductor equipment industry, getting a new tool to market on time is vital for success. Ever-increasing demands for process yields, tool reliability, and productivity however, are at odds with the software development time required to ensure them. Balancing these forces calls for a new synergy—the unification of design process expertise, control hardware, and control software—to produce reliable semiconductor tools in ever-shorter periods.

An example of his occurred recently when SpeedFam Corporation, a leading supplier of high-throughput precision surface processing systems, enlisted Berkeley Process Control to speed production of the Auriga, a sophisticated new chemical mechanical planarization (CMP) machine. Using Berkeley's breakthrough control architecture, it reached market four months ahead of schedule, achieving unheard-of productivity and reliability.

This white paper details the Auriga's design challenges and the combined SpeedFam-Berkeley solution.

Auriga Project Overview

Bob Allen, Sr. Project Engineer at SpeedFam, provides some important background on the Auriga: "In principle, a CMP machine is a high tech wafer polisher. Technically, it planarizes the surface of silicon wafers by a carefully controlled chemical and abrasive polishing process down to just a few atoms." Virtually any precise integrated circuit with more than three layers of circuitry (such as thin film memory, disk media, or semiconductor wafers) demands that each of the circuit layers be flat prior to disposition of subsequent layers. Since these high-end chips are in high demand, SpeedFam Corporation, an innovator in precision surface processing, sought to develop a high throughput tool—the Auriga—to capture a large share of the emerging CMP market. SpeedFam wanted the Auriga to market yesterday.

Mr. Allen explains that the key to the Auriga's high wafer throughput is not merely polishing many wafers at one time, but overlapping the polish, load, and unload operations. This complex, multitasking design works as follows: a load section transfers dry wafers from cassettes into a rotating five-station servo-controlled index table. The polish section comprises a gantry mechanism that transfers the wafers for planarization to a primary polish table. Slurry, downforce, polish speeds, oscillation range, and other parameters are all controlled by the process recipe. At the end of the process, the wafers are cleaned and unloaded into output cassettes.

Machine control requirements were estimated at 22 servo axes with overlapping asynchronous behavior, hundreds of I/O points, an operator interface, and SECS-II/GEM machine networking. The Auriga would be a highly complex machine.

The Auriga project goals were outlined as follows:

1. Ensure a tight, predictable development process. Each month that the project was delayed could mean millions of dollars of lost revenue. Mr. Allen felt that SpeedFam's existing designs for automation control would no keep pace with the Auriga's requirements-besides time-to-market, manufacturability would suffer as well. So he suggested that SpeedFam start with its previous CMP design, but bring in Berkeley's engineers to simplify the Auriga's automation control system.
2. Boost Wafer Throughput. The Auriga was to increase wafer production from current capacity of 44 wafers per hour to 75 for a standard test process. Production increases had been attempted before by overlapping of the load, polish and unload sections, but with poor results. The problem was not the material science of polishing, but the failure of previous controls to multi-task these operations reliably. Previous designs resulted in what designers called "mystery stops"—occasional unexpected pauses in wafer processing believed to originate somewhere in the control system. To achieve aggressive throughput, Auriga engineers would have to deliver an automation system that "stamped out the mystery stops."
3. Establish Industry-Leading Reliability. CMP machines are complex, and crashing the machine or a wafer is costly. The Auriga Team would re-evaluate all potential failure sources, from high stresses in a flexible cable track to redundant axis sensors to unpredictable control software lock-ups.
4. Improved Process Uniformity. Accurate and repeatable control of downforce during polishing results in greater polish uniformity and predictability. The automation controls introduced by Berkeley would enable a high degree of precision and ensure that process recipe selections successfully locked out potentially damaging sequences.
5. Simplify Machine Manufacturability and Start-up. SpeedFam could not afford to invest the weeks of time commonly required for the start-up phase of a new CMP machine. To ensure the shortest possible start-up phase, the Auriga team would design for the independent, modular "bring-up" of the load, polish, and unload sections. Further, the team would utilize pro-active machine diagnostics throughout. Mr. Allen expected that the resulting improvement in machine reliability would reduce manufacturing, start-up, and maintenance costs, and make the whole project a lot less stressful.

An Uncommon Development Process

There was some skepticism in the SpeedFam camp that Berkeley, a machine control supplier, could integrate successfully into the Auriga's fast track development. SpeedFam engineering were expert at CMP machine development, and had considerable experience with commonly available machine control architectures. But it was the lengthy design and debug cycles common to these bus-based control systems that led Mr. Allen to Berkeley in the first place. The Auriga needed a faster track.

What set Berkeley apart were their decidedly unconventional control products and their control-oriented design methodology. According to David Taylor, Berkeley Project Manager, "Many engineers choose to 'roll their own' machine control systems, choosing the popular servo motion cards, I/O cards and such, and a generic language like C++. But because real-time machine control is particularly tough, getting a machine to work right takes a huge amount of experience and effort. At Berkeley, we pre-integrate most of the control hardware and software needed. They are built to work together from the start. So development is faster and the end machine goes together smoothly."

Berkeley pioneered this integrated control technology more than 15 years ago, and has applied its products in thousands of the world's most sophisticated production machines.

The Development Path

"SpeedFam didn't have time for mistakes," explains Mr. Taylor, "so we adopted a control-oriented design process that we have been working with for many years."

It proceeds as follows:

1. Do all the real design up front (mechanisms, hardware, even software) and get the team to sign off on a detailed operational specification.
2. Configure the control hardware.
3. Develop and test the machine software in parallel modules.
4. Complete the final machine integration and start-up.

This control-oriented design process is unconventional, suggesting that machine design should stem from a firm understanding of machine control technology. That is, if a designer first understands what the control technology can offer, a simpler machine can result, one that is simpler both in hardware and software. You might expect this kind of control-centric perspective from a controls manufacturer like Berkeley, but thousands of reliable, complex machines have proven this design process to yield superior results.

The Operational Specification

In practice, the control-oriented design process was a collaborative effort between Berkeley engineers who new controls, SpeedFam engineers who knew CMP process, and both groups who understood machine design. In several meetings, which consumed nearly one-third of the entire project schedule, the Auriga team hammered out a 227-page document that detailed exactly what the Auriga would do, how it would do it, and what all the possible failure sources might be. At this point, not a single line of code had been written! Mr. Allen commented, "We were all getting a bit nervous that the Auriga was only a machine on paper. Project updates with (SpeedFam) management were getting a bit tense."

On the Berkeley side, however, this perceived "inaction" was considered routine and critical. Berkeley engineers knew that failure to detail exactly how the Auriga would operate could lead to serious re-work later on. The Auriga Specification was extremely detailed, and included sections regarding machine calibration and testing, production machine operation, a top-level operator panel tree, and even process recipe details.

The Resulting Auriga Control Design

A simple, clean control design emerged that not only met machine goals, but also avoided potential problems. One of the more obvious potential failure sources was a flexible cable track that carried the interconnections between the load, polish and unload machine sections. Another potential failure source was the control software needed to multi-task these sections together.

The Auriga team selected a distributed control architecture to meet these and other project goals. Three networked Berkeley MachineWorks™ controllers formed the heart of the control system. Each MachineWorks controller controls up to eight servo axes, with servo amplifiers, pressure regulators, pneumatic valves and other I/O localized to each controller, minimizing interconnections and modularizing machine bring-up and operation.

Integrated USA (Universal Servo Amplifier) brushless servo drive systems were applied on all motion axes except the main polish table, which was driven by a large flux vector torque control system. The USA drives provided up to four servo control axes per package with foolproof connections to the motors and the MachineWorks controller. Neither the motor nor the drive had any field-adjustable parameters, so all calibration and tuning was unified in the controller.

All I/O signals were hooked to the distributed MachineWorks controllers using Berkeley's Micro I/O system, a PLC-style modular I/O structure. The total number of home/limit switches was reduced from 40 to 8 by implementing hard-stop homing, using the controllers' precision torque control capabilities. These and other control-centric design decisions reduced cable track contents by a factor of 10 and significantly improved the Auriga's integrity.

A touch screen was used for all diagnostics, for all test and production operating modes, and for programming and debugging as well.

Lastly, machine connectivity was accomplished on several levels. Each MachineWorks controller communicated with the others through a high-speed machine network. MachineWorks-resident GEM/SECS-II capabilities allowed the Auriga tool to link into the fab floor using an industry-standard connection. The final machine connection was for supervisory and diagnostic data exchange through OpenLink, a Windows NT®-compliant Berkeley gateway.

Separate from the control architecture choice, the Auriga design team made many other proprietary design improvements. Possibly more important was recognizing what the Auriga team did not have to do once the Berkeley control architecture was chosen.

Machine Characterization

Consider the following example, where the Auriga Team avoided a common Catch-22 and really accelerated development time. Most machine development paths require software development to wait for the hardware to be done, or risk developing that software in a vacuum. Yet physical mechanisms cannot traditionally be exercised without much of the software written.

Berkeley helped avoid this trap. Each MachineWorks controller contains a vast amount of pre-installed software: software used to characterize the machine, program the machine, operate the machine, and even debug the machine.

One of these pre-tested software elements is a machine database that makes setting up machine hardware practically an afterthought-underlying machine functions with full diagnostics are provided without writing a single line of code. Berkeley call this process step machine characterization. The machine database is used to record and store all hardware configurations, from axis naming to engineering units, from auto-tuning to machine homing.

The machine database in MachineWorks allowed the hardware and software team members to proceed independently. In the case of the Auriga's wafer unload flipper, the servo axis was cycled to verify that it was correctly assembled. In one prototype, improper assembly resulted in flipper binding that showed up early as high torque values on diagnostic touchscreen panels, thus avoiding costly debugging later on.

At this stage SpeedFam caught and corrected many small (and some larger) problems that would have meant major delays if they had reached the full system testing stage undetected.

Software Development

Although the machine characterization involved a huge amount of control software, the Auriga team hadn't written one line of that control code-it was already resident in the MachineWorks controllers. Now, the "real" machine operation software was needed, and the Auriga team relied heavily on this. Mr. Taylor explains, "Each MachineWorks controller comes supplied with an integrated environment that easily accepted our (three controller) distributed control scheme. All of the networking facilities are provided (in MachineWorks). The multitasking capabilities are provided. Basically, we started the bulk of our Auriga software development by simply figuring out what the machine needed to do instead of worrying about how it would do it." Unlike other control architectures, in which most f the development effort is expended on low-level integration issues, MachineWorks focuses nearly all attention on machine operation, whether the machine is two servo axes or 56.

MachineWorks control programs are broadly organized into tasks and steps. The step, the most basic program element, looks something like a statement in an algorithmic language, but has an extensive internal structure that makes it much more powerful. Tasks can operate simultaneously (multitasking) and are the primary high-level organizing tool for programming. Because of their simultaneous operation, the design of tasks can closely parallel the physical and time-scale organization of the machine being controlled. This multitasking capability directly impacted the Auriga's throughput and allowed for parallel software development. An Auriga software designer explains, "When we sat down to organize the Auriga software, we broke out the parallel tasks knowing that we could program them in parallel. For example, we knew that the unload flipper had to grab wafers and drain them, and that for optimal throughput this should happen in parallel to the scrubber/transfer paddle/elevator function. Using (the Berkeley) platform, I could concentrate on these tasks separately and code them separately, with inter-task communication used only where needed."

For the unload flipper task, the communication between tasks was done via global variables. With tasks that existed on other MachineWorks controllers, the communication medium was network variables. All machine network maintenance was transparent to the programmers. Even GEM/SECS-II capabilities are built into MachineWorks.

According to the lead software engineer, "The resulting code is easy to write, easy to debug, and easy to understand." Once developed, all Auriga MachineWorks tasks can be executed simultaneously, providing an overlapping motion that boosts wafer throughput.

Debugging was also simplified. Part of the MachineWorks development environment is a panel that allows the programmer to view, while the code is running, the current status of variables and monitor which line of code is being run in a task. This panel is an extremely powerful debugging tool. The lead software engineer explains, "For example, a common bug in the development of parallel tasks is an error in the setting of variables used to communicate between tasks. One task ends up waiting for something from another task that will never occur, and the problem manifests itself as a tool that appears to have 'locked up'. In many cases the bug is not readily reproducible and becomes evident only after a very specific sequence of events. With the MachineWorks panel, the programmer can see what steps are being executed in each task and the current status of the variables, quickly debugging the machine well before it begins processing wafers."

Final Machine Integration

The load, polish, and unload sections of the Auriga were brought to life first individually, and then in an overlapping, smooth operation. The moment when the entire Auriga finally came alive was surprisingly anti-climatic. It just "happened" as the Auriga specification had suggested it would.

The first real wafer tests went off nearly without a hitch, and the software rework was limited to operational sequences, not low-level control code. Mr. Taylor put it best: "The Auriga didn't creep through its production trials, it sailed."

Huge Code Savings

Not only did this control-oriented design save valuable development time, but overall code was reduced to just 10,000 lines of MachineWorks steps from the more than 150,000 lines of C++ contained in a previous CMP design. The Auriga team had to write and maintain less than 10% of the equivalent control software!

Fewer new lines of code not only means shorter development time but much higher reliability and MTBF. The software code included in the Berkeley-supplied MachineWorks controllers is proven over thousands of production machines, providing the highest code re-use of any control solution. 100% software/hardware compatibility has been a hallmark of Berkeley control products.

Auriga Market Results

The Auriga is a "killer" tool like no other. From a commercial standpoint, the Auriga hit the market window dead-on. SpeedFam's high throughput machine accelerated the company's growth and market share. From a technical and operational standpoint, the Auriga is possibly even more impressive, especially considering the tight development schedules. It is hard not to blush with these results:

Time to market. The first production unit was up four months ahead of schedule, in an industry where being late is commonplace.

Wafer throughput. Production increased from 44 wafers per hour to between 75-100 in continuous operation, outpacing SpeedFam's competition by nearly 100 percent.

Streamlined control software. Control code was reduced by more than 90 percent! Machine uptime and tool availability has also far exceeded expectations.

Installation time. The first Auriga unit was installed in just 10 days, whereas competing tools take months to install.

Improved manufacturability. The Auriga was installed on the fab floor so quickly because it was built so fast. The machine is fully built and debugged in modules that dramatically shorten build times and reduce work-in-process (WIP).

Process consistency. Intelligent recipe specification and downforce control were integrated into the MachineWorks controllers, significantly enhancing end-product consistency.

In sum, the amazing Auriga success was one part knowledge, one part design discipline and two parts integrated control technology. The result for SpeedFam was immediate success, and a clear signal sent to the semiconductor equipment community that there is now a better way to build machines.

The significance of this story ultimately compelled Semiconductor International magazine to confer upon the Auriga its "Editor's Choice Best Product of the Year" award.

Cooperation between SpeedFam and Berkeley will continue on the next-generation CMP tool in and industry that rewards those who can manage ever-increasing machine complexity.