Home > Community > Blogs > Industry Insights > five modeling abstraction levels clarify meaning of esl
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Industry Insights blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Five Modeling Abstraction Levels Clarify Meaning of “ESL”

Comments(3)Filed under: Industry Insights, ESL, SystemC, High-level Synthesis, HLS, TLM, TLM-2.0, verification, Virtual platform, virtual prototype

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.

Richard Goering

 

Comments(3)

By Neil Johnson on September 30, 2010
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.

By Gary Smith on September 30, 2010
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.

By rgoering on September 30, 2010
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.

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.