During my vacation, a blog post went up on the Wind River blog with an interview with Hyungmin Cho, a researcher at Stanford. Hyungmin has done some seriously heavy and cool work with Simics, using it together with a circuit-level simulator to investigate error resiliency in hardware devices, and how errors propagate from hardware into the software. As part of this process, he has setup an automated test system using Simics, and this system has done more than a million automated Simics runs. That is an insane number – I have been using Simics for twelve years now, and if I had used it every day for all these years, I would have had to start 10 runs per hour, every hour of the day. It shows the power of automation along with parallel runs on clusters of machines – once the setup is automated, you can pour on the volume.
The September 2013 issue of the Intel Technology Journal (which actually arrived in December) is all about Simics. Daniel Aarno of Intel and I served as the content architects for the issue, which meant that we managed to contributed articles from various sources, and wrote an introductory article about Simics and its usage in general. It has taken a while to get this journal issue out, and now that it is done it feels just great! I am very happy about the quality of all the ten contributed articles, and reading the final versions of them actually taught me some new things you could do with Simics! I already wrote about the issue in a Wind River blog post, so in this my personal blog I want to be a little bit more, well, personal.
As an old embedded systems and real-time guy, I have always worked with computer systems that are in some way tied to their environment. Simics has often been used to model such computer systems, inside of customer organizations. Which makes it a bit hard to show… however, recently I have cooked up a demo showing Simics simulating a computer system alongside a physical system.
I just put out a post on the Wind River blog, pointing to both a video of my own “water heater” demo and some other Youtube videos showing Simics integrated with simulations of the real world. A screenshot of my setup in action is shown on the side of this post.
Simics can run and debug UEFI BIOSes, and that is the topic of my latest blog at Wind River. UEFI is actually pretty interesting once you get to know it, and building a good debug experience for UEFI took a bit of work. Still, it was built as just another target for the standard uniform Simics debugger, which is not the way most other UEFI and BIOS debuggers are built. I guess in that in the past, debugging a BIOS required such specialized tools that it made sense to also build a custom specialized frontend for the purpose. With a simulator as the backend, things do become simpler and more uniform, and Eclipse CDT is a actually a very good basis for a debugger for any kind of C and C++ code.
For more reading on UEFI itself, I can recommend the 2011 Intel Tech Journal on the topic.
I have a silly demo program that I have been using for a few years to demonstrate the Simics Analyzer ability to track software programs as they are executing and plot which threads run where and when. This demo involves using that plot window to virtually draw text, in a way akin to how I used to make my old ZX Spectrum “draw” things in the border. But when I brought it up in a new setting it failed to run properly and actually starting hanging on me. Strange, but also quite funny when I realized that I had originally foreseen this very problem and consciously decided not to put in a fix for it… which now came back to bite me in a pretty spectacular way. But at least I did get an interesting bug to write about.
There is a new post at my Wind River blog, where I go back to the basics of reverse execution in Simics and what it can do. The post is not about reverse debugging, about which I have written quite a bit (see for example my series of blog posts: 1, 2, 3, 4, 5, 6), but about the core of reverse execution. I.e., moving the system state back in time in a variety of ways. There is an accompanying video demo on Youtube.
There is a new post at my Wind River blog, about how Simics sessions are started and the mechanics of system setups in Simics. It also has a link to a Youtube video demonstrating various ways of starting Simics simulation sessions.
There is a new post at my Wind River blog, with a video demo of the new Simics 4.8 System Editor function. Posts are coming out quite quickly now, with various aspects of Simics and in particular Simics 4.8 being highlighted. This particular feature is probably the biggest news in Simics 4.8 from a user interface perspective, as it allows you to (finally) inspect a target setup in a nice graphical tree view.
Nudge theory is an intriguing fairly new take on how to manage societies and modulate the behavior of people to make them behave in a “better” way. My layman’s interpretation of the idea is that instead of threating punishment and setting up rules, you try to encourage desired behavior with rewards and discourage undesired behavior by making it require an effort. When working with the new Test Runner view in the Simics 4.8 GUI, I realized that we had invented exactly such a nudge.
There is a new post at my Wind River blog, about how some new features in Simics 4.8 improve the collaboration power of Simics checkpoints. For the first time, Simics checkpoint can now carry a piece of history (slice of time), which also makes reverse execution and reverse debug work with checkpoints in a logical way.
Simics 4.8 is finally released, and I put up a blog post explaining the most important news in this release. It is two years since we released Simics 4.6, so there is quite a bit of news in Simics 4.8 – even though lots of functionality has been released continuously into 4.6 over the past twenty four months. My personal favorite are the comments you can put on an execution and the stop log, but then again, that might be because they have been a couple of pet ideas of mine so I am hardly an impartial judge. Everything else is also really good, and the engineering teams and marketing teams involved have put in a lot of effort into this release (as we do in all releases).
There is a new post at my Wind River blog, about how I ran a Windows file share server (CIFS) on a Simics-simulated VxWorks big-endian Power Architecture target. Something that just should work, given that the software in question is known to work in the real world. But still, pretty cool, and a bit eerie.
On my Wind River blog, you can now find a description on how we have used the Eclipse TCF (target connection framework) to build the Simics GUI. Or rather, the connection between the Simics GUI and the Simics simulation process. It is actually quite revolutionary what you can do with the TCF, compared to older debug protocols. In particular, TCF lets you combine many different services across a single connection.
Last year, I did a Simics webinar which included a two-part demo of how to use Simics to debug an endianness bug in a networked system as it migrates from big-endian to a little-endian system. Along the way, I also showed off various Simics features like reverse execution and checkpointing and scripted execution.
The demo is now online at the Wind River Youtube channel, and the setup is explained in a blog post at the Wind River company blog which is worth reading before watching the video.
There is a new post at my Wind River blog, telling the story of how some of the Simics developers used Simics itself to debug an intermittent Simics program crash caused by a timing-sensitive race condition.
Running Simics on itself is pretty cool, and shows the power of the simulator and its applicability even to really complex software.
I just added a new blog post at the Wind River blog, about determinism and illustrating Simics-style determinism is by looking at the game Bad Piggies. Games and simulators have quite a lot in common, actually.
There is a new blog post on my Wind River blog, about the Landslide system from CMU. It is a pretty impressive Master’s Thesis project that used the control that Simics has over interrupts to systematically try different OS kernel thread interleavings to find concurrency bugs. The blog is an interview with Ben Blum, the student who did the work. Ben is now a PhD student, and I bet that he will continue to generate cool stuff in the future.
I am going to be talking about how to transport bugs with virtual platform checkpoints, in the Software Tools track at the Embedded Conference Scandinavia, on October 3, 2012, in Stockholm (Sweden). The ECS is a nice event, and there are several tracks to choose from both on October 2 and October 3. In addition to the tracks, Jan Bosch from Chalmers is going to present a keynote that I am sure will be very entertaining (see my notes from a presentation he did in Göteborg last year).
A few years ago, I built a demo on Simics that used a hacked Freescale MPC8641D target that was forced to scale from 1 to 8 cores. Some interesting experiements could be made using this target, and it was nicely scalable for its time. However, I always wanted to have something just a bit bigger. Say 20 cores, or 100. Just to see what would happen. Finally, I got it.
The Simics QSP target that we quietly launched earlier this Summer is such a scalable target. As discussed in a blog post describing the architecture, it is designed to scale to 128 cores currently. Using this ability, I repeated my old experiments, but trying very large threads counts and target core counts. The results show clearly that the way that I coded my parallel computation program was pretty bad, and I really would like to try to rewrite it using some more modern threading library. All I need is time and a way to cross-compile Wool…
Anyway, the new blog post is here.
There is a new post at my Wind River blog, about the design and technical contents of the new Simics Quick Start Platforms, more widely known as the QSP. The blog describes the virtual-only hardware that forms part of the QSP, and how it was designed. It is interesting to note that the hardware ended up a bit more complex that I initially thought it would be, since an ideal virtual platform should be very simple. Right? Turns out an OS complicates things.
We just uploaded a short movie about reverse execution and reverse debugging to Youtube, to the Wind River official channel. In the short time available in this demo, we really only show reverse execution. Reverse debug, as I define it, is not used much at all, as explaining what goes on when you start to put breakpoints into a program and analyze its behavior takes a surprising amount of time.
On the Wind River corporate blog, I have put up a blog post about how Wind River Education Services is going to use Simics to teach networking. What is interesting with this approach is that it shows how a virtual platform can be used for tasks like teaching that don’t have much to do with hardware modeling or similar “typical” VP uses. In this case, the key value is encapsulation of a set of machines running real operating systems and software stacks, and with lots of networks connecting them.
There is a new post at my Wind River blog, about how a team of researchers at the University of Nebraska at Lincoln is using Simics to force rare bugs to manifest themselves as errors. They used Simics to control a target system to force it into rare situations much more likely to trigger latent bugs, requiring far fewer test runs compared to just randomly rerunning tests again and again and hoping to see a bug.
Wind River recently added a couple of new processor models to Simics: the 30-year-old 80186 and the 32-year-old 8051.
I have a blog post about this up on the Wind River tools blog. Pretty amazing to see us model an eight bit machine in 2012 – just proves how long-lived some hardware systems are.
There is a new post at my Wind River blog, about Simics running a model of the new Intel Crystal Forest platform. Crystal Forest is a very complex piece of hardware, but I am pretty happy that we managed to demo it in an understandable way – by essentially using it as a black box and putting a pretty display on top of that (using Eclipse).
There is a new post at my Wind River blog, about how you actually do fault injection in Simics. This particular post is pretty detailed, showing the actual architecture of a fault injector in Simics, not just “yes you can do it”. It includes actual diagrams of system components and how you can insert fault injection into an existing system, so it is a bit more technical than most my Wind River blog posts that tend to be more conceptual.
In this final part of my series on the history of reverse debugging I will look at the products that launched around the mid-2000s and that finally made reverse debugging available in a commercially packaged product and not just research prototypes. Part one of this series provided a background on the technology and part two discussed various research papers on the topic going back to the early 1970s. The first commercial product featuring reverse debugging was launched in 2003, and then there have been a steady trickle of new products up until today.
Originally published in January 2012. Post updated 2012-09-28 with a revised timeline for Lauterbach CTS. Post updated 2016-04-05 to include Mozilla RR. Post updated 2016-12-26 to add Simulics. Post updated 2017-10-08 to add Microsoft WinDbg.
There is a new post at my Wind River blog, an interview with Dan Poirot at RTI who is using Simics to model and test heterogeneous, distributed, networked systems.
I just had two articles published the Embedded Design part of the EETimes.
First, “Rethink your project planning with a virtual platform“, which talks about how virtual platforms can change your entire project planning. Essentially, by reducing project friction and risks related to hardware availability, software integration, and show-stopper bugs, you can make projects work much better.
Then we have “Transporting bugs with virtual checkpoints“, which is a shorter, popular science, version of the paper I published last year at S4D. This describes how you can use checkpointing in a virtual platform to communicate bugs across time, space, and teams.
There is a new post at my Wind River blog, about hypersimulation in virtual platforms and how it lets virtual time fly much faster than real time. It was the result of simple mistake of leaving Simics running in the background as I did other work on my machine.