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.
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.
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.
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.
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.
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.
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.
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.
Jakob Engblom is Technical Marketing Manager for the Simics product line at Wind River. He came to Wind River with the Virtutech acquisition in March 2010, and has been working with Simics since 2002. As technical marketing manager, he works with the what and how of Simics usage, including actually writing real code.
The postings on this site are the views of the individual poster and do not represent Wind River's positions, strategies or opinions. Please review the Wind River Blogging Guidelines. We may be reached via email at blogs@windriver.com.
Jakob Engblom is Technical Marketing Manager for the Simics product line at Wind River. He came to Wind River with the Virtutech acquisition in March 2010, and has been working with Simics since 2002. As technical marketing manager, he works with the what and how of Simics usage, including actually writing real code.
Subscribe to RSS feed.
