[SI-LIST] Re: OT: Overvoltage breakdown on 120 nm silicon?
- From: Dimiter Popoff <dp@xxxxxxxxxxx>
- To: <si-list@xxxxxxxxxxxxx>
- Date: Thu, 17 Feb 2011 21:17:08 +0200
But do you believe the memory can fail in such a subtle way?
I have tested it - well, most of it, $30000 to $3ffffff - in
a pretty rigorous way,
>> I also made the CPU check almost all of the 64M DDRAM, write address
>> to location/verify - works, did that with the written address rotated
>> 0 to 31 times, also works.... And all that also misaligned,
>> also works fine - it is pretty maddening really.
Do you think the memory can have failed even though it passes
the above? Not unthinkable to me, but I have not seen many failed
devices.
There is one more reason why I am digging more into what you
suggest.
One of the changes I made was on this memory overvoltage protection,
it was too soft and triggered at times with no need. So I made it
harder... It may have seen a somewhat higher overvoltage event
than before only that day.
I guess I'll have to replace the memories as well, perhaps
start with them.
Please comment some more on what failures you have seen/heard about
etc. in that context.
Dimiter
>Date: Thu, 17 Feb 2011 10:52:15 -0800
>From: steve weir <weirsi@xxxxxxxxxx>
>To: Dimiter Popoff <dp@xxxxxxxxxxx>
>CC: si-list@xxxxxxxxxxxxx
>Subject: Re: [SI-LIST] OT: Overvoltage breakdown on 120 nm silicon?
>
>Memories have been known to suffer cell damage from OV / UV transients
>at the I/Os. Many engineers think that if damage comes via the I/O that
>the I/O will show up problems first. That's not always true. In the
>1990's I recall static RAM memories from one vendor in particular that
>were far more vulnerable than from other vendors. Your device may have
>been ESD'd, or a victim of too many OV/UV transients at the I/Os. Stuff
>happens.
>Dimiter Popoff wrote:
>> I am facing an unbelievable reality at the moment.
>> A processor which will not boot - although all tests I have
>> done to it pass.
>>
>> I still refuse to believe I can have killed the CPU - but after
>> 3 days of tracing of the boot process I seem to run out of
>> other explanations (heck, I had to dig through code some of
>> which I have written 15+ years ago...).
>>
>> The CPU (an MPC5200B) appears to work - monitor via UART, even disk
>> I/O worked etc. - but it fails some way into the boot process.
>> This happened after I fixed the power up sequencing closer to
>> the specs :-).
>>
>> That board had been working for nearly a year before that, had survived
>> the development process (lots of programming/debugging and power on/off).
>> It had lived through all that with a nice spike on the 1.5V, 2.5V and 3.3V
>> upon poweron, perhaps 1 to 5mS over the absolute maximum by perhaps
>> 50%. I changed that now - and it won't boot, fails at more or less
>> the same place (pulls the wrong return address from the stack if I am
>> not tracing ....). This is after a few system calls have returned OK
>> already. It looks unbelievable to me to have killed the CPU in such
>> a subtle way - but I have not seen many killed ones.
>>
>> How likely is it that I have killed it? The only news about the
>> spikes which I believe to may have killed it is that I now know they
>> used to exist...
>> Not to speak of the other boards which keep on workingfine :).
>>
>> I also made the CPU check almost all of the 64M DDRAM, write address
>> to location/verify - works, did that with the written address rotated
>> 0 to 31 times, also works.... And all that also misaligned,
>> also works fine - it is pretty maddening really.
>>
>> I am simply clueless as to how likely it is to break a gate
>> with say 2.5V instead of 1.5? I guess drain/source breakdown won't
>> be an issue even if they break for a few mS (not enough energy
>> to fry anything)?
>>
>> Hopefully people with more silicon inside knowledge can
>> comment...
>>
>> Thanks,
>> Dimiter
>>
>> ------------------------------------------------------
>> Dimiter Popoff Transgalactic Instruments
>>
>> http://www.tgi-sci.com
>> ------------------------------------------------------
>> http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
>>
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List technical documents are available at:
http://www.si-list.net
List archives are viewable at:
//www.freelists.org/archives/si-list
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
Other related posts: