Breaking News
Comments
Newest First | Oldest First | Threaded View
tpfj
User Rank
CEO
Re: I think EDAC depends on the application
tpfj   11/5/2013 9:42:25 AM
NO RATINGS
I've seen similar. Routing RTC (real time clock) tracks across address tracks on a PCB for a mobile phone caused the RTC to jitter when those address lines toggled on wake-up from deep sleep, thereby destroying the value of having an RTC in the first place and triggering a complete cell aquisition. Battery did not last long. Temporary solution was to rearrange program memory such that those address lines did not toggle on wake-up. Permamant solution was to respin the PCB.

MS243
User Rank
Manager
Re: I think EDAC depends on the application
MS243   11/3/2013 3:45:55 PM
NO RATINGS
For examples of systems being used in high error generation enviroments that do not use EDAC see www.spacemicro.com.

 

There are other methods besides these -- I have written a requirements guidelines document for this for another company for using automotive parts in an aerospace environment(Used to generate requirements for software)   I have also done this for firmware.

 

It also would be interesting to see if the PCB had a latent defect such as a weak ground via, or other issue that could have contributed in the Toyota case -- Often unaware board layout people will reduce an OEM PCB's layer count to try and save cost -- this can lead to ground bounce due to I/O toggling and result in bit errors in the core CPU on rare occasions when a large number of pins toggle at once due to coincidence.

Good skill with PCB design can make or break a board in mass production -- have had to help troubleshoot many mass production board issues that contributed to hardware issues also.

See my profile for contact details if more information is needed

 

 

Frank Eory
User Rank
CEO
Re: I think EDAC depends on the application
Frank Eory   10/30/2013 6:59:27 PM
NO RATINGS
Let's point out that parity checked RAM is just EDAC RAM that uses the simplest possible EDAC. As we've been discussing on other threads, in the end it's all about probability. There is a probability that one or more RAM bits could get randomly flipped, and the single bit flip event can be detected with a parity check, but many multi-bit flips will escape the parity check. EDAC can detect and/or correct many multi-bit flips, depending on the complexity of the error correcting code.

How much EDAC is enough? How low of a failure probability is low enough? As was already stated, "it depends."

We all agree that if a failure could cost a human life, then the probability of failure must be extremely low. But no matter how low we make it, failure-proof can never be completely guaranteed. And that is likely to be unsettling to many people.

 

Bert22306
User Rank
CEO
Re: I think EDAC depends on the application
Bert22306   10/29/2013 4:14:36 PM
NO RATINGS
I agree. I wouldn't go off and focus on just this one aspect - whether RAM was parity checked or not. There are way more overarching design issues at play here, it looks like, and there are safe systems out there that don't necessarily have parity checked RAM.

MS243
User Rank
Manager
I think EDAC depends on the application
MS243   10/29/2013 4:02:12 PM
NO RATINGS
Depends -- For example in DO-178/DO-254 used in the aviation industry, there are Safety Assurance Levels -- Level A = Loss of Aircraft or Life, Level E = No effect on continued safe flight of the aircraft --  For Key things like Flash and RAM integrity, There are OS'es that have  been safety certified that can perform this all in software ---  In aircraft systems whole redundant systems are used such that this allows one systems OS to drop offline and restart while the remaining Two or More Systems continue operation -- With that said this also increases cost sometimes.   For automotive systems, the preceding systems relied on two means of controlling throttle -- the mechanical cable or link, and the EFI sensor -- both had to be in agreement to go full throttle -- It is clear the designers did not think the code through in terms of the OS implementations in this regard from the comments/article, based on the safety implications.



Most Recent Comments
Flash Poll
EE Life
Frankenstein's Fix, Teardowns, Sideshows, Design Contests, Reader Content & More
Engineer's Bookshelf
Caleb Kraft

The Martian: A Delightful Exploration of Math, Mars & Feces
Caleb Kraft
6 comments
To say that Andy Weir's The Martian is an exploration of math, Mars, and feces is a slight simplification. I doubt that the author would have any complaints, though.

The Engineering Life - Around the Web
Caleb Kraft

Surprise TOQ Teardown at EELive!
Caleb Kraft
Post a comment
This year, for EELive! I had a little surprise that I was quite eager to share. Qualcomm had given us a TOQ smart watch in order to award someone a prize. We were given complete freedom to ...

Design Contests & Competitions
Caleb Kraft

Join The Balancing Act With April's Caption Contest
Caleb Kraft
57 comments
Sometimes it can feel like you're really performing in the big tent when presenting your hardware. This month's caption contest exemplifies this wonderfully.

Engineering Investigations
Caleb Kraft

Frankenstein's Fix: The Winners Announced!
Caleb Kraft
8 comments
The Frankenstein's Fix contest for the Tektronix Scope has finally officially come to an end. We had an incredibly amusing live chat earlier today to announce the winners. However, we ...

Top Comments of the Week
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)