Breaking News
Newest First | Oldest First | Threaded View
User Rank
Re: I think EDAC depends on the application
tpfj   11/5/2013 9:42:25 AM
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.

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


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
Re: I think EDAC depends on the application
Frank Eory   10/30/2013 6:59:27 PM
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.


User Rank
Re: I think EDAC depends on the application
Bert22306   10/29/2013 4:14:36 PM
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.

User Rank
I think EDAC depends on the application
MS243   10/29/2013 4:02:12 PM
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. Parts Search

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

What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.

Brought to you by:

Like Us on Facebook
Special Video Section
The LTC2380-24 is a versatile 24-bit SAR ADC that combines ...
In this short video we show an LED light demo to ...
Wireless Power enables applications where it is difficult ...
LEDs are being used in current luxury model automotive ...
With design sizes expected to increase by 5X through 2020, ...
Linear Technology’s LT8330 and LT8331, two Low Quiescent ...
The quality and reliability of Mill-Max's two-piece ...
LED lighting is an important feature in today’s and future ...
The LT8602 has two high voltage buck regulators with an ...
Silego Technology’s highly versatile Mixed-signal GreenPAK ...
The quality and reliability of Mill-Max's two-piece ...
Why the multicopter? It has every thing in it. 58 of ...
Security is important in all parts of the IoT chain, ...
Infineon explains their philosophy and why the multicopter ...
The LTC4282 Hot SwapTM controller allows a board to be ...
This video highlights the Zynq® UltraScale+™ MPSoC, and sho...
Homeowners may soon be able to store the energy generated ...
The LTC®6363 is a low power, low noise, fully differential ...
See the Virtex® UltraScale+™ FPGA with 32.75G backplane ...
Vincent Ching, applications engineer at Avago Technologies, ...