In the latest piece that Jim Hogan and I put together about re-aggregation of value back at the system companies I talked a little bit about Carbon.
I got two things wrong, that I’d like to correct here. The first goes back a long way to the mergers of Virtutech, VaST and CoWare when I listed the other virtual platform companies that are still independent. I omitted Carbon since I didn’t actually realize they had acquired the virtual platform technology SOCdesigner from ARM when they did the deal to take responsibility for creating and selling ARM’s cycle accurate models.
SOCdesigner was originally a product from a company called Axys, based in southern California. I believe that they had technology pretty similar to VaST at the time, but it was hard to know since they were very secretive. Despite rules against doing so they would throw us out of their presentations at DAC and ESC (so we sent over our finance person to see what she could find out…but they even spotted her). ARM acquired Axys, which I never understood the reason for. Even ARM- based designs typically involve lots of models not from ARM, so it never seemed likely that ARM would be able to make SOCdesigner a successful standalone business, it seemed like a business for someone independent of the processor companies. After all, you can’t imagine MIPS putting much effort in to make their models run cleanly in SOCdesigner. At VaST we considered it less of a threat post-acquisition than before.
Anyway, Carbon got SOCdesigner (still called SOCdesigner) and used their own technology for turning RTL into fast C-based cycle accurate models to solve another problem ARM had, namely the cost of creating, maintaining and distributing cycle-accurate models. ARM had always had fast models of their processors and many peripherals, since that is what software developers required, and these are relatively cheap to produce (they only need to be functionally accurate so there are many corners that can be cut, for instance it is not usually necessary to model the cache or branch prediction since the only difference is the number of cycles used).
The second error was that I didn’t really realize that in the Carbon world there are now 3 speeds of models. RTL, cycle-accurate models, and fast models.
RTL models aren’t really in the Carbon world, actually. But cycle-accurate models are automatically generated from the RTL which means that they are correct by construction. These models are not fast enough for software development, and in fact it is impossible to create models that are fast enough for software development and simultaneously accurate enough for SoC development. However, given their RTL provenance they tie the software and the SoC design together accurately, which is really important because increasingly it is only possible to validate the software against the hardware and vice versa.
Fast models usually either come from the vendor of the processor or IP, or are created by the end-user. Processor models are not actually models in the usual sense of the word, they are actually just-in-time (JIT) compilers under the hood, converting instruction sequences from ARM, MIPS or whatever instructions into x86 instructions that run a full native speed. Fast peripheral models again are created by cutting lots of corners, but this is not something that can be done automatically since it is not clear (and often depends on the use to which the model will be put) which corners can be cut.
The remaining piece of the puzzle is the capability for the virtual platform to switch from fast models to cycle-accurate models. Boot up the system until it gets interesting (or perhaps just before to give the cycle-accurate models a bit of runway), then suck out all the state information from the fast models and inject into the cycle-accurate models. This gives the best of both worlds, fast models when you don’t care about the details of what is going on in the hardware, and complete accuracy when you do, either because you are responsible for verifying the hardware or debugging low-level software that interacts intimately with the hardware.