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
Apr 26, 2018
Everyone in EDA is familiar with the phenomenon where the internal testing of a tool all goes perfectly, the initial customer checkout flights of the tool go well. Then when that same customer starts to use the tool for real, on a real design, all sorts of issues emerge. This...
Apr 24, 2018
Counterfeit parts and the issues posed by them are a growing concern throughout the electronic industry.  However, counterfeit products are nothing new when it comes to consumer goods, and for many years, in any large city, traveling merchants have sold everything from purse...