Electronic Design

Don't Fret Over IC Obsolescence, Prepare For It

ICs are discontinued all the time. Last year, some 150,000 components were declared end of life (EOL). For some manufacturers, this isn't a problem. Their products are on to the next revision anyway. For more and more long-life systems manufacturers, though, obsolescence drains time and money. One study says a redesign could cost more than a half-million dollars. Fortunately, by following some common sense, you can protect your systems from obsolescence.

First, include component engineering in the design phase and identify the problem components. Calculate the impact each component will have if it is discontinued. Identify the cost drivers. Usually that's requalification, but don't ignore logistics or carrying costs. You can go crazy by reacting to every discontinuation notice. An obsolete memory chip is easy to solve, while a discontinued microcontroller can push your costs sky-high. The 80-20 rule applies here: 20% (or fewer) of your devices will cause 80% of the problem. Identify that 20% before the parts and vendors are chosen.

Second, minimize the probability of an early discontinuation notice by choosing the right part for the socket. If one of your candidate chips is used primarily in a cell phone, then watch for a quick EOL. Choose parts that specifically target your market and application, and choose a vendor that has a reputation for supplying devices for the length of time you require.

In picking a processor, beware of "compatibility." Reusable code is great, and you should pursue it. Yet choosing a microprocessor because it will have compatible versions in the future won't save you from rewriting your software. Even a small change to a chip can cause a rewrite of some code, which in turn can trigger a requalification effort. If code is written in C, there is often minimal cost difference between porting code to a new version of the same processor family and porting to a new family altogether. Writing in high-level languages is the best way to protect your code, while assembly code is likely doomed.

Third, even though you've chosen a part with the right pedigree, have a plan in place just in case. Bad news comes without warning, and Murphy's Law applies: the bigger a problem it will cause, the shorter the notice you will get. If you wait until the last minute, you have only one choice—a huge last-time buy.

Look closely at all the options, and keep your plan flexible. Calculate the entire life-cycle costs of any option—non-recurring costs, recurring costs, carrying costs, and logistics costs. One option may work well with one kind of part, while another will be better for another. One option may look good today but be problematic down the road.

Plan for only the hard problems—the troublesome 20%. Have a blanket strategy for the rest. The easiest is a lifetime buy, but a scheduled redesign works well sometimes. If you've started the process during the design phase, it's already in the budget, so you can solve the easy ones quickly and focus on the hard ones.

Review your plan regularly, yearly at first, and perhaps more often as the product ages. Review the status of your problem parts. Are they in danger of being discontinued?

Finally, develop a strategy to predict and respond before the part goes EOL. Prediction tools can become a part of your system. Keep in touch with the supplier, too. If a part that could endanger your product is on the brink, act well before the discontinuation notice. Begin your effort early so you aren't pressed for time when the dreaded notice comes in. It may be as simple as acquiring a year's supply, or you might begin an emulation or redesign effort.

Obsolescence likely will continue to accelerate as life cycles for cell phones and computers deviate from industrial and medical systems. The European Union's Restrictions on Hazardous Substances will only compound the issue in the next few years. Only a methodical approach will alleviate the problem.

See Associated Figure

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.