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.
Politics : Formerly About Advanced Micro Devices

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Petz who wrote (23859)10/2/1997 3:58:00 PM
From: Yousef   of 1578136
 
John,

Re: "This would suggest exactly the problem Yousef has been talking about. I would
suggest you re-read some of his recent posts."

This suggestion of a mask change causing the speed bin yield problem is
ridiculous. One, you have to make a large "leap of faith" to state
that the fix of the Linux bug would just happen to be in a critical
speed path. Two, no Fab manager is his right mind would ever commit
all of his WIP (Work In Process) to use an untried reticle. AMD would
have run a couple of high priority lots with the new reticle before
committing the whole Fab. If not, then the K6 design manager and Fab
manager should be fired !!

I think a more likely explanation is simply an unexpected process variation
causing a speed path that just barely met the 233mhz speed to now fall
short of 233mhz. AMD probably announced the 233mhz K6 product with
lower bin yield than normal due to the product pressure from Intel. Then
as the process has varied, the bin yield has dropped dramatically and
any yielding 233mhz parts (even as scarce as they are) have been promised
to PC vendors. As Ritz's pointed out, the very fact that AMD needed to
raise their operating voltage to meet the 233mhz speed point is a clear
indication of a part with little to no margin.

John, I think you would be wise to re-assess your position on this !!

Make It So,
Yousef
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext