Software developers have a love-hate relationship with hardware development boards. On the one hand, they make software come to life. On the other, they can cause headaches, especially since development schedules depend on their availability. Limited visibility in development boards’ behavior for software debugging and analysis often forces developers to use more complex approaches. And sometimes they simply do not work the way developers expect. Virtual hardware platforms can help resolve developers’ frustrations by executing software quickly and thus shortening development cycles.

Complex multicore platforms such as those used to design cellular base stations are increasingly presenting challenges for software developers, compounding the reasons why they tend to despise hardware development boards. A recent RadioFrame Networks design project demonstrates this dilemma, which leads to developers’ double-edged relationship with hardware.

An alternative development methodology

After the initial hardware specification, the development team considered using a reference development board that slightly resembled the preliminary hardware design. None of the design peripherals or the DDR RAM controller would have matched the development board; however, there was nothing else available at the time. Once the final hardware became available, developers would have had to blindly write and then modify the software because they did not have all the hardware components on the reference board. It was the only method they thought they could use to get the job done.

Then the development team came across virtual platforms for software development, a type of technology that simulates hardware models and executes software at speeds close to real time. Although developers were interested in this concept, they had some reservations stemming from a lack of understanding about the modeling technologies and methodologies used to create a virtual hardware platform. Developers wondered if the flash model would be common flash interface/scalable command set compliant and if the new MAC controller would be functional enough to provide a head start on developing the driver. Since the ARM core selected for the ASIC did not use the full ARM instruction set, developers wanted the virtual hardware platform to capture illegal instructions attempted by the kernel as well as trap and report illegal register writes.

As the team started the project, it became clear that some of the concerns were not warranted. They quickly learned that modeling uses a standard language called SystemC, a subset of C++ specifically designed for modeling hardware, and a methodology called transaction-level modeling. The concepts in SystemC were very natural to the developers; thus, modeling the flash in this project was not an issue.

Using this technology saved modifications from session to session. Although the specific core in this case was not modeled, developers still gained control over simulation and stopped execution when illegal instructions occurred, which they accomplished by using a Tool command language (Tcl) scripting feature.

During initial modeling, developers discovered that communication between software and modeling teams was essential to understand what could be achieved with a virtual hardware platform. They learned that they needed to consider virtual hardware platform modeling itself and pay attention to peripheral models and the functionality they support. Developing the virtual hardware platform involved interaction between IP and tool suppliers. After a few weeks of modeling, developers started using the virtual hardware platform to commence software development.

Fast feedback, simulation

The initial software development task was to develop a Linux support package and U-Boot monitor. From the outset, the virtual hardware platform provided valuable feedback, giving developers the ability to determine if they were on the right track. Oversights in the initial assumption for the board support package development were quickly captured and solved.

One specific issue involved the advanced high-performance bus controller. Support had to be included for swapping flash and DDR RAM during the initial boot. The virtual platform quickly helped developers identify and correct how the jump was set up – a simple feature available in the virtual platform, but one that would have required a JTAG tool to catch it in the physical hardware. The modeling done in the platform enabled developers to not only instrument the code but also instrument the platform. The virtual hardware platform provided a view of any and all peripheral states, if desired, without affecting the operation.

During the software development process, the Virtual Platform Analyzer from CoWare (Figure 1) allowed developers to observe and control the virtual hardware platform and use it to efficiently trace peripheral block accesses by initiators. In particular, breakpoints could be placed on peripheral block accesses and specific debug messages could be used through a Tcl application programming interface. The same Tcl scripting capability also enabled developers to adapt the virtual hardware platform to their development needs and thus validate programming of the hardware configuration in the firmware by simulating timing-related configurations without requiring models to be time-accurate. As a result, the team enjoyed fast simulation speed and avoided having to wait for the physical hardware.

Valuable insight into code

In this project, using a virtual hardware platform shortened the development cycle by 33 percent compared to using the physical hardware. The virtual hardware platform provided a pre-silicon software development testing environment. In addition, its unique debug and analysis capability made it superior to similar debug and analysis capabilities provided on the physical hardware.

Given the success of this project, it is evident that virtual hardware platforms can significantly improve productivity in software development teams. With a rapid increase in multicore platform development, the level of visibility provided by a virtual hardware platform can give application developers insight into code they could not see before without specialized equipment.

Therefore, developers should consider using a virtual hardware platform to correct code. The value of doing so far outweighs the initial modeling investment. Communication, education, expertise, and other advantages gained from virtual hardware platform technology suppliers such as CoWare can alleviate any concerns.

To appreciate the technology, consider the benefits of white-box testing versus black-box testing. Making the hardware set logging levels allows developers to record various accesses performed by the operating system and application programs. Designers also can place hardware breakpoints on register accesses down to the bit level, visually verify changing states on interrupts and other discrete signals, and extend the virtual hardware platform’s capability through Tcl script procedures such as setting hardware watchpoints and breakpoints. Most importantly, developers can accomplish all this on their workstations without complex hardware setup, cables, and unstable hardware boards.

No more waiting for hardware

Virtual hardware platforms promise a bright future for developers, sparing them the pain of waiting for hardware availability and providing debugging capabilities that would not be possible with hardware development boards. Virtual hardware platforms are definitely productivity-proven, production-ready tools for software developers in this decade and beyond.

James Clough is currently working as platform software engineer at RadioFrame Networks, a complete radio access system provider based in Redmond, Washington. James has more than 20 years of experience in embedded systems development, covering a wide range of embedded operating systems, including VxWorks, Linux, pSOS, and Windows CE as well as various hardware architectures, including PowerPC, ARM, MIPS, XScale, and 68K cores. He attended the University of Washington.

RadioFrame Networks
[email protected]
www.radioframe.com