Viewpoint: Is ESL for everyone?

Like the Dr. Seuss story about plain-bellied Sneetches who all wanted to become star-bellied Sneetches, so too are EDA vendors all claiming now to be "ESL vendors" despite how much they often need to stretch the definition.

It seems that the "star-bellied Sneetches" in the Dr. Seuss story were the top dogs, and the poor plain- bellied Sneetches were always being left out of all the fun.
Things get interesting when a clever fellow named Sylvester McMonkey McBean showed up with a machine to add stars on the bellies of the plain-bellied Sneetches, who quickly fork over their cash to get the cosmetic surgery and join the in-crowd. Of course, the star-bellied Sneetches are outraged and turn to Sylvester to use another machine to have their stars removed so that they can once again tell themselves apart.

Things get confused, and by the end of the book no one can remember who originally had stars and who didn't. Sneetches learn to get along, and Sylvester leaves with everyone's life savings.

Wandering around the last few Design Automation Conferences brought this story to mind. Instead of star-bellies, it seems that someone has invented an "ESL-bellied" machinee. We are hearing more claims about how every tool is, in fact, an ESL tool, no matter how tenuous the claim.

The real ESL vendors are almost ready to start looking for Sylvester and his "plain belly" machine to separate us from the raft of freshly-minted ESL companies.
To be fair, part of this is our own collective fault: ESL, like any good short acronym, is a slippery term. ESL design can be interpreted in many different ways.

What does it really mean to do system-level design? Is it electronic system level or something else? Does ESL design require some minimum level of abstraction? Does ESL design have to happen at a certain point in the design process? Can ESL verification be done without ESL design or vice versa? Is there some minimum level of complexity that makes it a "system"?Does ESL design have to include hardware and software, or can it just be high-level hardware design?

Perhaps no on has been more involved in tracking ESL and the exploding ESL industry than Gary Smith of Gary Smith EDA. In fact, Smith is generally credited with coining the term ESL, and he defines ESL simply as, "concurrent design of hardware and software."

Other definitions focus more on the hardware aspect of the design and define it to include the design of the entire "system," which may or may not include any sofware.

The promise of an effective ESL implementation is both the shortening of the development cycle as well as dramatically reduced risk by ensuring that hardware and software both work before any commitment to production. Instead of developing software after the silicon prototype is available, design teams can develop software before silicon. Not only do they get software earlier, they are able to use the actual software to validate hardware. White-box testing and targeted testbenches are both useful, but until the actual software is running on hardware, design teams don't know if the system really works or not.

If we can agree on the general definition, what does that mean for an ESL solution or tool? Obviously, the solution has to help address the design and verification of the entire system, not just part of it. While much of the EDA industry's focus today is on system-on-chip, this could be a system-on-a-chip, a pc-board or a whole chassis.