For manufacturers and developers
Porting an FPGA design is not copying it
Why moving a proven reference design to a new FPGA remains an engineering project, even with the vendor's migration tool.
Moving a proven reference design to a new FPGA: anyone who has tried knows it is rarely a copy job. A question about this occupied me in March 2026, shortly after the preparations for embedded world.
What does a real-world example look like?
Years ago, a low-cost camera extender was developed at Promwad, where I work. It consists of two small Lattice devices and a twisted pair cable that carries the image data from a sensor to its ISP. The extender worked well back then and still works today.
Today, customers want the same function on a modern device. The requirements have changed:
- twice as many inputs and outputs,
- only a fraction of the power consumption,
- security that is ready for the Cyber Resilience Act (CRA), “CRA-ready”,
- shorter boot times.
A design that was made for the old task now meets new conditions. It does not simply keep running because the function stays the same. That the requirements change while the purpose stays the same is the heart of the question whether a design can simply be moved over.
Does a vendor migration tool help?
It helps, but it does not replace the work. Lattice has released a migration tool that is meant to make the move easier. The vendor itself would say, though, that a successful port is an engineering project and not a shortcut. The tool can support the move. The decisions that underpin a design stay with the development team, because porting means understanding the old and consciously shaping the new.
What does a port involve?
Three things:
- Understand the constraints of the old design. Before anything is changed, it must be clear which requirements shaped the proven design.
- Rethink interfaces and timing. A modern device offers different options from the old one, and they can only be used if these two points are not simply carried over.
- Use what modern FPGAs offer without blowing deadlines and budgets. This is the real trade-off: the new design should use what the device can do, and schedule and cost have to stay within bounds.
This is where engineering work comes in. It sits between the old, working design and the new requirements.
What does the CRA have to do with it?
After the CRA conversations at embedded world 2026, it was clear to me that this kind of cooperation between chip vendor and development team is becoming more important. That customers name security as part of the requirement from the start shows how closely the two are now linked: the new design has to boot faster and use less power, and it is also meant to fit the requirements of the CRA.
Why is this example useful?
It shows that the same function can be two different tasks. The first was to move image data from the sensor to the ISP cheaply and reliably. The second is to do exactly that on a modern device, with more connections, lower power consumption, a shorter boot time and security in line with the requirements of the CRA. The old design addresses only the first task.
Who is this relevant for?
For everyone who owns an old but proven design and is thinking about what comes next. That design has shown over the years that it works. The question is how to carry this value over to a modern device with different properties. A port is then not a copying process but a development task with a clear starting point: a design that already proves what it can do.