Legacy processor and chip replacement on FPGA
We build FPGA replacements for processors, DSPs and custom chips that are no longer made, so your existing software runs unchanged.
The problem
When a processor or custom chip goes out of production, the options are remanufactured stock, a software rewrite with recertification, or a compatible replacement. Remanufactured stock runs out, and a rewrite can cost more than the system is worth. A compatible FPGA implementation keeps the binaries, the board and the qualification you already have.
What we build
- Instruction-set-compatible CPU cores that run existing binaries
- Cycle-accurate cores where software depends on exact timing
- Drop-in modules that are pin- and bus-compatible with the original part
- Re-implementations of custom ASICs and gate arrays from netlist or specification
- Replacements for legacy DSPs and bus interface controllers
- Compatibility verification against reference models and the original hardware
Parts we replace
Markets
- Defense and avionics
- Rail signalling
- Industrial control
- Telecom infrastructure
Frequently asked questions
Will our existing software run without changes?
Yes. The core implements the original instruction set, so existing binaries run as they are. Where software depends on exact timing, the core is made cycle-accurate.
Do you replace the chip or the whole board?
Either. We deliver a core for a new FPGA design, or a module that fits the original socket.
How do you prove the replacement is compatible?
We run the core and a reference model side by side, compare every state change instruction by instruction, then test on the target system.
Can the replacement support DO-254 or IEC 61508 certification?
Yes. The verification is built to produce the evidence those programs need.
What if we only have the netlist or the datasheet?
Either is enough to start. Custom chips can be re-implemented from a netlist, and standard parts from their documentation, then verified against the original hardware.
Related
Discuss your project
Share the target, interfaces, and timeline. We’ll tell you what we’d take on first.