ESL Modeling: Be Careful What You Wish For
I was talking to a customer last week about his most recent ESL activities and he brought up a question that I’ve heard from many different sources : “How accurate does my ESL model need to be?” The level of timing accuracy, and even function accuracy, needed for effective system level analysis is a very dynamic question, with different answers for different organizations, and even different stages of the design process.
I’ve seen many cases where adopting ESL techniques has been successful and those where it has not worked. One of the significant contributing factors in the failed cases is engineering obsessing about the accuracy of the models they are creating. As organizations look at moving to higher levels of modeling, they naturally come up with a wish list of all the possible things they would like to accomplish with these abstract models. The problem occurs when they then take this wish list and try to satisfy all of it right away in the model requirements.
Moving to a new methodology and trying to answer all the possible questions you might want to answer in one step is a monumental task. Organizations that have been successful in adopting ESL focus their initial system modeling task on the simplest questions that will have a significant impact on key architectural decisions. Then they create ESL/TLM system models to answer those specific initial questions. By taking a small revolutionary step in creating the initial ESL/TLM system, they can then refine this system model in an evolutionary process of increasing complexity and accuracy, ultimately answer ing all of the questions before beginning implementation.
I am eager to hear if you have had the same experience , or not , when creating ESL models. So I’ll propose a few open questions for any of you who have been involved in a successful ESL/TLM modeling effort:
- What has worked for you?
- What level of accuracy did you require in your models?
- What types of issues were you addressing with your effort?
Tags: Add new tag, editorial, ESL, mentor graphics
February 5th, 2009 at 9:41 am
In the book that Grant Martin, Andrew Piziali and I co-wrote a couple of years back “ESL Design and Verification: A prescription for electronic system design methodology”, we defined ESL as:
The utilisation of appropriate abstractions in order to increase comprehension about a system, and to enhance the probability of a successful implementation of functionality in a cost-effective manner.
I think this ties in very well with the point that you are making in that there is no one right level of abstraction for all possible tasks. The correct level has to be implemented in order to understand the decisions that it will help you to make. It also has to be remembered that if the abstract model comes first, then what cycle accurate or other form of accuracy cannot be known because it does not yet exist. If the abstract model is being created after the fact, then it is clearly for a defined purpose and only just enough information should be contained in that model so that it can developed fast and execute fast.
At the end of the day – you get what you pay for. Don’t overspend or try to do it on the cheap.