ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਗਾਈਡ ਕਿ ਕਿਵੇਂ KLA-ਸਟਾਈਲ ਇੰਸਪੈਕਸ਼ਨ ਅਤੇ ਮੈਟਰੋਲੋਜੀ yield, scrap, cycle time ਅਤੇ ਲਾਗਤ ਨੂੰ ਰੂਪ ਦਿੰਦੇ ਹਨ—ਨਾਲ ਹੀ ਕੀ ਟ੍ਰੈਕ ਕਰਨਾ ਹੈ ਅਤੇ ਫੈਬ ਟੂਲ ਨਹੀਂ ਚੁਣਦੇ।

ਨਿਰੀਖਣ ਅਤੇ ਮੈਟਰੋਲੋਜੀ ਫੈਬ ਦੀਆਂ “ਅੱਖਾਂ” ਹਨ, ਪਰ ਉਹ ਵੱਖ-ਵੱਖ ਚੀਜ਼ਾਂ ਦੇਖਦੇ ਹਨ।
ਨਿਰੀਖਣ (Inspection) ਦਾ ਉੱਤਰ ਹੈ: ਵਾਫਰ 'ਤੇ ਕਿਤੇ ਕੁਝ ਗਲਤ ਹੈ? ਇਹ particles, scratch, pattern break, contamination ਜਾਂ ਐਸੀਆਂ ਹਲਕੀ ਅਸਰ-ਦਿਖਾਈ ਗਈਆਂ ਗਲਤੀਆਂ ਸਕੈਨ ਕਰਦਾ ਹੈ ਜੋ ਭਵਿੱਖ ਵਿੱਚ ਫੇਲ੍ਹਰ ਨਾਲ ਜੁੜ ਸਕਦੀਆਂ ਹਨ।
ਮੈਟਰੋਲੋਜੀ (Metrology) ਦਾ ਉੱਤਰ ਹੈ: ਕੀ ਪ੍ਰਕਿਰਿਆ ਉਹੀ ਕਰ ਰਹੀ ਸੀ ਜੋ ਅਸੀਂ ਚਾਹੀਦੀ ਸੀ? ਇਹ critical dimensions (CD), overlay (ਲੇਅਰ-ਟੁ-ਲੇਅਰ ਐਲਾਈਨਮੈਂਟ), ਫਿਲਮ ਮੋਟਾਈ ਅਤੇ ਹੋਰ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਮਾਪਦਾ ਹੈ ਜੋ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਚਿਪ ਕੰਮ ਕਰੇਗੀ ਜਾਂ ਨਹੀਂ।
ਇੱਕ ਫੈਬ ਸਿਰਫ਼ ਉਸੇ ਚੀਜ਼ ਨੂੰ ਕੰਟਰੋਲ ਕਰ ਸਕਦੀ ਹੈ ਜੋ ਉਹ ਮਾਪ ਸਕਦੀ ਹੈ—ਪਰ ਮਾਪਣ ਖੁਦ ਟੂਲ ਸਮਾਂ, ਇੰਜੀਨੀਅਰਿੰਗ ਧਿਆਨ ਅਤੇ ਕਤਾਰ ਸਥਾਨ ਖਾਂਦਾ ਹੈ। ਇਸ ਨਾਲ ਇੱਕ ਲਗਾਤਾਰ ਟਰੇਡ-ਆਫ਼ ਬਣਦਾ ਹੈ:
ਜੇ ਨਿਰੀਖਣ ਬਹੁਤ ਹੌਲੀ ਹੋਵੇ ਤਾਂ defect ਇੱਕੋ-ਲੌਟਾਂ ਵਿੱਚ ਫੈਲ ਸਕਦੇ ਹਨ ਪਹਿਲਾਂ ਕਿ ਕਿਸੇ ਦਾ ਧਿਆਨ ਜਾਵੇ। ਜੇ ਮੈਟਰੋਲ noisy ਹੈ ਤਾਂ ਇੰਜੀਨੀਅਰ ਭੂਤਪੂਰਵ ਸਮੱਸਿਆ 'ਤੇ "ਪਿੱਛਾ ਕਰ ਸਕਦੇ" ਹਨ, ਜਿਸ ਨਾਲ ਅਣਜ਼ਰੂਰੀ ਪ੍ਰਕਿਰਿਆ ਸੈਟਿੰਗ ਬਦਲ ਸਕਦੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ ਉੱਚ-ਅਸਰ ਵਾਲੇ ਫੈਬ ਫੈਸਲੇ ਡਰਾਮੇਟਿਕ ਨਹੀਂ ਹੁੰਦੇ—ਉਹ ਰੋਜ਼ਾਨਾ ਦੇ ਕਈ ਫੈਸਲੇ ਹਨ ਜੋ ਮਾਪ ਡੇਟਾ ਤੇ ਆਧਾਰਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ:
ਇਹ ਫੈਸਲੇ ਚੁਪਚਾਪ yield, cycle time ਅਤੇ ਪ੍ਰਤੀ-ਵਾਫਰ ਲਾਗਤ ਤੈਅ ਕਰਦੇ ਹਨ। ਵਧੀਆ ਫੈਬ ਸਿਰਫ਼ "ਬਹੁਤ ਮਾਪਦੇ" ਹੀ ਨਹੀਂ—ਉਹ ਸਹੀ ਚੀਜ਼ਾਂ ਨੂੰ, ਸਹੀ ਤਰ੍ਹਾਂ, ਅਤੇ ਸੰਕੇਤ ਵਿੱਚ ਭਰੋਸਾ ਨਾਲ ਮਾਪਦੇ ਹਨ।
ਇਹ ਲੇਖ ਉਹ ਧਾਰਣਾਵਾਂ ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੈ ਜੋ ਤੁਸੀਂ ਵਰਤ ਸਕਦੇ ਹੋ ਇਹ ਸਮਝਣ ਲਈ ਕਿ KLA ਵਰਗੇ ਵੈਂਡਰ yield ਪ੍ਰਬੰਧਨ ਵਿੱਚ ਕਿਵੇਂ ਫਿੱਟ ਹੁੰਦੇ ਹਨ—ਕਿਉਂ ਕੁਝ ਮਾਪ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਉਹ ਕਿਵੇਂ ਕਾਰਵਾਈ ਨੂੰ ਚਲਾਉਂਦੇ ਹਨ, ਅਤੇ ਉਹ ਅਰਥਸ਼ਾਸਤਰ 'ਤੇ ਕਿਵੇਂ ਪ੍ਰਭਾਵ ਪਾਉਂਦੇ ਹਨ।
ਇਹ ਕਿਸੇ proprietary specification ਜਾਂ model-by-model ਦਾਵਿਆਂ ਵਿੱਚ ਨਹੀਂ ਜਾਏਗਾ। ਇਸ ਦੀ ਥਾਂ, ਇਹ ਨਿਰੀਖਣ ਅਤੇ ਮੈਟਰੋਲੋਜੀ ਚੋਣਾਂ ਦੇ ਵਿਆਵਹਾਰਕ ਤਰਕ ਨੂੰ ਸਮਝਾਏਗਾ, ਅਤੇ ਇਹ ਚੋਣਾਂ ਕਿਵੇਂ ਪ੍ਰਤੀਯੋਗਿਤਾ 'ਚ ਪ੍ਰਭਾਵ ਪਾਉਂਦੀਆਂ ਹਨ।
ਇੱਕ ਵਾਫਰ "ਇੱਕ ਵਾਰ ਮਾਪਿਆ ਗਿਆ" ਨਹੀਂ ਹੁੰਦਾ। ਜਦ ਇਹ ਲੂਪਾਂ ਵਿੱਚ patterning ਅਤੇ material change ਦੇ ਨਾਲ ਅੱਗੇ ਵੱਧਦਾ ਹੈ ਤਾਂ ਇਹ ਮੁੜ-ਮੁੜ ਚੈੱਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਸਧਾਰਣ ਰਸਤਾ ਇਹ ਹੈ: lithography (pattern ਛਾਪੋ) → etch (ਉਸ ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕਰੋ) → deposition (ਫਿਲਮਾਂ ਜੋੜੋ) → CMP (ਪਲੇਨਰਾਈਜ਼) → ਦਹਾਕਿਆਂ ਲੇਅਰਾਂ ਲਈ ਦੁਹਰਾਓ → electrical test ਅਤੇ ਫਾਇਨਲ ਸੋਰਟ।
ਮਾਪ ਉਹਨਾਂ ਥਾਵਾਂ ਤੇ ਦਾਖਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਜਿੱਥੇ ਵੈਰੀਏਸ਼ਨ ਬਾਅਦ ਵਿੱਚ ਠੀਕ ਕਰਨ ਲਈ ਮਹਿੰਗਾ ਹੋ ਜਾਂਦਾ ਹੈ:
ਫੈਬ ਹਰ ਚੀਜ਼ ਨੂੰ ਇਕੋ ਦਰ ਨਾਲ ਮਾਪਦੇ ਨਹੀਂ। Critical layers (ਕਠੋਰ design rules, ਸੰਵੇਦਨਸ਼ੀਲ overlay budgets, ਨਵੇਂ ਪ੍ਰਕਿਰਿਆ ਕਦਮ) ਆਮ ਤੌਰ 'ਤੇ ਵੱਧ sampling ਪ੍ਰਾਪਤ ਕਰਦੀਆਂ ਹਨ—ਲੌਟ ਦੇ ਵੱਧ wafers, ਵਾਫਰ ਤੇ ਵੱਧ sites, ਅਤੇ ਵੱਧ ਅਕਸਰ ਨਿਰੀਖਣ। ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਜਾਂ ਪੱਕੀਆਂ ਲੇਅਰਾਂ ਅਕਸਰ throughput ਬਚਾਉਣ ਲਈ ਹਲਕੀ sampling ਵਰਤਦੀਆਂ ਹਨ।
ਸੈਟਿੰਗ ਦੀ ਯੋਜਨਾ ਇੱਕ ਕਾਰੋਬਾਰੀ ਫੈਸਲਾ ਹੈ ਬਿਲਕੁਲ ਤਕਨੀਕੀ ਜਿਹੀ: ਘੱਟ ਮਾਪੋਗੇ ਤਾਂ escapes ਵੱਧਣਗੇ; ਜ਼ਿਆਦਾ ਮਾਪੋਗੇ ਤਾਂ cycle time ਪ੍ਰਭਾਵਿਤ ਹੋਵੇਗਾ।
ਵਾਸਤਵਿਕ ਮਕਸਦ ਸੰਤੁਲਨ ਹੈ: ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਮੇਂ 'ਤੇ ਸਟੀਅਰ ਕਰਨ ਲਈ ਕਾਫੀ inline coverage, ਅਤੇ ਜਦ ਡੇਟਾ ਦਿਖਾਵੇ ਕਿ ਕੁਝ ਬਦਲਿਆ ਹੈ ਤਾਂ ਨਿਸ਼ਾਨਾ ਬਠਾਇਆ offline ਕੰਮ।
ਨਿਰੀਖਣ ਨੂੰ ਅਕਸਰ "ਡਿਫੈਕਟ ਲੱਭਣਾ" ਵਜੋਂ ਵਰਣਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਅਪਰੇਸ਼ਨਲ ਕੰਮ ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਹੁੰਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਸਿਗਨਲਾਂ 'ਤੇ ਰਿਸਪਾਂਡ ਕਰਨਾ ਲਾਭਦਾਇਕ ਹੈ। ਇੱਕ ਆਧੁਨਿਕ ਫੈਬ ਦਿਨ ਵਿੱਚ ਮਿਲੀਅਨ ਕਿਮਤ ਦੇ defect "events" ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ; ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਥੋੜ੍ਹੇ ਹੀ electrical performance ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ। ਕੇਂਦਰੀ ਸਿਸਟਮ ਅਤੇ ਟੂਲ (ਜਿਨ੍ਹਾਂ ਵਿੱਚ KLA-ਕਲਾਸ ਸਿਸਟਮ ਵੀ ਸ਼ਾਮਲ ਹਨ) ਰੋਊ ਡਿਪਨਸਿਟਿਵ ਇਮੇਜ਼ਾਂ ਨੂੰ ਫੈਸਲਿਆਂ ਵਿੱਚ ਬਦਲਦੇ ਹਨ—ਪਰ ਟਰੇਡ-ਆਫ਼ ਹਮੇਸ਼ਾ ਮੌਜੂਦ ਹੁੰਦੇ ਹਨ।
ਡਿਫੈਕਟ ਲੇਅਰ, pattern ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਕਦਮ ਅਨੁਸਾਰ ਵੱਖ-ਵੱਖ ਹੁੰਦੇ ਹਨ:
ਬਹੁਤ ਸਾਰੇ ਪਹਿਲਾਂ-ਨਜ਼ਰ ਵਿੱਚ ਇੱਕੇ ਜਿਹੇ ਲੱਗਦੇ ਹਨ। ਇੱਕ ਚਮਕਦਾਰ "ਬਲੱਬ" ਇੱਕ ਲੇਅਰ ਤੇ ਨਿਰਦੋਸ਼ resist speck ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਦੂਜੇ ਲੇਅਰ ਤੇ ਇਹ yield-killer ਹੋ ਸਕਦਾ ਹੈ।
A killer defect ਉਹ ਹੈ ਜੋ ਸੰਭਵ ਤੌਰ 'ਤੇ ਫੰਕਸ਼ਨਲ ਫੇਲ੍ਹਰ ਕਰੇਗਾ (opens, shorts, leakage, parametric shift). A nuisance defect ਅਜਿਹਾ ਹੈ ਜੋ ਮੌਜੂਦ ਹੈ ਜਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਪਰ yield 'ਤੇ ਪ੍ਰਭਾਵ ਨਹੀਂ ਪਾਂਉਂਦਾ—ਜਿਵੇਂ cosmetic pattern roughness ਜੋ ਮਾਰਜਿਨ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ।
ਕਲਾਸੀਫਿਕੇਸ਼ਨ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ fabs detection ਦੀ ਕਿਵੇਂ ਹੀ ਨਹੀਂ ਭੁਗਤਾਨ ਕਰਦੇ—ਉਹ detection ਦੇ ਕਾਰਨ ਜੋ ਰਿਸਪਾਂਸ ਹੁੰਦੀ ਹੈ ਉਸ ਦਾ ਭੁਗਤਾਨ ਕਰਦੇ ਹਨ: ਰਿਵਿਊ ਟਾਈਮ, ਲੌਟ ਹੋਲਡ, ਰੀਵਰਕ, ਇੰਜੀਨੀਅਰਿੰਗ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਟੂਲ downtime। ਵਧੀਆ ਕਲਾਸੀਫਿਕੇਸ਼ਨ ਘੱਟ ਮਹਿੰਗੀਆਂ ਰਿਸਪਾਂਸ ਲਿਆਉਂਦੀ ਹੈ।
ਉੱਚ-ਸਤਹ ਤੇ, defect density "ਇੱਕ ਇਕਾਈ ਖੇਤਰ ਰਾਹੀ ਡਿਫੈਕਟਾਂ ਦੀ ਗਿਣਤੀ" ਹੈ। ਜਿਵੇਂ ਚਿਪ ਵੱਡੇ ਜਾਂ design rules ਤੰਗ ਹੁੰਦੇ ਹਨ, ਸੰਭਾਵਨਾ ਵਧਦੀ ਹੈ ਕਿ ਘੱਟ ਨਹੀਂ ਇੱਕ killer ਕਿਸੇ ਅਹੰਕਾਰ ਖੇਤਰ ਵਿੱਚ ਆਵੇ। ਇਸ ਲਈ killer defect density ਨੂੰ ਘਟਾਉਣਾ—even ਥੋੜ੍ਹਾ—yield ਵਿੱਚ ਧਿਆਨਯੋਗ ਬਹਤਰ ਕਰਨ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ।
ਕੋਈ ਵੀ ਨਿਰੀਖਣ ਸਿਸਟਮ ਪਰਫੈਕਟ ਨਹੀਂ ਹੈ:
ਮਕसਦ "ਸਭ ਕੁਝ ਲੱਭ ਲਓ" ਨਹੀਂ। ਇਹ ਹੈ ਸਹੀ ਚੀਜ਼ਾਂ ਨੂੰ ਕਾਫ਼ੀ ਜਲਦੀ—ਅਤੇ ਸਸਤੇ—ਤਰਿਕੇ ਨਾਲ ਲੱਭਣਾ ਤਾਂ ਜੋ ਨਤੀਜੇ ਬਦਲ ਸਕਣ।
ਮੈਟਰੋਲੋਜੀ ਫੈਬ ਨੂੰ ਇਹ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ "ਟੂਲ ਚੱਲਿਆ" ਤੋਂ "pattern ਅਸਲ ਵਿੱਚ ਉਹੀ ਹੈ ਜੋ ਅਸੀਂ ਚਾਹਿਆ ਸੀ" ਵਿੱਚ ਕਿਵੇਂ ਬਦਲ ਹੁੰਦਾ ਹੈ। ਤਿੰਨ ਮਾਪ ਹਰਜਗਾ yield learning ਵਿੱਚ ਆਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਸਿੱਧਾ ਤੌਰ 'ਤੇ ਜੋੜਦੇ ਹਨ ਕਿ ਟ੍ਰਾਂਜ਼ਿਸਟਰ ਅਤੇ ਤਾਰਾਂ ਕੰਮ ਕਰਨਗੇ ਕਿ ਨਹੀਂ: critical dimension (CD), overlay, ਅਤੇ drift।
CD ਉਹ ਮਾਪੀ ਹੋਈ ਚੌੜਾਈ ਹੈ—ਟ੍ਰਾਂਜ਼ਿਸਟਰ ਦੀ gate ਲੰਬਾਈ ਜਾਂ ਪਤਲੀ metal ਲਾਈਨ ਜਿਵੇਂ। ਜਦ CD ਥੋੜ੍ਹਾ ਵੀ ਗਲਤ ਹੁੰਦੀ ਹੈ, ਬਿਜਲੀ ਵਿਵਹਾਰ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦਾ ਹੈ: ਬਹੁਤ ਪਤਲਾ ਹੋਵੇ ਤਾਂ ਰੋਧ ਵਧ ਸਕਦਾ ਹੈ ਜਾਂ open ਹੋ ਸਕਦਾ ਹੈ; ਬਹੁਤ ਚੌੜਾ ਹੋਵੇ ਤਾਂ ਪੜੋਸੀਆਂ ਨਾਲ short ਹੋ ਸਕਦਾ ਹੈ ਜਾਂ transistor drive current ਬਦਲ ਸਕਦਾ ਹੈ। ਆਧੁਨਿਕ ਡਿਜ਼ਾਈਨਾਂ ਵਿੱਚ margin ਬਹੁਤ ਘੱਟ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਕੁਝ nanometers ਦਾ bias ਤੁਹਾਨੂੰ ਕਈ dies 'ਚ "safe" ਤੋਂ "systematic failure" ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ।
CD ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਅਕਸਰ ਪਛਾਣਯੋਗ focus/exposure signatures ਰੱਖਦੀਆਂ ਹਨ। ਜੇ focus ਗਲਤ ਹੈ, ਲਾਈਨਾਂ ਗੋਲਦਾਰ, necked, ਜਾਂ "pinched" ਲੱਗ ਸਕਦੀਆਂ ਹਨ। ਜੇ exposure dose ਗਲਤ ਹੈ, ਫੀਚਰ ਬਹੁਤ ਵੱਡੇ ਜਾਂ ਬਹੁਤ ਛੋਟੇ ਪ੍ਰਿੰਟ ਹੋ ਸਕਦੇ ਹਨ। ਇਹ pattern fidelity ਮੁੱਦੇ ਹਨ: ਆਕਾਰ ਵਿਸ਼ਕਸਿਤ ਹੋ ਸਕਦਾ ਹੈ ਭਾਵੇਂ average width ਠੀਕ ਲੱਗੇ।
Overlay ਮਾਪਦਾ ਹੈ ਕਿ ਇਕ ਲੇਅਰ ਪਿਛਲੀ ਲੇਅਰ ਨਾਲ ਕਿੰਨੀ ਚੰਗੀ ਰੀਤ ਨਾਲ align ਹੁੰਦੀ ਹੈ। ਜੇ alignment errors ਜੁਡਦੇ ਹਨ, vias ਸਹੀ ਟਾਰਗੇਟ ਨੂੰ ਨਹੀਂ ਪਹੁੰਚਦੇ, contacts ਅਧ-ਸਥਿਤ ਰਹਿ ਜਾਂਦੇ, ਜਾਂ edges ਗਲਤ ਢੰਗ ਨਾਲ ਓਵਰਲੈਪ ਹੋ ਜਾਂਦੇ ਹਨ। ਇੱਕ ਚਿਪ ਦੀ ਹਰ ਲੇਅਰ 'ਤੇ CDs "ਪରਫੈਕਟ" ਹੋ ਸਕਦੀਆਂ ਹਨ ਪਰ ਫੇਲ੍ਹ ਹੋ ਸਕਦੀ ਹੈ ਕਿਉਂਕਿ ਲੇਅਰਾਂ ਲਾਈਨ ਨਹੀਂ ਹੋ ਰਹੀਆਂ।
ਸਧਾਰਣ ਤੌਰ 'ਤੇ, ਫੈਬ ਤੇਜ਼, ਉੱਚ-ਥਰੂਪੁੱਟ ਮਾਪਣ ਲਈ optical metrology ਅਤੇ ਛੋਟੀ ਵਿਸ਼ੇਸ਼ਤ ਦੇਖ-ਭਾਲ ਲਈ SEM-based metrology ਵਰਤਦੇ ਹਨ। ਵੈਂਡਰਾਂ ਨੂੰ ਇਸਨੂੰ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਉਹ ਕਿੰਨੀ ਭਲਕੇ real drift ਨੂੰ ਛੇਤੀ ਫੜਦੇ ਹਨ—ਜਿਸ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਲੌਟ-ਵਿਆਪਕ yield ਨੁਕਸਾਨ ਬਣ ਜਾਵੇ।
ਪ੍ਰਕਿਰਿਆ ਡ੍ਰਿਫਟ ਖਾਮੋਸ਼ ਸ਼ੱਤਰ ਹੈ: ਤਾਪਮਾਨ, ਰਸਾਇਣ, ਟੂਲ ਪਹਿੜ੍ਹ, ਜਾਂ reticle ਬਦਲਾਅ CD ਅਤੇ overlay ਨੂੰ ਹੌਲੇ-ਹੌਲੇ ਧੱਕ ਸਕਦੇ ਹਨ, ਜਦ ਤੱਕ ਫੈਬ ਅਚਾਨਕ spec ਤੋਂ ਬਾਹਰ ਨਾ ਹੋ ਜਾਏ।
ਮਾਪ-ਜਾਂਚ ਤਦ ਹੀ ਲਾਗਤ ਘਟਾਉਂਦੀ ਹੈ ਜਦ ਇਹ ਸਥਿਰ ਫੈਸਲੇ ਟ੍ਰਿਗਰ ਕਰੇ। ਉਹ "ਆਖਰੀ ਮੀਲ" ਹੈ Statistical Process Control (SPC): ਰੁਟੀਨ ਜੋ inspection ਅਤੇ metrology ਦੇ ਸਿਗਨਲਾਂ ਨੂੰ ਐਸੇ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਬਦਲਦਾ ਹੈ ਜਿਨ੍ਹਾਂ 'ਤੇ ਓਪਰੇਟਰ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹਨ।
ਕਲਪਨਾ ਕਰੋ ਇੱਕ etch ਕਦਮ ਦੇ ਬਾਅਦ CD ਮਾਪ ਰਿੱਕਿਆ ਹੋ ਰਿਹਾ ਹੈ ਅਤੇ ਚੌੜਾ ਹੋ ਰਿਹਾ ਹੈ।
Feedback control ਮਾਪਦਾ ਹੈ ਨਤੀਜਾ, ਫਿਰ etcher recipe ਨੂੰ ਐਡਜਸਟ ਕਰਦਾ ਹੈ ਤਾਂ ਕਿ ਅਗਲਾ ਲੌਟ ਮੁੜ ਟਾਰਗੇਟ 'ਤੇ ਆ ਜਾਵੇ। ਇਹ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੈ ਪਰ ਹਮੇਸ਼ਾ ਇੱਕ ਕਦਮ ਪਿੱਛੇ ਰਹਿੰਦਾ ਹੈ।
Feedforward control upstream ਜਾਣਕਾਰੀ ਵਰਤਦਾ ਹੈ ਤਾਂ ਜੋ ਗਲਤੀ ਬਾਅਦ ਵਿੱਚ ਨਾ ਆਉਂਵੇ। ਉਦਾਹਰਨ ਲਈ, ਜੇ lithography overlay ਜਾਂ focus ਮਾਪ ਦੱਸਦੇ ਹਨ ਕਿ ਕਿਸੇ ਨਿਰਧਾਰਿਤ scanner ਤੇ bias ਹੁੰਦਾ ਹੈ, ਤੁਸੀਂ ਨੌਕਰੀ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ downstream etch ਜਾਂ deposition ਸੈਟਿੰਗਾਂ ਨੂੰ ਆਪਣੇ ਆਪ ਠੀਕ ਕਰ ਸਕਦੇ ਹੋ।
SPC charts ਟਾਰਗੇਟ ਦੇ ਆਲੇ ਦੁਆਲੇ ਕੰਟਰੋਲ ਲਿਮਿਟ (ਅਕਸਰ ਪ੍ਰਕਿਰਿਆ ਵੈਰੀਏਸ਼ਨ ਆਧਾਰিত) ਖਿੱਚਦੇ ਹਨ। ਜਦ ਡੇਟਾ ਉਹਨਾਂ ਲਿਮਿਟਾਂ ਨੂੰ ਪਾਰ ਕਰਦਾ ਹੈ, ਇਹ ਇੱਕ excursion ਹੁੰਦਾ ਹੈ—ਇਹ ਸੰਕੇਤ ਹੈ ਕਿ ਪ੍ਰਕਿਰਿਆ ਬਦਲੀ ਹੈ, ਸਿਰਫ਼ ਆਮ ਨੌਇਜ਼਼ ਨਹੀਂ।
ਜੇ ਟੀਮਾਂ ਰੋਜ਼-ਰੋਜ਼ ਅਲਾਰਮਾਂ ਨੂੰ "ਆਮ ਤੌਰ 'ਤੇ ਠੀਕ ਹੋਵੇਗਾ" ਕਹਿ ਕੇ override ਕਰਦੀਆਂ ਹਨ, ਤਦ ਦੋ ਗੱਲਾਂ ਹੁੰਦੀਆਂ ਹਨ:
ਭਰੋਸੇਯੋਗ ਅਲਾਰਮ ਤੇਜ਼, ਦੋਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ containment ਨੂੰ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ: ਲਾਈਨ ਨੂੰ ਸਹੀ ਕਾਰਨਾਂ ਲਈ ਰੋਕੋ, ਨਾ ਕਿ ਨਿਰੰਤਰ।
Latency ਉਹ ਸਮਾਂ ਹੈ processing ਅਤੇ ਵਰਤੋਯੋਗ ਮਾਪ ਨਤੀਜੇ ਵਿਚਕਾਰ। ਜੇ CD ਨਤੀਜੇ ਕਈ ਲੌਟਾਂ ਦੇ ਚੱਲਣ ਤੋਂ ਬਾਅਦ ਆਉਂਦੇ ਹਨ, ਫੀਡਬੈਕ ਸਿਰਫ਼ ਭਵਿੱਖ ਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ ਜਦ ਕਿ defect ਮੌਜੂਦਾ ਵਿੱਚ ਇਕੱਠੇ ਹੋ ਰਹੇ ਹੁੰਦੇ ਹਨ। ਘੱਟ latency (ਜਾਂ ਸਮਾਰਟ ਸਮਪਲਿੰਗ) "at-risk" ਸਮੱਗਰੀ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ ਅਤੇ ਦੋਹਾਂ ਫੀਡਬੈਕ ਅਤੇ ਫੀਡਫਾਰਵਰਡ ਨੂੰ ਸੁਧਾਰਦੀ ਹੈ।
ਜਦ ਲਿਮਿਟ, ਰਿਸਪਾਂਸ ਯੋਜਨਾਵਾਂ, ਅਤੇ ਮਲਕੀਅਤ ਸਪਸ਼ਟ ਹੁੰਦੇ ਹਨ, ਘੱਟ ਲੌਟ ਹੋਲਡ ਹੋਂਦੇ ਹਨ "ਸਿਰਫ਼ ਸੁਰੱਖਿਆ ਲਈ" ਅਤੇ ਘੱਟ ਵਾਫਰ ਮਹਿੰਗੀ ਰੀਵਰਕ ਲੌਗਦੀ ਹੈ। ਨਤੀਜਾ ਸ਼ਾਂਤ آپਰੇਸ਼ਨ: ਘੱਟ ਵੈਰੀਏਸ਼ਨ, ਘੱਟ ਹੈਰਾਨੀਆਂ, ਅਤੇ ਤੇਜ਼ yield learning।
ਮਾਪ-ਜਾਂਚ ਫੈਬ ਵਿੱਚ "ਓਵਰਹੈਡ" ਨਹੀਂ—ਇਹ ਚੋਣਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਹੈ ਜੋ ਜਾਂ ਤਾਂ ਮਹਿੰਗੀਆਂ ਗਲਤੀਆਂ ਰੋਕਦਾ ਹੈ ਜਾਂ ਮਹਿੰਗਾ ਬਿਜੀਵਰਕ ਬਣਾਉਂਦਾ ਹੈ। ਲਾਗਤ ਪ੍ਰਭਾਵ ਪ੍ਰਸਿੱਧ ਬਕਤਿਆਂ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:
ਨਿਰੀਖਣ ਵਿੱਚ ਵੱਧ ਸੰਵੇਦਨਸ਼ੀਲਤਾ (ਉਦਾਹਰਨ ਲਈ ਛੋਟੇ defect ਆਕਾਰਾਂ ਦੀ ਖੋਜ) escapes ਘਟਾ ਸਕਦੀ ਹੈ—ਪਰ ਇਹ ਇੰਜੀਨੀਅਰਿੰਗ ਨੂੰ nuisance ਸਿਗਨਲਾਂ ਨਾਲ ਭਰ ਸਕਦੀ ਹੈ। ਜੇ ਹਰ "ਸੰਭਵ дефੈਕਟ" ਨੂੰ hold ਕੀਤਾ ਜਾਵੇ ਤਾਂ ਫੈਬ ਟੂਲ idle ਸਮਾਂ, ਕਤਾਰ ਵਾਧਾ, ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਲੇਬਰ 'ਚ ਖਰਚ ਚੁੱਕੇਗੀ।
ਆਰਥਿਕ ਸਵਾਲ ਇਹ ਨਹੀਂ ਹੈ "ਟੂਲ ਇਹ ਦੇਖ ਸਕਦਾ ਹੈ?" ਬਲਕਿ "ਉਸ 'ਤੇ ਕਾਰਵਾਈ ਕਰਨ ਨਾਲ ਕੀ ਨੁਕਸਾਨ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਜ਼ਿਆਦਾ ਬਚਤ ਹੋਵੇਗੀ?" ਹੈ।
ਜਿੱਥੇ ਤੁਸੀਂ ਵੱਧ ਜਾਂ ਘੱਟ ਮਾਪਦੇ ਹੋ—ਇਹ ਇਸ ਗੱਲ ਵਰਗਾ ਹੀ ਅਹੰਕਾਰ ਵਾਲਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਟੂਲ ਖਰੀਦਦੇ ਹੋ। ਉੱਚ-जोਖਮ ਲੇਅਰ (ਨਵੇਂ ਪ੍ਰਕਿਰਿਆ ਕਦਮ, ਟਾਈਟ overlay ਲੇਅਰ, ਜਾਣੇ-ਪਛਾਣ ਵਾਲੇ excursions) ਆਮ ਤੌਰ 'ਤੇ ਗਾਢੇ sampling ਦੇ ਹੱਕਦਾਰ ਹੁੰਦੇ ਹਨ। ਸਥਿਰ, ਪਰ ਪੱਕੇ ਲੇਅਰਾਂ ਨੂੰ ਹਲਕੀ sampling ਨਾਲ ਅਤੇ ਮਜ਼ਬੂਤ SPC ਗਾਰਡਰੇਲਾਂ ਨਾਲ ਬੇਹਤਰ ਸੇਵਾ ਮਿਲ ਸਕਦੀ ਹੈ।
ਕਈ ਫੈਬ inspection/ਮੈਟਰੋਲੋਜੀ ਨਤੀਜਿਆਂ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਵਰਤਦੇ ਹਨ: ਜਿੱਥੇ excursions ਆਮ ਹਨ ਉਥੇ coverage ਵਧਾਓ, ਅਤੇ ਜਿੱਥੇ ਸਿਗਨਲ ਕਦੇ ਵੀ ਕਾਰਵਾਈ ਨਹੀਂ ਚਲਾਉਂਦੇ ਉਥੇ ਪਿਛੇ ਹੱਟੋ।
A ਚੰਗੀ ਪਕੜ: ਇੱਕ focus drift ਦੀ ਸ਼ੁਰੂਆਤੀ ਪਛਾਣ ਜੋ ਇੱਕ ਪੂਰੇ ਲੌਟ ਨੂੰ ਖਰਾਬ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਠੀਕ ਕਰਕੇ downstream litho/etch ਕਦਮਾਂ ਨੂੰ ਬਚਾਉਂਦੀ ਹੈ।
ਮਹਿੰਗਾ ਨੌਇਜ਼: ਵਾਰ-ਵਾਰ ਨਿਰਦੋਸ਼ patterning artifact ਨੂੰ ਫਲੈਗ ਕਰਨਾ ਜੋ holds ਅਤੇ ਰਿਵਿਊ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੈ, ਜਦ ਕਿ yield ਅਤੇ electrical ਨਤੀਜੇ ਬਦਲਦੇ ਨਹੀਂ—cycle time ਨੂੰ ਜ਼ਿਆਦਾ ਬਿਨਾਂ scrap ਘਟਾਏ।
Yield learning "ਮੁਫ਼ਤ" ਨਹੀਂ ਹੁੰਦੀ। ਹਰ inspection ਸਕੈਨ, metrology ਸੈਂਪਲ ਅਤੇ defect ਰਿਵਿਊ ਕੀਮਤੀ ਟੂਲ ਸਮਾਂ ਖਾਂਦੇ ਹਨ—ਅਤੇ ਜਦ ਉਹ ਸਮਰੱਥਾ ਤੰਗ ਹੁੰਦੀ ਹੈ, ਮਾਪ-ਜਾਂਚ ਇੱਕ ਫੈਕਟਰੀ ਬੋਤਲਨੇਕ ਬਣ ਜਾਂਦੀ ਹੈ ਜੋ cycle time ਨੂੰ ਖਿੱਚਦੀ ਹੈ।
ਅਧਿਕਤਰ cycle-time ਪ੍ਰਭਾਵ ਸਕੈਨ ਖ਼ੁਦ ਨਹੀਂ; ਇਹ ਉਡੀਕ ਹੋਣ ਕਾਰਨ ਹੁੰਦਾ ਹੈ। ਫੈਬ ਆਮ ਤੌਰ 'ਤੇ ਹੇਠਾਂ ਕਤਾਰਾਂ ਦੇਖਦੇ ਹਨ:
ਉਹਨਾਂ ਕਤਾਰਾਂ ਕਾਰਨ lots ਨੂੰ ਲਾਇਨ-ਭਰ ਵਿੱਚ ਹੌਲੀ ਹੋਂਦੀਆਂ, WIP ਵੱਧਦਾ, ਅਤੇ ਅਕਸਰ ਘੱਟ-ਲਾਇਕ ਫੈਸਲੇ—ਜਿਵੇਂ confirmatory measurements ਛੱਡ ਕੇ ਸਿਰਫ਼ ਸਮੱਗਰੀ ਨੂੰ ਅੱਗੇ ਭੇਜਣਾ—ਨਾ-ਚਾਹੀਦਾ ਨਤੀਜੇ ਲਿਆ ਸਕਦਾ ਹੈ।
ਮੈਟਰੋਲੋਜੀ ਸਮਰੱਥਾ ਦੀ ਯੋਜਨਾ ਸਿਰਫ਼ "ਨਹੀਂ, ਕਾਫ਼ੀ ਟੂਲ ਖਰੀਦੋ" ਨਹੀਂ ਹੈ। ਇਹ capacity ਨੂੰ recipe mix ਨਾਲ ਮਿਲਾਉਣ ਹੈ। ਇੱਕ ਲੰਮਾ, ਸੰਵੇਦਨਸ਼ੀਲ inspection recipe ਇੱਕ ਹਲਕੇ ਮਾਨੀਟਰ ਦੇ ਮੁਕਾਬਲੇ ਵਿੱਚ ਟੂਲ ਸਮੇ ਦੀਆਂ ਗੁਣਾ ਲੈ ਸਕਦਾ ਹੈ।
ਫੈਬ ਵਰਤਦੇ ਕੁੰਜੀ ਲੀਵਰ:
ਆਟੋਮੇਸ਼ਨ cycle time ਸੁਧਾਰਦਾ ਹੈ ਜਦ ਇਹ "ਬੀਚ-ਵਿੱਚ" ਕੰਮ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ:
ਗਤੀ ਦਾ ਸਭ ਤੋਂ ਵੱਡਾ ਨਫਾ ਸਿੱਖਣ ਹੈ। ਜਦ inspection ਅਤੇ ਮੈਟਰੋਲੋਜੀ ਨਤੀਜੇ ਤੇਜ਼ੀ ਨਾਲ ਸਪਸ਼ਟ, ਕਾਰਵਾਈਯੋਗ ਨਿਰਣਯ ਵਿੱਚ ਆਂਦੇ ਹਨ, ਫੈਬ ਇੱਕੋ ਜਿਹੀ excursion ਕਈ ਲੌਟਾਂ 'ਤੇ ਦੁਹਰਾਉਣ ਤੋਂ ਬਚਦਾ ਹੈ। ਇਸ ਨਾਲ rework, scrap ਰਿਸਕ, ਅਤੇ "ਵਧੀਕ sampling ਕਿਉਂਕਿ ਅਸੀਂ ਚਿੰਤਤ ਹਾਂ" ਦੇ compounding cycle-time ਹਿਤ ਨੂੰ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
ਫੀਚਰ ਛੋਟੇ ਹੋਣ ਦਾ ਮਤਲਬ ਸਿਰਫ਼ ਚਿਪ ਤੇਜ਼ ਨਹੀਂ—ਇਸ ਦਾ ਅਰਥ ਇਹ ਵੀ ਹੈ ਕਿ ਮਾਪਣ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਅਡਵਾਂਸ ਨੋਡਾਂ ਤੇ, "ਇਜਾਜ਼ਤ ਦੀ ਖਿੜਕੀ" ਇੰਨੀ ਛੋਟੀ ਹੋ ਜਾਂਦੀ ਹੈ ਕਿ inspection ਸੰਵੇਦਨਸ਼ੀਲਤਾ ਅਤੇ ਮੈਟਰੋਲੋਜੀ ਸਹੀਤਾ ਨੂੰ ਇਕੱਠੇ ਬਿਹਤਰ ਹੋਣਾ ਪੈਂਦਾ ਹੈ। ਨਤੀਜਾ ਸਧਾਰਨ ਹੈ: ਇੱਕ ਡਿਫੈਕਟ ਜਾਂ ਕੁਝ ਨੈਨੋਮੀਟਰ ਡ੍ਰਿਫਟ ਜੋ ਪੂਰਬੱ ਤੋਂ ਨਿਰਦੋਸ਼ ਸੀ, ਦੇ ਨਾਲ-ਨਾਲ ਇੱਕ ਵਾਫਰ ਨੂੰ "ਚੰਗਾ" ਤੋਂ "ਮਾਰਜਿਨਲ" ਵਿੱਚ ਬਦਲ ਸਕਦੀ ਹੈ।
EUV ਕੁਝ ਮਹੱਤਵਪੂਰਨ ਤਰੀਕਿਆਂ ਨਾਲ defect ਅਤੇ ਮੈਟਰੋਲੋਜੀ ਸਮੱਸਿਆ ਨੂੰ ਬਦਲਦਾ ਹੈ:
ਇਹ ਫੈਬਾਂ ਨੂੰ ਹੋਰ ਸੰਵੇਦਨਸ਼ੀਲ ਨਿਰੀਖਣ, ਸਮਾਰਟ ਸਮਪਲਿੰਗ, ਅਤੇ ਜੋ ਮਾਪਿਆ ਜਾ ਰਿਹਾ ਹੈ ਅਤੇ ਜਿਸ 'ਤੇ ਅਨੁਕੂਲਤਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਦੇ ਦਰਮਿਆਨ ਕੜੀ ਲਿੰਕਿੰਗ ਵੱਲ ਧਕੇਲਦਾ ਹੈ।
EUV ਤੋਂ ਬਾਅਦ ਵੀ, ਬਹੁਤ ਸਾਰੀਆਂ ਲੇਅਰਾਂ ਵਿੱਚ multi-patterning steps ਅਤੇ ਜਟਿਲ 3D stacks (ਵਧੇਰੇ ਫਿਲਮਾਂ, ਵਧੇਰੇ ਇੰਟਰਫੇਸ, ਵਧੀਕ ਟੋਪੋਗ੍ਰਾਫੀ) ਹੁੰਦੀਆਂ ਹਨ। ਇਸ ਨਾਲ ਚੀਜ਼ਾਂ ਵਧਦੀਆਂ ਹਨ:
ਮੈਟਰੋਲੋਜੀ ਟਾਰਗੇਟ ਘੱਟ ਪ੍ਰਤੀਨਿਧਿਤ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ recipes ਨੂੰ ਪ੍ਰਤੀਯੋਗਿਤਾ 'ਤੇ ਰਿਹਾਇਸ਼ ਰੱਖਣ ਲਈ ਅਕਸਰ ਜ਼ਿਆਦਾ ਤਰਤੀਬੀ ਤੌਰ 'ਤੇ ਠੀਕ ਕਰਨ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ।
ਹਰ ਲੇਅਰ ਨੂੰ ਇਕੋ ਉਹੀ ਸੰਵੇਦਨਸ਼ੀਲਤਾ ਜਾਂ ਸਹੀਤਾ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। logic, memory ਅਤੇ power ਡਿਵਾਈਸ ਵੱਖ-ਵੱਖ ਫੇਲ੍ਹਰ ਮਕੈਨਿਜ਼ਮ ਉੱਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਇੱਕੀ ਚਿਪ ਵਿੱਚ ਵੀ gate, contact, via, ਅਤੇ metal ਲੇਅਰਾਂ ਵੱਖ-ਵੱਖ ਨਿਰੀਖਣ thresholds ਅਤੇ ਮੈਟਰੋਲੋਜੀ uncertainty ਮੰਗ ਸਕਦੀਆਂ ਹਨ। ਜਿੱਤਣ ਵਾਲੀਆਂ ਫੈਬ ਮਾਪ-ਯੋਜਨਾ ਨੂੰ ਲੇਅਰ-ਬਾਇ-ਲੇਅਰ ਇੰਜੀਨੀਅਰਿੰਗ ਵਜੋਂ ਦੇਖਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਇੱਕ-ਸਾਈਜ਼-ਸਾਰਾ ਸੈਟਿੰਗ ਵਜੋਂ।
Inspection ਅਤੇ ਮੈਟਰੋਲੋਜੀ ਤਦ ਹੀ yield ਵਿੱਚ ਸਹਾਇਕ ਹੁੰਦੇ ਹਨ ਜਦ ਨਤੀਜੇ shift ਤੋਂ shift ਅਤੇ ਟੂਲ ਤੋਂ ਟੂਲ ਦੁਹਰਾਏ ਜਾ ਸਕਣ। ਅਮਲੀ ਤੌਰ 'ਤੇ, ਇਹ ਮੈਜ਼ਰਮੈਂਟ ਫਿਜ਼ਿਕਸ ਨਾਲੋਂ ਘੱਟ ਰੂਪ ਵਿੱਚ operational ਅਨੁਸ਼ਾਸਨ ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ: recipes, tool matching, calibration, ਅਤੇ controlled change।
“ਰੇਸਪੀ” ਉਹ ਸੰਭਾਲਿਆ ਹੋਇਆ ਸੈਟ ਹੈ ਜੋ ਮਾਪਣ ਸਥਾਨ, optics/beam ਸੈਟਿੰਗ, ਫੋਕਸ ਨੀਤੀ, thresholds, sampling plans, ਅਤੇ classification ਨਿਯਮ ਲਏ ਹੁੰਦੇ ਹਨ ਜੋ ਕਿਸੇ ਖਾਸ ਲੇਅਰ/ਉਤਪਾਦ 'ਤੇ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਚੰਗਾ recipe management ਇੱਕ ਜਟਿਲ ਟੂਲ ਨੂੰ ਇੱਕ ਸਥਿਰ ਫੈਕਟਰੀ ਇੰਜਿਨ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਛੋਟੇ recipe ਫਰਕ "ਨਕਲੀ" excursions ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ—ਇੱਕ ਸ਼ਿਫਟ ਵਿੱਚ ਜ਼ਿਆਦਾ defects ਦੇਖੇ ਜਾ ਸਕਦੇ ਹਨ ਬਸ ਇਸ ਲਈ ਕਿ sensitivity ਬਦਲੀ। ਬਹੁਤ ਫੈਬ recipe ਨੂੰ production asset ਵਜੋਂ ਸਲੱਖਦੇ ਹਨ: versioned, access-controlled, ਅਤੇ product/layer IDs ਨਾਲ ਜੁੜੇ ਤਾਂ ਜੋ ਇੱਕੋ ਵਾਫਰ ਨੂੰ ਹਰ ਵਾਰੀ ਇੱਕੋ ਹੀ ਤਰੀਕੇ ਨਾਲ ਮਾਪਿਆ ਜਾਵੇ।
ਜ਼ਿਆਦਾਤਰ high-volume ਫੈਬ ਕਈ ਟੂਲ (ਆਮ ਤੌਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਜਨਰੇਸ਼ਨਾਂ) ਚਲਾਂਦੇ ਹਨ ਤਾਂ ਕਿ ਸਮਰੱਥਾ ਅਤੇ redundancy ਮਿਲੇ। ਜੇ Tool A CD ਨੂੰ 3 nm ਉੱਤੋਂ ਵੱਧ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ Tool B ਘੱਟ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਦੋ ਰੁਲਰ ਹਨ।
ਕੈਲੀਬ੍ਰੇਸ਼ਨ ਰੁਲਰ ਨੂੰ ਇੱਕ ਰੈਫਰੈਂਸ ਨਾਲ ਜੋੜ ਕੇ ਰੱਖਦੀ ਹੈ। ਮੈਚਿੰਗ ਵੱਖ-ਵੱਖ ਰੁਲਰਾਂ ਨੂੰ aligned ਰੱਖਦੀ ਹੈ। ਇਸ ਵਿੱਚ ਸਮੇਂ-ਸਮੇਂ ਤੇ gauge checks, reference wafers, ਅਤੇ offsets ਅਤੇ drift ਦੀ ਸਾਂਖਿਆਉਕ ਨਿਗਰਾਨੀ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ। ਵੈਂਡਰ matching workflows ਦਿੰਦੇ ਹਨ, ਪਰ ਫੈਬਾਂ ਨੂੰ ਸਪਸ਼ਟ ਮਲਕੀਅਤ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਕੌਣ offsets ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ, ਕਿੰਨੀ ਵਾਰ ਰੀ-ਮੈਚ ਕਰਨਾਂ ਹੈ, ਅਤੇ ਕਿਹੜੇ ਲਿਮਿਟ stop ਟ੍ਰਿਗਰ ਕਰਦੇ ਹਨ।
ਜਦ ਮੈਟੀਰੀਅਲ, pattern, ਜਾਂ ਟਾਰਗਟ ਬਦਲਦੇ ਹਨ ਤਾਂ recipes ਨੂੰ ਬਦਲਣਾ ਲਾਜ਼ਮੀ ਹੁੰਦਾ ਹੈ—ਪਰ ਹਰ ਬਦਲਾਅ ਨੂੰ ਵੈਲਿਡੇਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਆਮ ਅਭਿਆਸ "shadow mode" ਹੈ: ਅਪਡੇਟ ਕੀਤੀ ਰੇਸਪੀ ਨੂੰ ਪੈਰਲੇਲ ਚਲਾਓ, ਡੈਲਟਾ ਤੁਲਨਾ ਕਰੋ, ਫਿਰ ਹੀ તેને promote ਕਰੋ ਜੇ ਇਹ correlation ਬਰਕਰਾਰ ਰਖੇ ਅਤੇ downstream SPC ਲਿਮਿਟਾਂ ਨੂੰ ਨਹੀਂ ਭੰਗ ਕਰੇ।
ਦਿਨ-ਨੁ-ਦਿਨ ਸਥਿਰਤਾ ਤੇਜ਼ ਅਤੇ ਸਥਿਰ ਫੈਸਲਿਆਂ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੀ ਹੈ:
ਜਦ ਇਹ ਵਰਕਫਲੋ ਸਟੈਂਡਰਡ ਹੈ, ਮਾਪ-ਜਾਂਚ ਇੱਕ ਨਿਰਭਰ ਯੰਤਰ ਬਣ ਜਾਂਦੀ ਹੈ ਨਾ ਕਿ ਵੱਖ-ਵੱਖਤਾ ਦਾ ਇੱਕ ਹੋਰ ਸਰੋਤ।
ਮਾਪ-ਜਾਂਚ ਤਦ ਹੀ ਪ੍ਰਤੀਯੋਗਿਤਾ ਸੁਧਾਰਦੀ ਹੈ ਜਦ ਇਹ ਪ੍ਰਕਿਰਿਆ ਡ੍ਰਿਫਟ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਫੈਸਲੇ ਬਦਲ ਦੇਵੇ। ਹੇਠਾਂ ਦਿੱਤੇ KPI inspection/ਮੈਟਰੋਲੋਜੀ ਨੂੰ yield, cycle time, ਅਤੇ ਲਾਗਤ ਨਾਲ ਜੋੜਦੇ ਹਨ—ਬਿਨਾਂ ਤੁਹਾਡੇ ਹਫਤਾਵਾਰ ਸਮੀਖਿਆ ਨੂੰ ਡੇਟਾ ਡੰਪ ਬਣਾਉਣ ਦੇ।
Capture rate: ਉਹ ਹਿੱਸਾ ਜੋ ਤੁਹਾਡੀ inspection ਅਸਲ yield-limiting defects ਵਿੱਚੋਂ ਲੱਭਦੀ ਹੈ। ਇਸਨੂੰ defect ਕਿਸਮ ਅਤੇ ਲੇਅਰ ਅਨੁਸਾਰ ਟਰੈਕ ਕਰੋ, ਨਾ ਕਿ ਇੱਕ headline ਨੰਬਰ ਵਜੋਂ।
Defect adder: ਮਾਪਣ ਕਦਮਾਂ ਦੁਆਰਾ ਲਿਆਂਦੇ ਗਏ defects (handling, ਵਧੀਕ queue time ਕਾਰਨ WIP ਰਿਸਕ, ਰੀਵਰਕ)। ਜੇ ਤੁਹਾਡਾ adder ਵਧ ਰਿਹਾ ਹੈ ਤਾਂ "ਅਧਿਕ sampling" ਵਾਪਿਸ ਨਤੀਜਾ ਦੇ ਸਕਦਾ ਹੈ।
Nuisance rate: ਪਾਇਆ ਗਿਆ events ਦਾ ਉਹ ਹਿੱਸਾ ਜੋ actionable ਨਹੀਂ (ਨੌਇਜ਼, ਨਿਰਦੋਸ਼ patterning artifacts)। ਉੱਚ nuisance rate ਰਿਵਿਊ ਸਮਰੱਥਾ ਖਪਾਉਂਦਾ ਅਤੇ root-cause ਕੰਮ ਨੂੰ ਦੇਰੀ ਕਰਦਾ ਹੈ।
Precision: ਇੱਕੋ feature 'ਤੇ ਇੱਕੇ ਟੂਲ ਦੀ repeatability; ਇਹ ਇਸ ਨਾਲ ਸਿੱਧਾ ਜੁੜਿਆ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੰਟਰੋਲ ਲਿਮਿਟ ਕਿੰਨੇ ਤੰਗ ਹੋ ਸਕਦੇ ਹਨ।
Accuracy: ਸੱਚੀ ਕਿਸਮ ਦੇ ਨਜ਼ਦੀਕਤਾ (ਜਾਂ ਸਹਿਮਤ ਰੈਫਰੈਂਸ)। precision ਬਿਨਾਂ accuracy ਤੋਂ systematic mis-control ਹੋ ਸਕਦਾ ਹੈ।
TMU (total measurement uncertainty): ਇੱਕ ਅਮਲੀ ਰੋਲ-ਅਪ ਜੋ repeatability, matching, sampling ਪ੍ਰਭਾਵ ਅਤੇ recipe sensitivity ਨੂੰ ਜੋੜਦਾ ਹੈ।
Tool matching: ਇੱਕੋ recipe ਚਲਾਉਂਦੇ ਟੂਲਾਂ ਵਿਚਕਾਰ ਸਹਿਮਤੀ। ਖਰਾਬ matching ਪ੍ਰਕਿਰਿਆ ਵੈਰੀਏਸ਼ਨ ਨੂੰ ਵਧਾਉਂਦਾ ਅਤੇ dispatching ਨੂੰ ਮੁਸ਼ਕਲ ਕਰਦਾ ਹੈ।
Excursion rate: ਕਿੰਨੀ ਵਾਰ ਪ੍ਰਕਿਰਿਆ ਆਪਣੀ ਸਧਾਰਨ ਵਿੰਡੋ ਤੋਂ ਬਾਹਰ ਜਾ ਰਿਹਾ ਹੈ (module, layer, shift ਦੁਆਰਾ)। ਇਸਨੂੰ escape rate ਨਾਲ ਜੋੜੋ (excursions ਜੋ downstream ਪ੍ਰਭਾਵ ਤੋਂ ਪਹਿਲਾਂ ਫੜੀ ਨਹੀਂ ਗਈਆਂ)।
Mean time to detect (MTTD): excursion ਸ਼ੁਰੂ ਤੋਂ detection ਤੱਕ ਦਾ ਸਮਾਂ। MTTD ਘਟਾਉਣਾ ਅਕਸਰ ਕੱਚੇ ਟੂਲ ਵਰਣਨ ਤੋਂ ਬਹੁਤ ਵੱਡਾ ਨਫਾ ਦਿੰਦਾ ਹੈ।
Lots on hold: metrology/inspection ਸਿਗਨਲਾਂ ਕਾਰਨ hold ਤੇ ਰਹਿਣ ਵਾਲੇ ਲੌਟਾਂ ਦੀ ਮਾਤਰਾ ਅਤੇ ਉਮਰ। ਬਹੁਤ ਘੱਟ ਹੋਣਾ ਮਤਲਬ ਤੁਸੀਂ ਮੁੱਦਿਆਂ ਨੂੰ ਨਹੀਂ ਲੱਭ ਰਹੇ; ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੋਣ ਨਾਲ cycle time ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਦਾ ਹੈ।
Yield learning rate: yield ਸੁਧਾਰ ਦੀ ਦਰ ਪ੍ਰਤੀ ਹਫਤਾ/ਮਹੀਨਾ ਬਾਅਦ ਵੱਡੇ ਬਦਲਾਅ (ਨਵਾਂ node, ਨਵਾਂ ਟੂਲਸੈਟ, ਵੱਡਾ recipe revision)।
Cost of poor quality (COPQ): scrap + rework + expedite + late discovery costs ਜੋ escapes ਨੂੰ ਨਿਯੁਕਤ ਕੀਤਾ ਗਿਆ ਹੈ।
Cycle time impact: ਮਾਪ-ਜਾਂਚ-ਕਾਰਨ ਹੋਈ queue time ਅਤੇ rework loops। ਇੱਕ ਲਾਭਦਾਇਕ ਨਜ਼ਰੀਆ ਹੈ "ਲੌਟ ਪ੍ਰਤੀ minute of cycle time ਜੋ control step ਵੱਲੋਂ ਜੋੜਿਆ ਗਿਆ"।
ਜੇ ਤੁਸੀਂ ਸ਼ੁਰੂਆਤ ਲਈ ਆਸਾਨ ਸੈਟ ਚਾਹੁੰਦੇ ਹੋ, ਹਰ ਗਰੁੱਪ ਤੋਂ ਇੱਕ KPI ਚੁਣੋ ਅਤੇ ਇਸਨੂੰ SPC ਸਿਗਨਲਾਂ ਨਾਲ ਇੱਕੋ ਮੀਟਿੰਗ ਵਿੱਚ ਸਮੀਖਿਆ ਕਰੋ। For more on turning metrics into action loops, see /blog/from-measurements-to-action-spc-feedback-feedforward.
ਫੈਬ ਵਿੱਚ ਟੂਲ ਚੋਣ ਨੂੰ ਅਲੱਗ-ਥੱਲੇ ਯੰਤਰ ਖਰੀਦਣ ਵਾਂਗ ਨਹੀਂ ਦੇਖਿਆ ਜਾਂਦਾ—ਇਹ ਫੈਕਟਰੀ ਦੇ ਨਰਵਸ ਸਿਸਟਮ ਦਾ ਹਿੱਸਾ ਚੁਣਨ ਵਰਗਾ ਹੁੰਦਾ ਹੈ। ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਹਾਰਡਵੇਅਰ ਅਤੇ ਆਸ-ਪਾਸ ਦੇ ਮੈਜ਼ਰਮੈਂਟ ਪ੍ਰੋਗਰਾਮ ਦੋਹਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦੀਆਂ ਹਨ: ਇਹ ਕੀ ਲੱਭ ਸਕਦਾ ਹੈ, ਕਿੰਨੀ ਤੇਜ਼ ਚੱਲਦਾ ਹੈ, ਅਤੇ ਇਸਦਾ ਡੇਟਾ ਕਿੰਨ੍ਹਾਂ ਤਰ੍ਹਾਂ ਭਰੋਸੇਯੋਗ ਫੈਸਲੇ ਚਲਾਉਂਦਾ ਹੈ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਫੈਬ sensitivity (ਸਭ ਤੋਂ ਛੋਟੀ defect ਜਾਂ ਪ੍ਰਕਿਰਿਆ ਬਦਲ ਜੋ ਟੂਲ ਭਰੋਸੇ ਨਾਲ ਫੜ ਸਕਦਾ ਹੈ) ਅਤੇ nuisance rate (ਕਿੰਨੀ ਵਾਰ ਇਹ ਨਿਰਦੋਸ਼ ਸਿਗਨਲਾਂ ਨੂੰ ਫਲੈਗ ਕਰਦਾ ਹੈ) ਨੂੰ ਵੇਖਦੇ ਹਨ। ਜੇਕਰ ਇੱਕ ਟੂਲ ਹੋਰ ਸਮੱਸਿਆਵਾਂ ਲੱਭਦਾ ਹੈ ਤਾਂ ਇਹ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਵਧੀਆ ਨਹੀਂ ਹੈ ਜੇ ਇਹ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ false alarms ਨਾਲ ਪ੍ਰੇશਾਨ ਕਰ ਦੇਵੇ।
ਦੂਜਾ ਹੈ throughput: wafers per hour ਜਿਹੜਾ ਲੋੜੀਂਦੇ recipe settings 'ਤੇ। ਇੱਕ ਟੂਲ ਜੋ ਸਿਰਫ਼ slow mode 'ਚ spec ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ ਉਹ ਬੋਤਲਨੇਕ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ।
ਤੀਜਾ ਹੈ cost of ownership, ਜਿਸ ਵਿੱਚ ਖਰੀਦ ਕੀਮਤ ਤੋਂ ਆਗੇ ਹੋਰ ਚੀਜ਼ਾਂ ਸ਼ਾਮਲ ਹਨ:
ਫੈਬ ਇਹ ਵੀ ਦੇਖਦੇ ਹਨ ਕਿ ਟੂਲ ਕਿਵੇਂ MES/SPC, standard fab communication interfaces, ਅਤੇ ਡੇਟਾ ਫਾਰਮੈਟਾਂ ਨਾਲ smoothly ਜੁੜਦਾ ਹੈ ਜੋ auto charting, excursion detection, ਅਤੇ lot disposition ਨੂੰ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ। ਬਰਾਬਰ ਮਹੱਤਵਪੂਰਨ ਹੈ ਰਿਵਿਊ ਵਰਕਫਲੋ—ਡਿਫੈਕਟ ਕਿਵੇਂ classify ਹੁੰਦੇ ਹਨ, sampling ਕਿਵੇਂ manage ਹੁੰਦਾ, ਅਤੇ ਨਤੀਜੇ ਪ੍ਰਕਿਰਿਆ ਮੋਡੀਊਲ ਤੱਕ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਸ ਆਉਂਦੇ ਹਨ।
ਇੱਕ ਆਮ ਪਾਇਲਟ ਰਣਨੀਤੀ split lots ਵਰਤੀਦੀ ਹੈ (ਮੈਚ ਕੀਤਾ ਵਾਫਰ ਵੱਖ-ਵੱਖ ਮਾਪਣ ਤਰੀਕਿਆਂ 'ਚ ਭੇਜੋ) ਨਾਲ golden wafers ਟੂਲ-ਟੂਲ consistency ਨੂੰ ਸਮੇਂ ਦੇ ਨਾਲ ਚੈੱਕ ਕਰਨ ਲਈ। ਨਤੀਜੇ ਇੱਕ ਬੇਸਲਾਈਨ ਨਾਲ ਤੁਲਨਾ ਕੀਤੇ ਜਾਂਦੇ ਹਨ: ਮੌਜੂਦਾ yield, ਮੌਜੂਦਾ detection limits, ਅਤੇ corrective action ਦੀ ਤੇਜ਼ੀ।
ਕਈ ਫੈਬਾਂ ਵਿੱਚ, KLA ਵਰਗੇ ਵੈਂਡਰਾਂ ਨੂੰ capability, factory fit, ਅਤੇ economics ਦੇ ਇਸੇ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਮੁਲਾਂਕਣ ਕੀਤਾ ਜਾਂਦਾ ਹੈ—ਕਿਉਂਕਿ ਜਿੱਤਣ ਵਾਲਾ ਚੋਣ ਉਹ ਹੁੰਦਾ ਹੈ ਜੋ ਪ੍ਰਤੀ ਵਾਫਰ ਫੈਸਲੇ ਸੁਧਾਰਦਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਪ੍ਰਤੀ-ਵਾਫਰ ਮਾਪ।
Yield learning ਇੱਕ ਸਾਦਾ ਕਾਰਨ-ਅਤੇ-ਪਰਣਾਮ ਲੰਕ ਹੈ, ਭਾਵੇਂ ਟੂਲ ਜਟਿਲ ਹੋਣ: detect → diagnose → correct।
Inspection ਦੱਸਦਾ ਹੈ ਕਿੱਥੇ ਅਤੇ ਕਦੋਂ defects ਆਉਂਦੇ ਹਨ। Metrology ਦੱਸਦੀ ਹੈ ਕਿੰਨਾ ਪ੍ਰਕਿਰਿਆ ਡ੍ਰਿਫਟ ਹੋਈ (CD, overlay, film thickness ਆਦਿ)। Process control ਉਹ ਸਬੂਤ ਕਾਰਵਾਈ ਵਿੱਚ ਬਦਲਦਾ ਹੈ—recipes adjust ਕਰਨਾ, scanners/etch tools tune ਕਰਨਾ, maintenance ਕਸਨਾ, ਜਾਂ sampling plans ਬਦਲਣਾ।
ਇਹ ਸੂਚੀ ਵਰਤੋ ਜਦ ਤੁਸੀਂ ਵਧੀਆ yield ਪ੍ਰਭਾਵ ਚਾਹੁੰਦੇ ਹੋ ਬਿਨਾਂ "ਜ਼ਿਆਦਾ ਮਾਪਣ ਖਰੀਦਣ" ਦੇ:
ਇੱਕ ਅਣਦੇਖੀ ਉਪਾਇ ਇਹ ਹੈ ਕਿ ਟੀਮ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ measurement data ਨੂੰ operationalize ਕਰ ਸਕਦੀ ਹੈ—SPC signals, tool matching status, hold aging, ਅਤੇ MTTD/escape-rate ਰੁਝਾਨਾਂ ਨੂੰ combine ਕਰਨ ਵਾਲੇ ਡੈਸ਼ਬੋਰਡ।
ਇੱਥੇ ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ: ਟੀਮਾਂ chat ਵਿੱਚ ਵਰਕਫਲੋ ਵੇਰਵਾ ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਇੱਕ ਹਲਕੀ ਅੰਦਰੂਨੀ ਵੈੱਬ ਐਪ (ਉਦਾਹਰਣ ਲਈ SPC review console, excursion triage queue, ਜਾਂ KPI dashboard) ਤਿਆਰ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਫਿਰ ਪ੍ਰਕਿਰਿਆ ਦੇ ਨਾਲ iterate ਕਰ ਸਕਦੀਆਂ ਹਨ। ਕਿਉਂਕਿ Koder.ai React-based web apps ਨੂੰ Go + PostgreSQL backends ਦੇ ਨਾਲ ਸਮਰਥਨ ਕਰਦਾ ਹੈ—ਅਤੇ source code export ਦਿੰਦਾ ਹੈ—ਇਹ ਤੇਜ਼ ਪਾਈਲਟਾਂ ਅਤੇ ਅੰਦਰੂਨੀ ਇੰਜੀਨੀਅਰਿੰਗ ਨੂੰ ਹandoff ਕਰਨ ਲਈ ਫਿੱਟ ਹੋ ਸਕਦਾ ਹੈ।
If you want a refresher on how these pieces connect, see /blog/yield-management-basics. For cost and adoption questions, /pricing can help frame what “good” ROI looks like.
Inspection ਅਣਊਮੀਦਿਤ дефੈਕਟਾਂ (particulate, scratch, pattern breaks, anomalies) ਦੀ ਤਲਾਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਦਾ ਸਵਾਲ ਹੁੰਦਾ ਹੈ: “ਵਾਫਰ ਦੇ ਕਿਸੇ ਹਿੱਸੇ ਵਿੱਚ ਕੁਝ ਗਲਤ ਹੈ?”
Metrology ਨਿਰਦੇਸ਼ਤ ਨਤੀਜਿਆਂ (CD, overlay, film thickness, planarity) ਨੂੰ ਮਾਪਦਾ ਹੈ ਅਤੇ ਹੁੰਦਾ ਹੈ: “ਕੀ ਪ੍ਰਕਿਰਿਆ ਟਾਰਗੇਟ ਨੂੰ ਹਾਸِل ਕਰ ਰਹੀ ਸੀ?”
ਅਮਲੀ ਤੌਰ ’ਤੇ, fabs inspection ਨੂੰ yield-killers ਜਲਦੀ ਫੜਨ ਲਈ ਵਰਤਦੇ ਹਨ, ਅਤੇ metrology ਨੂੰ ਪ੍ਰਕਿਰਿਆ ਡ੍ਰਿਫਟ ਨੂੰ ਲੌਟ-ਵਿਆਪਕ ਨੁਕਸਾਨ ਬਣਨ ਤੋਂ ਰੋਕਣ ਲਈ।
ਕਿਉਂਕਿ ਮਾਪ-ਜਾਂਚ ਉਹ ਰੋਜ਼ਾਨਾ ਫੈਸਲੇ ਚਲਾਉਂਦੀ ਹੈ ਜੋ ਅਖੀਰਕਾਰ yield ਅਤੇ ਲਾਗਤ ਨੂੰ ਤੈਅ ਕਰਦੇ ਹਨ:
ਅੱਗੇ ਹੋ ਕੇ ਤੇਜ਼ੀ, ਦੁਹਰਾਏ ਜਾਣ ਦੀ ਯੋਗਤਾ ਅਤੇ ਸਹੀ ਵਰਗੀਕਰਨ ਮਾਪ-ਜਾਂਚ ਨੂੰ ਤੇਜ਼ containment ਅਤੇ ਘੱਟ ਮਹਿੰਗੀਆਂ ਅਚਾਨਕ ਘਟਨਾਵਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ।
ਆਮ “insert points” ਉਹਨਾਂ ਕਦਮਾਂ ਦੇ ਬਾਅਦ ਹੁੰਦੇ ਹਨ ਜਿੱਥੇ ਵੈਰੀਏਸ਼ਨ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਠੀਕ ਕਰਨਾ ਮਹਿੰਗਾ ਪੈਂਦਾ ਹੈ:
ਮੁਕ਼ਾਬਲਾ ਇਹ ਹੈ ਕਿ ਜਿੱਥੇ ਨਿਰਣਾ ਲੈ ਸਕਦੇ ਹੋ ਉਥੇ ਹੀ ਮਾਪ ਕਰੋ, ਤਾਂ ਜੋ ਸਮੇਂ ਤੇ ਕਾਰਵਾਈ ਕੀਤੀ ਜਾ ਸਕੇ।
Sampling plan ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿੰਨੀ ਵਾਰ ਅਤੇ ਕਿਹੜੀ ਡਗਰੀ ਤੱਕ ਮਾਪ ਕਰਦੇ ਹੋ (wafers per lot, sites per wafer, ਕਿਹੜੇ layers)।
ਪ੍ਰਾਇਕਟਿਕਲ ਨਿਯਮ:
ਜ਼ਰੂਰਤ ਤੋਂ ਜ਼ਿਆਦਾ sampling cycle time ਨੂੰ ਰੋਕ ਸਕਦੀ ਹੈ; ਘੱਟ sampling escapes ਦਾ ਖਤਰਾ ਵਧਾਉਂਦੀ ਹੈ।
Inline ਮਾਪ-production flow ਵਿੱਚ, ਉਸ ਟੂਲ ਦੇ ਨਜ਼ਦੀਕ ਹੁੰਦੀ ਹੈ ਜਿਸ ਨੇ ਨਤੀਜਾ ਬਣਾਇਆ—ਇਹ control loops ਲਈ ਤੇਜ਼ ਹੈ ਅਤੇ queue time ਘਟਾਉਂਦੀ ਹੈ।
Offline ਮਾਪ ਲੈਬ ਜਾਂ ਡੈਡੀਕੇਟੇਡ ਏਰੀਆ ਵਿੱਚ ਹੁੰਦੀ ਹੈ—ਅਕਸਰ ਡੀਪਰ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਹੌਲੀ ਹੋਣ ਵਾਲੀ। ਇਹ troubleshoot, model building ਅਤੇ root-cause ਪੱਕਾ ਕਰਨ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ—ਪਰ ਕਾਰਵਾਈ ਵਿੱਚ ਦਿਰੀ ਲਾ ਸਕਦੀ ਹੈ।
ਵਾਸਤਵਿਕ ਮਕਸਦ ਸੰਤੁਲਨ ਹੈ: ਸਮੇਂ ਤੇ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਹੀ ਦਿਸ਼ਾ ਵਿੱਚ ਘੁਮਾਉਣ ਲਈ ਕਾਫ਼ੀ inline coverage ਅਤੇ ਜਦ ਡੇਟਾ ਬਦਲ ਦਿਖਾਏ ਤਾਂ ਟਾਰਗੇਟਡ offline ਕੰਮ।
Killer defect ਉਹ ਹੈ ਜੋ ਸੰਭਵ ਤੌਰ 'ਤੇ ਫੰਕਸ਼ਨਲ ਫੇਲ੍ਹਰ ਪੈਦਾ ਕਰੇ (opens, shorts, leakage, parametric shift)।
Nuisance defect ਅਜਿਹਾ ਹੈ ਜੋ ਮੌਜੂਦ ਹੈ ਜਾਂ ਲੱਗਦਾ ਹੈ ਪਰ yield 'ਤੇ ਅਸਰ ਨਹੀਂ ਪੈਂਦਾ—ਆਮ ਤੌਰ 'ਤੇ ਕੋਸਮੈਟਿਕ pattern roughness ਜੋ ਮਾਰਜਿਨ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ।
ਵਰਗੀਕਰਨ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ fabs detection 'ਤੇ ਹੀ ਨਹੀਂ, balki detection ਦੇ ਰਿਸਪਾਂਸ ਤੇ ਭੁਗਤਾਨ ਕਰਦੇ ਹਨ: ਰਿਵਿਊ ਟਾਈਮ, ਲੌਟ ਹੋਲਡ, ਰੀਵਰਕ ਅਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮਾਂ। ਵਧੀਆ ਵਰਗੀਕਰਨ ਘੱਟ ਮਹਿੰਗੀਆਂ over-reactions ਲਿਆਉਂਦੀ ਹੈ।
False negatives (ਕੁਝ killers ਛੁੱਟ ਜਾਂਦੇ ਹਾਂ) ਸਭ ਤੋਂ ਖਤਰਨਾਕ ਹਨ: yield ਖੋਹ ਬਾਅਦ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ ਜਦ ਕੀ ਵੈਲਯੂ ਵਧ ਚੁੱਕੀ ਹੁੰਦੀ ਹੈ।
False positives ਮੰਗੋਂ-ਬਾਹਰ ਦਾ ਖਰਚ ਪੈਦਾ ਕਰਦੇ ਹਨ: ਅਣਜ਼ਰੂਰੀ holds, ਵਧੀਕ ਰਿਵਿਊ ਅਤੇ ਲੰਬੀਆਂ ਕਤਾਰਾਂ।
ਪ੍ਰਯੋਗਿਕ ਲਕਸ਼ ਹੈ “ਹਰ ਚੀਜ਼ ਲੱਭੋ” ਨਹੀਂ, ਸਗੋਂ ਸਹੀ ਚੀਜ਼ਾਂ ਇੱਥੇ ਸਮੇਂ ਤੇ ਲੱਭੋ ਅਤੇ ਉਨ੍ਹਾਂ ਤੇ ਕਾਰਵਾਈ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲਾਗਤ-ਮੁਨਾਫ਼ਾ ਜਾਣਚੋ।
CD (critical dimension) ਉਹ ਮਾਪ ਹੈ ਜੋ ਪ੍ਰਿੰਟ ਕੀਤੀ ਲਾਈਨ ਦੀ ਚੌੜਾਈ/ਆਕਾਰ ਦਿਖਾਉਂਦਾ ਹੈ—ਜਿਵੇਂ ਟ੍ਰਾਂਜ਼ਿਸਟਰ ਦੀ gate ਲੰਬਾਈ ਜਾਂ ਇਕ ਪਤਲੀ ਧਾਤ ਲਾਈਨ ਦੀ ਚੌੜਾਈ।
ਛੋਟੇ CD ਡ੍ਰਿਫਟ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਬਿਜਲੀ ਵਿਵਹਾਰ ਬਦਲ ਸਕਦੇ ਹਨ (ਰੋਧ, ਲੀਕੇਜ, ਡਰਾਈਵ ਕਰੰਟ ਆਦਿ) ਕਿਉਂਕਿ ਆਧੁਨਿਕ margins ਬਹੁਤ ਮੁੱਕਤ ਹਨ।
ਬਹੁਤ ਸਾਰੀਆਂ CD ਸਮੱਸਿਆਵਾਂ ਦੇ ਪਰਛਾਂਹ ਨੂੰ focus/exposure signatures ਨਾਲ ਪਛਾਣਿਆ ਜਾ ਸਕਦਾ ਹੈ—ਇਸ ਲਈ CD ਮੈਟਰੋਲੋਜੀ + SPC ਰਿਸਪਾਂਸ ਯੋਜਨਾ ਅਕਸਰ ਉੱਚ ROI ਦਿੰਦੇ ਹਨ।
Overlay ਮਾਪਦਾ ਹੈ ਕਿ ਇਕ ਲੇਅਰ ਪਿਛਲੀ ਲੇਅਰ ਉੱਤੇ ਕਿੰਨੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਥਿਤ ਹੈ।
ਜੇ alignment ਗਲਤ ਹੋ ਜਾਂਦੀ ਹੈ ਤਾਂ vias ਆਪਣੇ ਟਾਰਗੇਟ ਨੂੰ ਨਹੀਂ ਪਹੁੰਚਦੇ, contacts ਅਧ-ਸਥਿਤ ਰਹਿ ਜਾਂਦੇ ਜਾਂ edges ਗਲਤ ਢੰਗ ਨਾਲ ਓਵਰਲੈਪ ਹੋ ਸਕਦੇ ਹਨ। ਹਰ ਲੇਅਰ ਦੇ CD ਠੀਕ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਵੀ, misalignment ਕਾਰਨ ਚੀਪ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ।
Overlay control ਉਨ੍ਹਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਅਹਮ ਹੈ ਜਿੱਥੇ alignment ਬਜਟ ਕਠੋਰ ਹੋਵੇ ਜਾਂ ਅਨੇਕ patterning ਕਦਮਾਂ ਵਿੱਚ ਤਰਤੀਬੀ ਗਲਤੀਆਂ ਜੁੜ ਸਕਦੀਆਂ ਹੋਣ।
Latency ਉਹ ਸਮਾਂ ਹੈ ਜੋ ਇੱਕ ਵਾਫਰ ਪ੍ਰੋਸੈਸ ਹੋਣ ਤੋਂ ਬਾਅਦ ਇੱਕ ਵਰਤੋਯੋਗ ਮਾਪ ਨਤੀਜੇ ਤੱਕ ਲੱਗਦਾ ਹੈ।
ਜੇ ਨਤੀਜੇ ਕਈ ਲੌਟਾਂ ਦੇ ਚੱਲਣ ਤੋਂ ਬਾਅਦ ਆਉਂਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਸਿਰਫ਼ ਭਵਿੱਖ ਨੂੰ ਠੀਕ ਕਰ ਸਕਦੇ ਹੋ ਪਰ ਮੌਜੂਦਾ ਵਿੱਚ ਨੁਕਸਾਨ ਇਕੱਠਾ ਹੋ ਰਿਹਾ ਹੁੰਦਾ ਹੈ।
Latency ਘਟਾਉਣ ਲਈ:
ਬਹੁਤ ਵਾਰ ਇਹ ਕਦਮ ਰੇਖੀ ਟੂਲ ਦੀ sensitivity ਵਿੱਚ ਥੋੜੀ ਵਾਧੇ ਤੋਂ ਬੇਹਤਰ ਨਤੀਜੇ ਦਿੰਦੇ ਹਨ।