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: Yousef who wrote (23885)10/2/1997 6:57:00 PM
From: Petz   of 1577814
 
Yousef, re: <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>

There were two ways to fix the Linux bug -- fix the logic that detected "potential self-modifying code" or fix the double execution of an instruction which occurred under extremely rare conditions when "potential self modifying code" was detected.

AMD may have chosen the first way because of time pressure. This required changing a 24 or 25 bit address comparator to a full 32 bits. This could affect speed in several ways: 1)the upper address bits are usually the last ones to settle, therefore the comparison becomes valid later in the clock cycle, 2)additional loading on the upper address bits, 3)additional capacitance on the upper address bits due to the routing of these bits to the comparator.

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 !!

There is always the possibility that 1)the test lots had better process control than the rest of the fab, 2)not enough test lots were run to judge speed mix because no difference was expected, 3)the test lots just gave randomly better results than they should have.

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.

The main argument against this is that LB report says it will take a month to fix it. If they changed something in the process, why not just go back to the old temperatures, timing, solution mix or whatever was changed?

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.


1. Intel announced the 300 MHz part with lower bin yield than normal due to product pressure also.
2. For the K6, the bin yield AND the overall yield have been improving until about a month ago, when the 233 part suddenly became scarce again.
3. Regarding no margin in speed, many K6's have been successfully overclocked to 250 MHz and even to 262.5 MHz (75 x 3.5). There are also examples of successful 233 MHz operation at 2.9v ... until the last month or so.

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

This is not a position. I don't know 100% what caused the speed binning problem. Chances are, its a combination of more than one thing. What I do know is
1. The problem will not exist one month from yesterday
2. The problem did not exist one month ago

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