For more years than I care to count, I've heard that the pressures of complexity and time-to-market will force designers to move upward in abstraction, and that RTL to electronic system level (ESL) design will be the next solution to take off. Every year we wait for it to happen, and every year it doesn't. Why?

I believe it's partly based on the EDA community's assumption that moving from RTL up to ESL will resemble the shift from gate level to RTL. The latter was a transition that was constrained in the domain of hardware designers. It was simply a step to improve efficiency and manage complexity, but with no other influencing factor or anything else to take into consideration.

When ESL was first proposed, the perceived wisdom was that it would be a question of defining a new higher-level hardware description language and developing behavioral synthesis tools to automate the downward transition. In other words, it's a problem/solution that hardware designers own. Wrong. The move to ESL is fundamentally different because it affects more than just hardware-centric people-in fact, it has a huge interference pattern to deal with in the form of embedded software.

This is not a battle. It's not a question of persuading software engineers to write in pseudo-hardware languages. To go down that path is to fail to understand that embedded software engineers already have perfectly good languages and development environments. And guess what? They are pretty happy with them.

At its heart, moving RTL to ESL has, as a fundamental requirement, to find a way to link the embedded software world into an ESL to RTL flow that can understand and leverage the work that software engineers have already done as a natural starting point for hardware development.

So what are the challenges here? We need to recognize that software has increasingly become the only true source of system functionality, and that it is the starting point for a top-down development flow. We also need to recognize that this first step, a software-only approach, is rarely able to meet the required system performance goals. And that at this point, some form of hardware acceleration becomes necessary to make the end product viable.

This smart way to drive the development of these hardware accelerators is not to start again from scratch. Recapturing the functionality in a new language isn't logical. The natural approach is to expand on existing efforts from developed software.

Let's look at hardware development from a software engineer's perspective-an inconvenience necessary to get the required system performance! You need to carve out the functions to be accelerated, partition them, specify the hardware functionality and performance, develop the communications protocol with the main processor, wait for the design to be completed, and integrate the hardware and software together.

Even taking the approach of either a standalone fixed DSP or a configurable coprocessor introduces the huge complexities associated with having another software development tool chain within the same design. A company or methodology that has the ability to deliver a controlled migration path from the software domain toward the necessary hardware accelerators will deliver a fundamental shift in the industry.

Until the EDA industry stops thinking about embedded software developers in terms of the size of their tools budget and embraces them as key components in the drive toward ESL, the language wars will rage on and users won't stray far from RTL.

http://www.eet.com