Since I've complained in the past that electronic system level (ESL) means little more than "anything above RTL," anything that can provide more insight into just what is above RTL is welcome. I have found some clarification through five levels of modeling abstraction described in TLM-Driven Design and Verification Methodology, a Cadence-published book I have blogged about in the past. (The latest news is that the book is now available through Amazon).
So far as I can tell, the five levels of abstraction listed here pretty much cover the hardware and system design space from Matlab to RTL, emcompassing most of what people mean by "ESL." Since the fifth level is RTL, which is well understood, I'll just focus on the top four here. I should note that these levels are mostly orthogonal to SystemC transaction-level modeling (TLM) coding styles such as loosely timed (LT), approximately timed (AT), and cycle accurate (CA). In this scheme RTL is the first completely cycle-accurate modeling level.
1. Pure Functional Level
At the highest level of abstraction, the design goal is to choose an algorithm that meets all functional requirements, and the verification goal is to ensure functionality is correct. This level is typically used by systems architects and algorithm developers using C/C++ models or tools like Matlab. Models are untimed computational blocks. These models are not useful for hardware designers, but some code is potentially reusable at the next level.
2. Functional Virtual Prototype (FVP) Ready
Virtual prototyping allows early software development using TLM models. The SystemC TLM 2.0 standard is increasingly applied at this level. Computational blocks remain untimed, but it may be necessary to define some timing at interfaces. Models expose such features as the hardware/software boundary and concurrency.
3. HLS-Ready TLM Level
This is the highest point of abstraction that allows entry into high-level synthesis (HLS). Obviously, models need to be synthesizable, and should be optimized for quality of synthesis results (rather than simulation performance). While computational blocks may remain untimed, communication blocks also need to be modeled, and this typically involves LT or AT coding styles. Specific requirements at this level vary from one synthesis tool to another.
4. HLS-Ready Signal Level
At this level, the external transaction-level interfaces of a block are refined to the signal level. Protocols are cycle-accurate but the computational blocks are unchanged. This refinement can be accomplished with synthesizable communication design IP.
The Next Challenge
With these modeling abstraction levels in view, we have a clearer map. Now we need to connect the dots. The next challenge is to avoid having to re-write and re-verify models at every level of abstraction. For this reason, the TLM methodology outlined in the book uses a single verification environment to span multiple levels of abstraction. This methodology is reflected in the "refine and reuse" approach, described in my earlier blog, that Cadence and TSMC used to build the verification portion of ESL Reference Flow 11.
Much more remains to be done. One current problem is that SystemC TLM 2.0 is not synthesizable. However, we're not going to have a coherent ESL (or TLM or whatever term you choose) methodology if we don't clarify what we're talking about.
Gary -- that's very true. We are still a long ways from real system-level design, especially when you consider all the areas EDA has never addressed. And the list of considerations goes on and on. With the iPhone 4, somebody should have modeled not only the packaging and the antenna, but the hand that holds the device.
We keep forgetting that this doesn't really cover system level design. There are always mechanical considerations to deal with and often other areas, for instance fluids, bio, chemical and optical, that need to be designed before the entire system is completed.
Richard, I expect you'll get to this eventually (unless you already have and I've just missed it) but I hope you follow this post up with a view of the top-down validation/verification flow from the same book (also mentioned in bailey's and grant martin's "ESL Models and their Applications"). I think that's the point where the verification guys can start getting excited about the innovation in esl and how it can being meaningfully applied in functional verification.