FPGA designs that met the requirements and technologies of ten years ago and more are now increasingly becoming legacy devices. While they still work, they’re now constrained by dated architectures, older clocking primitives, and limited DSP blocks. Interfaces like PCIe, DDR4 and DDR5, and multi gigabit transceivers are also often not fully supported.
At the same time, toolchains have moved on and integration complexity has increased, with Arm cores, hardened memory controllers, and high speed I/O. Designs that once required only small updates now need more substantial changes just to stay compatible with new processors and board-level requirements.
At Concurrent, for example, we design and manufacture Intel processor-based embedded computing cards and chassis systems. Our cards contain an Intel Xeon or Core CPU, depending on the target application, along with DRAM, storage, Ethernet and PCIe interfaces, and usually I/O such as USB or display interfaces.
The core logic that controls the power to the CPU, brings it out of reset, and enables it to communicate with and control other board functions is contained within an FPGA. For many years this has been implemented with a Microchip ProASIC3 FPGA, and the core logic and functionality have been migrated from product to product and adapted as necessary for each new platform.
In addition, there is usually a secondary processing element we use for the Intelligent Platform Management Interface (IPMI). This is typically implemented using a small microcontroller such as an STM32.
This has worked well as a core architecture and supported the development of many platforms over the years. However, it has limitations and the CPU platform is evolving beyond what we can easily and cleanly support within the existing design.
Legacy platform realities: ProASIC3 at its limits
The ProASIC3 has been around for almost 20 years. It’s a solid performer with flexible I/O, a reasonably sized FPGA fabric with dedicated FIFO logic for the RAM blocks, Flash-based instant-on operation, and low power. These are all things which made it a good choice when it was first selected.
However, the minimum I/O bank voltage is 1.5V which limits its ability to support the I/O standards at lower voltages that are becoming more common on devices we need it to interface with. The number of available I/O pins is also constrained, so we’re pin-bound in the parts we currently use. There are solutions that would have allowed us to continue with ProASIC3 for a little longer, like level translation, I/O expanders, etc, and these still have their place today. That said, we needed to consider the bigger picture and our long-term vision and strategy, not just Can we make it work today?
In order to develop our products and bring new functionality to the market, our FPGA platform needs to be able to support the needs of tomorrow as well as those of today. ProASIC3 will stop being able to support those needs as CPU technology and platform requirements move on, so we sought to identify a solution which could grow with the product roadmap.
New Intel architecture as the forcing function
In the Xeon CPU generation we were targeting, Intel has moved to a CPU-centric architecture where the traditional Platform Controller Hub (PCH) no longer exists in its own right. Instead, critical parts are embedded within the CPU itself, with boot sequencing and hardware initialization handled within the microcode of the System-on-Chip (SoC). This has knock-on effects for the power sequencing logic, I/O voltage compatibility, and required supporting functions.
These changes were going to have a deeper impact on the FPGA platform and transform the process from just copying what we’ve done before and tweaking a few bits to make it fit, to rewriting large chunks of the core functionality. This increased risk significantly and amplified any technical debt because more needed to be reopened and changed.
Ultimately, as the Design Authority for the platform, I needed to address the risks to the technical feasibility and schedule, while also factoring in future outcomes. The decision was made that the risk-reward ratio improved significantly if we migrated to a new platform, and this was the lowest risk option.
Selecting a modern FPGA platform
We needed to migrate to a new platform to enable easier interfacing with new CPU generations and enable our FPGA designs to scale for new functionality. There was a large selection of possible choices from a number of vendors, so the question became how to narrow this down to a vendor and eventually a part.
In order to support an increasing role for FPGAs beyond board support logic, the final choice had to be more than the same again with better I/O. We needed a platform designed to scale to much bigger applications, with a large ecosystem of solutions and available IP.
There were four main FPGA vendors to choose from: AMD (Xilinx), Intel (Altera), Microchip Technologies Inc. (Actel), and Lattice Semiconductor. While all four vendors have scalable solutions, AMD and Intel offered the broadest ecosystem and tool maturity for our requirements, which helped narrow the field.
The final choice was to identify parts which would work within the current target application and to narrow down the options. The combination of available board area and I/O count helped with selecting the suitable candidates. Combining this with the extent of the support ecosystem, the AMD Artix-7 family was chosen as the solution.
Platform strategy: Artix-7 as a stepping stone
The AMD Artix-7 offers many new architectural improvements but was never intended to be the final destination. It doesn’t solve one key issue, namely that the new CPU architecture moves away from the 1.8V I/O interface standard for key signals to much lower voltages of 1.0V and 1.1V for many signals.
To solve this, we needed to include I/O level translators to match the FPGA I/O voltages to the CPU I/O voltages. This comes at the cost of additional interfacing complexity, board real estate, and Bill of Materials (BOM) cost.
In addition, the board space constraints limited the package size and I/O count. This meant that in order to interface to a number of external devices we needed to include I/O expanders connected to the FPGA via I2C. Much like the I/O level translators, these have penalties, including the complexity of interfacing to the I/O expanders.
The solution to this would be to migrate from the Artix-7 to the Spartan UltraScale+ for our next platforms. This supports lower I/O bank voltages so we could directly interface to the CPU. It also has much more I/O in a smaller footprint so we wouldn’t need the I/O expanders.
We’d done the hard part of migrating to the AMD ecosystem already. The next stepping stone was to optimize for a simpler and more flexible solution to take us into the future. We didn’t just go straight to the Spartan UltraScale+, however. It’s a very new device from AMD and is only just starting to get a proper public release. Our project was slightly too far ahead of the launch to take advantage of it, so we used the Artix-7 as the ideal first step.
Architectural and debug capabilities unlocked
The Artix-7 family enabled us to immediately scale up what the FPGA does within our platform. The Board Support FPGA can be a complete platform in its own right, there to add system functionality, no longer just board support logic. We had the ability to include soft core processing (Microblaze V), interface to DDR3 SDRAM, create complex systems visually within the Block Design functionality of Vivado, and drop in standard IP from their extensive library which all connect together using the ubiquitous AXI interface. This enabled us to make significant architectural changes to improve the core platform.
As mentioned, we usually have a separate microcontroller for our IPMI functionality. Because of the greater capabilities of the new FPGA platform, we incorporated this within our FPGA design using a Microblaze V, enabling tighter coupling between the IPMI and CPU subsystems. We also added a second Microblaze V to provide additional board management functionality, giving much more insight into and control over the operation of the FPGA via one of the USB serial interfaces the new platform provides.
Development and debugging capability are where the new solution really shines though. We built the JTAG programmer and debug serial interfaces directly into the board using an FTDI USB serial device and these integrate tightly with AMD Vivado/Vitis so we now have one solution for programming the FPGA and the microcontrollers, all tied together with a neat little bow.
We were also able to leverage the Integrated Logic Analyzer (ILA) and Virtual I/O (VIO) functionality of Vivado to gain greater insights into where issues are occurring so they can be identified and fixed much more quickly.
A good example of the debug capability in action was getting our new Enhanced Serial Peripheral Interface (eSPI) IP block up and running. We could capture and decode the eSPI transactions on our oscilloscope but we couldn’t see from there the reason it was failing. After inserting an ILA on the eSPI block we were able to track down where it was getting stuck and the missing response. This enabled us to quickly find a solution and move on to the next step.
Similarly, when debugging the power sequencing of the rails for the new CPU we were able to use the ILA to provide insights into where things were stopping in the power-up process, and we were able to use the VIO to override the sequencer and enable each of the rails to test they were working.
The foundations have now been laid for our future FPGA developments. We have a scalable architecture with a large existing ecosystem we can leverage. We’ve got debug tools baked right in to eliminate the need for external programming tools. We have tighter coupling between various parts of our design, and hardware and software teams are now working within a familiar shared environment for easier collaboration.
Possibly the most important benefit for the long term is that it will allow us to scale up for future designs which are more FPGA-focused rather than CPU-focused, and this is where things will start to get interesting. For now, reusing the FPGA designs between projects is simpler and more maintainable, reducing design effort. The Board Support FPGA has become a well-defined platform in its own right, there to complement the CPU and provide additional functionality, not just to help the CPU to boot.
What surprised us:
Building a new FPGA platform was easier than expected
After deciding to take the leap and go ahead with a major step change in our FPGA architecture and capability, stakeholders quite rightly challenged the risks this could introduce both to the development lifecycle and in the product design where the change was being introduced. By using objective success criteria and early proof-of-concept (PoC) work, we found the risks were manageable and the benefits compelling.
We approached the migration as a structured engineering change. We aligned on the ‘why’, agreed measurable acceptance criteria, ran early PoC activity, and then scaled the approach once confidence was established.
In the end though, implementing the new FPGA platform was surprisingly easy. There is a plethora of development boards available for most FPGAs and the Artix-7 is no exception. These come as self-contained development platforms with example FPGA and software designs to get FPGA and software engineers up and running quickly, as well as schematics and layout details for the board designers to use. We chose an Arty A7 and used the supplied schematics as the basis for our own, ensuring things like FPGA configuration, clocking, and DDR3 interfaces would be correct from the outset.
We had anticipated there would be challenges faced when making the architectural shift. In the end, this change was much easier than expected and the FPGA platform worked straight away and provided immediate benefits in debug visibility and development flow. That, in turn, reduced integration uncertainty elsewhere in the program and helped build confidence in the longer-term platform strategy.
Tooling and workflow: Where ambition got ahead of us
We also used the migration as a catalyst to improve build automation and reproducibility. Our first iteration aimed for a full CI/CD pipeline with ambitious goals. It delivered value, but we learned that FPGA workflows have different constraints (tool runtimes, licensing, artifact sizes and iteration cadence) and need a tailored approach.
We built a sophisticated CI/CD system, but it was optimized for software-style workflows. When hardware engineers started to use it, they found the setup and user experience added friction to day-to-day iteration. When errors occurred, we also learned we needed clearer ownership and support pathways to avoid over-dependence on a single team.
In practice, adoption lagged because the workflow added steps for rapid prototyping. We therefore simplified the path from change to bitstream for day-to-day engineering, and we’re iterating on automation with the hardware team so it delivers value without slowing iteration.
The key take-away here is not that CI/CD isn’t suitable for FPGA development. It is, but it can be complicated and you need to bring your hardware team along for the journey, building on the opportunity to do things correctly for the long term.
Results and outcomes
We now have a new, extensible FPGA platform fit for the future. It offers more capability and scalability, improved development tools, and better debug tools with programming and debug interfaces baked into the architecture. This has enabled us to more rapidly analyze and debug issues as we face them, speeding up development times considerably.
With the previous FPGA, the tools were limited so when something didn’t work we had to figure out how we could get the data we needed to solve the problem, relying heavily on simulation and trying to reproduce the failure as a test case in the testbench. Now we add the signals of interest to an ILA and in a matter of minutes we can start debugging live on the real hardware where the problem actually exists.
Future projects now have a powerful platform to build upon as we look further ahead to where we want to be, not just the next project.
Conclusion: Advice to teams considering a similar move
If you’re considering whether you should embark on a similar path, start by being clear about the driver. What is changing in your platform or requirements that makes maintaining the status quo more complex or riskier?
To give due diligence to the decision, evaluate whether you’re carrying any technical debt within your legacy architecture that is quietly sapping productivity, slowing down development, making debug harder. These factors can quietly add cost and time over multiple programmes.
Look at whether the benefits of future-proofing your architecture, reducing or eliminating technical debt, and introducing tighter integration of components within the subsystem, better development environments, and better debug capability are worth the extra development effort now. That’s not to say this isn’t without risk, but you can mitigate many of the risks associated with change, and weigh those that remain against the benefits you’ll gain.
Ultimately, the benefits for us have been significant, and made what was a very challenging project a lot more manageable because the FPGA subsystem was much more flexible and manageable.
