I just read an interview with Steve Furber, the original ARM designer, in the May 2011 issue of the Communications of the ACM. It is a good read about the early days of the home computing revolution in the UK. He not only designed the ARM processor, but also the BBC Micro and some other early machines.
There is a new post at my Wind River blog, about how you build virtual platforms with Simics. The post is more about the methodology than the nature of models, cycle accuracy, endianness, and all the other details of virtual platform modeling. I have written about modeling methodology on this blog too, and in particular I would recommend looking at “Two perspectives on modeling“.
I just read the book Sex, Bombs, and Burgers, written by technology journalist Peter Nowak. The summary (minus some unnecessary hyperbole) from the book’s website reads:
Peter Nowak argues that most of the major technological advances of the last sixty years have stemmed from the trio of billion-dollar industries that cater to our basest impulses. From Saran Wrap to aerosols, digital cameras to cold medicine and GM foods to Google, many of the gadgets and conveniences we enjoy today can be traced back to either the porn, military or fast food industry.
This certainly sounded interesting. And the book was a good read. However, it was not a great read.
Recently, Gary Stringham has been running a series of interviews with providers of register design tools on his website. Register design tools seems to be an active area with several small companies (and some open-source tools) fighting for the market. I have written about Gary Stringham and register designs before, and it is an area that keeps fascinating me. There is something about the task of register design that keeps it separate from the main hardware design languages, tools, and flows.The different approaches taken by the tools supporting the register design task also illustrates some points about programming language standards, domain-specific languages, and exchange formats that I want to address.
This Summer, our travel-away-from-home vacation was spent in Sälen, Sweden. Sälen is normally considered a winter destination, one of the biggest ski resorts in Sweden – but they are working on making it more of a year-round attraction. To be more precise, we went to Lindvallen, which is one of the seven or so separate “villages” that form the “Sälen” area. It was a nice and relaxed place, with little stress from having too many things to do, but enough to keep the kids happy. Seeing the mountains in the Summer was nice.
There is a new post at my Wind River blog, about the “Toddler stage” of software in general and Simics 4.6 in particular. To me, software in an early stage of development shares many traits with a toddler:
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.
For some reason, in the past few weeks I have talked to more than a few PhD students and researchers about various ideas. It is striking how often fundamentally very smart people have a problem in articulating just why what they are doing is useful, relevant, and potentially commercially interesting. Of course, we all know that this is hard, and all PhD students get some kind of training in presentation and selling their ideas. It is also unfair to expect a fresh graduate student to be able to put on a show like a Simon Peyton-Jones.
However, this did get me thinking some about the articulation of problems.
By chance, I got to attend a day at the UPMARC Summer School with a very enjoyable talk by Francesco Zappa Nardelli from INRIA. He described his work (along with others) on understanding and modeling multiprocessor memory models. It is a very complex subject, but he managed to explain it very well.
I often have to create screenshots and screen recordings as part of my job, and to make that look good I don’t want any part of my Windows desktop or task bar to show in the results. Until now, I have done this the hard way by using very few desktop icons and putting them around the edges of the screen.
There is a better way.
There is a new post at my Wind River blog, about the new Simics 4.6 release. 4.6 has some serious new goodies in it, including an Eclipse source-code debugger and a way to build blinking lights front panels for boards.
Episodes 299 and 301 of the SecurityNow podcast deal with the problem of how to get randomness out of a computer. As usual, Steve Gibson does a good job of explaining things, but I felt that there was some more that needed to be said about computers and randomness, as well as the related ideas of predictability, observability, repeatability, and determinism. I have worked and wrangled with these concepts for almost 15 years now, from my research into timing prediction for embedded processors to my current work with the repeatable and reversible Simics simulator.
Since I have a certain interest in debugging, I was happy find the article “Guidelines for SystemC – Debugger Integration” at the usually interesting Design and Reuse website. However, I must say that it was pretty disappointing.
The submissions for S4D 2011 is now open, at http://www.ecsi.org/s4d/submissions. I have been to S4D for two years now, and I find it one of the most interesting conferences around. It is a nice mix of hardware design and software tools, all directed at the fundamental problem of how to debug a digital system. To me, it is the “debug conference” par excellence.
If you have something interesting to submit, please do. I won’t have time myself to write something for this year, unfortunately.
Software is Concrete. Once poured it becomes extremely difficult and very expensive to change.
It comes from a blog post by Robert Howe, CEO of Verum, a company selling formal-methods-based and model-based programming tools. It does capture something of the phenomenon we all know: that software can be pretty darn hard to change, once it has shipped and is in use. It fits well with the fact that the later bugs are found, the more expensive they are to fix.
But it also provoked quite a bit of opposition when I put the quote up on Facebook, and I have to agree that maybe not all is as simple as that blog makes it out to be.
There is a new post at my Wind River blog, about some computing history. Wind River turns thirty this year, Simics twenty, and simulation for debug (and probably debug in general) turns sixty. Computing has come a long way.
I am using TortoiseGit on Windows for a while now, and it works OK. However, today, it just stopped working. The error I got persistently was:
0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487 AllocationBase 0x0, BaseAddress 0x68540000, RegionSize 0x480000, State 0x10000 c:\msysgit\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0
I recently read the “Cubase64 White Paper” by Pex Tufvesson. It is a fantastic piece of retro computing, where he makes a Commodore 64 do real-time audio effects on a sampled piece of music. There is a Youtube movie showing the demo in action. Considering how hard we worked in the early 1980s to make a computer make any kind of useful noise at all, this is an amazing feat. It is also a feat that I think would have been impossible at the time.
There is a new post at my Wind River blog, about how Simics was used to kick-start the development of the 64-bit version of VxWorks. It is an interesting example of how to use a virtual platform as a model of something much simpler and gentler than actual hardware systems.
There is a new post at my Wind River blog, about the testing on an integrated software stack in simulation. I base the discussion on the very interesting report about the Toyota “unintended acceleration” problems and the deep investigation into the control software of the affected vehicles performed by a NASA team (!). The report covers a lot of different tools, but also notes that about the only thing not done was to integrate the complete software stack in simulation.
James Aldis of TI has published an article in the EEtimes about how Texas Instruments uses SystemC in the modeling of their OMAP2 platform. SystemC is used for early architecture modeling and performance analysis, but not really for a virtual platform that can actually run software. The article offers a good insight into the virtual platform use of hardware designers, which is significantly different from the virtual platform use of software designers.
Read more…
I am just finishing off reading the chapters of the Processor and System-on-Chip Simulation book (where I was part of contributing a chapter), and just read through the chapter about the Tensilica instruction-set simulator (ISS) solutions written by Grant Martin, Nenad Nedeljkovic and David Heine. They have a slightly different architecture from most other ISS solutions, since that they have an inherently variable target in the configurable and extensible Tensilica cores. However, the more interesting part of the chapter was the discussion on system modeling beyond the core. In particular, how they deal with interrupts to the core in the context of a temporally decoupled simulation.
There is a new post at my Wind River blog, about how you can use a virtual platform to complete work faster. Not by making the virtual platform execution of target code faster, but by optimizing the way you work and taking advantage of the features of a virtual platform.
I previously blogged about the HAVEGE algorithm that is billed as extracting randomness from microarchitectural variations in modern processors. Since it was supposed to rely on hardware timing variations, I wondered what would happen if I ran it on Simics that does not model the processor pipeline, caches, and branch predictor. Wouldn’t that make the randomness of HAVEGE go away?
When I was working on my PhD in WCET – Worst-Case Execution Time analysis - our goal was to utterly precisely predict the precise number of cycles that a processor would take to execute a certain piece of code. We and other groups designed analyses for caches, pipelines, even branch predictors, and ways to take into account information about program flow and variable values.
The complexity of modern processors – even a decade ago – was such that predictability was very difficult to achieve in practice. We used to joke that a complex enough processor would be like a random number generator.
Funnily enough, it turns out that someone has been using processors just like that. Guess that proves the point, in some way.
There is a new post at my Wind River blog, about warnings in virtual platforms. It is an art to add good warnings to virtual platform models, and just being correct visavi the hardware behavior is not necessarily that helpful for a software developer. A virtual platform should warn about suspicious operations, even if they are technically “correct”.
I also have to apologize for the slow blogging in January of 2011. There was too much going on at work and quite a few days taking care of sick kids. Hopefully, the pace can improve going forward.
In the June 2010 issue of Communications of the ACM, as well as the April 2010 edition of the ACM Queue magazine, George Phillips discusses the development of a simulator for the graphics system of the 1977 Tandy-RadioShack TRS-80 home computer. It is a very interesting read for all interested in simulation, as well as a good example of just why this kind of old hardware is much harder to simulate than more recent machines.
Ever since I got my BlackBerry smartphone, I was annoyed that the display said “My Number: Unknown number” in a number of places. I assumed that this would be automatic, just like everything else information-related on this device. However, I finally worked out how to “fix” the problem by manually setting my phone number.
Endianness is a topic in computer architecture that can give anyone a headache trying to understand exactly what is happening and why. In the field of computer simulation, it is a pervasive problem that takes some thinking to solve in an efficient, composable, and portable way.
This blog post describes how I am used to working with endianness in virtual platforms, and why this approach makes sense to me. There are other ways of dealing with endianness, with different trade-offs and overriding goals.
Read more…
There is a new post at my Wind River blog, about iterative hardware-software interface design. It is a discussion with some examples of why hardware designers would do well to use virtual platforms to include software designers in the loop when designing new devices and their programming interfaces.
New post up at my Wind River blog, about cheating in virtual platforms.

