特表 2024-533219 チャンバ制御のオートチューニング及び処理パフォーマンス評価のための方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-09-12

(54)【発明の名称】チャンバ制御のオートチューニング及び処理パフォーマンス評価のための方法

(51)【国際特許分類】

   G05B 13/02 20060101AFI20240905BHJP

【ＦＩ】

G05B13/02 E

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024514407

(86)(22)【出願日】2022-08-12

(85)【翻訳文提出日】2024-05-02

(86)【国際出願番号】 US2022040194

(87)【国際公開番号】W WO2023034008

(87)【国際公開日】2023-03-09

(31)【優先権主張番号】17/467,020

(32)【優先日】2021-09-03

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

(71)【出願人】

【識別番号】390040660

【氏名又は名称】アプライド マテリアルズ インコーポレイテッド

【氏名又は名称原語表記】ＡＰＰＬＩＥＤ ＭＡＴＥＲＩＡＬＳ，ＩＮＣＯＲＰＯＲＡＴＥＤ

【住所又は居所原語表記】３０５０ Ｂｏｗｅｒｓ Ａｖｅｎｕｅ Ｓａｎｔａ Ｃｌａｒａ ＣＡ ９５０５４ Ｕ．Ｓ．Ａ．

(74)【代理人】

【識別番号】110002077

【氏名又は名称】園田・小林弁理士法人

(72)【発明者】

【氏名】チミノ， マウロ

(72)【発明者】

【氏名】ダン， アルカプラバ

(72)【発明者】

【氏名】バルジャ， サンジーヴ

【テーマコード（参考）】

5H004

【Ｆターム（参考）】

5H004GA03

5H004GB15

5H004HA01

5H004HA03

5H004HB01

5H004HB03

5H004KC34

5H004KC48

(57)【要約】

本明細書に開示された実施形態は、システムをオートチューニングするための方法を含む。一実施形態では、当該方法は、システムが定常状態であるか判断することを含む。その後、当該方法は、システムを起動することを含む。一実施形態では、当該方法は、起動されたシステムからの処理フィードバック測定値を保存して、一組の保存データを提供することを含む。一実施形態では、一組の保存データが、起動されたシステムによって生成されたすべての利用可能なデータのサブセットである。一実施形態では、当該方法は、起動されたシステムがいつ定常状態に戻るかを判断することと、一組の保存データを使用して、システムをチューニングすることとをさらに含む。
【選択図】図１Ｂ

【特許請求の範囲】

【請求項1】

システムをオートチューニングするための方法であって、
前記システムが定常状態であるか判断することと、
前記システムを起動することと、
起動された前記システムからの処理フィードバック測定値を保存して、一組の保存データを提供することであって、当該一組の保存データが、前記起動されたシステムによって生成されたすべての利用可能なデータのサブセットである、一組の保存データを提供することと、
前記起動されたシステムがいつ前記定常状態に戻るかを判断することと、
前記一組の保存データを使用して、前記システムをチューニングすることと
を含む方法。

【請求項2】

前記システムを起動する前に、処理フィードバック測定値内のノイズレベルを特定することをさらに含む、請求項１に記載の方法。

【請求項3】

前記ノイズレベルが、前記方法の反復ごとに特定される、請求項２に記載の方法。

【請求項4】

前記ノイズレベルが、前記方法の第１の反復の前に、かつ前記方法のあらかじめ定められた数の反復の後に、又はあらかじめ定められた期間の後に特定される、請求項２に記載の方法。

【請求項5】

処理フィードバック測定値を保存することが、連続的なデータポイントを一連の長方形ボックスにグループ分けすることを含み、所与の長方形ボックス内の第１のデータポイントのみが、前記一組の保存データの一部として保存される、請求項１に記載の方法。

【請求項6】

前記ボックスの高さが、前記システム内のノイズの関数である、請求項５に記載の方法。

【請求項7】

長方形ボックスが時間軸に対して実質的に平行な傾きを有する場合、前記起動されたシステムが前記定常状態に戻る、請求項５に記載の方法。

【請求項8】

前記システムをチューニングすることが、前記システムの閉ループコントローラのゲイン値を設定することを含む、請求項１に記載の方法。

【請求項9】

収集されたデータを内部シミュレーションモデルと比較することにより、前記チューニングを検証することをさらに含み、前記内部シミュレーションモデルが、前記保存データから抽出された情報から、又は前記システムの第１原理解析から得られたモデルである、請求項８に記載の方法。

【請求項10】

前記システムが、半導体製造ツールにおける閉ループ制御システムである、請求項１に記載の方法。

【請求項11】

前記閉ループ制御が、熱システム又は圧力システムの制御である、請求項１０に記載の方法。

【請求項12】

前記システムが、半導体製造ツールにおける複数の閉ループ制御システムである、請求項１に記載の方法。

【請求項13】

半導体処理ツールにおけるレシピパフォーマンスをモニタリングする方法であって、
システムにおけるノイズレベルを特定することと、
前記システムからの処理フィードバック測定値を保存して、一組の保存データを提供することであって、当該一組の保存データが、前記システムによって生成されたすべての利用可能なデータのサブセットである、一組の保存データを提供することと、
前記一組の保存データを一組の基準データと比較することと
を含む方法。

【請求項14】

前記一組の基準データが、前記レシピの既知の良好な反復からのデータである、請求項１３に記載の方法。

【請求項15】

前記一組の保存データが前記一組の基準データと異なる場合、レシピパフォーマンスステータスを報告することをさらに含む、請求項１３に記載の方法。

【請求項16】

前記一組の保存データと前記一組の基準データとの間の違いが、記録されたデータポイントの時間遅延シフトである、請求項１５に記載の方法。

【請求項17】

処理フィードバック測定値を保存することが、連続的なデータポイントを一連の長方形ボックスにグループ分けすることを含み、所与の長方形ボックス内の単一のデータポイントのみが、前記一組の保存データの一部として保存される、請求項１３に記載の方法。

【請求項18】

半導体処理ツールであって、
チャンバ、及び
前記チャンバとインターフェース接続する複数の構成要素
を備え、前記構成要素の各々が、異なる閉ループ制御システムで制御され、前記半導体処理ツールが、前記閉ループ制御システムをチューニングするためのオートチューニングモジュールを備え、前記オートチューニングモジュールが、
ノイズ推定モジュールであって、各閉ループ制御システムに存在するノイズを特定する、ノイズ推定モジュールと、
データ収集モジュールであって、当該データ収集モジュールが、前記閉ループ制御システムからの処理フィードバック測定値を保存して、各閉ループ制御システムのための一組の保存データを提供し、前記一組の保存データが、前記閉ループ制御システムによって生成されたすべての利用可能なデータのサブセットである、データ収集モジュールと
を備えている、半導体処理ツール。

【請求項19】

処理フィードバック測定値を保存することが、連続的なデータポイントを一連の長方形ボックスにグループ分けすることを含み、所与の長方形ボックス内の単一のデータポイントのみが、前記一組の保存データの一部として保存される、請求項１８に記載の方法。

【請求項20】

前記チャンバとインターフェース接続する前記複数の構成要素が、温度制御された構成要素及び圧力制御された構成要素を備えている、請求項１８に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、２０２１年９月３日出願の米国特許出願第１７／４６７，０２０号からの優先権を主張し、その全内容は参照によって本明細書に組み込まれる。

【0002】

本開示の実施形態では、半導体処理の分野に関し、具体的には、半導体処理環境におけるチャンバ制御のオートチューニング及び処理パフォーマンス評価に関する。

【0003】

関連技術の記載
半導体業界では、処理ツールは非常に複雑なシステムに成長している。処理の均一性を向上させる努力の一環として、様々な処理パラメータを測定するために、処理ツールには多数のセンサが取り付けられている。センサは、制御アーキテクチャの一部であり得る。制御アーキテクチャは、アクチュエータを調節するために使用され、それにより処理パラメータを変化させることができる。例えば、半導体ツールにおける一部の処理パラメータには、温度、圧力、ＲＦ周波数、電力などがあるが、これらに限定されるものではない。このような半導体ツールを設定する処理の間、半導体ツールの正確かつ精密な制御を実現するために、システムの制御パラメータ（例えば、ゲイン値）を設定する必要がある。現在では、チューニングタスクを担当するエンジニアには、そのタスクを達成するための特定のスキルが要求されるが、かようなエンジニアはつかまらない可能性があるため、チャンバの設定時間がさらに延長される。

【0004】

チャンバを長時間にわたって稼働させると、通常、一部のハードウェア構成要素の挙動及び／又はパフォーマンスの変化が見られる。そのため、このようなドリフトを補正するために使用される処理として、種々の閉ループコントローラの再チューニングが挙げられる。しかしながら、このタスクには膨大なエンジニアリング時間が必要であり、それに比例してチャンバのダウンタイムも等しく長くなる。

【発明の概要】

【0005】

本明細書に開示された実施形態は、システムをオートチューニングするための方法を含む。一実施形態では、当該方法は、システムが定常状態であるか判断することを含む。その後、当該方法は、システムを起動することを含む。一実施形態では、当該方法は、起動されたシステムからの処理フィードバック測定値を保存して、一組の保存データを提供することを含む。一実施形態では、一組の保存データが、起動されたシステムによって生成されたすべての利用可能なデータのサブセットである。一実施形態では、当該方法は、起動されたシステムがいつ定常状態に戻るかを判断することと、一組の保存データを使用して、システムをチューニングすることとをさらに含む。

【0006】

追加の実施形態は、半導体処理ツールにおけるレシピパフォーマンスをモニタリングする方法を含む。一実施形態では、当該方法は、システムにおけるノイズレベルを特定することを含む。ノイズレベルが特定された後、実施形態は、システムからの処理フィードバック測定値を保存して、一組の保存データを提供することを含む。一実施形態では、一組の保存データは、システムによって生成されたすべての利用可能なデータのサブセットである。一実施形態では、当該方法は、一組の保存データを一組の基準データと比較することをさらに含む。

【0007】

実施形態は、半導体処理ツールをさらに含み得る。一実施形態では、ツールは、チャンバ、及びチャンバとインターフェース接続する複数の構成要素を備えている。一実施形態では、構成要素の各々は、異なる閉ループ制御システムで制御されている。一実施形態では、処理ツールは、閉ループ制御システムをチューニングするためのオートチューニングモジュールを備えている。一実施形態では、オートチューニングモジュールは、各閉ループ制御システムに存在するノイズを特定するノイズ推定モジュールを備えている。一実施形態では、オートチューニングモジュールは、データ収集モジュールをさらに備えており、データ収集モジュールは、閉ループ制御システムからの処理フィードバック測定値を保存して、各閉ループ制御システムのための一組の保存データを提供する。一実施形態では、一組の保存データは、閉ループ制御システムによって生成されたすべての利用可能なデータのサブセットである。

【図面の簡単な説明】

【0008】

【図1A】実施形態に係る、半導体処理ツール内の単一ループ制御アーキテクチャの概略図である。

【図1B】実施形態に係る、図１Ａの制御アーキテクチャで制御される温度制御構成要素を有する半導体処理チャンバの概略図である。

【図2A】実施形態に係る、２つの制御ループを有する半導体処理ツールの制御アーキテクチャの概略図である。

【図2B】実施形態に係る、図２Ａの制御アーキテクチャで制御される温度制御構成要素及び圧力制御構成要素を有する処理チャンバの概略図である。

【図3】実施形態に係る、複数の制御ループを有する半導体処理ツールの制御アーキテクチャの概略図である。

【図4A】実施形態に係る、経時的な応答変数のグラフである。

【図4B】実施形態に係る、経時的な応答変数の既知値と比較した経時的な応答変数のグラフである。

【図5】実施形態に係る、半導体製造ツールにおける改善された閉ループ制御のためのデータ収集の方法の処理フロー図である。

【図6】実施形態に係る、応答変数の幾何学的減少を示すグラフである。

【図7】実施形態に係る、半導体ツールをオートチューニングする方法の処理フロー図である。

【図8】実施形態に係る、半導体ツール上のレシピをモニタリングする方法の処理フロー図である。

【図9】本開示の一実施形態に係る、例示的なコンピュータシステムのブロック図を示す。

【発明を実施するための形態】

【0009】

半導体処理環境におけるチャンバ制御のオートチューニング及び処理パフォーマンス評価についてここに説明する。以下の説明では、本開示の実施形態の完全な理解をもたらすために、多数の具体的な詳細が提示されている。当業者であれば、これらの具体的な詳細がなくても本開示の実施形態を実施できることは明らかであろう。他の事例では、不必要に本開示の実施形態を不明瞭にしないように、周知の態様は詳細に説明されない。さらに、図に示す様々な実施形態は例示的な表現であり、必ずしも縮尺どおりには描かれていないことを理解すべきである。

【0010】

半導体製造における温度と圧力の制御は、期待される処理結果を達成するために極めて重要である。複数のステーションのマルチチャンバ処理プラットフォームを利用することで、処理スループットを向上させ、基板上で複数の種類の処理を順次行うことができる。そのために、このような複雑なプラットフォームでは、プラットフォーム全体にわたって、温度、圧力、流量の信号や、動く構成要素の電力使用量と運動をモニタリングするために、何百ものセンサが組み込まれなければならない。多くのセンサを作動させるために、プラットフォームは、応答変数（例えば、温度や圧力）を所望のターゲットに向けて駆動するために、上述の信号を自動的に制御する手段を組み込まなければならない。上述したように、プラットフォームのドリフトを考慮するために、コントローラを初期設定し、継続的にモニタリングする必要がある。

【0011】

半導体プラットフォームにおける制御システムの例としては、温度制御リッド、マルチゾーン温度制御ガス分配システム、温度制御面板、基板背圧コントローラ、及びプロセスチャンバへのガス供給のための圧力制御アンプルがある。１つの処理チャンバ内にある上記のコントローラの数は、容易に５０以上のセンサに及ぶことがある。例えば、あるシナリオでは、単一のチャンバが、１つのリッドヒータ、４つの面板ヒータ、３０個のガスヒータゾーン、４つの基板背圧コントローラ、１０個の圧力制御アンプル及びリザーバ、場合によっては、処理チャンバの中でサセプタを動かすための複数の電動アセンブリを含み得る。

【0012】

ここで図１Ａを参照すると、一実施形態に係る、制御アーキテクチャ１０８の構造の概略図が示されている。一実施形態では、全体的な制御アーキテクチャ１０８は、アクチュエータ１０３、入力／出力（Ｉ／Ｏ）デバイス１０２、及びコンピューティングサーバ１０１を含む。アクチュエータ１０３は、制御信号１０６を処理環境に供給する。一実施形態では、アクチュエータ１０３は、バルブ、増幅器、シリコン制御整流器（ＳＣＲ）、ドライバ、ポンプ、又は質量流量コントローラであってもよいが、これらに限定されるものではなく、その目的は、制御される処理ハードウェアと直接インターフェース接続することである。一実施形態では、Ｉ／Ｏデバイス１０２は、処理フィードバック１０７を受信する。処理フィードバック１０７は、処理のパラメータ（例えば、温度や圧力等）をモニタリングするセンサによって生成され得る。例えば、処理フィードバック１０７には、温度、圧力、流量トランスデューサ測定値、又はレベルトランスデューサ測定値が含まれ得るが、これらに限定されない。

【0013】

一実施形態では、Ｉ／Ｏデバイス１０２は、処理フィードバック１０７をコンピューティングサーバ１０１へ供給する。コンピューティングサーバ１０１は、所望の反応を特定し、その反応をＩ／Ｏデバイス１０２に伝達し、次いで、Ｉ／Ｏデバイス１０２が所望の反応１０５をアクチュエータ１０３へ中継する。用途に関係なく、コンピューティングサーバ１０１は、制御パラダイムが保存かつ実行される場所である。コンピューティングサーバ１０１は、バス１０４を介してＩ／Ｏデバイス１０２と通信する。すなわち、Ｉ／Ｏデバイス１０２は、最新の処理フィードバック１０７でコンピューティングサーバ１０１を更新し、コンピューティングサーバ１０１は、取るべき対応する所望の反応をＩ／Ｏデバイス１０２に伝達する。

【0014】

次に、図１Ｂを参照すると、実施形態に係る処理ツール１２０の概略図が示されている。一実施形態では、処理ツール１２０は、チャンバ１２１を備えている。加熱された面板１２５は、流入ガスがチャンバ１２１に入るための孔を有する。面板の熱エネルギーの一部がガスに移動し、次いで、そのガスが、下方へと、基板支持体１２３上に置かれた基板１２２に向かう。面板は基板１２２に近接しているため、望ましい処理結果を得るために面板の温度制御が非常に重要である。したがって、面板の温度を正確に測定するために温度トランスデューサ１２４が使用され得る。その測定値１０７は、制御アーキテクチャ１０８のコンピューティングサーバ１０１で実行される制御戦略によって使用され、その目的は、面板の温度を目標値に維持することである。

【0015】

図１Ｂに示された事例では、アクチュエータ１０３は、外部電源に接続されたＳＣＲであり、Ｉ／Ｏデバイス１０２を介してコンピューティングサーバ１０１から供給されるデジタル信号１０５によって駆動され得る。ＳＣＲアクチュエータ１０３は、面板１２４の温度を制御する制御信号１０６を生成する。このように、コンピューティングサーバ１０１は、面板１２５の温度１０７が所望の値に到達し、その値に留まるように、デジタル信号１０５を扱う方法を決定する。

【0016】

ここで図２Ａを参照すると、一実施形態に係る、制御アーキテクチャ２０８の構造の概略図が示されている。一実施形態では、コンピューティングサーバ２０１は、対応する制御出力２０６Ａ及び２０６Ｂを使用して、２つの異なる処理フィードバック２０７Ａ及び２０７Ｂを制御する役割を担っている。この場合、同じＩ／Ｏデバイス２０２を使用して、コンピューティングサーバ２０１を（バス２０４を介して）制御アーキテクチャの残りの部分とインターフェース接続することができる。コンピューティングサーバ２０１は、所望の反応を特定し、その反応をＩ／Ｏデバイス２０２に伝達し、次いで、Ｉ／Ｏデバイス２０２が、所望の反応２０５Ａ及び２０５Ｂをそれぞれアクチュエータ２０３Ａ及び２０３Ｂへ中継する。一実施形態では、２つの異なるアクチュエータ２０３Ａ及び２０３Ｂが、それぞれ、処理フィードバック２０７Ａ及び２０７Ｂの制御のために使用され得る。図２Ａの制御アーキテクチャ２０８は、２つの閉ループ制御を含むと言われている。第１の閉ループ制御は、処理フィードバック２０７Ａの制御用であり、第２の閉ループ制御は、処理フィードバック２０７Ｂの制御用である。

【0017】

次に、図２Ｂを参照すると、実施形態に係る処理ツール２２０の概略図が示されている。一実施形態では、処理ツール２２０は、２つの閉ループ制御アーキテクチャの一例である。面板２２５の温度制御に加えて、制御アーキテクチャ２０８は基板の裏側圧力も制御する。この例では、ガスライン２２６内の圧力を測定する圧力計２２７を用いて圧力測定値２０７Ｂが得られる。サーバ２０１は、圧力フィードバック２０７Ｂのリアルタイム通知を受信し、その応答として質量流量制御アクチュエータ２０３に命令し、制御出力２０６Ｂに応答してポンプ２２８を駆動する。

【0018】

図１Ｂに示した実施形態と同様に、基板２２２は、面板２２５の下方の基板支持体２２３上にある。温度トランスデューサ２２４は、温度フィードバック２０７Ａを制御アーキテクチャ２０８に供給する。サーバ２０１は、温度フィードバック２０７Ａのリアルタイム通知を受信し、その応答として、温度制御アクチュエータ２０３（例えば、ＳＣＲ）に命令し、温度制御アクチュエータ２０３が、面版２２５の温度を制御する制御信号２０６Ａを出す。

【0019】

図示された実施形態では、一対の閉ループ制御が示されている。しかしながら、実際の処理ツールでは、ツール２２０の全体的な制御アーキテクチャは、多数の閉ループ制御（例えば、４０以上の閉ループ制御）を含み得ることを理解されたい。一実施形態では、各ループは、異なるトランスデューサ及びアクチュエータとインターフェース接続するように設計されている。

【0020】

ここで図３を参照すると、実施形態に係る、複数の閉ループ制御を伴う制御アーキテクチャ３０８の構造の概略図が示されている。図３では、フィードバック信号バス３０７Ａ－ｎは、すべてのトランスデューサからのフィードバックラインを含むバスである。一実施形態では、アクチュエータ３０３Ａ～３０３ｎの数は、フィードバック信号３０７の数に等しい。Ｉ／Ｏデバイス３０２は、デジタル信号３０５ａ～３０５ｎによってアクチュエータ３０３Ａ～３０３ｎの各々と通信可能に連結し得る。アクチュエータ３０３ａ～３０３ｎは、制御信号３０６ａ～３０６ｎによってシステムに連結され得る。図示されるように、単一のコンピューティングサーバ３０１が、Ｉ／Ｏデバイス３０２に連結されたバス３０４を介して、アクチュエータ３０３Ａ～３０３ｎの各々とインターフェース接続し得る。

【0021】

ｎの値が増加するにつれて、制御アーキテクチャ３０８内のすべてのコントローラをチューニングするのに必要なエンジニアリング時間や、チャンバをレシピ実行可能な状態にするのに必要な設定時間も増加することを理解されたい。さらに、チューニングタスクを担当するエンジニアには、そのタスクを達成するための特定のスキルが要求されるが、かようなエンジニアはつかまらない可能性があるため、チャンバの設定時間がさらに延長される。このようなチューニングは、ツールを初めて使用する前にも必要である。

【0022】

チャンバを長時間にわたって稼働させると、通常、一部のハードウェア構成要素の挙動及び／又はパフォーマンスの変化が見られる。このようなドリフトを補正するには、種々の閉ループコントローラを時々再チューニングすることで十分であるかもしれない。しかしながら、このタスクには膨大なエンジニアリング時間が必要であり、それに比例してチャンバのダウンタイムも等しく長くなる。万全を期して、又はおそらくベストプラクティスとして、閉ループコントローラの一部を定期的に再チューニングするのもよいかもしれない。このような措置は、例えば、既に予定されているチャンバのダウンタイム中に行うことができる。しかしながら、このタスクを達成するために必要なリソースが膨大であることが、めったに実行されない理由かもしれない。

【0023】

したがって、本明細書に開示される実施形態は、制御アーキテクチャ３０８内のすべてのループを自動的にチューニングする方法を含む。これにより、必要なエンジニアリング時間が、無視できるレベルにまで短縮される。さらに、実施形態では、本明細書に開示されたオートチューニング方法を使用するラボオペレータに必要とされる重要なスキルセットが大幅に少なくなる。さらに、ラボオペレータは、チャンバが通常稼動していない時間（例えば、夜間）にチューニング作業を自動的に実行するようスケジュールすることができる。さらに、このようなオートチューニング法を利用できることにより、定期的なメンテナンス、ひいては、既知のシステムの故障又はドリフトによって引き起こされる任意のメンテナンスのスケジューリングが簡単になる。

【0024】

上記の利点を半導体製造ツールに適用するために、オートチューニング方法は、リアルタイムのソフトウェア環境において、最小限の支援で当該方法を確実かつ正確に使用する能力を含み得る。モニタリングされる処理は、未知の帯域幅を有する場合があり、潜在的に、処理の帯域幅は、種々の大きさであり得る。さらに、オートチューニングは、必要とされるサーバメモリの量について最小限のフットプリントを有するべきである。したがって、この方法は、各チャンバ内の多数の処理に対して同時に実行することができ、ツール周辺で他の作業が行われている間にバックグラウンドで実行することができる。

【0025】

上記のような特徴を有するオートチューニング法は、現在、半導体製造施設内では使用されていないことを理解されよう。１つの理由としては、サードパーティーのオートチューニングソフトウェアが、通常、半導体業界で一般的な独占ソフトウェアインフラストラクチャ内で使用が許されていないことが挙げられる。さらに、類似の方法は、課せられる要件がそれほど厳しくない。例えば、このような方法は、オートチューニングルーチンのみを実行する（他のリソース集約的なプロセスは実行しない）専用コンピュータ上で実行される。さらに、既存の処理は、一度に１つの閉ループ制御で使用されるように設計されている。したがって、このような方法は、半導体製造施設には適合せず、チャンバのダウンタイムを最小限に抑える方法としては実用的ではない。

【0026】

本明細書に開示される実施形態は、オートチューニング機能に加えて、処理レシピ全体を通して、ｎ個の閉ループコントローラのパフォーマンスをモニタリングする能力も提供することができる。ｎの値が大きい複雑なシステムでは、処理レシピを通じて、各ループのパフォーマンスをモニタリングすることがしばしば重要になる。これにより、任意のパフォーマンスドリフトを適時に報告し、ドリフトが発生したループを特定することができる。ドリフトするループを特定することで、ドリフトの根本原因を見つける処理の速度が上がり、潜在的な生産の無駄を最小限に抑えることができる。

【0027】

一般的なパフォーマンスモニタリングは、処理フィードバック（例えば、上述のフィードバック１０７）が、一部のあらかじめ設定された限界値を超えているかどうか、予想よりも速く若しくは遅く変化しているかどうか、又は所望の値から大きく逸脱していないかどうかをモニタリングすることを可能にする。同様に、一般的なパフォーマンスモニタリングは、コントローラの動作１０６が所定の限界値を超えた場合に、ユーザに通知する。しかしながら、図４Ａ及び図４Ｂに示すように、このような一般的なパフォーマンスモニタリングでは、処理フィードバックが期待通りに挙動したかどうかを特定できないことがある。例えば、図４Ａの処理フィードバック４３１は、特定の処理レシピの間に期待される処理挙動を表し得る。図４Ａに示すように、処理フィードバック４３１は、ドリフト限界値４３２及び４３３の範囲内に収まっており、その結果、処理挙動は許容可能であるとみなされる。しかし、図４Ｂでは、同じ処理レシピの、後の実行作業中に観察された処理フィードバック４３４は、先のレシピで観察された挙動４３１に対して時間的にずれているように見える。挙動４３４が限界値４３２及び４３３の範囲内に収まっているため、一般的なパフォーマンスモニタリングでは、処理挙動４３４が許容可能とみなされるであろう。しかしながら、挙動４３１によって期待値が設定されると、挙動４３４はさほど期待通りではない。

【0028】

本明細書で開示される実施形態に従って説明されるレシピパフォーマンスモニタリングは、上述の問題を解決することができる。つまり、レシピパフォーマンスモニタリングは、各々の閉ループコントローラがレシピを通じて、期待通りに動作しているかどうかのリアルタイム情報をユーザに提供する。このようなパフォーマンスモニタリングが半導体処理サーバ内で機能するためには、オートチューニング法について述べたのと同様の要件が必要である。レシピパフォーマンスモニタリングは、リアルタイムサーバ環境で実行可能でなければならず、レシピパフォーマンスモニタリングは、複数のループの同時モニタリング可能にするように、サーバのメモリ使用量を最小限に抑えなければならず、レシピパフォーマンスモニタリングは、閉ループコントローラが動作している間、バックグラウンドで実行しなければならない。サーバのメモリ使用量を最小限に抑えることは、非常に重要なことであり、簡単ではない。実際に、処理のレシピは、数分から数時間に及ぶこともある。さらに、モニタリングされた信号は、非常に速い速度でリフレッシュされる。つまり、同じ信号の２つの連続する更新の間の時間が非常に短い場合がある。そのため、単位時間あたり多数のデータサンプルを分析に利用することができる。したがって、レシピパフォーマンスモニタリングにとって、データをリアルタイムで最適化できることが非常に重要である。

【0029】

レシピパフォーマンスモニタリングの幾つかの事例を非リアルタイム環境で見つけることができる。オフライン容量で実装された場合、レシピモニタリングはメモリ使用量制限に縛られない。代わりに、このようなモニタリングは通常、専用サーバでオフラインで動作する。リアルタイム環境におけるパフォーマンスモニタリングの利点は、半導体処理ツールにおける予期せぬパフォーマンスに対応する通知を即座に受け取る能力である。これにより、生産の無駄を最小限に抑えることができる。

【0030】

本明細書に開示された実施形態は、チャンバ内の閉ループコントローラの大部分を同時にかつ自動的にチューニングすることを意図したオートチューニング方法、及びプロセスレシピ全体を通してこのようなコントローラのパフォーマンスをモニタリングすることを意図したレシピパフォーマンスモニタリングを含む。これら２つの用途は、データマイニングのための同様の基礎的方法に基づく。データマイニング処理は、メモリ使用量が少なく、実行コストが低いため、これらの用途をリアルタイム実行に適したものとする。

【0031】

オフラインデータ分析の際、分析が実行される前にデータセット全体が利用可能である。このようなデータは、時系列として入手可能で、多くの場合、データポイントは時間的に等間隔に配置されている。対照的に、リアルタイムデータ分析では、分析が実行される時点ではデータ時系列全体が利用可能ではない。つまり、過去と現在のデータしか使えないわけである。さらに、リアルタイムのデータ分析では、多くの場合、特定の時間レートでデータを収集かつ保存することができない。これは、時系列が長すぎる場合、処理レシピが終了する前に、システムが利用可能なメモリ資源を使い果たしてしまう可能性があるためである。したがって、オンラインデータ解析は、以下の理由によりもともと困難である。１）オンラインデータ解析には、どの入力データポイントが将来の分析のために保存する価値があるかを判断するより効率的な方法が必要である。２）分析が実行される時点で全体像を把握できないため、過去と現在のデータに対して実行される分析は、誤った結果に至る可能性がある。

【0032】

これより図５を参照すると、実施形態に係る、データマイニングのための処理５４０の処理フロー図が示されている。図５に示すように、入力データポイント選択のために開発された方法は、ノイズ推定操作５４１と、その後のデータ収集操作５４２の操作を含む。ノイズ推定操作５４１の間、信号のノイズが推定され、処理フィードバックのどの変動が処理応答の実際の変動に対応し、代わりにどの変動が測定誤差に起因するかを判断する。ノイズは、外部の電力源／磁気源からの干渉やトランスデューサの不正確さに起因することがあり、周波数成分が処理の帯域幅をはるかに超える範囲にあるので、高周波変動として特徴付けることができる。

【0033】

一実施形態では、ノイズ推定操作５４１は、データを収集する必要があるたびに実行する必要はない。例えば、ノイズ推定操作は、毎回のデータ収集の前、１日に１回、１ヶ月に１回、１年に１回、又はその他の任意のあらかじめ設定された期間に実行することができる。ノイズ推定操作５４１の結果は、後続のデータ収集操作で利用される単一の値であるか、又は将来の参照のために保持され得る値である。

【0034】

データ収集操作５４２の間、連続的なデータは、図６に示すように長方形ボックス６５０にグループ化される。一実施形態では、長方形ボックス６５０の高さＤは、ノイズ推定の関数である。一実施形態では、長方形ボックス６５０は、処理フィードバックの可変性に依存する。つまり、連続的なデータポイントが、所定のボックス内に収まる場合、そのようなデータポイント間の相対的な変動は切り捨てられる。一実施形態では、新しいボックスは、ノイズレベル、処理フィードバックの変動量、及びこのようなボックスの相対的な傾きの関数として作成される。各ボックスに対して１つのデータポイントだけを記憶すべきであり、新しいボックスが作られるまでは、残りのデータポイントを切り捨てることができる。この方法では、収集されるデータポイントの量は、生の処理フィードバック測定値のサンプリングレートに反比例する因数によって大幅に削減される。さらに、任意の時点における処理フィードバックの値は、保存されている隣接するデータポイントからの簡単な補間によって、収集されたデータから簡単に取り出すことができる。

【0035】

長方形ボックス６５０アプローチによるデータ収集により、保存されたデータがデータのサンプリングレートに影響されないことを理解されたい。例えば、データがマイクロ秒レート、ナノ秒レート、秒レート、又は任意のレートで取得される場合、保存される全データは、長方形ボックス６５０内の単一の値、及び長方形ボックスの形状／傾きを含む。つまり、記録されたデータは、すべての利用可能なデータのごく一部である。必要なデータ量が少ないため、実施形態は、専用の分析サーバでオフラインで実行する必要がなく、データ収集と分析をリアルタイムで実行することが可能となっている。

【0036】

これより図７を参照すると、実施形態に係る、閉ループコントローラをオートチューニングするための処理７６０の処理フロー図が示されている。一実施形態では、処理７６０は、処理７６０を開始するユーザコマンドで開始し得る。他の実施形態では、処理７６０は、自動的に開始されてもよい。例えば、処理７６０は、予め設定された期間の後、又は予め設定されたレシピサイクル数が実行された後に開始され得る。一実施形態では、オートチューナの第１の操作７６１は２回行われる。第１の操作７６１は、操作７６３で、処理フィードバック測定値内のノイズを特定することと、操作７６２で、処理フィードバックが定常状態にあるかどうかを評価することとを含む。操作７６２は、将来のチューニング操作７６７の正確性を向上させるために非常に重要である。処理フィードバックは、収集されたデータから生成された長方形の時間軸に対する配向の分析に基づいて、定常状態にあると仮定される。

【0037】

一旦ノイズが測定され、処理フィードバックが定常状態にあると評価されると、処理７６０は、操作７６４に進む。操作７６４は、システムを起動することを含む。一実施形態では、起動信号がシステムに送られる。この起動信号は、制御すべき処理の主な特性を顕在化させることができる。起動信号は、システムへの入力の変化である。例えば、温度を制御する閉ループコントローラの場合、起動信号は、ヒータへの電力の増加であり得る。

【0038】

起動操作７６４の後、処理は、操作７６５に進む。操作７６５は、データ収集を含む。データ収集操作７６５は、図５に関連して以上に記載したデータ収集処理５４２に実質的に類似し得る。すなわち、データ収集処理５４２は、処理フィードバックグラフの形状に実質的に一致する複数の長方形ボックスを生成することを含み得る。例えば、ボックス内の単一のデータポイントと、ボックスの形状／傾きだけが、保存されるデータである場合がある。このように、保存されたデータは、生成されたデータのサブセットである。データ量が少ないため、データのリアルタイム処理が可能となる。

【0039】

一実施形態では、データ収集操作７６５は、操作７６６によって示されるように、処理が定常状態にあるとみなされるまで継続する。上述のように、処理は、収集されたデータから生成された長方形の時間軸に対する向きの分析に基づいて、定常状態にあるとみなされる。処理が一旦定常状態に達すると、チューニング操作７６７により、それまでに収集されたデータが分析される。一実施形態では、チューニング操作７６７は、閉ループコントローラのすべてのゲイン値を決定する目的で実施される。

【0040】

チューニング操作７６７の後、処理７６０は、操作７６８に進む。操作７６８は、チューニングを検証することを含む。検証操作は、収集されたデータと、そのようなデータから導き出された内部シミュレーションモデルとを比較することによって実行される。このような検証は、以前に収集したデータに基づいて、チューニング結果が妥当かどうかを判断するのに有用である。一実施形態では、検証操作は、必要に応じて、物理学に基づくモデルとの比較をさらに含み得る。物理学に基づくモデルは、制御ループを仮想的に表現したもので、物理学に基づく方程式を使って、システム挙動をモデリングする。

【0041】

これより図８を参照すると、実施形態に係る、処理８７０のフロー図が示されている。処理８７０は、レシピが実行されるのをモニタリングするための処理を含み得る。一実施形態では、処理８７０は、処理レシピの開始を合図する開始コマンドで開始し得る。開始コマンドは、新しい処理レシピの開始時に自動的に生成され得る。例えば、処理レシピのすべての事例を処理８７０でモニタリングすることができる。他の実施形態では、レシピモニタリング処理８７０は、処理レシピのすべての反復のサブセットをモニタリングし得る。一実施形態では、開始コマンドと停止コマンドの適切なタイミングにより、同じレシピパフォーマンス分析処理８７０が、所望に応じてレシピの一部に適用され得る。すなわち、幾つかの実施形態では、処理レシピの全期間がモニタリングされない場合がある。

【0042】

一実施形態では、処理８７０は、操作８７１で開始される。操作８７１は、ノイズを推定することを含む。ノイズ推定操作８７１は、図５のノイズ推定操作５４１と実質的に類似し得る。ノイズ推定操作８７１の後、処理は、操作８７２に進み得る。操作８７２は、データ収集を開始すること８７３と、データ収集を停止すること８７４を含む。データ収集８７２は、図５のデータ収集５４２に実質的に類似し得る。すなわち、データ収集処理５４２は、処理フィードバックグラフの形状に実質的に一致する複数の長方形ボックスを生成することを含み得る。例えば、ボックス内の単一のデータポイントと、ボックスの形状／傾きだけが、保存されるデータである場合がある。このように、保存されたデータは、生成されたデータのサブセットである。データ量が少ないため、データのリアルタイム処理が可能となる。

【0043】

幾つかの実施形態では、保存されたデータは、「標準の」データセットとみなされる。すなわち、将来の分析は、「標準」として記録されたパフォーマンスと、現在記録されているデータとの比較に基づいて行われることになる。「標準の」データセットは、レシピの予め設定された数の反復の後、一定期間（例えば、数日、数週間、１年、等）の後、又は処理ツールのメンテナンスの後に、再投入されることがある。

【0044】

一実施形態では、処理８７０は、操作８７５に進み得る。操作８７５は、記録されたデータを既知の基準と比較することを含む。例えば、既知の基準は、「標準の」データセットであり得る。他の実施形態では、既知の基準は、レシピの以前の反復からのデータセットであってもよい。一実施形態では、処理８７０は、次いで、操作８７６に進む。操作８７６は、レシピパフォーマンスステータスを報告することを含む。報告には、レシピが「標準の」データセットから逸脱しているという警告が含まれてもよく、かつ／又は出力として処理に関する他の統計情報が含まれてもよい。一実施形態では、「標準の」データセットからの逸脱には、長方形ボックスの形状、サイズ、及び配向の変化が含まれてもよい。代替的に、ボックスの形状、サイズ、及び向きは、新しいデータに時間遅延があることを除いて、「標準の」データセットと同様（例えば、図４Ｂに示す実施形態と同様）であってもよい。

【0045】

図９は、コンピュータシステム９００という例示的な形態のマシンの概略図を示しているが、コンピュータシステム９００内では、ここに記載された方法のうちの任意の１つ又は複数をマシンに実行させるための一組の命令が実行され得る。代替的な実施形態では、マシンは、ローカルエリアネットワーク（ＬＡＮ）、イントラネット、エクストラネット、又はインターネットにおいて、他のマシンに接続（例えば、ネットワーク接続）され得る。当該マシンは、クライアント／サーバネットワーク環境においてサーバ若しくはクライアントマシンの能力により、又は、ピアツーピア（又は分散）ネットワーク環境においてピアマシンとして、作動し得る。当該マシンは、パーソナルコンピュータ（ＰＣ）、タブレットＰＣ、セットトップボックス（ＳＴＢ）、携帯型情報端末（ＰＤＡ）、携帯電話、ウェブ機器、サーバ、ネットワークルータ、スイッチ若しくはブリッジ、又は当該マシンによって実行される動作を特定する（連続的な若しくはその他の態様の）一組の命令を実行可能な、任意のマシンであってもよい。さらに、単一のマシンのみが示されているが、「マシン」という用語は、ここに記載された方法のうちの任意の１つ又は複数を実行するために、１組の（又は複数の組の）命令を、個別に又は共に実行するマシン（例えば、コンピュータ）の任意の集合体を含んでいると解釈してもよい。

【0046】

例示的なコンピュータシステム９００は、バス９３０を介して互いに通信する、プロセッサ９０２、メインメモリ９０４（例えば、読み出し専用メモリ（ＲＯＭ）、フラッシュメモリ、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）（同期ＤＲＡＭ（ＳＤＲＡＭ）又はランバスＤＲＡＭ（ＲＤＲＡＭ）等））、スタティックメモリ９０６（例えば、フラッシュメモリ、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ＭＲＡＭ等）、及び二次メモリ９１８（例えば、データ記憶デバイス）を含む。

【0047】

プロセッサ９０２は、マイクロプロセッサ、中央処理装置などの１つ又は複数の汎用処理デバイスを表している。より具体的には、プロセッサ９０２は、複合命令セットコンピューティング（ＣＩＳＣ）マイクロプロセッサ、縮小命令セットコンピューティング（ＲＩＳＣ）マイクロプロセッサ、超長命令語（ＶＬＩＷ）マイクロプロセッサ、他の命令セットを実装するプロセッサ、又は命令セットの組み合わせを実装するプロセッサであってもよい。プロセッサ９０２は、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、デジタル信号プロセッサ（ＤＳＰ）、ネットワークプロセッサなどといった、１つ又は複数の特殊用途処理デバイスであってもよい。プロセッサ９０２は、ここに記載の操作を実施するための、処理ロジック９２６を実行するように構成されている。

【0048】

コンピュータシステム９００は、ネットワークインターフェースデバイス９０８をさらに含み得る。コンピュータシステム９００は、ビデオディスプレイユニット９１０（例えば、液晶ディスプレイ（ＬＣＤ）、発光ダイオードディスプレイ（ＬＥＤ）、又は陰極線管（ＣＲＴ））、英数字入力デバイス９１２（例えば、キーボード）、カーソル制御デバイス９１４（例えば、マウス）、及び信号生成デバイス９１６（例えば、スピーカ）を含み得る。

【0049】

二次メモリ９１８は、ここに記載される任意の方法又は機能のうちの１つ又は複数を具現化する命令の１つ又は複数セット（例えば、ソフトウェア９２２）が記憶されたマシンアクセス可能記憶媒体（又はより具体的にはコンピュータ可読記憶媒体）９３２を含み得る。このソフトウェア９２２は、また、コンピュータシステム９００によって実行される間、完全に又は少なくとも部分的に、メインメモリ９０４内及び／又はプロセッサ９０２内に存在してもよい。メインメモリ９０４とプロセッサ９０２は、さらにマシン可読記憶媒体を構成している。このソフトウェア９２２は、ネットワークインターフェースデバイス９０８を介して、ネットワーク９２０上でさらに送信又は受信され得る。

【0050】

例示の実施形態において、マシンアクセス可能記憶媒体９３２を単一の媒体として示したが、「マシン可読記憶媒体」という語は、１つ又は複数の組の命令を記憶する単一の媒体又は複数の媒体（例えば集中データベース若しくは分散データベース、並びに／又は関連キャッシュ及びサーバ）を含むと理解されたい。さらに、「マシン可読記憶媒体」という用語は、マシンによって実行される１組の命令であって、本開示の方法のうちの任意の１つ又は複数をマシンに実行させる１組の命令を、記憶又は符号化することが可能な任意の媒体を含むと解釈すべきである。したがって、「マシン可読記憶媒体」という用語は、固体メモリ、光学媒体、及び磁気媒体を含むと解釈すべきであるが、これらに限定されない。

【0051】

本開示の一実施形態によれば、マシンアクセス可能記憶媒体は、命令を記憶しており、この命令は、データ処理システムに、リアルタイムで実行されるデータマイニングアルゴリズムを使用して処理レシピをモニタリングする方法を実行させる。

【0052】

このように、リアルタイムで実行されるデータマイニングアルゴリズムを使用して処理レシピをモニタリングする方法が開示されている。

【図1A】

【図1B】

【図2A】

【図2B】

【図3】

【図4A】

【図4B】

【図5】

【図6】

【図7】

【図8】

【図9】

【国際調査報告】