What is exciting about TLM is the abstraction of data and communication. One of my own frustrations with using traditional HDLs for system-level modeling is that once an interface is defined, it is almost impossible to refine data representation or communication mechanism. TLM gives me the ability to model data communication without committing too early to a particular implementation. It also provides a common abstraction for communication among heterogeneous components that is not biased.

In other words, I don’t think any one company or spokesperson gets to define what ESL is or isn’t. I have seen a lot of interesting experiments with tools that help designers create designs at the “electronic system level” and I am loathe to anoint just one of these as the one true path. At this moment, maintaining “clarity” as to the “true” meaning of ESL is far, far less important to me than finding design methods that let mere mortals successfully design systems containing hundreds of millions of gates.

* Hamlet, Act I, scene v

I think ultimately the users of SLD and ESL tools and methods will end up defining them “with their feet”, and will define the level of fuzz in the terms vs. the level of precise clarity. However, here are a couple of examples of fuzz that indicate, in my book, how hard it is to state definitively that ESL MUST have hardware, and SLD MUST be all about function. (even if “hardware implementation is not the focus of these languages”).
1. UML: UML is not a language, but a “meta-notation” that through profiling, allows the creation of domain-specific notations or languages. Although driven from software roots, UML profiles for SystemC (for hardware definition) have been created by several groups including a consortium of companies in Japan, by STMicroelectronics, and several academic research groups. Is UML in this use model an SLD tool, an ESL tool, or does it cross the fuzzy line?
2. SPW (was Comdisco, then Cadence Alta, then Cadence mainstream, and now CoWare). SPW allows you to describe algorithms in floating point, then refine them into fixed point, and then, if you want, using the HDS (hardware development system – although I may not be up on the current names CoWare is using) you can further refine the algorithm into an RTL implementation by substituting hardware/RTL blocks for algorithmic ones. Is SPW in this use case an SLD tool, an ESL tool or does it cross the fuzzy line.
3. Matlab and Simulink are also crossing the similar line into HW implementation, and although they are primarily algorithm oriented (and thus SLD by the definition), they may do more on HW in the future.

There may be a case, as Jon says, to try to clearly label the use models and define them more precisely, to reduce confusion. But I think the ESL and SLD terms are probably likely to remain somewhat loose in definition and application.

But as always, designers can change the game by their actions here.

The sizing of interconnects on heterogeneous multicore chips to me sounds like classic inside-the-chip EDA. So I cannot quite follow the point being made here. It is clear that in principle there is a need for larger-scale design something, but in practice tools today are focused on bringing out new chip designs.