ARM Models: Carbon Inside

ARM used to build their own models. By hand. They had an instruction-set simulator (ISS) called ARMulator that was largely intended for software development, and cycle-accurate models that were intended to run within digital simulators for development of the hardware of ARM-based systems.

There were two problems with this approach. Firstly, ARMulator was built using interpretive technology and consumed approximately 1000 host instructions to simulate each ARM instruction so ran at a few MIPS. Modern virtual platform models use Just-In-Time (JIT) compilation, cross-compiling the ARM code into host instructions and so avoiding any interpreter overhead (the compiler creates overhead but that is minimal for instruction sequences executed many times). They thus run hundreds of times faster, fast enough to boot operating systems and debug industrial-sized loads of embedded software.

ARMulator was reasonably cheap to maintain since it simulated the instruction set which didn’t change much, apart from its half-hearted attempt at cycle-counting. The same could not be said for the cycle accurate models. These were expensive to develop and had to be re-implemented for each separate ARM processor. Verification, in particular, was a huge challenge. It is comparatively easy to get the basic model to work, but handling all the corner cases (pipeline interlock, delayed writeback, branch prediction, bus contention etc) is a real challenge.

In 2004, ARM acquired Axys Design in an attempt to leverage their models more as true virtual platforms. They renamed it SoC Designer. At the time I was working for VaST (so competing with Axys) and predicted that this would fail. And it was nothing to do with the technology, which was perfectly fine.

I had watched at VLSI Technology as customers balked at using our design tools since they didn’t want to get locked into VLSI-only solutions and I felt ARM customers wouldn’t want to get locked into ARM-only solutions. If you were using, say, a CEVA (then still DSP Group I think) Teak DSP then how are you going to get that into the platform. And what sort of support will you get from ARM if there are problems.

In 2008 ARM gave up, and sold SoC Designer to Carbon. This fixed the ARM-only issue since Carbon is an independent company. Further, at the same time, they gave up trying to hand-build their own cycle accurate models. Instead, Carbon used existing technology to build the models automatically from ARM’s RTL. ARM shifted their modeling focus to concentrate on their own JIT technology which they introduced as ARM Fast Models. These TLM models don’t attempt to model cycle accuracy and therefore execute much faster.

Since then Carbon has moved from being an RTL acceleration company to a true virtual platform company, with a complete set of ARM models (and later MIPS, Imagination and others) and some powerful technology for both bringing in transactional level models such as ARM’s Fast Models, where they exist, or creating models automatically from RTL where they do not. In some cases where both models exist, such as with ARM’s Cortex A processors, Carbon has even introduced dynamic swap technology to enable a virtual platform to start running with TLM models (to do the operating system boot, for example) and then switch to accurate models at a point of interest.