It is always fascinating to follow trend lines, and then to extrapolate them out toward infinity to see what absurd conclusions you can reach. We do that a lot with Moore’s Law around here, and it’s pretty easy to come to absurd conclusions extrapolating on those particular exponentials.
Even with the absurdity disclaimer in place, however, it is interesting to look to the not-too-distant future implications of our most recent half-century of progress. Yes, the cost of a transistor has dropped to … so close to zero that we might want to finally just call it zero. In truth, most of the cost of designing a silicon chip today is the non-recurring engineering costs, not the cost of the silicon area. By the time you amortize all those huge expenses over your production run, the cost of the silicon area itself becomes pretty insignificant. In fact, silicon starts to look a lot more like software – where all of the cost is for development and the incremental cost of an additional copy is basically zero.
Our supply-and-demand economy isn’t very good at handling situations where incremental unit cost is zero. It makes the “supply” side of the equation approximately infinity. If the supply is infinity, it doesn’t really matter what the demand is – competition drives the price of the product to zero. If we all want to continue to get paid for designing hardware, we might want to pause and think about that for a minute.
Did you think about it?
OK, so the software industry has been dealing with this for a very long time and has struggled to find business models that work. First, a bit of important background: When you “buy” software, you’re really not buying anything. You’re paying for a license to use software that belongs to somebody else – the copyright holder. The original software business model was to sell you a permanent license to use a piece of software. You paid for it once, and you were free to use it forever without paying any more money. This made it difficult to get continuing revenue streams for improving the product. And, since software doesn’t wear out, it meant that each program tended toward a point of market saturation.
Next, the software folks added “maintenance” charges on top of that. You paid once for the permanent license, and then you paid an ongoing fee for updates and bug fixes. This was better, but it led to uncomfortable decisions on what constituted an “update” (which was included in the maintenance fee) and a whole new product (which required a new permanent license).
Then, of course “term-licensing” came along. You basically rented the software from the software company for a specified amount of time. That fee included the old “maintenance” charges as well as a pro-rated portion of the old permanent license fee. Term licensing is the preferred mode for many software offerings today. In our industry, EDA in particular has glommed onto term licensing as a way to extract reasonable value.
But, with the advent of cloud-based computing, it became possible to be more sophisticated about charging for the value actually delivered by software. That gave rise to the idea of “software as a service” (SaaS). In this model, you aren’t really licensing a copy or a seat of anything. You’re just paying for access to a service that is delivered via software (using running on the provider’s centrally-located servers).
SaaS has myriad benefits, which we won’t go into at the moment because the relevant question here is: What does this have to do with hardware?
Fuzz your eyes a little bit and envision hardware being delivered as a service. OK, it doesn’t really take that much fuzzing, because we actually have examples of that today (or close to it, anyway). Consider mobile phones. Few of us actually “buy” them. They are generally provided (or heavily subsidized) by a network provider in exchange for a commitment to purchase their network services. We understand we are not just buying a device. If you take your phone into the middle of the ocean, it’s basically useless. We are buying communication services, and delivery of those services requires a highly complex system of hardware and software to realize.
Or, in a different mode, consider ARM. While providing more processors than any company on Earth, ARM doesn’t build any processors. They design hardware, and they license their designs to other companies to build. Even though ARM is a hardware company, their business model is much more akin to software.
Turning that model around, however, we have the FPGA companies who, arguably, could be said to be more software companies than chip companies. They typically have enormous software development teams, and increasingly more of their value and differentiation comes from the EDA tools they deliver than from the chips they sell. It could be argued that Xilinx and Altera, for example, are actually EDA companies who have found a more profitable way to extract the value from their tools – by selling it locked to their chips.
Now, think about the hardware you personally design. If it involves FPGAs, for example, it immediately assumes many properties of software, such as the ability to be re-configured, altered, and improved in the field. Would a service-oriented model make more sense for FPGA-based products? If you’re trying to cost-optimize a single device, FPGAs often don’t make sense. But, if you’re trying to cost-optimize the delivery of a service, programmable hardware could be a major advantage.
Or, expanding our scope a bit more to “systems,” just about every system we work on today is “programmable” in some way. And more and more of the capability and differentiation is being delivered by software (or, with programmable logic in the mix, programmable hardware). This programmability-of-everything naturally begins to make our systems, and therefore our hardware, have more and more properties of software when it comes to market forces.
If you don’t think this could become a problem where you work, consider the explosion of the app ecosystem. A few years ago, consumer-grade GPS, digital cameras, music players, and PDAs were all valid stand-alone product categories. Consumers could reasonably be expected to own many of these items, and to plunk down hundreds of dollars for each. Today, however, we see the consumer get pretty upset when that killer camera app is $1.99 instead of just 99 cents (or preferably free). Thousands of functions that were formerly stand-alone pieces of electronic gear are now software apps that run on a single, standardized, programmable piece of hardware. Those electronic hardware markets evaporated almost overnight.
When any maker in a garage can crank out a sophisticated capability based on a standardized hardware platform and a little (or a lot) of value-added software, do we see a shift in the value chain from products to services? Do we naturally end up in a place where everything is a service, and the notion of “owning” a physical chunk of technology is an anachronism?
If we did, in fact, reach this “everything as a service” (EaaS) world, how would it change your engineering priorities? Would you focus less on BOM costs, and more on long-term durability, robustness, and upgradeability? If, rather than selling an “improved” new product to the customer every two years, the goal was to deliver the best possible service at the lowest total cost, you certainly might. And, if more of the hardware engineering development is focused on creating standardized, reusable, versatile platforms rather than one-off single-function products, then making those platforms as programmable as possible – both in hardware and in software – would take priority over task-specific optimizations.
In our industry the one constant, as they say, is change. And, that change is not restricted to the number of transistors we cram onto a chip. New technology and new customers mean new economics and new business models. If we assume that we’ll be selling the technology of tomorrow through “business as usual” markets and economies, we are certain to be wrong.
