Cycle-Accurate Models?

By Jon McDonald
I was sitting in a meeting this week and someone made the statement, “I have to have a cycle-accurate model.” This was a meeting discussing early delivery of system models for software development, performance and power analysis. The final RTL didn’t even exist for the device in question, yet somehow the thinking was that a “cycle-accurate” model was required. I hear this point of view fairly often. I believe it’s a knee-jerk reaction to the historical role of models in the eyes of hardware designers.

During the discussion we explored two questions that evolved from the “cycle-accurate” statement. First, why are the cycle-accurate models needed? What analysis or decisions are going to be made based on the results of these cycle- accurate simulations? And second, what sources of cycle-accurate models exist or could be created? When will they be available? And what is the cost or pain associated with using the possible models?

I’ll start with the second point. For this organization there were historically two possible sources of a “cycle-accurate” model. One is the RTL implementation. The RTL has the benefit of being a required deliverable that was going to be created by the hardware design group as a normal part of the development process and is, by definition, 100% accurate.

There were four distinct disadvantages to this option: 1) The RTL was not available early in the process; 2) It is subject to continual change throughout the development cycle; 3) The simulation performance of the RTL severely limited the amount of software and the types of analysis that could be done, and 4) There are security and cost issues associated with distributing the RTL.

The second historical option was to create a cycle-accurate C/C++ model. This approach had been taken a number of times. The benefits were a model that could be freely distributed, the object code was reasonably secure, and the simulation performance was somewhat better than the RTL. Again there were four disadvantages: 1) The model was generally not available before the RTL; 2) It required continuing investment to track the RTL; 3) It was an expensive additional cost to develop, and 4) While it was faster than the RTL it still wasn’t fast enough for much of the desired software execution and analysis.

Now going back to the first question, why are the models needed, there were two main drivers. First to support software development, this use case involved the largest number of end users. Second to prove the value of the device through performance analysis of the models potential impact in their customers’ applications, this case did not involve as many users but drove tremendous value through using the model to win sockets.

For the software development user, there was no need to have a cycle -accurate model. A fast functional model would provide the best simulation performance, which was the primary need of the software developers. The second use case, performance analysis, could be addressed with the cycle-accurate models, but after further discussion it was acknowledged that the cycle-accurate models had two many disadvantages to be effective in achieving the ultimate goal of winning the socket. Some compromise was needed to balance the simulation performance with the timing and power accuracy. In the end we came to the conclusion that a cycle-approximate model which was about 90% accurate would provide the confidence needed in their customers to “win the socket.”

For their use cases, and I believe for many potential users, the TLM2.0 approach of creating a loosely timed (LT) model for the software developers and an approximately timed (AT) model for use in the performance analysis case would allow the user to select the optimal trade-offs between simulation performance and accuracy to meet their specific needs.

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