Last week was spent at the Design Automation Conference (DAC) in Las Vegas. I had a presentation and poster in the Designer/IP track about Clouds, Containers, and Virtual Platforms , and worked in the Intel Simulation Solutions booth at the show floor. The DAC was good as always, meeting many old friends in the industry as well as checking out the latest trends in EDA (hint: same trends as everywhere else). One particularly nice surprise was a book (the printed type, not the Vegas “book” that means something else entirely).Continue reading “DAC 2019 – Cloud, a Book, an Award, and More”
The US Defense Advanced Projects Agency (DARPA) ran a “Cyber Grand Challenge” in 2016, where automated cyber-attack and cyber-defense systems were pitted against each other to drive progress in autonomous cyber-security. The competition was run on physical computers (obviously), but Simics was used in a parallel flow to check that competitors’ programs were not trying to undermine the infrastructure of the competition rather than compete fairly inside the rules of the competition.Continue reading “Intel Blog Post: Simics in the DARPA Cyber Grand Challenge”
Running Simics inside a container is a topic that has come up several times in recent years. In a two-part Intel Developer Zone blog post, my colleague Mambwe Mumbwa and I discuss both some background on container technology, how and how well Simics can run inside of containers, and what you can with containerized Simicses. Overall, containers offer a very good alternative to virtual machines for running programs like Simics, and the tool ecosystem opens up some exciting new ways to manage Simics installations and simulation instances.
Update: this post was extended to link to both part 1 and part 2 of the blog.Continue reading “Intel Blog Posts: Running Simics in Containers”
Simics and other simulation solutions are a great way to add more variation to your software testing. I have just documented a nice case of this on my blog at the Intel Developer Zone (IDZ), where the Simics team found a bug in how Xen deals with MPX instructions when using VT-x. Thanks to running on Simics, where scenarios not available in current hardware are easy to set up.
Last year (2015), a paper called “Don’t Panic: Reverse Debugging of Kernel Drivers” was presented at the ESEC/FSE (European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering) conference. The paper was written by Pavel Dovgalyuk, Denis Dmitriev, and Vladimir Makarov from the Russian Academy of Sciences. It describes a rather interesting approach to Linux kernel device driver debug, using a deterministic variant of Qemu along with record/replay of hardware interactions. I think this is the first published instance of using reverse debugging in a simulator together with real hardware.
I have posted my first blog post to the Intel Software and Services blog channel. The Intel Software and Services blog is one channel in the Intel corporate blog you find at https://blogs.intel.com/. Other bloggers on the Software and Services channel write about security, UEFI, cloud, graphics, open source software, and other topics. Intel has a large software development community, and we produce quite a bit of software – and we do write about the innovations that come out of Intel that rely on software.
On my part, I will be posting more materials on simulation at Intel, as part of my role as a simulation evangelist on the Software and Service blog channel.
There are still some articles being published that I wrote while at Wind River. The latest is a piece on just what you could do with a lab in cloud – in particular, a lab based on virtual platforms like Simics. Eva Skoglund at Wind River and I wrote this together, and it is a nice high-level summary of why you really need to have a virtual cloud-based lab if you are doing embedded systems development. It is published in the online European magazine Electropages.
On November 3, 2015, I will give a presentation at the Embedded Conference Scandinavia about simulating IoT systems. The conference program can be found at http://www.svenskelektronik.se/ECS/ECS15/Program.html, with my session detailed at http://www.svenskelektronik.se/ECS/ECS15/Program/IoT%20Development.html.
My topic is how to realistically simulate very large IoT networks for software testing and system development. This is a fun field where I have spent significant time recently. Only a couple of weeks ago, I tried my hand simulating a 1000-node network. Which worked! I had 1000 ARM-based nodes running VxWorks running at the same time, inside a single Simics process, and at speeds close to real time! It did use some 55GB of RAM, which I think is a personal record for largest use of system resources from a single process. Still, it only took a dozen processors to do it.
I have read a few news items and blog posts recently about how various types of software running on top of virtual machines and emulators have managed to either break the emulators or at least detect their presence and self-destruct. This is a fascinating topic, as it touches on the deep principles of computing: just because a piece of software can be Turing-equivalent to a piece of hardware does not mean that software that goes looking for the differences won’t find any or won’t be able to behave differently on a simulator and on the real thing.
For the past six months I have not been doing much blogging at all, neither here nor on the Wind River blog. The reason is that I have been directing my writing energy into writing a text book about Simics together with Daniel Aarno at Intel. Last year, Daniel and I worked on an Intel Technology Journal issue on Simics. The ITJ issue was kind of a first step on the way to the book, collecting several articles about Simics usage at Intel and elsewhere. The book itself will be much more of a detailed description of Simics and how it works and why it works the way it works.
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.
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.
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.
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.
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 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.
This post features some additional notes on the topic of transporting bugs with checkpoints, which is the subject of a paper at the S4D 2010 conference.
The idea of transporting bugs with checkpoints is some ways obvious. If you have a checkpoint of a state, of course you move it. Right? However, changing how you think about reporting bugs takes time. There are also some practical issues to be resolved. The S4D paper goes into some of the aspects of making checkpointing practical.
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 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. See the longer Wind River blog posting about this topic for a few more details.
Past Friday, I posted a new blog post in my Wind River blog. It is an interview the PhD student Girish Venkatasubramanian from the University of Florida. He is doing research on virtual machines/hypervisors and how they can be implemented more efficiently by making fairly small changes to the architecture of memory management units.
I listened to an interesting FLOSS Weekly interview with Adam Hall and Achim Hasenmuller of VirtualBox. For someone interested in virtual machines and hardware simulation, the interview was full of interested tidbits. I think the best part was the discussion on multiprocessing in Virtualbox.
I just read a short paper by Antoine Trouvé and Kazuaki Murakami from the RAPIDO 2010 workshop on “rapid simulation and performance evaluation”. The paper is “FFast: Efficient Application of Compiled Simulation Techniques To A Fast ISS Over a Virtual Machine”. It explores the interesting idea of how an existing virtual machine infrastructure can be used to build a fast instruction-set simulator, and in the extension, a full system simulator.
To me, this idea is worth exploring, since using a mature VM like the .net CLR (used in this paper) or a JVM would offer a shortcut to get high-quality code generation for a JIT compiler. It could also offer other benefits, as these environments support many advanced configuration and management features. I have touched on this topic before, in the posts “Dream ESL Language” (VM as the basis for a simulator) and “The JVM as Universal Parallel Glue” (that a common VM can offer huge benefits for an ecosystem).
Last Friday, I attended this year’s edition of the SiCS Multicore Day. It was smaller in scale than last year, being only a single day rather than two days. The program was very high quality nevertheless, with keynote talks from Hazim Shafi of Microsoft, Richard Kaufmann of HP, and Anders Landin of Sun. Additionally, there was a mid-day three-track session with research and industry talks from the Swedish multicore community. Continue reading “SiCS Multicore Day 2009”
I just found “The Toaster Project“, a Royal College of Art project where Thomas Twaites built a simple toaster from scratch. Really from scratch, going all they way back to iron ore and raw petroleum. In the process, he had to smelt ore, create plastic from petroleum, etc. It is a very interesting observation about the immense industrial complexity behind the very simple everyday items of our lives. I also think it has something to tell us computer scientists about abstraction.
I have an old Canon LIDE 30 scanner that I purchased sometime late in 2003. At that time, it was connected to a PC running Windows XP, and drivers worked just fine. However, after I got my new computer in early 2009, with Vista 64, there are no more drivers available. There is a funny way around this though, using a virtual machine.
I just read the panel interview at the start of the latest issue (Number 4, 2008) of ACM Queue. Here, you have Bryan Cantrill of Sun (the man behind dTrace) bemoan the difficulty of testing faults. In particular:
Part of the reason I’m interested in virtualization is as a development methodology. It has not delivered on this, but one of the things that I ask is can I use virtualization to automate someone pulling the Ethernet cable out of the jack? I can get a lot closer to simulating it if you let me create a toy virtual machine than I can running on the live machine.
Well, this already exists. It is a common feature to any virtual platform that is not a datacenter-oriented runtime engine like VmWare, Xen, LPAR, and its ilk. Doing fault injection is a primary use case for virtual platforms, especially for larger servers and systems featuring redundancy and fault tolerance.
The Register has a few podcasts in addition to their website, and the one called “Semicoherent Computing” has turned into a very nice series of interviews with interesting people from the computer industry. I recently listened to their interview from September 2007 with David Ditzel of Transmeta fame. He had a lot to say about the history of computing, as well as interesting things on where computing is going. Well worth a listen! Particular interesting highlights…
It must have been Google Alerts that send me a link to the HOTOS 2007 (Hot Topics in Operating Systems) paper by Tal Garfinkel, Keith Adams, Andrew Warfield, and Jason Franklin called Compatibility is not Transparency: VMM Detection Myths and Realities. This paper is slightly less than a year old today, so it is old by blog standards and quite recent by research paper standards. It deals with the interesting problem of whether a virtual machine can be made undetectable by software running on it — and software that is trying to detect it. Their conclusion is that it is not feasible, and I agree with that. The reason WHY that is the case can use some more discussion, though… and here is my take on that issue from a Simics/embedded systems virtualization perspective.
Some more thoughts on how to program multicore machines that did not make it into my original posting from last week. Some of this was discussed at the multicore day, and others I have been thinking about for some time now.
One of the best ways to handle any hard problem is to make it “somebody else’s problem“. In computer science this is also known as abstraction, and it is a very useful principle for designing more productive programming languages and environments. Basically, the idea I am after is to let a programmer focus on the problem at hand, leaving somebody else to fill in the details and map the problem solution onto the execution substrate.