Estimates, Spreadsheets And Abstract Models
By Jon McDonald
Lies, damn lies and statistics. Occasionally I get the impression that some engineers feel we’ve just taken that step beyond statistics in our ESL modeling.
In a recent discussion I was very pointedly reminded of the subjective nature of abstract design and analysis. Like most predictions, you don’t really know what’s going to happen until it actually comes to pass. Using abstract modeling, ESL design is trying to predict what will happen when you build something before building it. No one has a perfect understanding of things that have not yet been done, but we can make educated decisions based on current knowledge and refine our decisions as more information becomes available.
This is a very important concept to keep in mind as we go through our design processes. We can start with estimates, guesses by another name, of our expected system capabilities. We can estimate performance and power characteristics to make some very early decisions on a project’s viability and the best approach for the design tradeoffs. As we get more detail on what we will be doing we may build spreadsheets to capture some of the dependencies between our choices. As our system understanding increases we may come to a point at which the number of variables and the interaction of these variables is too complex to effectively maintain in a spreadsheet.
At this point creating an abstract model of our system may make sense. With an abstract model we can start to explore much more detailed analysis, we can create models that allow us to understand the detailed system performance and power consumption of our system. Our models may be able to process realistic data sets, run software and exploring the efficiency of our hardware platform for its intended task.
All of this gives us a fantastic amount of information and understanding of our target design, but it is critical to remember that the accuracy of our understanding is limited by the accuracy of our models. We need to remember this fact and understand that knowledge of our design is continuously being refined. As we learn more from our decisions moving through implementation, we need to verify the effects of these implementation decisions on our earlier assumptions and models. Creation of an abstract platform for a new design is not a single exercise completed and frozen as we move to the next step. It is a continuous process of improving the accuracy of our abstract platform to reflect the decisions and trade-offs identified as we go through implementation.
Mark Twain popularized the disparaging view of statistics. I believe this largely hinged on the perceived practice of claiming faulty conclusions by selectively misusing statistical data. If we hope to achieve the full value from our abstract modeling and avoid negative interpretations, we need to accept the fact that our abstract platforms are continuously evolving representations of our current understanding of our target implementation. The accuracy of the models at any given time is very subjective, subject to the current visibility we have into the implementation decisions we have yet to make.
–Jon McDonald is a technical marketing engineer for the design and creation business unit at Mentor Graphics.
December 17th, 2009 at 11:40 am
Yes, accuracy of information depends on accuracy of models… which depends on accuracy of information we put into them… But saying this doesn’t help us at all. On the contrary. The ESL market has been frozen for a decade by the lack of clear modeling guidelines. When the answer to “how should model” is “it depends”, you don’t get people going. RTL methods were structured around well defined semantics. What above? Close to nothing? TLM brings us “loosely” and “approximately” timed models. That doesn’t help the industry at all. So please don’t tell us “it depends”, tell us instead how to do things. Some will like and some won’t, but that’s always more users than if “it depends”.
December 17th, 2009 at 4:18 pm
This modeling dilemma is why Cadence provide a TLM design and verification methodology. Check us out!
December 23rd, 2009 at 8:35 am
From my perspective we are seeing a dramatic increase in the amount and variety of analysis that is being done with abstract models. I have worked with customers on production projects using abstract models for everything from basic functional verification, architectural performance analysis through detailed architectural power optimization with power information extracted from the implementation. The issue is that there are many different things that can be done. The path from a very abstract spec to the RTL implementation has many steps and many points at which design decisions and trade-offs need to be made. We need to use the abstract models we develop in the right way to answer the appropriate questions. The risk we face is in oversimplifying the stepwise refinement process that we will go through in moving from the highest level abstract models down to the approximately timed models that become the final step before RTL implementation. The tools and standards available today greatly improve the efficiency of creating and refining these abstract models, but they still have to be applied appropriately. To address Harald’s point, the “it depends” message relates to what question you want to answer. If you ask a specific question you will get a specific answer in terms of the fidelity of the models required to answer the question, but without knowing the question no one can define the appropriate level of accuracy required in the abstract models.