Back to top
Designing embedded systems that stand the test of time isn’t easy, especially when the FPGA landscape is shifting beneath your feet. From device obsolescence and vendor roadmap changes to new interface standards and AI-driven performance requirements, teams are increasingly asked to migrate FPGA platforms mid-lifecycle. Whether you’re moving from a legacy part to a next-gen SoC or across families altogether, the cost and complexity of migration can derail timelines—unless your design is built with adaptability in mind.
At Fidus, we’ve supported dozens of such migrations. This blog presents field-tested strategies and architectural practices that help embedded designers avoid rework and future-proof their FPGA-based designs.
The lifespan of a well-designed embedded system often exceeds the availability of the FPGA on which it was built. This mismatch is one of the leading causes of mid-lifecycle redesigns. In the past, designers could count on a given family of programmable logic remaining available for years. Today, pressure from next-generation applications like multi-channel high-speed interfaces, edge AI workloads, and security compliance means upgrades are not only beneficial but required.
Many teams face scenarios where, even a year or two after release, the chosen device may no longer be available at a predictable cost or lead time. Even when the silicon is still shipping, it may lack the hardware acceleration or modern toolchain support necessary to meet new system demands. Fidus has helped customers respond to these shifts by replatforming their designs, migrating logic, adapting layouts, and refactoring firmware.
The best way to prepare for migration is to architect your design so that critical logic is decoupled from vendor-specific constraints. This starts with the HDL itself. Code should avoid direct instantiation of primitives unique to one platform unless necessary. Where such instantiations are unavoidable, for instance, in transceiver logic, phase-aligned resets, or I/O buffers. They should be wrapped in generic modules with parameterized interfaces.
If your design includes soft-core processors, memory controllers, or high-speed interfaces, isolating them behind bus bridges or generic wrappers makes it much easier to retarget these subsystems. A project that requires porting from a legacy board to a modern SoC, for example, benefits greatly from having its DMA engine encapsulated behind a standard bus and a single top-level interface.
Toolchains evolve. Teams that maintain a clean boundary between functional logic and toolchain-specific scripts (like synthesis directives or constraint files) consistently experience smoother migrations. For example, in a recent project, the synthesis flow was hardwired to an outdated, GUI-driven version of a tool suite. Before migration could begin, we rewrote their build process as a fully automated pipeline, enabling reproducibility, CI integration, and modern tool compatibility.
Reusable IP is a cornerstone of productivity, but it can become a liability during migration if it’s tightly bound to a specific vendor’s toolchain. In multiple engagements, Fidus encountered situations where third-party or vendor-supplied IP cores, particularly for DMA, Ethernet MACs, or memory controllers, became migration blockers.
For example, in a data acquisition project with real-time streaming over PCIe, the team’s original IP relied on proprietary DMA with limited configurability. We refactored the data path to use a portable streaming interface with a lightweight control plane. The result was not only reusable across platforms but also easier to validate and tune for different bandwidth and latency targets.
In response, we help customers assess the tradeoffs between short-term convenience and long-term portability. In some cases, it’s worth the upfront investment to develop custom IP around standard interfaces like AXI or AMBA. These IPs are easier to verify and modify and provide insulation from toolchain or silicon changes.
Fidus has encountered a wide range of migration scenarios. In one case, a customer in the industrial sensing space had built their platform around an aging FPGA that lacked native support for high-speed serial connectivity. As bandwidth requirements grew, they were forced to consider a platform migration to support both PCIe Gen4 and advanced DSP functionality. Our team worked alongside theirs to isolate the PCIe data path logic, rewrite the clocking strategy, and repackage the signal processing cores to meet timing under the new architecture.
Another project involved a customer in the aerospace domain facing a compliance-driven requirement to switch to radiation-tolerant FPGAs. These devices had vastly different toolchains, logic densities, and even language support limitations. Our solution was to separate mission-critical logic into portable SystemVerilog modules, while platform-specific features like watchdog timers and redundancy controls were handled in wrappers that could be redefined per platform.
In yet another example, a team building high-throughput video capture systems had optimized their board for a particular DDR interface that was unavailable in newer devices. We collaborated to redesign the memory controller interface, adjusting timing and pipeline depths while preserving API compatibility with the existing application software.
These stories demonstrate that migration is rarely a drop-in process—it involves holistic updates to architecture, timing, and software integration.
Many teams aren’t just migrating—they’re supporting two or more FPGA platforms in parallel. This is common in defense, medical, and aerospace sectors, where certification cycles delay full transitions. In such cases, dual-platform support becomes essential.
Fidus has successfully implemented dual-platform builds by leveraging parameterized top-level modules, version-controlled build profiles, and conditional compilation. This allows the same source code to support both legacy and modern hardware targets with minimal divergence.
In one such program, we built a system that could target two radically different FPGAs: a small legacy device and a large SoC with an embedded CPU. Rather than fork the codebase, we introduced abstraction layers for reset handling, memory mapping, and bus protocols. The configuration header selected platform-specific modules at build time. The same testbench verified functional parity between both implementations, ensuring consistent results and accelerating signoff.
Migration is not complete until the new system is validated, both at the signal level and in full system context. Verification is often underestimated in migration planning, yet it consumes a significant portion of engineering time.
At Fidus, we emphasize automated testbench reuse and vector-based regression testing. When working with clients who have partial or undocumented verification assets, we help reconstruct coverage-based test environments that provide high confidence during logic rework. This allows teams to maintain deterministic behavior even when internal architecture changes.
We also implement hardware-in-the-loop (HIL) setups for projects involving ADC/DAC interfaces, real-time Ethernet, or PCIe. This is especially useful when the final application environment is unavailable during development. In one video-processing program, we simulated multiple frame sources and validated FPGA logic against known CRCs and latency budgets before any physical camera was connected.
In regulated industries, such traceability isn’t optional. Our approach includes simulation coverage metrics, waveform archives, and platform-aware CI pipelines that track results across builds and tool versions.
To illustrate how migration unfolds, here’s how a recent customer engagement progressed—from initial analysis to production validation.
The customer approached us with a high-performance processing card originally built on a now-unavailable FPGA. Their system involved DDR memory, multi-lane PCIe, and a set of low-latency I/O channels. Our engagement began with a code audit that surfaced several vendor-specific constructs, an outdated memory controller, and constraints that wouldn’t map to the target device.
We began by abstracting platform-dependent modules—building wrappers for memory, transceivers, and resets. Next, we rewrote timing constraints based on the new clock tree and I/O voltage standards. The existing simulation testbenches were adapted to align with revised port mappings, and we added regression tests to confirm consistent data integrity.
In parallel, the board layout was revised to support a new pinout and memory topology. The software stack, initially tied to fixed addresses and hardcoded peripherals, was updated to work with a BSP supporting both devices.
After validation in simulation and hardware loop, the migrated platform passed performance thresholds and was released to manufacturing with full backward compatibility. The new design also opened the door to future enhancements that were previously blocked by silicon limitations.
At its core, future-proofing an FPGA-based system isn’t about predicting exactly which platform you’ll need next—it’s about giving yourself the freedom to pivot when the time comes.
That freedom starts with modular RTL. Systems that isolate platform-specific logic—such as clock management, resets, and transceivers—are dramatically easier to retarget. It also comes from smart abstraction: IP cores built with standard interfaces are more reusable across toolchains, and embedded software structured around clean HALs and BSPs can often move with minimal rewriting.
Constraint files that are organized by clock domain or function, rather than tied to net names or specific pins, tend to adapt better across platforms. Portable testbenches and simulation environments built early in the project also pay dividends down the line, especially when logic needs to be verified post-migration. And having CI pipelines in place to validate across multiple targets helps teams catch issues as early as possible, before they get expensive.
Put simply, designs that are built with change in mind are more stable, more sustainable, and ultimately more successful. Migration doesn’t have to be painful. With the right architecture, tools, and mindset, it becomes just another engineering milestone—not a crisis.
Platform stability is an illusion. Whether driven by obsolescence, performance goals, or integration opportunities, FPGA migration is a reality every embedded system team must face. But with smart abstraction, modular design, portable tool practices, and robust testing infrastructure, it’s possible to turn migration into an opportunity for improvement, not a source of risk.
At Fidus, we’ve helped customers in aerospace, medical, defense, and communications plan and execute successful migrations between FPGA platforms. From schematic and layout updates to RTL refactoring and embedded software support, our team brings deep experience across generations of silicon and a philosophy rooted in adaptability.
If your system needs to stand the test of time or evolve into something better, we’re ready to help you build it right from the start.
📩 Get in touch with our team
📚 Or explore more insights in our Blog Hub
This deep dive explores how to tackle debugging challenges at the intersection of FPGA hardware and software. From clock domain crossings to distributed system issues, learn strategies, tools, and cultural best practices that reduce debug time and build more resilient embedded systems.
FPGA Co-Processors are redefining what’s possible at the edge—enabling real-time analytics with precision, efficiency, and scalability. This guide explores proven design patterns, integration models, and optimization strategies to help engineering teams build smarter, faster embedded systems.
This in-depth guide explores the evolving security challenges in FPGA-based embedded systems. Learn how to implement secure boot, protect against runtime threats, and build resilient architectures that meet the demands of aerospace, automotive, and medical applications. See how FPGAs like AMD Versal adaptive SoCs support robust security from design through deployment.
Trust us to deliver on time. That’s why 95% of our customers come back.
