The ESL Edge

It is always great to receive compliments after giving a presentation. While many people may say good job, or nice presentation, it is even better when you get the kinds of comments I received after a presentation I gave at the DAC Workshop for virtual platforms in San Francisco on Wednesday morning. To put the comments in a nutshell they said, “that could be one of the most important and insightful comments I have heard at DAC this year”. So what did I say that produced such comments?

The presentation was about putting timing into virtual platforms. A virtual platform is a software model of an actual or intended system that captures functional or behavioral aspects of a system. It normally involves the use of some form of abstraction such that adequate performance can be obtained at a desired level of accuracy. It is very common to hear people say that they need very accurate timing as this is the only way they can really know what is going on in the system. In other words they want the same level of accuracy and detail that have been used to at the RTL level, but want the performance that can only be obtained by applying abstractions. So while it is true that greater detail provides more accuracy about a specific transaction, it is not the whole story. There are times when the addition of accurate timing details actually makes the information that is obtained less accurate. Let me explain.

If you want to examine how two parts of a system interact with each other, you could do this at an untimed transaction level and gain some knowledge about the amount of traffic that pass between them. The good news is that you can obtain that information very quickly. If you were to add detailed timing, you would see exactly when that data is transferred and any contentions that may exist on the communications channel. This will take a lot longer to simulate, so you may have to limit the length of the simulation, or the number of cases are considered. But what if you included just a small amount of timing information. You can then get the best of both worlds. You can see the expected data rates, any periods of time when there may be congestion, and you can do it fast, which means that you can put enough data through to get a real picture of how the data patterns may change over time; if there are conditions under which extremely heavy load is expected etc. In short you can get an accurate statistical picture of that communications that will allow you to tune the communications, or the architecture. This data is way more accurate than you would have gotten from the detailed timing simulation that could only look at transactions over a short period of time.

This goes back to the definition of ESL that was captured in the book “ESL Design and Verification” which starts – The utilization of appropriate abstractions in order to increase comprehension about a system…

The key element in that definition is that there is no ONE right abstraction that tells you everything you may need to know. You need to consider the abstraction and match it to the type of comprehension that you are seeking to obtain. If you want to know how an implementation works – stick to RTL. If you want to understand how a system is performing or to get a bigger view of system level operations, you must adjust your view of accuracy accordingly.

So, thank you to those people who made the comments. It confirms that I am helping people in the industry understand the bigger issues.

—————————————————————————————————————-

Brian Bailey – keeping you covered