Carbon has Six Weeks of ARM, not to Mention Imagination and MIPS

As George E.P. Box said, “essentially all models are wrong but some are useful.” That is certainly the case with Carbon’s models. For processors they have two models, one that is fast (but not timing-accurate) and one that is accurate (but not fast). But both are useful.

Carbon attended the ARM TechCon in Santa Clara a couple of weeks ago, as I did myself. I wasn’t able to make it to their presentation which was about how you can have both high performance and cycle accuracy. The challenge is how to deliver this. Historically the approach was to compromise a bit, give up a bit of accuracy and a bit of speed. But this often ends up with a model that satisfies nobody. It is too slow for the software developers to run full software loads (like booting Android) and it is not accurate enough for the hardware developers who need to be able to examine every signal transition to zoom in on the root cause of a bug.

The Carbon approach is different. It uses two models, one that is fast and one that is accurate. The fast model has just enough detail to be able to run software binaries unchanged (for example running ARM code even though the server is x86). The more detail that can be lost, the faster the model will run. For ARM processors, the fast models come from ARM and are the ones they use internally.

The accurate model is constructed automatically from the RTL for the processor so that it is completely accurate. However, detail can’t be thrown away fast enough to end up with a model that has good enough performance that the fast model can be discarded. Again, for ARM processors, the models are generated from ARM’s code using Carbon’s technology and then made available through the IP Exchange portal.

The trick is making it possible to switch from one model to the other. Well, actually only from the fast model to the accurate one. So, for example, to develop a device driver, the operating system is booted using the fast model and the system is brought up. Then the switch is made to the timing-accurate model and the device driver can be stepped through in detail. Or perhaps the fast model continues to be used until a known problem point with the device driver where the user can zoom in and see exactly what is happening. Problems on the edge of hardware/software such as device drivers are some of the hardest to debug since neither software tools (debuggers, breakpoints etc) nor hardware approaches (dumping signal traces) is enough on its own.

For more details see Bill’s blog on his ARM presentation here.

Carbon will also participate during November in ARM’s Technical Symposia Program throughout Asia:

• Seoul, Korea November 20
• Taipei, Taiwan November 22
• Hsinchu, Taiwan November 23
• Shanghai, China November 26
• Beijing, China, November 28
• Shenzhen, China November 30
• Tokyo, Japan, December 6
• And finally that famous Asian city, Paris France December 13.

One topic that will probably not get talked about at the ARM Symposia is Imagination’s acquisition of MIPS. Presumably one outcome that is likely is that there may be more designs done involving MIPS CPUs with Imagination GPUs. But Carbon is ready since they already have model partnerships with both companies and their models are made available on the IP exchange portal. And for a complex system, that might involve multi-core CPUs and multi-core GPUs, virtual prototypes are the perfect approach for software bringup.