This is close to the 20th birthday of Simics as a commercial product, and in this blog post we take a look back at what happened before Simics went commercial. The product was officially launched in late June 1998. At that point, the code had been in development for seven years already as part of a research project at the
Swedish Institute of Computer Science (SICS). The first lines of code go back to 1991, and I asked Bengt Werner who was part of the original project that ended up developing Simics some questions about just what the plan was, originally, and how things developed from there.
 Bengt Werner, screen capture from the Youtube video of his presentation at the SICS Multicore Day in 2015. |
JE: How did you get involved with Simics?
BW: I came to SICS in 1992, with a Master’s Degree in Computer Engineering from Lund Institute of Technology (LTH) and after working three years at an Ericsson R&D company. SICS was doing research on massively parallel computer systems and they had come up with this idea called COMA (cache-only memory architecture). I got the task to build a prototype of it. At one of the other desks, Peter Magnusson was working on a simulator that could simulate a multiprocessor. It would later get the name Simics.
JE: What was the research project about?
BW:
COMA was about making a massively parallel computer efficient, essentially by making sure caches worked even if scaling the number of processors up to thousands of nodes. It included questions ranging from how to design processor caches to how software like operating systems (OS) and applications would be affected. The architecture considered was radically different and design space to explore was huge. Simulation was the only reasonable way to get answers to the questions.
JE: So that’s how Simics came into the picture I guess?
BW:
Modeling and simulation was an important part of my education and I was surprised how little this was used in industry. At SICS, it was a given. To study cache effects, a solution had been developed that traced applications, but that excluded studying the effect of how the OS scheduled the applications and all code executed in the OS. So we wanted a multiprocessor simulator that would include running OS code. Building such a simulator was a research topic in itself and soon started looking for other users.
JE: What users did you find, and what did they want?
BW:
Although we pitched Simics as a cache analysis tool in our research collaboration with industry, it was soon discovered that this kind of a tool is a great help when developing software, in particular parts that interfaced hardware. However, a company could not be dependent on a tool being developed and maintained by a group at a research institute. This was a driving factor behind forming a company behind Simics in 1998.
Source: Peter Magnusson, Magnus Christensson, Jesper Eskilson, Daniel Forsgren, Gustav Hållberg, Johan Högberg, Fredrik Larsson, Andreas Moestedt, and Bengt Werner: “Simics: A full system simulation platform”, IEEE Computer 35(2), February 2002.
In this picture from 2002, you can see how we had worked on the messaging that a tool as Simics will reduce the development time. Testing can start earlier as you can run on the simulator. Testing is easier as the simulator makes control and instrumentation much easier. The interface between hardware and software becomes better defined and thereby reducing the number of bugs introduced.
I remember a surprised engineer at one of the companies we worked with, saying that they had never before had such high quality hardware specs as when they started to use Simics. This was an effect of Simics engineers asking detailed questions about the specs when they built models of the hardware.
JE: We used that picture in various variants quite a bit in the early Simics marketing materials – and it is still describes much of what we do at Intel today. It is a pretty prescient pitch (even if functional simulation existed and had been used to rescue projects before Simics).
What other projects existed at the time, and what were their pitch like?
BW:
Note that we are back at SICS days, pre 1998, so “at the time” is not 2002.
When simulation itself became the research topic, the focus changed. It was a lot about the speed of the simulator but also generality and simulator features. We were comparing ourselves to other simulator projects, quoting speeds of various benchmarks and what software was run. One of the projects that was close to Simics was SimOS from Stanford University. Both were so called full-system simulators, capable of running operating system and driver code, not only applications. When the article “SimICS/sun4m, a virtual workstation” was published in 1998, we managed to be the first group to publish that the simulator had booted an unmodified commercial operating system.
JE: See the previous blog post called “Running Large Software on Wind River® Simics® Virtual Platforms, Then and Now” for more on the 1998 achievement!
It is worth noting the name of the simulator as written in title of the paper: it is “SimICS”, capitalizing the last three letters. This was the original name, as a play on “Simulator from SICS”. When Simics went commercial and cut the ties to SICS, the product was named Simics as a normal word.
Changing the topic a bit… when I joined Virtutech myself in 2002, I think I started out using Simics 1.2 with Simics 1.4 and 1.6 coming quickly after. Digging back in the early history for this series of blog posts, I discovered that getting to 1.0 took quite a while… why?
BW:
The ambition of Simics has always been very high. One effect of this was that we wanted the 1.0 version of Simics to be complete. That included a long list of features that were not implemented in 1998. Instead we released customer specific packages and launched several beta program before Simics 1.0 finally saw the light of day in 2001.
JE: What were some of the more important early features?
BW:
Speed was probably the most important feature. Users would never had accepted waiting for days, not even hours to boot their OS but Simics performance was sufficient to avoid this. Speed also increased the pace we develop models as lots of test-runs are needed.
There are several other features that are almost unavoidable. A command line to interact with the simulator, a programming interface to scale and automate the interaction, and a structure to easily add new models, were three that Simics started working on early.
Determinism was important both for our customers, who could reproduce problems easier, and for us because it reduced our debugging and testing efforts. Checkpointing is another interesting feature that has served both us and the customer. The customer could avoid re-running identical parts of a simulation. Internally, it forced us to define what the essential state of the model was.
More abstractly, you could say that a very important early feature was a short distance between our engineers and the users of Simics, making sure that we focused on developing what was needed.
Another perspective
Some additional observations on the early days of Simics was provided by Peter Magnusson in the foreword that he wrote for the
Intel Technology Journal special issue on Simics that we released in 2013 (download the full text
here). Peter was the driving founder behind Virtutech, and was originally hired into SICS to write the simulator that was to become Simics.