Slow Adoption for ESL

By Brian Fuller
It’s been more than a decade since electronic system level (ESL) abstraction started to gain traction in EDA. It’s been more than a few years since the industry began to plan for the day when the benefits of embracing C-language approaches to design description and validation would find designers churning out massively complex and profitable designs while sitting in lawn chairs sipping drinks with little pink umbrellas in them.

What happened?

Well, it’s still with us, but no one’s broken out the lawn chairs just yet.

ESL in general, and SystemC at the transaction level in particular, still hold promise—and have had tongues wagging for years—because of the design-efficiency gains that should accrue to the industry. Describing and verifying at a higher abstraction level a project of mind-boggling complexity that’s slated to cost tens of millions of dollars has got to save time and energy, right? Embracing C-language approaches to design would make hardware design as simple and carefree as software design, right?

Not so fast, notes Jon McDonald, technical marketing engineer for the design and creation business unit at Mentor Graphics. In February, he opined:

“For those of you who were around for the last big design shift—from schematics to RTL—you may remember hearing these kinds of statements back then. Managers believed or were sold the story that hardware design was going to be more like software as design moved to RTL. Back then there were a number of projects that tried to have software programmers writing the RTL code. What I remember most are some spectacular failures, primarily because the people writing the RTL did not understand the hardware implications of the choices they were making.”

Longtime industry analyst Gary Smith of Gary Smith EDA notes that while ESL in general caught fire in 2004, increased adoption has come at a sober pace.

“Our survey that year showed significant use of ESL, albeit often with in-house, proprietary C/C++ tools,” Smith said at DVCon. “Our survey two years later showed that, of the engineers who could be expected to benefit from the use of ESL methodologies, about 4% were actually using it. This year, it’s about 5%. Remember that the shift to RTL took about eight years. If ESL pans out the same way, it should be done by 2012.”

Where’s the beef?
If time to market is more critical than ever and design productivity crucial to the very survival of some companies, shouldn’t we be seeing proof of productivity gains through higher abstraction approaches to design?

It could be, as Smith noted, that it’s still early. It also could be a cultural-transition issue. Wholesale change comes slowly to most industries, even ones as creative and electronics. And it’s a complex world.

“SystemC and transaction-level modeling takes its place in what is now a multi-language world and a very complex flow involving modeling issues and then design issues and verification,” said John Aynsley, CTO of Doulos, in a recent presentation.

One school of thought argues past is prologue. Steven Brown, blogging at Cadence, suggested that the history of RTL adoption—which has been a design automation workhorse for three decades now—suggests the next abstraction to System C transaction-level modeling will boost productivity. He illustrates the historic improvement in productivity as an improvement in the design of gates per day. But productivity as defined by gates-per-day isn’t necessarily an accurate measure of design engineering productivity, as more gates per day could be attributable to the gains from a higher abstraction level, faster computing systems and or more (or more experienced) engineers. (Still, it’s hard to argue that we should still be clinging to the schematic capture wagon today).

Think different
There are some voices that argue different definitions (and a complete rethinking of EDA assumptions) are necessary if we’re to stay on top of design complexity.

Mike Eneboe, former vice president of programmable platforms at LSI and now a business and technology consultant at Ridge Partners, LLC, is one of those voices.

“We are the EDA industry’s equivalent of the Donner Party with everyone waiting to see their neighbor fall asleep,” he said. “There is little movement and minimal efficiency in technology, business models, or investments. We can change this.”

He argues that as the industry converges around C for high-level languages and abstractions, the proof points should revolve around short time-to-market, simple, deterministic. In this way, he gives the software-development industry an ‘A’ grade for improving time to market, simplicity and deterministic design. “I don’t want to hazard a guess as to the EDA industry’s grade over the last 10 years,” Eneboe said.

Eneboe believes a different way of approaching the problem needs to be considered and argues for improvements in four areas:

1. Find a way to abstract the timing challenges of hardware. Clock to clock, nanosecond-sized timing calculations can no longer be handled efficiently across entire complex designs. Abstract the system-level needs up to frame and packet timings.
2. Wrap or otherwise get IP blocks (or functional blocks) to not be as bursty as they are today. Use of temporal fabrics (with QoS) can help facilitate the deterministic throughput to/from the functional blocks.
3. Create new metrics for the target platforms (FPGA, structured ASICs, full ASICs) in the form of new, high-level guaranteed libraries. These new libraries would present the low-level resources (with guardbanded area and timing) as high-level objects that are malleable and deterministic.
4. Tools need to be written to efficiently convey the “completability” (design completion all the way through place and route) of the design at the point of architectural integration. What it means is that if a designer connects 10 IP blocks and targets the design to a 45nm library, the tools need to quickly indicate to the designer if the design will absolutely complete or not.

“If these four concepts are done well, then the language—C, C++, SystemC, Java, and so forth—do not matter,” Eneboe said. “Pick the most efficient one and use it. Verification is only done at the transactional level because that’s all that the interconnect fabric guarantees and ‘cares’ about.”

In any case, this story is, as they say on television…to be continued.