A good engineer is constantly evolving. We don’t graduate from engineering school perfectly loaded with all the skills and expertise we need. Instead, we graduate with a solid, employable subset of engineering skills. Then, for the rest of our career, we are constantly learning and improving. Each year, we hone new abilities based on the lessons we’ve learned from previous years’ experience. We iteratively improve.

Historically, we have taken the opposite approach with our products. We have tried to nail every possible requirement, then develop a perfect specification, then create an optimal implementation to that spec, and then to test and verify our creation to be sure it’s exactly what we intended. Finally, we let go. As an engineering project, it falls off a cliff. We ship the thing to manufacturing and to our customers, and we are done.

In the software world, this “waterfall” development flow has gradually been replaced by “agile” methods. Agile methods prescribe an iterative development process. Feedback from the results of each iteration are applied to the next, and the product evolves to something that is generally far superior to what was initially envisioned. For products that are entirely software, this agility has spread to the product release and delivery itself. The product continues to evolve, even after it is in the final customer’s hands. Mobile apps are perfect examples of this model. You are seldom buying a “final” version of an app. You are buying a present and a future – with faith that the app will continue to improve over time with frequent updates. 

Products with a significant hardware component don’t traditionally have this option. Once a circuit board has been fabricated, parts have been picked and placed, and the whole thing has been dropped into an enclosure and shipped to the customer, we don’t have much wiggle room to improve the thing. Concrete has been poured, and any customer that wants something better will have to go buy the “new and improved” product that we release next.

However, as more of the functionality of products has been encapsulated in software, the nature of products has shifted. We buy a mobile phone with the expectation that OS and firmware releases, as well as the aforementioned app upgrades, will improve the product as we use it. We are constrained to the waterfall model only for hardware components that can’t be upgraded in the field.

FPGAs facilitate agile development and agile products even in hardware, however. If a significant component of our hardware functionality is in programmable logic, we have at least the option to make it field upgradeable. The potential of this capability in customer hands is enormous, and the implications for making more competitive products are substantial. With FPGAs, the number of aspects of a product that cannot be agile drops even farther.

Of course, FPGAs themselves have always continued to evolve. Thanks to the benevolence of Moore’s Law, it is often more beneficial to develop a new version of a system with a newer-generation FPGA – even if the old one could theoretically have been field upgraded instead. The benefits of a newer generation part outweigh the advantages of product agility. But, with Moore’s Law crawling to an end, and incremental generations of chips delivering smaller marginal improvements, we are approaching a time when FPGA-based systems may have a much longer hardware shelf life and field upgrades will be more attractive. 

Ironically, even though FPGAs offer the capability for field upgrades, most FPGA-based systems are not set up to take advantage of that capability. Often, FPGA-based systems are developed with the FPGA functioning simply as an ASIC replacement in a product that couldn’t afford ASIC development costs. They are not set up with a practical mechanism for field upgrades – even though those are among the most attractive benefits of FPGAs.

If you want your product to be truly agile, you can’t just drop in an FPGA. You have to have a comprehensive plan for making your product upgradeable. At the highest level, you have to design in a mechanism where new configuration bitstreams and software can be easily distributed, downloaded, uploaded, and applied. You have to design a failsafe to keep the system from “bricking” in the event of a failed field upgrade. In short, you need to design and test the entire customer field upgrade experience, from top to bottom.

Then, you need to consider what things in your design might require future upgrades. You should choose your IP, your interface design, and your overall structure in a way that leaves the door open for swapping out sections that you feel are most likely to evolve in the future. If new industry standards are in the pipe, consider designing in a way that can adapt in the direction you believe the future standard is most likely to go,

Finally, consider over-buying your FPGA. If you fill your device to capacity and then you have upgrades that require more real estate, you’ll be bummed. Buying a one-size larger FPGA is good insurance if you really plan to build a long-lasting product with field upgrade capability.

Again, think of the entire customer experience when you’re designing an agile product, and even when you’re considering whether or not it makes sense for your product to be agile. It goes far beyond simply having as much capability as possible be “soft” or using programmable logic for critical system functions that may change.

If you do go agile, however, the benefits can be substantial. Selling more of your existing product instead of having to go through the entire process of building a new one is a major competitive advantage. Selling a product that can respond to competitive features – even after it has been sold to customers – is a substantial weapon as well.

The world is just beginning to come to grips with the implications of agile products. Today, the concept of agility on the customer side is still niche-y and novel. However, there will be a time when agility is a normal, expected attribute of most products. When that time comes, those who already have the experience and mindset to engineer agile systems that will delight their customers will be the winners.