ESL, or electronic system level design, is a catchall term for tools above the level of RTL. There are two primary aspects to this: synthesis and verification of IC designs from representations higher than RTL (usually untimed C or System-C); and tools that do something to address development of the software component of electronic systems.
I have no problem with the term ESL for the first of these segments, synthesis and verification. There are several EDA companies (Mentor with Catapult, Forte, Synfora, CriticalBlue, AutoESL, Cadence C-to-silicon) providing synthesis and one (Calypto) providing formal verification of this level of design. Getting design productivity up higher than pumping out RTL Verilog is necessary and these companies, despite their limited success, are probably part of the solution.
But when EDA companies turn to the software space they look at everything through their IC spectacles and assume that ESL methodologies in the chip design world will have some part to play in development of the software that runs on the chips. They have IC bias. But the software component of electronic systems is much larger and much longer-lived than the hardware (chip) part. ESL thinking that it will impact software development is the tail trying to wag the dog.
I was at a keynote by the CTO of Cisco a couple of years ago. He revealed that IOS, Cisco’s router software and operating system, is 25 million lines of code and there are an additional 35 million lines of scripts for testing it. Consequently the number one priority for any chip being sold to go into a Cisco router is “don’t break the software.” This is way ahead of anything to do with chip area, performance, power dissipation and so forth. Indeed, I heard (anecdotally, so this is hearsay) that Cavium, who have a 16 core MIPS processor, were unable to penetrate Cisco since IOS isn’t multi-threaded enough to take advantage of all those cores. The chip has no problems and is probably desirable in all sorts of other dimensions but it breaks the software so game-over.
I once asked some embedded software developers at an electronic system company what they thought about ESL. This was fairly soon after I had joined VaST and still suffered myself from IC bias. I was expecting them to say it was promising, or they hated SystemC or something like that. Instead, they could only think of ‘English as a second language’ and had never even heard of ESL. Almost no software runs directly on the bare chip in any case, it is all intermediated by a real-time operating system such as Wind River’s VxWorks, Green Hills’s Integrity or, increasingly, some flavor of Linux (which includes OS-X on iPhone and Android on the Google-phone). This makes direct software-hardware co-design, where some of the code is optionally implemented in hardware, much more complex. Pulling out a block of software for synthesis into custom hardware (or for implementation on a special data-plane processor) requires the stubbed out software to make operating system calls to access a custom device driver that can talk to the custom hardware directly. Automating that process requires building not just the hardware, but the device driver and other operating system scaffolding, as well as the stub back in the original source code. Of course, that is completely operating system dependent and so requires multiple implementations.
Software people simply don’t care how the chip was designed. The models created as part of the hardware design process are too slow by factors of thousands or even millions to be useful as part of the software development process. But most importantly, the bulk of the software payload for the chip already exists in the form of previous versions of the product. Even a brand new product like iPhone carried over a lot of software from the Mac that was simply cross compiled to run on the iPhone’s ARM processor.