Garbage Or Treasure?

By Jon McDonald
“Garbage in, garbage out” is a very appropriate axiom to keep in mind as you consider what kind of system-level modeling to invest in. Unfortunately this can be complicated by considering another piece of wisdom that often applies as well: “One mans trash is another’s treasure.”

What might be an inappropriate abstraction for one type of analysis may be very acceptable for another application. Part of human nature and, I believe, a very strong part of most engineer’s psyches is to re-use what we’ve created in as many places as possible. Once we’ve created a model, we want to re-use that model for everything. Reuse in general is a good goal, but we need to be intelligent about our reuse and clear in our understanding of what kinds of information can appropriately be derived from the models we create.

Over the past few years I’ve worked with a number of customers adopting system-level design approaches. In one specific case I recall a sequence of discussions that highlighted this point. In this particular situation there were a number of architectural models available with various levels of detail. A virtual platform had been created from these models and a fair amount of functional verification had been completed. A number of the models relied on statistical generation of their data. The statistical models were mainly used for external I/O generation and in some portions of the design to model the expected execution of applications software. The models were appropriate for exercising various aspects of the system, but were not exercising the system in exactly the way the system would be used in the field. This led to some disagreement on the value of the system-level model.

On the right side, the designers felt the models and statistically generated data had found issues with the basic architectural functionality and capabilities of the system. Designers on the left side pointed to the fact that the statistical models had raised concerns with performance issues that would not be relevant in the final system running the actual software and data loads. For the left, the results were garbage due to the garbage in, while to the right the results were treasure due to the issues identified early in the process.

System-level design and analysis opens tremendous possibilities to answer questions before committing to a design, but intelligence must be applied to ensure that the level of modeling detail is appropriate for the conclusions being drawn. In this particular example, the system-level model evolved to a point of executing the target applications software on more accurate representations of the data. This allowed the left to turn their trash into treasure. They ended up identifying issues and proving the viability and performance impact of a number of decisions before undesired limitations had been designed into the system. System-level design is not one thing at one point in time; it is an evolving approximation of a system that can answer different questions at different points in time with different levels of investment.

—Jon McDonald is a technical marketing engineer for the design and creation business at Mentor Graphics.