A new short blog post on my Intel Developer Zone blog talks about the improved threading simulation core we have added in Simics version 6… and about how a colleague of mine climbed to the top of the highest mountain in Europe and showed a flag with our new Simics icon! Read the story at https://software.intel.com/en-us/blogs/2019/09/10/simics-6-at-the-mountain-top.
I have a new blog post out on the Intel Developer Zone, about the Simics 6 device register coverage feature. I use device register coverage to look at how different operating systems use the same hardware. The differences are significant, demonstrating the (rather expected) observation that different software stacks use the same hardware in different ways.Continue reading “Intel Blog: Simics 6 Device Register Coverage”
For Simics training 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.
I wrote an Intel Developer Zone Blog Post about our experience moving to Clear Linux for Simics demos and training, which contains a lot more details of what we observed and did to make this work for our purposes.
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”
A few weeks ago, I talked about temporal decoupling in virtual platforms at DVCon Europe 2018. I just posted some additional notes on the topic temporal decoupling on my Intel blog. In this new blog post, I discuss some more aspects of temporal decoupling, and how it affects simulation semantics. I also explain some of the clever techniques used to minimize the impact of temporal decoupling on the software running on the virtual target system.
Read the full text at as “Additional Notes on Temporal Decoupling“.
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.
Back in 2004, the startup Virtutech built a crazy demo for the 2004 Embedded Systems Conference (ESC). Back then, ESC was the place to be, and Virtutech was there with a battery of demos to blast the competition. The most interesting demo from a technology perspective was the 1002-machine network, as described in an Intel Developer Zone blog post of mine.
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.
There is a blog post out on my Intel Developer Zone blog where I take a look at the Gartner “Top Ten Tech Trends” for 2018. There are a couple of them where I found clear roles for the kinds of simulation tools we build in my little corner of Intel. In particular, Digital Twins is a concept that is all about simulation. To find the other trend where I found a big role for simulation, read the full blog post.
A while ago, I visited my Intel colleagues in Costa Rica and ran a workshop for university teachers and researchers, showing how Simics could be used in academia. I worked with a very smart and talented intern, Jose Fernando Molina, and after a rather long process I have published an interview with him on my Intel blog: https://software.intel.com/en-us/blogs/2017/12/05/windriver-simics-to-inspire-teachers-costarica
In a previous Intel blog post “Question: Does Software Actually Use New Instruction Sets?” I looked at the kinds of instructions used by few different Linux setups, and how each setup was affected by changing the type of the processor it was running on (comparing Nehalem to Skylake). As a follow-up to that post, I have now done the same for Microsoft* Windows* 10. In the blog post, I take a look at how Windows 10 behaves across processor generations, and how its behavior compares to Ubuntu* 16 (they are actually pretty similar in philosophy).
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?
inThere will be a session on checkpointing in SystemC at the upcoming SystemC Evolution Day in München on October 18, 2017. I will be presenting it, together with some colleagues from Intel. Checkpointing is a very interesting topic in its own right, and I have written lots about it in the past – both as a technology and it applications.
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.
I have just published a piece about the Intel Excite project on my Software Evangelist blog at the Intel Developer Zone. The Excite project is using a combination of of symbolic execution, fuzzing, and concrete testing to find vulnerabilities in UEFI code, in particular in SMM. By combining symbolic and concrete techniques plus fuzzing, Excite achieves better performance and effect than using either technique alone.
In the early 1990s, “PC graphics” was almost an oxymoron. If you wanted to do real graphics, you bought a “real machine”, most likely a Silicon Graphics workstation. At the PC price-point, fast hardware-accelerated 3D graphics wasn’t doable… until it suddenly was, thanks to Moore’s law. 3dfx was the first company to create fast 3D graphics for PC gamers. To get off the ground and get funded, 3dfx had to prove that their ideas were workable – and that proof came in the shape of a simulator. They used the simulator to demo their ideas, try out different design points, develop software pre-silicon, and validate the silicon once it arrived. Read the full story on my Intel blog, “How Simulation Started a Billion-Dollar Company”, found at the Intel Developer Zone blogs.
Doing continuous integration and continuous delivery for embedded systems is not necessarily all that easy. You need to get tools in place to support automatic testing, and free yourself from unneeded hardware dependencies. Based on an inspiring talk by Mike Long from Norway, I have a piece on how simulation helps with embedded CI and CD on my Software Evangelist blog on the Intel Developer Zone.
I have a two-part series (one, two) on testing posted on my Software Evangelist blog on the Intel Developer Zone. This is a long piece where I get back to the interesting question of how you test things and the fact that testing is not just the same as development. I call the posts Mindset and Toolset
It is really sad that the European Space Agency (ESA) lost their Schiaparelli lander last year, as we will miss out on a lot of Mars science. From a software engineering and testing perspective, the story of why the landing failed rather instructive, though. It gets down to how software can be written and tested to deal with unexpected inputs in unexpected circumstances. I wrote a piece about this on my blog at the Intel Developer Zone.
Intel CoFluent Technology is a simulation and modeling tool that can be used for a wide variety of different systems and different levels of scale – from the micro-architecture of a hardware accelerator, all the way up to clustered networked big data systems. On the Intel Evangelist blog on the Intel Developer Zone, I have a write-up on how CoFluent is being used to do model just that: Big Data systems. I found the topic rather fascinating, how you can actually make good predictions for systems at that scale – without delving into details. At some point, I guess systems become big enough that you can start to make accurate predictions thanks to how things kind of smooth out when they become large enough.
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.
I am going to present a paper about our new SystemC Library in Simics, at the DVCon Europe conference taking place in München next month. The paper is titled “Integrating Different Types of Models into a Complete Virtual System – The Simics SystemC* Library”, and I authored it together with my Intel colleagues Andreas Hedström, Xiuliang Wang, and Håkan Zeffer.
On my Intel Software Evangelist blog, I just published an updated version of an interview I first published back in May, about how to use Intel CoFluent Studio for IoT system architecture. This is a really cool story, about how you can use a calibrated simulation model to architect and analyze software performance before actually writing the code! I
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.