For Simicstraining and demo purposes, we often use Linux* running on the virtual platforms. In the early days of Simics and embedded Linux, we built our own minimal configurations by hand to run on simple target systems. Most recently, we changed our Linux default demo and training setup to use Clear Linux*. This change showed us just how sophisticated modern Linux setups are – which is good in general, but it also can make some low-level details more complicated.
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).
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.
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.
Bengt Werner was one of the first people to work on the simulator that would become Simics, way back in 1992. On my Intel Blog, I published an interview with Bengt a while back where we discuss the early days of Simics and the original product vision and use cases.
I have a new blog post up at the Intel Developer Zone, this time about the Simics “fulprompt”. Every software team has its legends about spectacular mistakes, crazy users, and customer calls with strange questions. The Simics “fulprompt” is one example of this from the early days of Simics. It was a prompt that appeared where no prompt would normally appear, right in the middle of executing an instruction. As such, it was an ugly hack… and for Swedes who were around in the 1990s, the only name for a ugly hack is a fulhack.
Injecting faults into systems and subjecting them to extreme situations at or beyond their nominal operating conditions is an important part of making sure they keep working even when things go bad. It was realized very early in the history of Simics (and the same observation had been made by other virtual platform and simulator providers) that using a virtual platform makes it much easier to provide cheap, reliable, and repeatable fault injection for software testing. In an Intel Developer Zone (IDZ) blog post, I describe some early cases of fault injection with Simics.
I have just released a new blog post on my Intel Developer Zone blog, about how Simics runs large huge workloads. I look back at the kinds of workloads that ran on Simics back in 1998 when the product first went commercial, and then look at some current examples running on Simics. This is the first post in a series intended to celebrate 20 years of Simics as a commercial product.
I will be presenting an Exhibitor Forum talk at the Embedded World in Nürnberg next week, about how to get to Agile and small batches for embedded. Using simulation to get around the annoying hard aspect of hardware.
Over time, Intel and other processor core designers add more and more instructions to the cores in our machines. A good question is how quickly and easily new instructions added to an Instruction-Set Architecture (ISA) actually gets employed by software to improve performance and add new capabilities. Considering that our operating systems and programs are generally backwards-compatible, and run on all kind of hardware, can they actually take advantage of new instructions?
I have posted a two-part blog post to the public Intel Developer Zone blog, about the “Small Batches Principle” and how simulation helps us achieve it for complicated hardware-software systems. I found the idea of the “small batch” a very good way to frame my thinking about what it is that simulation really brings to system development. The key idea I want to get at is this:
[…] the small batches principle: it is better to do work in small batches than big leaps. Small batches permit us to deliver results faster, with higher quality and less stress.
Integration is hard, that is well-known. For computer chip and system-on-chip design, integration has to be done pre-silicon in order to find integration issues early so that designs can be updated without expensive silicon re-spins. Such integration involves a lot of pieces and many cross-connections, and in order to do integration pre-silicon, we need a virtual platform.
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.
My first blog post as a software evangelist at Intel was published last week. In it, I tell the story of how our development teams used Simics to test the software behavior (UEFI, in particular) when a server is configured with several terabytes of RAM. Without having said server in physical form – just as a simulation. And running that simulation on a small host with just 256 GB of RAM. I.e., the host RAM is just a small fraction of the target. That’s the kind of things that you can do with Simics – the framework has a lot of smarts in it.
It was rather interesting to realize that just the OS page tables for this kind of system occupies gigabytes of RAM… but that just underscores just how gigantic six terabytes of memory really is.
I love bug and debug stories in general. Bugs are a fun and interesting part of software engineering, programming, and systems development. Stories that involve running Simics on Simics to find bugs are a particular category that is fascinating, as it shows how to apply serious software technology to solve problems related to said serious software technology. On the Intel Software and Services blog, I just posted a story about just that: debugging a Linux kernel bug provoked by Simics, by running Simics on a small network of machines inside of Simics. See https://blogs.intel.com/evangelists/2016/05/30/finding-kernel-1-2-3-bug-running-wind-river-simics-simics/ for the full story.
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.
A new record, replay, and reverse debugger has appeared, and I just had to take a look at what they do and how they do it. “rr” has been developed by the Firefox developers at Mozilla Corporation, initially for the purpose of debugging Firefox itself. Starting at a debugger from the angle of attacking a particular program does let you get things going quickly, but the resulting tool is clearly generally useful, at least for Linux user-land programs on x86. Since I have tried to keep up with the developments in this field, a write-up seems to be called for.
It is also my last blog post written at Wind River; since January 18, I am working at Intel. I am working on ways to keep publishing texts about Simics and simulation, but the details are not yet clear.
I just posted a short blog post on the Wind River blog, introducing a video demo of the Web API to Wind River Helix Lab Cloud. In the post and video, I show how the Lab Cloud Web API works. For someone familiar with REST-style APIs, this is probably baby-level, but for me and probably most of our user base, it is something new and a rather interesting style for an API. Thus, doing a video that shows the first few steps of authentication and getting things going seems like a good idea.
But the past part is that the targets I talk about in the blog post and use in the video are available for anyone! Just register on Lab Cloud, and you can try your own threaded software and check how it scales on a simulated 8-core ARM!
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.