Jakob Engblom

Serving Windows Files from a Simics Quick-Start Platform

Windows file sharing has always felt a bit magical to me. I use it all the time, certainly, but I never quite understood how it worked; it was just this big chunk of Microsoft protocol that felt like it really did not want to talk to other types of operating systems. Sure, I have used the open-source "samba" server for a long time with great success… but it always seemed to suffer from issues with access rights (probably the fault of me and server setup and mixing Unix and Windows accounts, not a fault in the server itself).

With this background, I was really delighted and surprised when I managed to almost effortlessly get a Simics target to share and serve files to my Windows host. A big-endian Power Architecture QSP target at that, running VxWorks, how cool isn’t that? The key to the puzzle was the Visuality NQ Server  from Visuality Systems Ltd. in Israel. It just worked, and let me try some interesting and educational setups.

Debug Quicker with Simics (video)

Late last year, I presented a one-hour webinar on how Simics lets you “resolve bugs in minutes instead of weeks.” Part of that webinar were two Simics demos that show Simics in action, from the first booting of a target system through loading software onto it and debugging a nasty crash in a server program. The webinar demos are now available as a single Youtube movie, on the Wind River Youtube channel.

Debugging Simics - on Simics

I often write and talk about how useful Simics is for debugging concurrency bugs and glitches in multithreaded and multicore systems. Recently, we had a case where we proved this on a very complex application, namely Simics itself. This nicely demonstrated both the recursive completeness of Simics, and its usefulness for conquering tricky bugs in complex software.

Determinism, Simics, and Flying Piggies

In a recent Simics seminar, I was asked about repeatability, variability, determinism and Simics. This is a question that comes up almost every time I present about Simics in front of an audience with testing experience. The people asking the question intuitively think that determinism is a bad thing - since it sounds like it will limit the execution scenarios that will be explored in testing. For a tester, variation is a good thing. However, determinism is not in conflict with variation. And I think I found a perfect illustration of this in a setting that is a bit more accessible and easy to understand than computer simulators. In a computer game, Bad Piggies, from Rovio.  

Systematically Exposing OS Kernel Races – An Interview with Ben Blum

Full-system simulators like Simics provide unparalleled insight into what is going on in a target system. Indeed, better insight is one of the main features of simulation that we get regardless of what we simulate and how. In addition, if we want to, we can also exert control over the target system to make it take different execution paths than it otherwise would. Earlier this year, Ben Blum at Carnegie-Mellon University  CMU presented a Master’s thesis that provides a very good example of just what can be achieved by combing the insight and control of a simulator with intelligence and domain knowledge. The system is called Landslide, and it is used to expose race conditions inside of operating-system kernels.

Analyzing Manycore Scaling with Simics

In my previous blog post on multicore scaling investigations with Simics, I tested a simple parallel program on a variety of machines. The scaling obtained was not particularly impressive, especially not on a 60-core target machine. In this post, we will use the Simics timeline view to look a bit closer at what is going on inside the target machines. In particular, with respect to operating system scheduling of the target threads. 

Testing Manycore Scaling with Simics

A few years ago, I did a Simics demo where I tested the scalability of a multithreaded program as the target hardware went from two to four to eight cores. Unfortunately, I could not take it beyond that point, since the hardware platform that I used simply did not allow for more than eight cores. Now, with the Simics Quick Start Platforms (QSP), the situation is different. I picked up the demo again, and pushed it to sixty (60) cores with ease.

Inside a Synthetic Simulation Platform

Recently, we introduced a synthetic simulation-only Simics target machine called QSP (Quick-Start Platform) and it's included in the latest version of Wind River Simics. The idea of QSP is to give every user a useful Simics target that allows them to immediately start using Simics and begin reaping the benefits of simulation for software development. In this blog post, we'll be taking a look under the hood of QSP to see how it works.

You Will be Simulated - A Bit Quicker

We just released a new Simics feature, the QSP (Quick-Start Platform). This is a synthetic simulation-only Simics target machine that is included with the Simics base product. QSP provides every user with a useful Simics target that allows you to immediately start using Simics and reap the benefits of simulation for software development, without waiting for a target model to be ready. It provides a quick way to realize our old Simics slogan: "Resistance is Futile, you will be Simulated."

With QSP, we provide a shortcut by offering a ready-to-use integration of a model and target software stack that can be used to do application-level development from the moment a user receives Simics. QSP also makes simulation features like checkpointing, reverse execution, unintrusive debug, repeatability, automation, and scripting easily available for application developers without having to first setup an OS and select a target machine.

Teaching Networking using Simics

Wind River Education Services provides user training for a variety of topics, including Wind River operating systems and tools, as well as more general topics like networking. Training always includes hands-on labs, which can complicate logistics for training sessions. Shipping boards and configuring networks is time-consuming and error-prone. For that reason, we are looking into using Simics as an alternative to physical hardware to streamline training logistics. It also makes it simple to encapsulate configurations, while maintaining the reality of cross-development. In this blog post, we will look at how Simics is used as a tool to facilitate network labs in the context of education.

Forcing Rare Bugs to Appear - an Interview with Tingting Yu

One use of Simics that has always been fascinating is to use the power you have over the target to somehow force error conditions in software. The hardware state control inherent in a tool like Simics should be useful to knock a system off of the expected common path and into code less tested, and to reveal bugs that normally only appear in particular rare circumstances.  Recently, there was a paper published that discussed exactly such an application of Simics.  In this blog post, I will be interviewing Tingting Yu from the University of Nebraska at Lincoln (UNL) about her paper.

Happy 30, 80186 (and 0b100000, 8051)

As mentioned in past blog posts on Simics, maintaining old software and developing new software for older hardware is a not-too-uncommon use case for Simics. Case in point: we recently added a couple of new target processors to the Simics model library that most people would probably consider "surprisingly old" hardware. For a long-time embedded programmer like myself, it just feels like going back to the roots.

Getting Code Coverage with LDRA Tools on Simics

A system development tool like Simics is rarely used completely on its own. Simics is usually brought in by companies and development teams who are already using a variety of tools and expect to keep doing so along with Simics. Also, Simics by itself cannot reasonably be expected to solve all problems for all people. Instead, we need to connect Simics with outside tools to provide an integrated solution.

In this blog post, Jay Thomas of LDRA and I will discuss one concrete example of such a tool integration. In particular, how Simics can be used together with the code coverage and certification tools from LDRA to perform code analysis on safety-critical software in a way that is more efficient than with most hardware platforms.

Crystal Forest on Simics

A few week ago, Intel announced the Crystal Forest platform, a new IA-based platform for networking and communications applications. The first Crystal Forest hardware is appearing now, but we have been working with Crystal Forest on Simics for more than a year already. 

While we cannot yet talk about the details of the hardware (and in any case, that is really Intel's job, not ours), it is a pretty complex piece of silicon.  Crystal Forest is based around Sandy Bridge processors and features hardware acceleration for network and security tasks.  It features multicore 64-bit processors with virtualization and the latest iteration of the IA instruction set.  All of this is faithfully modeled in Simics.

Making a Faulty Serial Port

As noted before, one common use case for Simics is doing fault injection.  Fault injection is typically added to an existing system without changing it, since the goal is to maintain a fundamentally fast simulator when not injecting faults.  There are a range of mechanisms available in Simics to implement fault injection. This blog post will take a look at two such mechanisms and how they are used in the context of injecting faults on a serial port.

Simics for Networked Systems: An Interview with Dan Poirot

Networked systems is one of the primary application areas for Simics. Simics can run many machines inside a single Simics simulation, and apply all Simics features to the system, not just to a single machine inside the system. This is something that Dan Poirot from Real-Time Innovations, RTI, has made quite extensive use of recently. It is a pretty cool use-case for Simics, so we arranged to interview Dan about his use of Simics.

 

Why Simics won't Run Super Mario

Emulating old computer gaming systems is a popular consumer-market application of simulation technology similar to Wind River Simics. There are a large number of emulators out there, emulating everything from old arcade games to the home computers of the 1980's to gaming consoles.  These emulators might seem quite similar to Simics on the surface, but in practice, the simulation technology employed is quite different.  You will never see Simics simulate an old Super NES running Super Mario Bros. 

It all comes down to the level of timing accuracy required.

Stop, Think, and Tie Your Shoes Right

I was sent a link to a past TED talk about how to tie your shoes. It is worth watching, and from the discussions I have seen on Facebook around the video, it seems that most people do it the "wrong" way.  I have actually started to try to do it the "right" way, and the result is real improvement. 

Tying the "right" way does make the bands look better. However, it did require a little bit of practice and a conscious effort to change. 

Shoe tying is admittedly somewhat away from embedded systems development, but the principle  is general.  Doing things in a better way requires three things: understanding that there is an issue with how things are done today (bad knots), knowledge of a better way of doing it (good knots), and the time and effort to change your habits (dedication).

Surfing the Web with Netscape 4

While looking into our old SPARC server targets for our new SPARC legacy offering, I  opened up a Simics demo checkpoint that we have had around for a long time (at least eight years). This demo is an UltraSPARC II running Solaris 9, and it shows how web browsers looked around 2001.  I used real-network to connect the machine to the Internet, and tried the default webbrowser - Netscape 4.78, built in June of 2001.

A Virtual Year

A while after I woke up my laptop today, I realized that the fan was pretty noisy. That typically indicates that the processor is working busy on something, and then I spotted Simics in the task bar. Checking in on that Simics showed that it was indeed running, and pausing it did lower the load on machine to the point that the fans calmed down. Turned out that while I was doing other things, Simics had been busily simulating away on one of my cores. Indeed, it had simulated what was almost a complete year.

How to Get Virtual

My blog posts about Simics tend to focus on how virtual platforms are used and what you can do with them. However, underlying all Simics use is the issue of getting a virtual platform in place. You need some kind of platform to run your software on in order to get the full benefit of Simics. Thus, creating virtual platforms is an important part of practical Simics use for many of our users.

We have been working with Simics for more than a decade, and we have learnt a lot about modeling along the way. The approach we have ended up with is a top-down methodology, where we start by investigating the target system as a whole from the perspective of the intended use cases, and then explore the details of each subsystem in order to determine how best to model it.  We then switch to bottom-up, applying an iterative modeling flow that delivers something useful as quickly as possible. During development, the goal is to always keep a useful (albeit probably incomplete) platform available at all times.

Software at the Toddler Stage

Developing software is an adventure where you explore the unknown, one line of code at a time.  At some point, the program reaches the stage where you can actually run it and try it - and that's where the real fun begins.  The software will sometimes behave as expected, but more often than not it will not. It will do something else, or crash, or generally do the wrong thing.  It is very much like a toddler - you can rely on it to some extent, but you never know when it will decide to do something unexpected, funny, or just throw a fit over something that would have seemed inconsequential.

Simics 4.6 Initial Impressions

Simics 4.6 is now out, and I would like to share some of my initial impressions of the new Simics version.

Teaching Operating Systems with Simics: An Interview with Massimo Violante

 

Wind River Simics has been used in teaching for as long as I have been aware of Simics. Indeed, my first contact with Simics was when it was used in a graduate computer architecture course at Uppsala University in Sweden. In that course, we modeled cache hierarchies and replacement strategies with Simics and measured the performance results. A few years later, I was part of a team that created a project course based on Simics where students got to write their own operating system from scratch. Using Simics in teaching is an ongoing interest of mine, and that's why I am very happy to present another interview with a Simics user. This time, it  is Professor Massimo Violante and the Politecnico di Torino in Italy, who is using Simics to teach operating systems.

Twenty, Thirty, and Sixty Years Ago

In 2011, we mark several anniversaries here at Wind River and in the world of virtual platforms.  First of all, it is 30 years since Wind River was founded, in 1981.  Ten years later, in 1991, the first code of what would become Simics was written by Peter S Magnusson at the Swedish Institute of Computer Science.  Thus, Simics turns 20!  2011 also marks the 60th anniversary of the instruction-set simulator and virtual platform-based debug.

Integration and Testing the Integration

The US National Highway Traffic Safety Administration (NHTSA) recently released a deep report into last year's issue with "unintended acceleration" on certain Toyota cars. They actually employed a team from NASA who analyzed the throttle control software using a wide range of cutting-edge tools. Reading their report gives a good idea for how embedded control software is developed, and the challenges inherent in validating it.

Working Faster with Less (Simulated) Sweat

One very important property of a virtual platform like Simics is its speed of execution. Without sufficient execution speed, a virtual platform is not very useful - users want to have results in reasonable time. Raw simulation speed (getting as many target instructions as possible simulated each second) is important, and Simics is certainly pretty good at that. It is not necessarily the case that the best way to get a job done faster is to process instructions faster. Sometimes, working smarter rather than harder is possible.

Being Helpful or simply Correct?

The other day, I spent some time getting a new operating system up on one of our Simics virtual platforms. The platform is stable, the hardware is shipping and it is being used with the very software I was setting up. However, as the operating system was booting, I got quite a lot of warnings from Simics about incorrect hardware settings. The operating system still worked, however, so why did we see all these warnings? Actually, when is it prudent to issue warnings to a user about suspicious uses of hardware? When building Simics models, we want them to be helpful and offer warnings as much as possible - especially for cases where some uses might be considered technically "correct" but are actually somewhat suspicious.

What I am Reading: Processor and SoC Simulation

A new book about processor and system-on-chip simulation recently appeared. Edited by Professor Rainer Leupers and Professor Olivier Temam, it features chapters from a wide spectrum of academic and industrial authors.

The chapters in the book each come from a particular company or research group. Each chapter addresses a different problem or technology, from a different perspective. This provides a good overview of the SoC simulation landscape, from processor architecture through hardware design to software development, system integration, and testing.

Iterative Hardware-Software Interface Design

Making good design decisions is hard, making bad decisions is easy. The best way to avoid really bad design is to actually work through how a certain design works in practice. One of my favorite examples is how Jeff Hawkins walked around with a mockup of the original Palm Pilot to tests its real feel through daily "use".

Sometimes, You Have to Cheat

In a virtual platform world, cheating is sometimes a good thing. One man's cheat is another man's optimization.

Debug, multicore, and more debug

I recently gave a talk at an industry-academia collaboration called ICES, Innovative Center for Embedded Systems, at KTH in Kista, Stockholm, Sweden. The theme was embedded multicore, and I realized that my role at these events seems to have changed. A few years ago, I would be the "embedded guy", defending the collective of embedded systems against speakers assuming that everything was a homogeneous shared-memory multiprocessor. This time was different, though. I have become the "debug fanatic".

The Giggle Effect

Last week, I went to Tel Aviv to present at the CDNLive event taking place there. CDNLive is Cadence's user meetings, and while still being mostly about hardware design and classic EDA, they added a small track about embedded software where I was presenting. The trip was quite a climate shock, going from Sweden where the puddles had just started to freeze at night to the coast of the mediterranean with 30+ degrees. The welcome was also warm, and I really appreciate the effort the local Cadence staff put into organizing the software track and the good discussions we had before, during, and after the event.

IMA on Simics: An Interview with Tennessee Carmel-Veilleux

After Summer, I have been in contact with Tennessee Carmel-Veilleux at the École de technologie supérieure in Quebec, who has been doing some really cool work with Simics.  Tennessee has learnt Simics very quickly, and has been very clever in how to apply Simics to the research problems he has encountered. In this interview, he tells us some more about his research and use of Simics.

The Virtual Basil Fawlty

In the 1970's BBC comedy show Fawlty Towers, John Cleese manages to turn harmless everyday situations into total disasters, with very little effort. It is a marvellous example of how to inject faults into what could have been a smoothly operating hotel, and demonstrating just how things fall apart as the unexpected happens. Injecting faults isn't always that easy, unfortunately (or should that be fortunately)?

Physical or Virtual

When you explain what a virtual platform or full-system simulation solution like Wind River Simics is, a key part is that it runs the same software as a physical board or physical system. This does capture the core of the idea - but it does not mean that the virtual platform is only "just like the real thing".

Comparing virtual and physical systems is like comparing apples and apples, not apples and oranges: while apples are mostly interchangeable, they is certainly variation between them. Some apples are best for eating, some are better for making sauce, some are pie material, and some are best for fermenting cider. The type you select depends on what you want to cook. The difference between physical and virtual hardware is similar: they can be used as replacements for each other to some extent, but the connoisseur can make much better use of both by looking at the differences.

This post goes through some of the important fundamental ways that virtual hardware is different from physical hardware. 

Virtual Trace

I spent most of last week at the S4D conference in Southampton, the UK. A small gathering of people interested in debug, it seems to be a good indicator of trends in debug. The dominant trends this year were clearly tracing and instrumentation. From the perspective of a virtual platform, tracing is a natural task, and it can be done with much less pain than on a physical platform.

Variable and Deterministic

A virtual platform like Wind River Simics is generally designed to be deterministic. Determinism brings a host of benefits to users (repeatability of bugs, reverse execution, bug transportation, etc.), but is also easily misunderstood. Quite often, users fear that they will lose an important "feature" of a physical machine - its built-in variation across runs of the same software. If the virtual platform is deterministic, surely it will not expose all the different ways a program can run that you get on a random physical machine? Yes it can.

There is a huge difference between the repeatable determinism of a virtual machine and completely invariant, predictable, predetermined behavior.

Transporting Bugs with Checkpoints

I have a paper about "Transporting Bugs with Checkpoints" to be presented at the S4D (System, Software, SoC and Silicon Debug) conference in Southampton, UK, on September 15 and 16, 2010. The core concept presented is to leverage Wind River Simics checkpointing to capture and move a bug from the bug reporter to the responsible developer. It is a fairly simple idea, but getting it to work efficiently does require that some things are done right.

Interview with Girish Venkatasubramanian

After my blog post on Academic Simics earlier this Summer, I got a very nice reply from Girish Venkatasubramanian of UFL. Turned out that he and his group was doing some really interesting and exciting stuff with Simics, researching into Hypervisor architectures and hardware support. Having been a PhD student myself, I can certainly appreciate the excitement and fun of working in that field. We ended up doing a virtual interview, which I am happy to present here.

Shiny Old Hardware

Normally when people are introduced to virtual platforms or full-system simulators like Wind River Simics, they jump at the ability to support software development before the hardware arrives. This is certainly an exciting prospect, as we all like shiny new things. What is often not as obvious is the extensive use of virtual platforms to support old, aging, and obsolete hardware.

Academic Simics

Simics has a long history of university usage. Simics grew out of research at the Swedish Institute of Computer Science (SiCS, which is part of the root of the name of Simics), and some universities started using Simics even before version 1.0 was out! When I joined the company in 2002 (it was Virtutech at the time), Simics had a strong presence in the academic sector. Today, Simics licenses are available for free to qualified academia through the Wind River University program (http://www.windriver.com/universities/). The value of a virtual platform is not been lost on the smart people working in universities across the globe, and we see a constant pull of Simics into many different application areas.

When is Scripting really Programming?

I recently updated some analysis scripts in Simics to use the new OS awareness framework in Simics 4.4. While doing so, I completely updated the structure of the code, ending up with something looking suspiciously like a regular Python program. It had declarations, classes, variables, did not rely on global variables, and was fairly robust to changes in the target. This got me thinking about the difference between "scripting" and "programming". When I was a computer science undergraduate in the 1990s, I recall the difference was very simple. Programming was done in C or other real languages (with the corresponding heated debate on whether anything except C or assembly counted), scripting was done in bash. For some reason, it does not feel that simple today.

Travelling into 64-bit Land with Simics

The new Freescale QorIQ P5020 SoC that was announced this week at the Freescale Technology Forum means that yet another chip family has now moved to 64 bits from 32 bits. This is a familiar scenario that has been played out many times before, starting in the mid-1990s as Sun, IBM and MIPS upgraded their server processor architectures to 64 bits. Before that, we had Intel extending the x86 family from 16 bits to 32 bits and IBM extending the System/360 architecture from 24 bits to 31 bits. Each time, the changed caused software pain for a while as the software is updated to work in the new world with more bits to use.  It is also something that Simics has helped with in the past.

True Concurrency is Truly Different (Again)

A recent article at Ars Technica describes yet another security flaw in Windows. Nothing much new in that respect, but this is indeed an interesting attack in that it is enabled by using multicore hardware. It is not practical on a single processor, demonstrating once again how multicore is fundamentally different from multitasking on a single processor.

Analyzer Analyzed

The big news in Simics 4.4 is the new Simics Analyzer product. Analyzer contains a few different technologies, but the most immediately visible is the new execution timeline view. The timeline view shows the execution history of the software on the target system, making it easy to see what has run where and when. In this blog post, I will try to peek a little behind the scenes to show what makes Analyzer and the timeline view work. 

What is Simics, Really?

As you might have seen, Wind River recently acquired Simics, a product formerly sold by Virtutech. My colleagues Michel Genard and Bill Graham recently blogged on the topic.

Simics can have a huge impact on the product development processes, time-to-market and quality. Apart from the cool things that Simics does to improve the development process, it is also a very interesting technology in and by itself. Since I am a technical marketing manager with a license to compile, I would like to spend some time to explain what Simics is under the hood. In my opinion, knowing how tools work is very useful to the engineer considering their adoption or tasked with using them.

Simics is a simulator - a piece of software simulating a piece of hardware. A Simics solution is often called a virtual platform, as it provides a virtual hardware platform for running software. One should note that Simics virtualizes embedded hardware in a different way than hypervisors like the Wind River Hypervisor.

A hypervisor expects operating systems to target a particular virtual machine architecture, while a Simics virtual platform is a software simulation of some concrete piece of hardware. Simics is a tool for developing software without needing hardware, and a hypervisor is a way to manage hardware at runtime. Indeed, you can run a hypervisor and its guest operating systems on top of Simics. The Wind River Hypervisor was actually developed using Simics.

The hardware that Simics has been used to simulate range from basic embedded boards with a single processor or SoC, all the way up to servers and rack-based fault-tolerant clusters. The virtual platform is sufficiently complete and correct to fool the target software into believing it is running on physical hardware, and it is fast enough to be useful for regular software development tasks. When I say "target," I mean the hardware that is being simulated.

From the perspective of the target software, Simics looks like hardware. A Simics setup will load the same binaries as would be used on a physical target system, and execute them in the same way they would execute on the physical target.  The software stack includes everything from the initial boot code to hypervisors, operating systems and user-level application code. There is no need to modify the target code to run on Simics (even though there are intriguing additional possibilities for smart workflows if you are willing to modify the code some).

Simics is a pure software program. It does not require any special hardware, FPGA boards, or "emulators" to function. Simics runs on any PC, anywhere, at any time (at least as long as the PC in question runs Windows or Linux). You can ship a Simics setup literally in an e-mail across the globe. In this way, it can replace hardware boards for global development teams in a fairly magical way.

Inside a Simics Simulation

So what does it actually contain and do?  One large part of a running Simics simulation is the simulation of the target hardware. This contains models of processor cores, buses and other interconnects, memories, peripheral devices, and networks.

A core component of Simics is its fast instruction-set simulators (ISS) which are used to execute the ARM, DSP, MIPS, Power Architecture, SPARC, x86/IA, or other processors' binary code. However, just an ISS does not let you run an operating system. Simics setups therefore also include simulation models for memory-management units (MMU), as well as all the memories and devices found in the memory maps of the processors.

Let's look at a common case, a processor doing a memory operation. When a processor issues a memory load or store, the address to access is first translated through the MMU, resulting in a physical address. This physical address is used to construct a memory transaction in Simics.

The memory transaction is sent to a memory map, which determines what part of the target system the transaction is targeting. If the transaction hits memory, the contents of the memory is read or modified.

If the transaction hits a peripheral device, the simulation model for that device is called to determine the effects of the access. The device model will work out the effects of the access. It might start a timer, send an interrupt to a different processor in the system, reconfigure the hardware, reset a board, send a packet onto a network, drive an IO pin high, or any other effect on the target system.  If the transaction does not hit anything, the simulated process could get an exception back to report the bus error to the software.

Looking at how Simics works as a software program on the host PC, all of this happens as a chain of function calls between the objects making up the simulation model.   Everything in a Simics simulation is an object, using function calls to communicate both transactions related to the target system (like memory operations) and for internal, maintenance, logging, tracing, and other operations. In the hardware design community, this style of simulator modeling is known as TLM, or transaction-level modeling. The essence of TLM is to use move data around in units of transactions, not of clocks or pins or other low-level hardware concepts.

Unlike any other virtual platform solution, Simics can add new objects to a simulation at any point in time. It is also possible to reconfigure how the objects are connected, and modify their properties at run-time.

This dynamic configuration makes it possible to simulate anything that can happen in the physical hardware system, including operations like adding and removing boards from a rack or changing how network cables connect boards together.

To support dynamic change, all Simics objects are created from classes loaded at run-time. Every Simics model is stored in its own .dll or .so file, and can be loaded at any time. A user does not need to recompile anything to create a new configuration, just load the required modules during a Simics run. Simics is actually fairly similar to the Java and .net environments, in terms of how objects are compiled, loaded, managed and connected.  It is not like the static linking model employed in simple C and C++ programs.

One particular advantage of the Simics approach is that each simulation module can be compiled separately, making it very cheap to recompile after a change to the simulated target system.

Modules for Simics can be created in C, C++, Python, or the Simics device modeling language DML. DML is really a C-code generator that automates the creation of much of the boilerplate code needed to build a device model. Other languages can also be used, as long as they can link to C-language modules.

To manage the complexity of the modeled hardware, Simics allows a virtual platform creator to use a special kind of object known as a component to create logical groupings of hardware units. Components group devices, memories, interconnects, and processor cores together into logical units corresponding to chips, SoCs, ASICs, boards, mezzanine cards, racks, and other hardware units. Components can be reused and arbitrarily nested, modeling any form of hardware design hierarchy. By traversing the component hierarchy, it is easy to understand the structure of the (virtual) hardware system.

What can be modeled?

Essentially, Simics can model any system. Multiple processors, boards, networks, and heterogeneous computer architectures and target operating systems pose no problem. The largest setups used by our customers have included up to a thousand processors. The longest simulations have covered many months of target time. The most heterogeneous simulations include tens of different types of processors from several different families.  Multi-core, single-core, symmetric shared memory, asymmetric multiprocessing, 8-bit or 64-bit, Simics have been used to simulate it all.

Adding models of new targets can be done by Wind River, a Simics user, or third-party consultants.  There is no hidden magic; any Simics user can extend the library of hardware models available in Simics with whatever components they need. You do need to buy the Model Builder product in addition to the basic Simics product to build new target models.

Input and Output

To provide input to the simulated system, Simics provides interactive sessions to the target serial consoles and graphical displays. It is also possible to connect simulated serial connections and Ethernet networks to physical networks, to get the real world involved.  The most common model is to keep target I/O automated and reproducible using scripts and various forms of traffic generators. If you count changes to the target software as input, the loading of newly compiled target system binaries to simulated memories and disks is a major form of input which Simics performs directly, without involving the target software. This paragraph is not exhaustive, there are many other (usually domain-specific) ways to produce stimuli for Simics targets.

Simics also has a user-interface side comprising a scriptable command-line, Python-language scripting, a simple GUI, an Eclipse GUI, and connections to debuggers like Wind River Workbench over protocols such as WDB and gdb-serial. These interfaces let users manipulate the target system and debug software running on it, without the target software being disturbed.

Extensibility

Everything in Simics is an object, including the user-interface components, debugger connections, and even the command-line interface itself. All Simics objects are able to use the Simics API and function calls into other objects to do pretty much anything.  This generality makes Simics very flexible and very easy to extend to support new workflows and new customer use cases.

Any Simics user (with the appropriate Simics products) can extend the functionality of the simulator with custom extensions such as specialized trace modules, fault-injection frameworks, connections to their favorite obscure debugger, remote control frameworks, or even custom graphical user interfaces.

Further Reading

This blog post, long as it is, can only scratch the surface of what Simics can do and how it works.  With this orientation, you should be able to go on and read the white papers available on particular aspects of Simics.

There is a also an ESC 2008 class I taught on simulation of embedded systems which provides a deeper conceptual introduction to the matter of simulation.