Guest blog by Achim Nohl
The recently announced Synopsys IP Accelerated initiative perfectly illustrates how the functionality of a device is equally influenced by the hardware and the software. To enable applications on a particular device to use the interface IP like USB or Ethernet, a software program called a device driver is required to map the generic requests to the underlying hardware functions. Writing a device driver requires an in-depth understanding of how the hardware and software work for a given platform function.
As virtual prototyping has seen a wide adoption over the last couple of years, it felt like the right time to work with industry leaders across multiple applications and publish a book that captures the best practices in virtual prototyping. As editor of the book: Better Software. Faster!, I had the privilege to work with some incredibly knowledgeable people who have been deploying virtual prototypes for many years. The book captures the main benefits of virtual prototyping as the key methodology to shift left the design cycle: namely reduce the overall time-to-market by starting software development before hardware availability. Better Software. Faster! features case studies and best practices from companies across mobile, consumer, automotive and industrial applications including: Altera, ARM Bosch, Fujitsu, General Motors, Hitachi, Lauterbach, Linaro, Microsoft, Ricoh, Renesas, Siemens, Texas Instruments and VDC Research. As editor I can of course not do anything less than recommend you read the book, but really … do read the book ;-).
Last week I was traveling across North America visiting customers. Besides being amazed at how cold it is in the rest of North America (I live in Silicon Valley where the sun has barely left us during the entire winter), it was good to talk to a wide variety of companies and discuss their software development needs. We encountered three types of companies considering the use of virtual prototyping to pull in their software development schedule:
Watching the Olympics this past summer was quite exciting. I enjoyed seeing athletes at the peak of their performance and multiple records broken in many sports. What we don’t see is the years of practice and work behind this excellence. These athletes work at the technique, strength, endurance and mental attitude of winning. To me, this is no different than the work that goes on behind the scenes of a new chip introduction or for that matter, any new product introduction.
Developing embedded software often requires a physical target to run software for the purpose of validation and debug. As is often the case, the exact hardware may not exist yet. The software developer is faced with a few choices: explore using models, use a previous generation board or consider another solution where the exact hardware is available. Most software developers generally try to find a solution that is “good enough”, yet pragmatic, which serves their time and cost requirements. For example, in order to work on the Linux scheduler for big.LITTLE processing, software developers used “old” hardware such as those presented at the recent Linaro Connect event. Software developers gave an example of this exact scenario and how they leveraged “old” hardware to complete their Linux scheduler development for big.LITTLE processing. Here, the performance asymmetry of an ARM Cortex-A15/A7 MPCore big.LITTLE processing system is emulated using an off-the-shelf Cortex-A9 MPCore board In the case of big.LITTLE processing, two CPUs with different performance characteristics are combined together, while the Cortex-A9MPCore has common CPUs with identical performance. To mimic big.LITTLE processing on the Cortex-A9MPCore, asymmetry is emulated by running a so called “cycle stealer” software process on one of the Cortex-A9 CPUs, resulting in reduced processing bandwidth on the second CPU. This solution creates a set up that mirrors the expected big.LITTLE processing capabilities and the software under test takes longer to run on one CPU, than it takes for the same software to run on the second CPU. Is it cycle accurate? For sure not, but this is certainly a pragmatic, “good enough” solution to start optimizing the Linux kernel scheduler.
In the last month, I had the opportunity to get some hands-on experience with hardware virtualization and hypervisors. My knowledge so far on this has been mainly limited to what I could read about it and what other people are saying about it. However, the PowerPoint slides I’ve seen leave a lot of white fog between the bullet items. This didn’t make me feel very comfortable talking about this topic myself; but, there was no escape. Hypervisors play an increasingly important role for system designers in context of supporting multiple guest operating systems on the same device, or taking advantage of ARM®’s new big.LITTLETM processing. The fog is not all gone, but let me provide you some insight on what I found out. As a disclaimer, I’m not going to (and I cannot) write an expert almanac about all the aspects of virtualization covering Xen, VMWare, etc. Instead, I’m going to focus on my personal experience that I believe will be relevant to you as well. This post is the starting point for a series on this topic in this blog.