SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Apple Inc.
AAPL 279.20-1.7%2:05 PM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Hugues who wrote (9895)3/23/1998 12:32:00 PM
From: Eric Yang  Read Replies (2) of 213173
 
"And the cost of die is a function of the square of the square of the size (exponent:4). Because with a twice smaller size die, you can put four times as much dies in a wafer, and you have 4 times less defaults (the default yield is itself a function of the size of the wafer)."

Smaller features size reduces cost in many ways but there are also many factors that will decrease yield when feature size is reduced. I'll just list a couple.

1.When circuit density is increased, defects that would have ended up been in none sensitive area has a higher probability of intersecting with critical circuit. Thus many previously non-fatal defects will become "killer" defects.

2.Smaller image used with smaller feature size are harder to print. It has the inherit tendency to increase defect count.

3. image with smaller feature size become ever more vulnerable to smaller defect size. Generally defects that are 1/10 the feature size are non-fatal even if it sits right on critical circuit.

All of these work against the manufacture. According to one assessment, if the defect density is kept constant, the wafer-sort yield would be about 10-15% lower when you move from .5 um to .35. So it's a trade off between packing more chips per wafer (good) and increase procedural cost, as well as lower wafer-sort yield (bad).

Eric
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext