ESL has engendered much hype (and ensuing cynicism) during the last decade, leading perfectly reasonable hardware engineers to ask, “Why move from RTL, which works perfectly well?� So far, there have been a number of good reasons, with an equal number of counter arguments.

The most oft-stated reason to adopt ESL is to enable system-level modeling and hardware/software integration. While system architects benefit greatly from modeling the performance and integration of complete systems, there’s historically been little value for hardware engineers. In fact, it often creates more work for them to translate high-level models into compliant architectures that are efficient in terms of power, timing, and area.

For hardware engineers, the most touted reason to switch, so far, is higher productivity — synthesizing more gates, more quickly, with more compact code, using high-level synthesis (that is, synthesis from C/C++/SystemC to Verilog RTL). But it’s often easier for design teams to throw more engineers at the problem — or even outsource — rather than experience the risk and disruption of changing their design paradigm.

The best, most compelling reason for almost all EDA paradigm shifts is to achieve better quality of results. Better results quality directly increases value for every hardware design team, impacting both top and bottom lines. Better-performing products consume less power, fetch higher prices, often have lower design costs, and achieve better profits.

How does ESL improve quality of results?

Obviously, this lies in the ESL implementation flow, which has received less attention than ESL verification. Efficiently implementing a system-level design description in ANSI C/C++ or SystemC is the golden enabler of system-level hardware design. For years, tools have existed that can synthesize RTL designs from high-level algorithmic descriptions in various flavors of C. But these RTL implementations rarely are as efficient in performance and area as designs coded by hand at the RT level by a skilled engineer. Thus, the primary value proposition for high-level synthesis tools was “better productivity.� And, traditionally, hiring more engineers was a lower-risk choice than changing methodologies.

However, a new quality-of-results opportunity exists. Power consumption, previously a second-order concern, now is as crucial a consideration as performance and area — even more so for portable designs. And greater gains can be made with power by starting at the system-level rather than RTL.

Why?

Unlike timing and area, power consumption is very data-dependent, due to switching activity. To accurately implement a low-power architecture, power analysis must be based on a representative set of real, expected activity vectors, rather than corner-case behavior. A design’s power consumption has as much to do with the switching activity of the typical data set moving through the system as the architecture of the design itself.

The most efficient RTL architecture only can be determined by understanding the nominal switching activity driven by a typical data set moving through the design. This information is available by simulating the full system (with software) at the ES Level; the analysis of the resulting switching activity enables synthesis of an RTL architecture that minimizes power consumption in typical mission mode.

Benchmarks of this approach have shown dramatic reductions in power consumption. When compared to RTL designed by hand or synthesized from C/C++/SystemC without taking power into consideration at the system level, power-optimizing high-level synthesis reduced total power consumption up to 75% — taking into account both dynamic and leakage power. This is not to suggest that RTL (and below) power solutions don’t add value. But once design architectures are locked in at the RT level, 80% to 90% of a power budget is set in stone. Although RTL tools can optimize in the margin, starting with a power-efficient architecture optimized at the system-level by a high-level synthesis tool with switching data-aware power analysis yields a superior result.

The growing need to reduce power consumption due to smaller, leakier process geometries and the trend toward battery-powered devices often makes power the most important consideration in semiconductor design. And I believe that power — the first semiconductor quality of results trait that can be greatly improved at the system-level — is now the best reason for hardware design engineers to adopt ESL tools.