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.
Carbon Design Systems have been quite busy lately with a flurry of blog posts about various aspects of virtual prototype technology. Mostly good stuff, and I tend to agree with their push that a good approach is to mix fast timing-simplified models with RTL-derived cycle-accurate models. There are exceptions to this, in particular exploratoty architecture and design where AT-style models are needed. Recently, they posted about their new Swap ‘n’ Play technology, which is a old proven idea that has now been reimplemented using ARM fast simulators and Carbon-generated ARM processor models.
Once upon a time, I was young man in high school where our little computer club got a new PC with a color screen and a floating-point coprocessor. One fun little program I wrote was a simple gravity simulator, where a number of point-size assigned various mass flew around interacting with each other. We used that program and tried to set up initial setting for sizes, speeds, and directions of bodies that would result in some kind of stable system. More often that not, all we managed to create were comets that came in, took a sharp corner around a “star” and disappeared out into the void again. Still, it was great fun. And when I discovered Angry Birds Space it felt like a chance to try that again. Overall, “space” as my son calls it is a great spin on the Angry Birds idea. However, the way it is sold does not make me too happy.
There is a new post at my Wind River blog, about how the LDRA code coverage tools have been brought to work on Simics using a simulation-only “back door “.
The most interesting part of this is how a simulator can provide an easy way to get information out of target software, without all the software and driver overhead associated with doing the same on a real target. In this case, all that is needed is a single memory-mapped location that can written to be software – which can be put into user-mode-accessible locations if necessary.
Once upon a time, all programming was bare metal programming. You coded to the processor core, you took care of memory, and no operating system got in your way. Over time, as computer programmers, users, and designers got more sophisticated and as more clock cycles and memory bytes became available, more and more layers were added between the programmer and the computer. However, I have recently spotted what might seem like a trend away from ever-thicker software stacks, in the interest of performance and, in particular, latency.
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).
I was recently pointed to a 2011 SPLASH presentation by David Ungar, an IBM researcher working on parallel programming for manycore systems. In particular, in a project called Renaissance, run together with the Vrije Universiteit Brussels in Belgium (VUB) and Portland State University in the US. The title of the presentation is “Everything You Know (about Parallel Programming) Is Wrong! A Wild Screed about the Future“, and it has provoked some discussion among people I know about just how wrong is wrong.
Ticket to Ride is a nice real-world board game that is generally considered one of the best family and gateway games (and a decent game even for experienced gamers). We recently got it for our iPod Touches, and the weakness of the computer players quickly turned it from “I wonder if I can win this game” into “let’s shoot for the highest score possible”.
Chasing high scores is fairly typical for computer games – playing against human beings you are motivated to win, even if you win by scoring a measly 75 points… while against the computer it becomes about beating your own old scores. Unfortunately, this also turns repetitive after a while, due to some small design flaws that really should be easy to fix.
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.
This is the second post in my series on the history of reverse execution, covering various early research papers. It is clear that reverse debugging has been considered a good idea for a very long time. Sadly though, not a practical one (at the time). The idea is too obvious to be considered new. Here are some papers that I have found dating from the time before “practical” reverse debug which for me starts in 2003 (as well as a couple of later entrants).
For some reason, when I think of reverse execution and debugging, the sound track that goes through my head is a UK novelty hit from 1987, “Star Trekkin” by the Firm. It contains the memorable line “we’re only going forward ’cause we can’t find reverse“. To me, that sums up the history of reverse debugging nicely. The only reason we are not all using it every day is that practical reverse debugging has not been available until quite recently. However, in the past ten years, I think we can say that software development has indeed found reverse. It took a while to get there, however. This is the first of a series of blog posts that will try to cover some of the history of reverse debugging. The text turned out to be so long that I had to break it up to make each post usefully short. Part two is about research, and part three about products.
Read more…
I have now posted the slides from my keynote talk at the S4D 2011 conference to the presentations list on my regular home page. The topic of that talk was “System-Level Debug”, something which has started to interest me in recent years.
Is the touchscreen the end-all of user interfaces for mobile devices? There were rumors in early 2011 that the iPad2 would lose all physical buttons (which did not come true, obviously). To me, that sounds like a really good and bad idea. Good, in the sense that a device that is all a big screen certainly looks nice. Bad, since it would be much less user-friendly than a device with some real physical buttons to press.
I have been thinking about this subject lately, after using a BlackBerry Torch 9800 as my work phone for a few months. I like the device a lot, but there are certainly some rough edges and some places where there is a UI conflict between touching the screen and pressing the buttons. At the same time, I am using both an iPod Nano 3G, and a couple of iPod Touches. I used to have SonyEricsson Symbian-based P900, P990i, and G900 smart phones which also were combined touch/press devices with a stylus.
Fault Injection is a topic that has fascinated me for a long time. Not just the area of software-to-software fault injection, but more so how you inject faults into hardware using hardware (and how to conveniently approximate this using a simulator). I just stumbled on a short interesting note about such hardware-actuated fault injection in a Fujitsu article.
It used to be that Microsoft was the big, boring, evil company that nobody felt was very inspiring. Today, with competition from Google and Apple as well as a strong internal research department, Microsoft feels very different. There are really interesting and innovative ideas and paper coming out of Microsoft today. It seems that their investments in research and software engineering are generating very sophisticated software tools (and good software products).
I have recently seen a number of examples of what Microsoft does with the user feedback data they collect from their massive installed base. I am not talking about Google-style personal information collection, but rather anonymous collection of user interface and error data in a way that is more designed to built better products than targeting ads.
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.
On the very binary date of 11-11-11, my alma mater, the computer science (DV, for datavetenskap) education at Uppsala University celebrated its thirty years’ anniversary. It was a great classic student party in the evening with a nice mix of old alumni and fresh-faced students. Lots of singing and some nice skits on stage. Great fun, and my voice has still not recovered. It also got me thinking about it is that we really do as computer scientists.
Last week, I had the honor of presenting at and attending the talks of the Lindholmen Software Development Day. The first keynote speaker was Professor Jan Bosch from Chalmers, who did his best to provoke, prod, and shock the audience into action to change how they do software. While I might not agree with everything he said, overall it was very enjoyable and insightful talk.
On my Wind River blog, I just posted a fairly long post about simulation abstraction levels. It was inspired by a cool article in ArsTechnica about Nintendo emulators, and the costs and benefits of being ever more faithful to the hardware.
I just read a quite interesting article by Christian Pinto et al, “GPGPU-Accelerated Parallel and Fast Simulation of Thousand-core Platforms“, published at the CCGRID 2011 conference. It discusses some work in using a GPGPU to run simulations of massively parallel computers, using the parallelism of the GPU to speed the simulation. Intriguing concept, but the execution is not without its flaws and it is unclear at least from the paper just how well this generalizes, scales, or compares to parallel simulation on a general-purpose multicore machine.
Paul Henning-Kamp has written a series of columns for the ACM Queue and Communications of the ACM. He is pointed, always controversial, and often quite funny. One recent column was called “The Most Expensive One-Byte Mistake“, which discusses the bad design decision of using null-terminated strings (with the associated buffer overrun risks that would have been easily avoided with a length+data-style string format). Well worth a read. A key part of the article is the dual observation that compilers are starting to try to solve the efficiency problems of null-terminated strings – and that such heavily optimizing compilers quite often very hard to use.

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.
Nvidia recently announced that their already-known “Kal-El” quad-core ARM Cortex-A9 SoC actually contains five processor cores, not just four as a “normal” quad-core would. They call the architecture “Variable SMP”, and it is a pretty smart design. The one where you think, “I should have thought of that”, which is the best sign of something truly good.
There is a new post at my Wind River blog, which could seem to be about shoes but which is really about process improvement. In particular, the need for companies to let their employees take a step or two back and look at what they are doing and what they could do better.
It is way too common to be so busy running around being inefficient that there is no time to think about how to become more efficient. Change also requires some discipline to actually keep pushing at habits until they change for the better.
Every once in a while I need to build demo setups to show debugging in action. As I have blogged before, finding a good bug when you need one isn’t always easy. The solution is to try to invent artificial bugs, and I was very happy when I managed to stage a buffer overrun in a VxWorks program.
It is pretty very nice demo in which you first start a period program A, which prints the value of an incrementing counter every target second. You then run a supposedly unrelated program B, resulting in the values that program A prints to become corrupted. Perfect to show off reverse execution and data breakpoints in reverse as you go from the point where the corrupted value is printed to the piece of code that overwrote the variable.
But then I ported the demo to a new platform… and the bug didn’t work anymore. My bug had caught a bug and was now not working, or at least not they way I expected it to. What had happened?
Read more…
Just for fun, I tried to surf the web of today using a Netscape 4 browser from 2001.
The result: not exactly useful. Netscape 4 was bad back then, and it does not work at all with the current style of web coding.
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.
From what little I had heard and read, the IBM AS/400 (later known as iSeries, and now known as simply IBM i) sounded like a fascinating system. I knew that it had a rich OS stack that contained most of the services a program needs, and a JVM-style byte code format for applications that let it change from custom processors to Power Architecture without impacting users at all. It was supposedly business-critical and IBM-quality rock solid. But that was about it.
So when Software Engineering Radio episode 177 interviewed the i chief architect Steve Will, I was hooked. It turned out that IBM i was cooler than I imagined. Here are my notes on why I think that IBM i is one of the most interesting systems out there in real use.

