Is There Finally A Silver Bullet For Software?

As I am in Nuremberg for the annual embedded world conference, the overall mood here seemed a bit muted and slow on day one. There are rumors of 200 exhibitors of the roughly 1100 having pulled out due to the global health situation—we are all asked not to shake hands and smile instead—and the rainy weather doesn’t help much either. With the weather turning to snow on day two, the attendance seems to be pretty good, actually, and we have good discussions with attendees. At Embedded World software is always on my mind, and with that, I am thinking of James (Jim) Ready, a colleague and friend who passed on a little bit over two years ago. I miss his humor and software insights. What has changed in software development? What would he say today?

Better to smile than to shake hands at Embedded World 2020

I had the honor of working very closely with Jim as we were assessing strategic options for embedded software in electronic design automation (EDA). “The best way to make money with software is to sell hardware,” used to be his comment after having worked at Cadence for a while. And that comment was coming from the RTOS software pioneer and inventor of the RTOS and board support package (BSP) himself! Modern systems on chips (SoCs) cannot work without all their software content, so discussions about EDA and how it relates to embedded software were natural. In one of our conversations, we went back to software basics—the famous “silver bullet.”

Frederick Brooks, in his famous paper from 1986 “No Silver Bullet—Essence and Accident in Software Engineering,” divides the difficulties in software development into two components: accidental and essential. An accidental difficulty is the challenge of transforming the conceptual representation of software into the reality of running on a particular piece of hardware. The introduction of high-level languages in software development has made the single-most significant gain in software productivity, as it automated this transformation process. What is left is the essential difficulty, and Brook’s thesis is that no one tool or tools will ever make the kind of productivity improvements gained from the introduction of high-level languages in attacking essential difficulties.

With this model in mind, Jim and I would quickly agree on why it’s different in the EDA world, where the tools continue to increase the productivity of developers with each change in process technology. In one of our email exchanges he wrote: “In effect, essential difficulties dominate the development process for semiconductors due to the physical changes in the semiconductor process as a result of moving to the next node of technology. As Brooks tells us, essential difficulties are amenable to tooling to get dramatic productivity gains, and EDA business continuously exploits that fact by developing those tools year after year. Every transition to the next technology node breaks the design rules of previous generations and requires new implementation tools.” To add to that, with each new technology node, the cost of verification and SoC-related software development is growing significantly as well.

So, what’s next in software?

Brooks said back in 1986, “Skepticism is not pessimism, however. Although we see no startling breakthroughs and, indeed, believe such to be inconsistent with the nature of software, many encouraging innovations are underway. […] There is no royal road, but there is a road”.  At the time, Brooks identified four promising areas of development that could be considered potential elements “along the road”:

• “Buy vs. build” – Best not to develop software at all but re-use it. During day one of the show, I ran into several vendors that provide databases, filesystems, and machine learning-related packages. Re-use is key.
• “Requirements refinement and rapid prototyping” – Dealing with changing customer requirements and prototype solutions, what we now call “being agile.” Here in Nuremberg, prototyping is one of the topics at our booth, as well as our partner and neighbor Green Hills Software in the context of safety and security. My presentation at the conference is about “Optimally Balancing Simulation, Emulation, and Prototyping for System on Chip Development.”
• “Incremental development—grow, not build, software” – Mimicking other building and construction processes. The assembly of software from its components is a topic here in Nuremberg, and modeling at higher levels can be seen at exhibitors like National Instruments and MathWorks, as well as in vertical application-specific context at companies like ETAS.
• “Great designers” – Focus on people and education. Thursday will be the student day here. It is always refreshing and exciting to see the talent of the next generation.

So, while it looks like we are well along “on the road” towards software improvements, some fundamentals have changed drastically. A little over 30 years after Brooks’ “Silver Bullet”, John Hennessy and David Patterson declared in their ISCA 2018 Turing Lecture that we are in “A New Golden Age for Computer Architecture.”

I assembled a couple of sources into one in the following graph to illustrate those changes, and overlaid some of the key publications.

The original source comes from the “42 Years of Processor Data” that K. Rupp is maintaining. I “underlaid” the core of the 2018 Hennessy/Patterson Turing Lecture, slide 22. CISC single program speed grew 2x in 3.5 years, RISC performance grew 2x every 1.5 years until about 2003. The end of Dennard Scaling still maintained 2x performance improvement in 3.5 years, but as Herb Sutter outlined in “The Free Lunch is Over,” clock frequencies and power were tapering off, causing the switch to multicore with all its associated challenges for software development. As the graph indicates, the transistor count still follows Moore’s Law, but the cost per transistor is slowing down faster due to fab costs (Turing lecture, slide 24).

It is noteworthy that right after the “Silver Bullet” publication, the software industry had essentially 17 years of “free lunch” enabled by hardware, but on top of it also introduced items that Brooks was suggesting – like Open Source (Linux, Android). Jim’s contributions to all this can be seen in VxWorks, for instance.

The bottom line for “The Golden New Age of Computer Architecture” – if I would take Fred Brooks’ software perspective – is that hardware will be a crucial part of the “essential” changes to come. Domain-specific architectures (DSAs) will be key and required lots of “accidental” improvements in mapping domain-specific languages (DSLs) to DSAs.

It’s a brave new world. And it is good to be at the hardware/software interface!

Incidentally, in the speaker preparation room, I ran into Mentor’s Colin Walls, who wrote a great article about Jim Ready’s contributions. We reminisced about how much is changing, while so much has not in several decades (like C usage for embedded programming). We chatted about our experiences with Jim. I imagined how Jim would smile over lunch at his favorite Vietnamese place serving shaking beef – bo luc lac. He would again point out the importance of hardware for software, and how with DSLs we are edging closer, step by step, to what could be a “Silver Bullet.”

Fond memories. I miss our conversations, Jim. You always have been an inspiration.