Gary Smith has done an incredible job of compressing a lot of updated System Realization concepts into a two-page “Industry Note” that I believe everyone should read. The note is titled “ESL Behavioral Design,” which is a modest title that belies the broad thinking and grand concepts within. The note is bullish on what Smith calls “ESL design methodology.” Cadence has a broader take on this activity and calls it System Realization, but the end goals are the same: to develop an integrated hardware/software design that’s proven and ready for detailed implementation.
For years, EDA companies didn’t want to enter this market because of a perceived lack of target customers. Smith writes:
“In 1997 we did a survey and came up with around 400 architects. We projected 1,970 by the year 2000. That obviously makes them a really small market.”
However, in 1997, SoCs were just two years old and generally consisted of an on-chip processor core, some interfaces, on-chip memory, and some glue logic. Not much architecting needed. Fast forward to this decade. Now we routinely include half a dozen or more on-chip processor cores, DSPs, graphics processing engines, and I/O subsystems such as Ethernet and NAND Flash storage management that are easily as complex as an entire SoC circa 1997.
Smith clearly recognizes this significant escalation in system complexity in his note when he writes:
“What we didn’t understand then was that the architect is really not the ESL market at all. John Darringer at IBM calls the System Architect the artist. The problem today is that systems are so complex that the System Architect has lost the ability to predictably define a system that is actually achievable, particularly when you throw in the power problem…
What companies like IBM are doing is putting a team of ESL Designers as close to the System Architect as possible, even physically close. Their job is to do the modeling of the proposed system and then extensive what-if analysis to come up with the optimal design. So today system partitioning is done by a multidiscipline team under the Architect’s direction.”
Smith goes on to write that development at the system level requires three sets of virtual-prototyping tools used by three teams. The architect or architecture team uses what Smith calls “The Architect’s Workbench.” The hardware-implementation team uses “The Silicon Virtual Prototype.” The software-development team uses “The Software Virtual Prototype.” The relationships are shown in the figure below, adapted from Smith’s paper.
With the postulation of these three virtual-prototyping tools, Smith recognizes a fundamental shift in the way systems are developed. Due to rapidly rising system complexity, even the conceptual development of the system must be split into high-level architecture, hardware, and software.
Is this vision correct? Does it accurately describe the way System Realization now happens? Well, that’s a lot to ask of a two-page industry note. However, it’s clear that Smith has developed a sophisticated picture of the rising complexity of system development that recognizes the very real rise in system complexity over the past 10 years, the growing importance of software in system-design, and the urgent need for better hardware/software codevelopment tools.