What is required is the ability to first explore different architectural tradeoffs associated with a new system — which requires the capability to run real software workloads — and then the ability to commence software development well in advance of any actual hardware becoming available.

Conventional solutions

Traditional instruction state simulator (ISS) products typically run at around a few Megahertz equivalent clock speeds. This may be sufficient to debug the hardware, but it falls far short of being able to test the operating system and support applications development. One common approach is to develop the hardware first — at least to the stage of having an FPGA-based emulation prototype. But this can be a very expensive option, and it means that software development can't commence in earnest until a long way into the system's design cycle.

And the problem usually isn't limited to simply verifying a new system in isolation. Most systems need to communicate with a complex environment, which means that they need to be tested in the context of that environment. For example, many of us would smile knowingly if we were to be presented with a systems development and test environment as illustrated in figure below.

Even though this sample environment may seem horrendously complicated to someone unused to working in the trenches, the engineers actually using it may not regard it as being particularly problematic. The problem is that the folks who are paying for it may take a very different view.

This type of solution is ferociously expensive — some companies spend hundreds of millions of dollars a year on this sort of setup — and things get really scary if you need to replicate such an environment at multiple locations. Also, if you do have multiple instantiations of such a monster, the problems of keeping them in sync such that everyone is working with exactly the same configuration should not be understated or underrated.

Full system simulation

And thus we come to the state-of-the-art in full system simulation, which stretches my imagination almost to its breaking point. For example, I was recently chatting to the guys and gals from Virtutech about their Simics full system simulator.

Originally developed in Sweden at the Swedish Institute of Computer Science, Simics can be used to create virtual systems range from simple, single, embedded processors to complex full-scale networked multiprocessor high-end client-server configurations. These virtual full-scale systems run unmodified binary executables from boot PROM to operating system to applications.

In some respects Simics is an ISS, but it's certainly not your mother's ISS! As opposed to simulating a system at a few Megahertz clock equivalent, Simics can run a simulation of a PowerPC-based system, for example, at over 1 billion instructions per second, which is orders of magnitude faster than a traditional ISS.

The trick is that most solutions in this space are geared toward hardware-software co-design and co-verification. This requires a conventional ISS that is running software at a sufficiently fine-grained level for design engineers to be able to debug their hardware. By comparison, Simics supports multiple levels of abstraction, including an ultra-high-level that essential omits any instructions that are "boring", such as idle loops or polling registers to see when bit changes (Simics already knows when those bits change).

This full system simulation offers tremendous configuration flexibility, full system visibility, highly accurate control — and it's FAST! First of all I saw a Simics simulation of the Windows XP operating system running on a virtual computer that was itself running on an IBM ThinkPad T40 notebook with 500MB of RAM. Just to see something happening, we brought up the Windows Clock display, which was actually running ten times faster than real-time (although we could have slowed the simulation down and synchronized to real time had we so desired).

Then we closed this simulation and brought up a new environment — still on the IBM ThinkPad — featuring a 64-bit Sun Solaris system with 8GB of RAM (even though we only had 500MB of physical RAM. This simulation allowed us to perform typical UNIX-level commands in real time.

Simics supports a range of processors, including those from AMD, Intel, and Sun, along with controllers for memory, interrupts, PCI, SCSI, Ethernet and also virtual peripheral devices like hard discs and so forth. At the April 2004 Embedded Systems conference in San Francisco, Virtutech demonstrated a simulation environment of 1,000 PowerPC boards communicating via Ethernet. This entire simulation was running on five physical computers each with two physical processors. Once again, the simulation was fast enough to be able to perform interactive commands in real-time.

As we previously noted a Simics simulation can run unmodified binary executables from boot PROM to operating system to applications. In the case of a Solaris simulation environment — which could be running on a PC or Linux host — for example, you can take an application on a CD and install and run it just as you would normally do on a real system. Alternatively, you could copy off the real CD on to a simulated disk and then boot off that disk. The trick to its incredible speed is that Simics is just accurate enough that the software can't tell the difference.

Of course, the "nitty-gritty" question is "how much is it"? Well, Virtutech points out that there's typically a large service component involved to create the initial model/environment, and that say that a "typical engagement could cost anywhere between $100K to $250K", but compared to the cost of establishing a hardware-based development and test environment, the Virtutech approach would be "cheap at twice the price" as the old saying goes.

And the stop-press-news as I pen these words is that Virtutech and Carbon Design Systems are partnering to offer a mixed Simics-DesignPlayer solution. As you may recall from my January 05, 2004 column entitled "RTL models fly at KHz speeds", Carbon's DesignPlayer allows you to take the Verilog and/or VHDL RTL associated with your design and generate a linkable or executable object that: