FPGA Obsolescence and Mid-Life Upgrade: When the FPGA Outlives Everything Around It

"An FPGA gets used because manufacturers can keep some FPGA series in production for a very long time, 20 to 30 years, and that extends the life of the design. I've come across this at customers in those industries, where what the FPGA was doing could have been done by some cheap processor, but the FPGA was used purely so the device could be produced for longer without a mid-life upgrade. And then it ended up that everything around it went obsolete except that FPGA, and the upgrade had to be done anyway."

‍

Adam Szychulec, Head of Hardware / Embedded, InTechHouse

That is FPGA obsolescence in one sentence: the component chosen to avoid a mid-life upgrade is often the one that survives long enough to force it. A mid-life upgrade (MLU) means re-hosting proven logic on a current device, preserving function and reliability, while the surrounding hardware that has actually gone obsolete gets replaced around it.

Key Takeaways

• In long-lifecycle equipment, the FPGA is frequently the last component still in production, often chosen for availability rather than capability, which is exactly why the rest of the board obsoletes around it.
• A mid-life upgrade has four phases: reverse engineering the existing design, selecting a target platform, porting the logic, and verifying it across every hardware variant.
• InTechHouse migrated a legacy AMD/Xilinx Spartan-3 safety design for a UK rail supplier onto a supported platform, meeting the customer's safety-integrity, testability and code-standard requirements throughout.
• "Future proofing" means four specific decisions at design time, not a promise: a family with a published longevity horizon, spare fabric headroom, portable RTL, and documentation written for the next migration.
• InTechHouse does the engineering when an upgrade has to happen. We do not monitor component lifecycles, track end-of-life notices, or source parts as a service.

FPGA Obsolescence: The Part Chosen to Prevent an Upgrade Is the One That Forces It

In long life systems, the FPGA is frequently the last component still in production. Manufacturers keep some FPGA series in production for 20 to 30 years, which is exactly why a customer designing a product with a long service life selects one in the first place: it keeps the device buildable well past the point where most other parts on the board would need replacing.

That is a reasonable decision, and it is also the one that creates the problem this article is about. As the quote above states plainly, the FPGA in these cases is often doing work a cheap processor could have handled. It was chosen for availability, not for capability. Then everything else around it, the supporting components, the connectors, the rest of the bill of materials, goes obsolete anyway, on its own schedule, and the mid-life upgrade has to happen regardless of what the FPGA itself is still capable of supplying.

The same property that makes an FPGA a good choice for extending product life is also what makes a redesign worth planning for rather than reacting to when it comes: an FPGA can integrate multiple functions on one device, and it can support evolving system requirements over decades of deployment far better than a fixed-function part can. A redesign carried out ahead of time, on those terms, is what limits an interruption to product supply when the surrounding components finally do reach end of life.

What Starts the Clock: End of Life, Last-Time-Buy and a Product With 20 Years Left

The sequence matters, because a reader who is early in it can still act, and a reader who is already inside it needs to know exactly where they stand.

It starts when the device manufacturer announces end of life (EOL), or a last-time-buy (LTB) window, for a platform sitting inside a product with a fifteen- to twenty-five-year service life. Obsolescence is the underlying condition; end-of-life is the manufacturer's announcement that a part is being withdrawn; last-time-buy is the final window in which the part can still be purchased; a product change notification (PCN) is the formal notice itself. These are the terms a buyer's own supply-chain function already uses, and getting them right signals having actually been inside one of these programmes before.

The part most obsolescence content leaves out: a last-time-buy sets a real date, and everything downstream of it happens under that time pressure, including the documentation requirements a regulated buyer needs met. That work does not compress just because the calendar is tight, and global supply chain disruptions can pull that date forward without much warning, on top of the manufacturer's own planned timeline.

Legacy FPGA designs often surface a second problem at the same moment: they frequently lack support for modern interfaces such as PCIe, which the rest of a product's electronics may have moved on to years before the FPGA itself became a supply problem. And the vendor toolchain used to build the original design can itself be discontinued well before the silicon is, which is worth checking alongside the device's own end-of-life status rather than assuming the tools will still be available when the part finally is not.

Why Long Life Systems End Up Here: Product Longevity and FPGA Families

Understanding why this keeps happening also explains why it will happen again to whatever replaces the current design.

Some FPGA families stay in production for 20 to 30 years specifically because they are designed into military and space programmes, and that sustained demand keeps the part alive for every other customer using it too. AMD/Xilinx Spartan-3, for example, was introduced in the early 2000s and is only being withdrawn now, a production life no general-purpose processor family matches or even attempts to declare in advance. Some vendors publish formal longevity commitments for specific product lines, typically the ones aimed at industrial, defence and aerospace markets, and those commitments are the thing worth checking at device-selection time, not discovered for the first time when an end-of-life notice finally arrives. Altera, for one, announced in April 2026 that it was extending lifecycle support for its Agilex, MAX 10 and Cyclone V families through 2045, specifically citing long-life industrial, aerospace, medical and transportation customers, though notably excluding Agilex 7 parts built with HBM2E memory from that extension (Altera, 2026). That is exactly the kind of published commitment worth checking against your own family and part number rather than assuming.

Rail, aerospace, energy and medical equipment all run long enough, as product categories, to meet this pattern on a long enough timeline. FPGA obsolescence itself is driven by the same forces across the industry: process nodes advancing rapidly under continued semiconductor development, vendors consolidating and discontinuing overlapping families after a merger or acquisition, and global supply chain disruptions that can pull a last-time-buy window forward with little warning. None of that is specific to any one vendor; it is simply how the semiconductor market behaves underneath a design with a multi-decade service life.

What a Mid-Life Upgrade Actually Involves

Four phases, and each one answers a different anxiety a buyer already has before they ever get on a call: can you understand what we have, can you choose what replaces it, can you actually move it, and can you prove it still does the same thing afterward.

1. Reverse Engineering the Existing Design

The work starts here rather than with a specification, because the original documentation may be incomplete or missing entirely. A mid-life upgrade cannot be quoted the way a greenfield project can, because the discovery phase stays open-ended until the existing design is actually understood. That is also the honest reason not to hand this kind of work to the cheapest bidder: the real risk sits in exactly the part nobody can scope in advance. Where source code does still exist, it has to be read against the physical hardware to isolate what the design actually does, rather than what any surviving documentation claims it does.

2. Selecting the Target Platform

A current device and family, chosen against today's requirements and today's availability horizon, not against whichever part happens to look closest to the one being replaced. This decision repeats the exact choice that created the original problem, which is why the longevity criterion belongs inside it just as much as raw capability does.

Check our Choosing an FPGA vendor and family guide.

3. Porting the Logic

Proven logic is re-hosted on the current device; function and reliability are preserved; the surrounding hardware is what actually gets replaced. Porting between FPGA families is never a recompile, because fabric architectures, primitives, memory and clocking resources differ between families and vendors, so timing constraints have to be re-established on the new target rather than assumed to carry over.

4. Verification, Across Every Hardware Variant

Verification confirms the migrated design still does exactly what it did before. Where a product exists in more than one hardware configuration, each configuration has to be verified separately rather than assumed to behave identically. This is the phase that produces the evidence a customer's own assessor will actually read.

The Rail Migration: A Legacy Spartan-3 Safety Design Brought Onto a Supported Platform

InTechHouse migrated a legacy AMD/Xilinx Spartan-3 safety design for a UK rail supplier onto a supported platform. The scope, delivered in full: reverse engineering of the existing design, selection of the target platform, porting the logic, and verification across two hardware variants, with functionality and the safety documentation preserved throughout.

What made this a buying decision rather than a maintenance task is worth stating plainly, because most obsolescence content assumes a customer still has the team that originally built the product. This customer did not: they had no internal competence left for the platform, and the technology itself had aged, both at the same time. Recognising that combination is often the first sign a reader is looking at their own situation rather than someone else's.

What the customer was actually looking for, in their own account of the decision, was experience migrating old FPGA designs, familiarity with regulated requirements, safety documentation, testability, repeatable verification, code formatting, and a team comfortable working under harsh operating conditions. In regulated sectors like this one, an upgrade has to satisfy today's requirements, requirements the original design may never have documented at all, on top of simply working. InTechHouse delivered FPGA logic that met the customer's safety-integrity, code-standard and testability requirements, and the safety documentation was preserved through the migration.

InTechHouse case study: mid-life upgrade of a legacy rail safety design

A UK rail supplier had no remaining internal competence for a legacy AMD/Xilinx Spartan-3 safety design, and the platform itself had aged past practical support. InTechHouse reverse engineered the existing design, selected a supported target platform, ported the logic, and verified the result across two hardware variants, meeting the customer's safety-integrity, testability and code-standard requirements throughout and preserving the safety documentation through the migration.

Future Proofing the Replacement, and What That Phrase Is Actually Worth

"Future proofing" usually means nothing specific. It is worth taking the phrase apart rather than repeating it, because underneath it are four concrete, checkable decisions made at design time, not a promise made at delivery.

Pick a family with a published longevity horizon, and actually check that horizon rather than assuming it based on reputation. Leave headroom in the fabric deliberately, so the next required function does not force a device change, and with it a board change. Keep the design portable where practical: vendor-neutral RTL where it makes sense, contained and documented use of vendor-specific primitives, and clearly recorded design constraints, so the next migration is a port rather than another archaeology project. And document the design now, at the level of detail an assurance regime will actually want in fifteen years, because the cost of skipping that step is exactly the open-ended discovery phase described above.

For a truly high-volume product, it is also worth raising lifecycle commitments directly with the supplier at selection time, as part of the commercial negotiation rather than as an afterthought once a notice arrives. A platform chosen this way, with headroom and portability designed in from the start, tends to lower long-term maintenance costs simply because it needs less repeated re-engineering over the product's life, not because any single component is inherently cheaper to own. The same obsolescence will happen again to whatever replaces this design. The only real question is how expensive that next round turns out to be.

What Obsolescence Management Is, and What InTechHouse Does Not Do

Obsolescence management, as the market practice, means tracking component lifecycle status, monitoring product change notifications and end-of-life notices from device vendors, planning last-time-buy purchases, and holding stock against future need. It is usually done by a supply-chain function inside a company, or by a specialist firm built specifically for that purpose.

InTechHouse does the engineering work when the upgrade actually has to happen. We do not sell obsolescence monitoring, component lifecycle management, or last-time-buy sourcing as a service, and we are not a parts broker. Stating that boundary plainly costs a handful of enquiries that were never going to be a fit anyway, and it is worth more than pretending otherwise.

Not sure whether your product needs a mid-life upgrade yet, or just a longer runway before one? Request an FPGA architecture assessment.

‍