Posted by Achim Nohl on June 28, 2012
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.
We in the Virtual Prototyping industry assume that the most logical action for today’s software developer is to use models which allow the creation of an exact virtual prototype (VP). The reality is that use of models is growing but largely dominated by a small segment of the software community who work in semiconductor companies. The concept of models is the accepted way ESL/EDA/CAD- centric engineers address the lack of hardware problems. This industry is still the primary source for Virtual Prototypes which have evolved as a use model for SystemC/TLM, next to hardware-centric design tasks such as high-level synthesis and verification. However, this may not completely fit into a software developer’s comfort zone yet. Back to the EDA/ESL/CAD world, there is a long-standing debate about model timing accuracy versus actual hardware. I contend that more important than timing accuracy, is the understanding of the constraints in which the results are useful or needed. This is an engineering skill that often differentiates the good from the great engineers. The presenter of the above Linaro example has identified a key shortcoming and points out that only the user space software performance is scaled down and the OS kernel performance is not impacted. And yet the approach is accurate enough, if this constraint or shortcoming is taken into account when interpreting the results. A software-centric perspective needs to be applied to what is “good enough” when using models for software development purposes and not applying an EDA perspective.
Those of us who work with virtual prototypes (VP) know that virtual prototypes would have been a very good choice in the example above. Specifically, a VP would have addressed the key shortcoming around the performance scaling of the kernel routines. Using a VP, the performance asymmetry of the CPUs could have been reflected by simply changing the clock frequencies. Furthermore, even the real binary big.LITTLE software stack could have been simulated. VPs were built for easy controls and non-intrusive debugging. But, in order to get VPs used by embedded software developers, we need to put them into a software developer’s comfort zone. In order to get there, VPs have to be as “out-of-the-box” as other software development targets, such as physical development boards. And it also needs to support reference embedded software stacks like Android and Linux. Finally, the VP tools need to be seamlessly integrated into the software developer’s standard tools (IDEs, debuggers, configuration management, testing frameworks). Understanding how the software developer uses tools are critical to the adoption of VPs becoming a natural choice. Once VPs are software friendly, developers will realize the full benefit of visibility, control and convenience of VPs as a development kit and not just for bare-metal simulation.
To take tangible steps in understanding the software developer, a step we’ve taken at Synopsys, is our focus on a well-known development board for ARM CPUs within the embedded software community, the “Versatile Express” prototyping system. Similar to a software development kit which is very familiar to a software developer, a “Virtualizer Development Kit” or VDK puts together in one convenient kit, a Virtual Prototype or target, tools and an installer so software development can begin without too much work. An advantage of our VDK is that we support new CPUs much faster than hardware ever could. ARM’s FastModels for the Cortex CPU family typically have a head-start of at least twelve months compared to hardware availability. By pairing models with a virtual motherboard and a comprehensive set of peripheral IP, such as USB 3.0 a path to earlier software development emerges. The result for the software developer is a huge head start on developing an ever increasing amount of software solutions. To complete the story I started with, I am seeing an increasing number of developers at Linaro use ARM’s FastModels to do more of their development. As models deliver on their development value, they will become the pragmatic solution for early software development.
Patrick Sheridan is responsible for Synopsys' system-level solution for virtual prototyping. In addition to his responsibilities at Synopsys, from 2005 through 2011 he served as the Executive Director of the Open SystemC Initiative (now part of the Accellera Systems Initiative). Mr. Sheridan has 30 years of experience in the marketing and business development of high technology hardware and software products for Silicon Valley companies.
Malte Doerper is responsible for driving the software oriented virtual prototyping business at Synopsys. Today he is based in Mountain View, California. Malte also spent over 7 years in Tokyo, Japan, where he led the customer facing program management practice for the Synopsys system-level products. Malte has over 12 years’ experiences in all aspects of system-level design ranging from research, engineering, product management and business development. Malte joined Synopsys through the CoWare acquisition, before CoWare he worked as researcher at the Institute for Integrated Signal Processing Systems at the Aachen University of Technology, Germany.
Tom De Schutter
Tom De Schutter is responsible for driving the physical prototyping business at Synopsys. He joined Synopsys through the acquisition of CoWare where he was the product marketing manager for transaction-level models. Tom has over 10 years of experience in system-level design through different marketing and engineering roles. Before joining the marketing team he led the transaction-level modeling team at CoWare.