You may have heard that "virtual platforms" enable software development and debugging before system hardware is available. But how do you build them, how do you solve common problems, and how do you debug software and hardware for multi-core systems? These questions and more were answered in a paper presented at the recent ARM TechCon conference by Jason Andrews, senior architect at Cadence.
The paper was titled "Creation and Usage of SystemC Virtual Platforms for Multi-Core System Debugging and Analysis," and was given Oct. 27. Proceedings are available to conference attendees at the ARM TechCon web site. A video of the presentation is available here and is also embedded below.
A virtual platform, Andrews noted, makes it possible to simulate hardware using SystemC, and to then run software on top of that simulated hardware. "It's all simulation," he noted. "Everything you'll hear about today runs on a workstation - no boards, no cables." While simulation has been used for software development for many years, the commercial virtual platform market is relatively new. Two standards that make this possible are SystemC (IEEE 1666), a set of classes on top of C++, and the Open SystemC Initiative (OSCI) transaction-level modeling (TLM 2.0) standard, which permits a high level of modeling abstraction.
As shown in the following diagram of the Cadence System Development Suite, virtual platforms are part of a larger hardware/software development continuum, and are used very early in the design flow:
To show how virtual platforms are created and how they work, Andrews used an example of a multi-core design. It includes a dual ARM Cortex-A9 processor with an L2 cache, an ARM Cortex-M3 processor, LPDDR2 controller, SRAM, ROM, UART, and timers, among other components. He then walked through a detailed example showing how a virtual platform was created for this design. Some of the key steps included:
- Generating SystemC TLM models for peripherals using an automated model generator
- Producing a register description (both individual registers and register banks)
- Customizing the generated model, adding the "behavior behind the registers"
- Using a memory map for the dual Cortex-A9
- Using ARM Fast Models for the processors (don't write SystemC models for these!)
What you end up with is a virtual platform that contains Fast Models for the ARM processors and SystemC models for all the peripherals. The ARM models take binary instructions and run software on a laptop or workstation at a very high rate of speed.
When designers plug everything together, Andrews said, "it never works" the first time. He reviewed a number of common problems that arise with virtual platforms. These include system integration issues such as a program memory that's too small, device driver crashes due to missing hardware, and problems with interrupts. The Direct Memory Interface (DMI), which lets SystemC models read directly into memory, is also a potential source of problems. Andrews also reviewed common problems made during model creation.
Andrews then showed how to set up a secure boot sequence for the Cortex-A9 and Cortex-M3, and reviewed potential problems such as poor synchronization of access to shared RAM and difficulties with the interrupt configuration.
Virtual Platform Debugging
Once the platform Is set up and simulation is running, designers will want to start debugging. "The first thing everybody tries is debugging software," Andrews noted. This can be done with a software debugger that shows what's going on in the various processor cores, displays register values, allows single-stepping, and provides other features one would expect from a software debugger. But just looking at software may not enough. Multi-core systems use frequent interrupts, and problems with interrupts are common.
"Now you're thinking you want something like a logic analyzer, and you want to see all the interrupt lines," Andrews said. "Well, in a virtual platform you can see hardware behavior that is harder to see on your board." This was a common theme in the presentation - that virtual platforms make it possible to observe hardware behavior that would be difficult to see in real hardware.
Andrews talked about the profiling capabilities available with virtual platforms, which can be used both to improve simulation speed and to make the system software and hardware implementation more efficient. While it's not easy to profile using real hardware, he noted, a virtual platform allows non-intrusive profiling without the need to instrument code. (For more information on profiling see Andrews' guest blog on the ARM web site, "Using the ARM Profiler with the Cadence Virtual System Platform.")
"For me, creating this type of virtual platform is fun," Andrews concluded. "You learn a lot and you see how things work." He also noted that a lot of companies are training or looking for "virtual platform engineers" who can create and debug the models. It's a chance to "be the hub for all the engineers working on your project," he said.
Click on the icon below to view the video of the presentation, or click here.
Other blog posts about ARM TechCon 2011 papers:
ARM TechCon Paper: New Methodology Eases Challenges of 32/28nm Designs
ARM TechCon Paper: "Tips and Tricks" for ARM Cortex-A15 Designs
ARM TechCon Paper: Why DRAM Latency is Getting Worse