No Second Sources - Embedded.com

No Second Sources

The very first board I designed that used FPGAs, back in the early 90s, had a huge hunk of firmware. We popped out a prototype board pretty quickly, which gave the software people a test platform. The code was complex; development dragged on for over a year before the system was customer-ready.

By then we couldn't buy FPGAs. The vendor had obsoleted them in favor of a newer, bigger, faster, more feature-rich part.

Disgusted, we delayed shipping for three months while re-engineering the board with new parts from a different vendor. Those extra months of engineering and lost revenue trashed the year's profit and loss statement.

Ironically, the main impetus for designing that product was that its older version used a peculiar kind of memory device that had itself gone out of production. That vendor had notified us well in advance so we could order a sufficient quantity to tide us over for a time.

In the distant past engineers expected parts to have second sources, alternative vendors who would continue to produce their products even if the prime got out of the business. Identical microprocessors were available from many companies. Logic devices were all elements of accepted families of products. Everyone made CMOS logic. Everyone made TTL components.

Today that's much less the case. Vendors tout their own “solutions” which, while generally wonderful bits of technology are hopelessly proprietary. The customer succeeds at the whim of the vendor; if they discontinue a part, you're plain outa luck with no attractive options.

In my travels around the industry I often hear such tales of woe. So many products use components with such short lifecycles that there's a re-engineering required before the first units even make it out the door.

It's easy to understand where the problems come from. In the olden days there weren't nearly so many variants of ICs and other components. How many distinct CPUs existed in, say, 1980? Consider the 8051 or PIC today: Each of these comes in hundreds of flavors, each tuned to a narrow market segment. Second sourcing isn't financially viable.

Yet customers do need stable sources of supply. Some embedded systems stay in production for achingly long periods of time. So a few companies fill their inventories with decades' worth of parts, to the shrill howls from accounting and senior management.

Though the parts may be critical to long-term success, IRS rules require depreciating them. Inventory's value – and thus the company's, since inventory is on the balance sheet – declines. That's no way to satisfy the stockholder.

The obsolescence of parts could be considered a job security program for EEs, but none of us care to work on old equipment, and it's certainly not a money-maker for the company.

What's your take? Have you had problems with parts going off the market? What action do you take?

Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at . His website is .


One might think that obsolescence is job security for EE's!

The primary problem with sole-sourcing is the pressures to 'differentiate' oneself from the competition. This all-consuming drive to 'differentiate' oneself from the competition is the primary raison-etre' for this sole-sourcing state of affairs! In contrast to conventional wisdom; I have found the following to be true:

– Working on obsolescent technologies tends to be a 'career-killer' for your normal permanent employees.

– If you mean 'job-security' as in getting on the design tread-mill to create the next generation of 'whiz-bang', or 'whup-a*s', then usually, it is not obsolescence that drives this… it is 'fear-of-obsolescence' that drives this… or the 'need-to-differentiate'.

– Even though the consulting types make a large portion of their bread and butter bringing in 'new technologies', there is a lot of work out there supporting, and extending 'obsolescent' technologies.

I even have a reverse 8080 dissassembler that gets used from time to time!

– Ken Wada


Just a comment relating to end of life… OS's have even a shorter end of life. Windows 3.1, Windows95, Windows98, WindowsNT, 2000, XP, now there is Bill's new OS. Seems like every year we have to throw out an old OS to get one with fewer bugs. If IC's had the bugs that MS OS's have, nothing would work.

– Steve King


After getting burned by vendor lock-in many years ago, I write portable code.

Whatever happens, we have got

At least nine-tenths done and that's a lot.

– John Firestone


The problem is exacerbated by the qualification requirements and long support lifetimes of the defence industry. There are companies that make a good living keeping an inventory of a product that a defence product needs.

– Chris M


Yup we consulting types do make our bread and butter on working with the latest technology and we get compensated for it a lot better than the sustaining employee. Always makes me laugh when I see Engineers who are not getting paid well and working with someone else's old nightmare, certainly indicates Engineers who have made bad career decisions!

But I am slipping off topic the part about obsolescence today that bothers me is the out and out lies told by manufactures about fit, form, and function compatible parts to replace end of life devices. I just got done debugging one of these (that went end of life during prototyping of a new system) that had to be replaced, th manufacturer had changed a no connect pad on a BGA form factor device (Intel flash) to a has to be grounded pad or else bad things happened, and the timing of some of the commands went from nanoseconds to seconds! But this was sold as fit, form & function compatible!

– Chris Gates


The problem appears when trying to leverage the good prices from the consumer market (due to volume) and try to extend the life of your product far beyond the consumer products.

Embedded components can have a better garanteed life at the expense of paying a price premium. (10yrs should not be a big problem)

Getting the best of both worlds is what is hard to achieve. You're then tied to rollovers because of AoS (which no one is willing to invest in).

The only solution is investing in platforms where new products are backwards compatible with the old ones, and are able to roll them.

This causes an extra cost (platform/new design in mature product/…) that has to be carefully controlled, as might make the embedded market solution a better solution overall vs. leveraging consumer solutions.

I've still not found a magic formula

– Carlos Lahoz


My experience has been to consider two factors:

1) Does the vendor like to end-of-life or allocate product unexpectedly (Motorola has to be the poster child). If so, don't use them.

2) Is the product early in the family lifecycle? Early might be harder on dev tools, but it certainly helps when they start adding newer, improved parts to the family.

– Andy Kunz


I have run into this with the microcontrollers we use for our products. By using C instead of assembler, the code I write is a bit more portable, but because the I/O changes, there are a number of tweaks that have to be done. I would really like second sources on these parts, but that does not appear likely!

– Dave Telling


Mr. Firestone makes a good point about writing portable code. While I think that any embedded system design is going to force you into non-portable code at some points, you should be able to leverage abstraction to keep your core IP portable.

Why is this so important? The way I see it, is that it takes much longer to port code from one processor/semi-house to another than it takes to 'port the PCB.'

One thing that we are doing at my company, is moving everything we can into an SRAM-based FPGA design using soft-core processors. Sure, the FPGA can get obsoleted, but they typically have much less painful migration paths than MCUs. Plus, the non-portable parts of the firmware become significantly easier to port (if at all) due to being able to synthesize the same CPU, peripherals, and memory map.

– Brandon White


There's no doubt that consideration of the EOL of components becomes an important design decision, and one that carries considerable risk.

It's interesting to compare the IC industry with the well-established automotive industry.

In most cases, it's feasible to keep a car from as far back to the 50s running and on the road, because parts are very much backwards compatible, and a considerable aftermarket exists to supply needed back-dated parts. Autozone or what have you carries a lot of what you need.

If the automotive industry operated on the same principles as the IC industry, we would never be able to drive a car more than a few years old. As cars envolve and become more and more reliant on computers, I dare say this may change.

Another interesting comparison is the reverse engineering aspect. This is virtually impossible with ICs, but with cars, it's possible to hand-craft components which have long since been made of unobtainium. People who restore rare vehicles successfully do this all the time.

Try restoring a vintage computer with missing parts – good luck.

– Joe Sallmen


One example for obsolence:I did mistake – use of ST75C185B -“standard” RS232 buffer in non-standard connection.Buffer requires+Vdd,-Vss,+5V,GND . In my device this was connected with Vss tied to GND.

We sell this product 3 years. After this chip goes into “obsolence”. After this i found that no other compatible chip can working in my device. OK, this is my mistake. But i still cant believe how this chip disappears from ST.com . They behave as this chip was never produced.

– Stegen Kanev

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.