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 26, 2022
Introducing Synopsys Learning Center, an online, on-demand library of self-paced training modules, webinars, and labs designed for both new & experienced users. The post New Synopsys Learning Center Makes Training Easier and More Accessible appeared first on From Silico...
May 26, 2022
CadenceLIVE Silicon Valley is back as an in-person event for 2022, in the Santa Clara Convention Center as usual. The event will take place on Wednesday, June 8 and Thursday, June 9. Vaccination You... ...
May 25, 2022
There are so many cool STEM (science, technology, engineering, and math) toys available these days, and I want them all!...
May 24, 2022
By Neel Natekar Radio frequency (RF) circuitry is an essential component of many of the critical applications we now rely… ...

featured video

Increasing Semiconductor Predictability in an Unpredictable World

Sponsored by Synopsys

SLM presents significant value-driven opportunities for assessing the reliability and resilience of silicon devices, from data gathered during design, manufacture, test, and in-field. Silicon data driven analytics provide new actionable insights to address the challenges posed to large scale silicon designs.

Learn More

featured paper

5 common Hall-effect sensor myths

Sponsored by Texas Instruments

Hall-effect sensors can be used in a variety of automotive and industrial systems. Higher system performance requirements created the need for improved accuracy and more integration – extending the use of Hall-effect sensors. Read this article to learn about common Hall-effect sensor misconceptions and see how these sensors can be used in real-world applications.

Click to read more

featured chalk talk

224 Gbps Data Rates: Separating Fact from Fiction

Sponsored by Samtec

Data rates are getting faster with each passing year. In this episode of Chalk Talk, Amelia Dalton chats with Matthew Burns from Samtec to separate fact from fiction when it comes to 224 Gbps data rates. They take a closer look at the design challenges, the tradeoffs, and architectural decisions that we will need to consider when designing a 224 Gbps design. They also investigate the variety of interconnect solutions that Samtec offers for your next 224 Gbps design.

Click here for more information about Silicon-to-Silicon Application Solutions from Samtec