feature article
Subscribe Now

Engineering Agility

FPGAs Necessary, but not Sufficient

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.

3 thoughts on “Engineering Agility”

  1. Glad to hear such important design goals on the EE side the product specification role

    Thinking that products will be obsolete in a year, or three, is really giving your customers a choice for a competitive purchasing option, to jump ship, and you loose the long term upgrade revenue as a company (and your long term paycheck).

    Planning products with upgradable 10 year lives, with a service contract, means you just sold 10 years of revenue, and 10 years of paychecks … even if the customer upgrades to a newer device, and the resells first to another buyer that may continue the upgrade path … the product is still a sales generating cash cow until salvaged.

    But if you are so short sighted, as to make it disposable, then you have lost that revenue stream, and possibly the customer. Price the product with a fair margin for the initial early adopter, and then make sure you provide on going value with a service plan for either the initial buyer, or it’s successive owners. Every device with your brand that remains in some customers hands, is revenue for your company, and is not lost to a competitor’s sale.

  2. Dear Kevin, your great article reminds me of a funny experience that I had:

    In 2010, I had to develop an FPGA-based solution for an industrial application for my employer.
    Prototypes in another part of the building.
    Other test machines at other company branches.
    Customers abroad.
    Thus, it was clear to me and my close colleagues that we need the possibility to modify the FPGA configuration data remotely.
    A few weeks later I was able to comfortably and safely upgrade my FPGA stuff within a few seconds – remotely. A feature that I use daily.
    And then… One day one of the managers asked me what I have done in last time. And, as I shortly described our great possibility to modify the FPGA functionality of any machine attached to the network, he said: “We don’t need this!”. A solid, employable subset of management skills 🙂

  3. Kevin – couldn’t agree more! And with the price of ARM-based SoCs falling like a rock, the day of shipping high-volume products with features that have yet to be conceived of on delivery day is fast approaching… It’s one of the big reasons we went with an SoC when developing our new dev board.

    Very excited to see what promises this holds for the fields of low-cost robotics, medical devices, and other complex, safety-critical systems.

    Ryan
    krtkl.com

Leave a Reply

featured blogs
May 24, 2024
Could these creepy crawly robo-critters be the first step on a slippery road to a robot uprising coupled with an insect uprising?...
May 23, 2024
We're investing in semiconductor workforce development programs in Latin America, including government and academic partnerships to foster engineering talent.The post Building the Semiconductor Workforce in Latin America appeared first on Chip Design....

featured video

Introducing Altera® Agilex 5 FPGAs and SoCs

Sponsored by Intel

Learn about the Altera Agilex 5 FPGA Family for tomorrow’s edge intelligent applications.

To learn more about Agilex 5 visit: Agilex™ 5 FPGA and SoC FPGA Product Overview

featured paper

Achieve Greater Design Flexibility and Reduce Costs with Chiplets

Sponsored by Keysight

Chiplets are a new way to build a system-on-chips (SoCs) to improve yields and reduce costs. It partitions the chip into discrete elements and connects them with a standardized interface, enabling designers to meet performance, efficiency, power, size, and cost challenges in the 5 / 6G, artificial intelligence (AI), and virtual reality (VR) era. This white paper will discuss the shift to chiplet adoption and Keysight EDA's implementation of the communication standard (UCIe) into the Keysight Advanced Design System (ADS).

Dive into the technical details – download now.

featured chalk talk

Autonomous Robotics Connectivity Solutions
Sponsored by Mouser Electronics and Samtec
Connectivity solutions for autonomous robotic applications need to include a variety of orientations, stack heights, and contact systems. In this episode of Chalk Talk, Amelia Dalton and Matthew Burns from Samtec explore trends in autonomous robotic connectivity solutions and the benefits that Samtec interconnect solutions bring to these applications.
Jan 22, 2024
17,601 views