Improving Software Driver Development and Hardware Verification Productivity using Virtual Platforms

By Frank Schirrmeister, Sam Tennent, Markus Willems
Synopsys, Inc., Mountain View, CA

Introduction

Over the course of the last decade, the cost of software has become the undisputed dominant factor in electronics design. Software development has fundamentally changed the shape of the electronics industry, from large integrated device manufacturers (IDMs) to a complex disaggregated design chain of heavily interacting companies. Hardware intellectual property (IP) providers deliver blocks and subsystems to semiconductor companies, who in turn deliver chips and board subsystems to system houses who increasingly seek differentiation through software. All of the hardware-related players interact with software providers who create everything from low level drivers to complex end-user applications.

The recent Nokia divesture of hardware efforts to STMicroelectronics combined with the full acquisition of Symbian is a good example of the increased differentiation through software in system houses. These steps allow Nokia to sharpen their focus in the key differentiating areas of software, services and specialized hardware (e.g., modem design.). Apple CEO Steve Jobs spelled it out explicitly; "Phone differentiation used to be about radios and antennas and things like that. We think, going forward, the phone of the future will be differentiated by software." [1].

This paper analyzes the root causes of escalating software development effort. It will highlight software driver development, specifically for traditional intellectual property (IP) models like USB, PCI-e, SATA and DDR, as a key factor in time-to-market results for combined hardware/software products. The paper will outline how higher abstraction layers of the hardware allow some areas of software development (i.e., drivers, middleware and OS’s) to become largely independent of the target hardware architecture. We will introduce virtual platforms and FPGA prototypes as key ingredients to expedite the availability of suitable development targets for software development and software driven hardware verification. We will outline the importance of IP models and different views for them at the implementation and transaction level, detailing how going forward specifically TLM views of the IP will be required as part of the actual selling process. Using the example of the Synopsys DesignWare® High-Speed USB On-The-Go (OTG) controller, we will show how the specific challenges for software driver development productivity – early availability, visibility and control - can be addressed using virtual platforms and applied to other complex IP blocks.

Software Determines the Success of Chip Development Projects

Ever since Moore’s Law was formulated, hardware designers have been in a race to fill up complexities offered by more and more silicon real estate. In the last decade, software has gained more and more importance as part of chip development. This trend is largely driven by the flexibility requirements of a diverse set of application domains, particularly those serving consumer markets. Recent market research (IBS) shows that especially in process nodes smaller than 90nm, the effort of software development already exceeds the hardware effort (Source: [2]). With the rising non-recurring engineering (NRE) cost of chips at smaller geometries, the investment to develop them has to be recovered over a wider range of products and product generations. In addition, to properly recuperate investments, not only the “time to market”, but also the “time in market” (the time how long a chip can be used in a specific market) needs to be optimized by allowing customization and feature extensions to accommodate the increasing influence of end-users. Customization through software can be relatively low-cost compared to hardware customization and can support fast time-to-volume for new products.

In addition, International Business Strategies, Inc. (IBS) predicts that at 65nm more than 90 percent of system IC designs will be implemented with embedded processor cores. Adding software functionality to these specific processor cores allows a wide set of system features to be supported, with relatively low costs for adding new features.

To understand the reason for the dominance and importance of software in modern electronic devices, it is important to understand the design flow as it is practiced most often today. As an example, we will analyze the hardware architecture of the Freescale i.MX31 multimedia application processor and its associated, complex layered software architectures executing on it. It will also outline design flow dependency issues in current design projects, in which software development has to wait for hardware to be available.

Given the disadvantages of the traditional serial design flow, developers have been looking for prototyping techniques to reduce the overall product turnaround time. Some of these techniques are indicated in Figure 1, contrasting the original serial design flow with an updated, parallelized design flow.


Figure 1 – Parallelized hardware-software design flow using prototyping

In a derivative design, a portion of the software can be developed using the previous-generation chip. This approach often works best for the portions of the software higher up in a layered software-architecture stack, specifically the hardware independent application software. However, given that the register fields are updated and enhanced from on chip generation to the next, this approach is difficult for lower-level portions of the software like drivers and middleware.

Later in the design flow, after the RTL is complete and has reached a stable state using functional verification techniques, FPGA prototypes can be used. They should be a pre-silicon, fully functional hardware representation of the SoC, board and I/O implementing unmodified ASIC RTL code. Optimally implemented, they can run at almost real-time with external interfaces and stimulus connected, and provide, in conjunction with hardware simulators, much better system visibility and control than the actual silicon prototype.

Virtual platforms offer a solution very early in the project, as soon as the architecture of the design has been worked out. Virtual platforms are a pre-RTL, register accurate and fully functional software model of SoC, board, I/O and user interfaces. They execute unmodified production code and run close to real-time with external interfaces like USB as ”virtual I/O”. Because they are fundamentally software, virtual platforms provide high system visibility and control including multi-core debug. And they can serve as an elegant vehicle of interaction between semiconductor and system house. Since the recent standardization of the OSCI TLM-2.0 transaction-level APIs, SystemC™ has become the suitable infrastructure to develop fast virtual platforms using interoperable transaction-level models and is supported by a variety of commercial products including Synopsys’ Innovator product line.

Even after FPGA prototypes and the actual silicon are available, virtual platforms continue to be used as software development kits (SDKs). Popular examples are the Nokia S60 SDK for the Symbian OS and the Apple iPhone SDK including an iPhone simulator, which were downloaded more than 100,000 times in the first four days of its availability. Some SDKs like the Metrowerks Symbian Development Kits may also include hardware for timing accurate software development.

In the following sections we will introduce the example of a driver development for the Synopsys DesignWare USB OTG controller. We will show how the use of virtual platforms accelerated the overall project by eight weeks for a derivative IP product.

Different View for Universal Serial Bus (USB) IP

USB enables cost-effective “outside-the-box” connectivity with hot-swap capability for industrial, consumer, embedded, PC, and PC peripheral products. USB requires a host to manage and control bus traffic to and from USB peripherals such as hard drives, cameras, flash card readers, printers, and scanners. USB peripherals must manage data translation between the peripheral application and the USB Host. OTG products typically must handle both host and peripheral functions and switch between the roles.

When integrating USB logic into a design, users face a make or buy decision. They can develop the block on their own or license predefined, configurable implementations from an IP provider. Synopsys provides a complete, integrated, silicon-proven USB IP solution consisting of a suite of configurable digital controllers, mixed-signal PHY, and verification IP.

The DesignWare USB IP is certified compliant to the USB 1.1, 2.0 and On-The-Go (OTG) standards. Integration risk is lowered with a single vendor solution by testing to ensure that all the IP functions (controller, physical interface and driver) work seamlessly together. Together with the USB IP itself, Synopsys provides a reference driver as well, enabling developers to design USB host, peripheral, and OTG products. The source code is available on a Linux/ARM9™ platform and is the same code used for all certification and interoperability testing.


Figure 2 – USB Device in virtual platform connected to real-world host

Transaction-level models corresponding to the implementation IP are used to build virtual platforms. Figure 2 shows the representation of a chip design at both the signal and transaction-level. The design contains a microprocessor, an AXI bus, SRAM, ROM, a bridge from AXI to AHB and low speed peripherals for I2C and UARTs connected to the AHB bus. High speed peripherals for USB, PCIe and DDR 3/2 memory are connected to the high speed bus.

The design is shown at two different layers: the signal-level used for implementation and the transaction-level used for virtual platform execution for pre-RTL software development. The transaction-level design is in Figure 2 also connects to peripherals, the user interface and a general virtual representation of the end product shown as the “virtual skin” of a media player. High speed peripherals such as USB are also connected to real-world interfaces using virtual I/O, i.e., the USB port in the virtual platform can connect to the USB host on the machine on which the virtual platform executes. To interface between the transaction-level and signal level, transactors translate between the two levels and are typically part of Verification IP (VIP).

Some users may need TLM models reflecting other USB implementations. For this case, the USB Model Authoring Kits (MAK) included in the DW SLL enables a head-start for developers, accelerating the development of the transaction-level model. Specifically, the Enhanced Host Controller Interface (EHCI) and Host Model Authoring Library provide generic USB functionality which can be extended by model developers to implement specific model characteristics like the actual register definitions. The libraries support C++ and SystemC model development and contain support for connecting to real-world devices and for test purposes, allowing virtual USB devices to be loaded into and exchange data with the host operating system.

Driver Development Challenges

Writing device drivers requires an in-depth understanding of how a given IP and platform functions, both at the hardware and the software level. Because many device drivers execute in kernel mode, software bugs often have much more damaging effects to the system. This is in contrast to most types of user-level software running under modern operating systems, which can be stopped without greatly affecting the rest of the system. Even drivers executing in user mode can crash a system if the device being controlled is erroneously programmed. These factors make it more difficult to diagnose problems, and the consequences of problems more impactful.

Virtual platform offer several instruments to ease the development, debug and verification of device drivers. Sequence of the device negotiating with the USB Host controller can be displayed in monitor windows, SystemC TLM-2.0 transaction monitors trace the transactions actually passing into the USB OTG Controller in the virtual platform. Software debuggers can be attached to the processor cores in which the actual driver software can be traced. Stopping and starting the platform is possible from the debugger and the actual virtual platform GUI. Breakpoints can be set in the software, the hardware models itself and the transaction interfaces of the USB OTG virtual device controller. The amount of insight and control developers gain by using virtual platforms greatly increases software development productivity because traditional “trial and error” approaches are replaced with a predictable and repeatable software development process.

Virtual Platform Use Models for USB Driver Development

There are two basic use models for virtual platforms supporting driver development in the context of a USB core.

First, a virtual platform can be used to model a device like a digital still camera, a USB video camera or a media player. Using Virtual I/O capabilities for software emulation of device I/O, the virtualized product can be connected to a Windows or Linux host on which the host controller resides and connects to the USB device. This process is illustrated in Figure 3.


Figure 3 – USB Device in virtual platform connected to real-world host

In this case the virtual platform simulates the USB device in question. The USB Device Controller model is part of the virtual platform and an ARM processor runs the device driver and application software within the virtual platform. A software debugger can be attached to the processor in the virtual and the function of the device driver can be developed and verified on the virtual platform long before RTL or silicon are available. In addition, the USB application software running on the device – a data transfer program for media files in the example of Figure 3 – can be developed, debugged and verified.

Pushing the button “USB Cable Input” connects the virtual platform to the USB Host Controller on the host on which the virtual platform executes. In effect, all the steps happening when the real device is connected will happen in this case as well, i.e., the Windows operating system will inform the user that a new hardware device has been detected. Together with Synopsys’ virtual platform offerings, a virtual USB Hub Driver is provided. This Hub Driver interfaces to the Windows USB driver environment connecting the virtual hard disk in the media player to the

Windows Application (in this case Windows Explorer) in which the virtual hard disk appears as a new disk to interact with.

Figure 4 illustrates another use model. This time the virtual platform simulates the USB Host environment and the Host PC is connected to a real-world USB device. The real-world device, a memory stick, is connected the Host PC using the Host Controller Driver and Hub Driver provided by the Windows operating system. Synopsys provides a USB Client Device Driver to connect this real-world device to the host executing in the virtual platform. This way it is easy to develop, debug and verify host controller drivers and applications for different host operating systems.


Figure 4 – USB host in virtual platform connected to real-world device

USB Driver Development Case Study

After Synopsys’ initial USB OTG implementation, hardware support for descriptor-based DMA transfers had to be added as a feature. The new feature was added for the device mode only, which required the Linux software device drivers to be extended to support it. A virtual platform was used for developing and testing the required driver updates.

The software engineering team extended the existing drivers based on published IP textual specifications. At the same time hardware support for the descriptor-based DMA enhancement in the DesignWare OTG IP core was added, the virtual platform modeling team enhanced the transaction-level model to support the new feature. The software engineering team completely debugged and tested the basic driver functionality early on the virtual platform. As a result the driver became available 4 weeks prior to FPGA prototype availability.

In addition to the early availability of the device driver, the actual software bring-up time was reduced by four weeks after the hardware prototype became available. The most critical bugs had already been removed during the development using the virtual platform, the hardware prototype bring-up focused on timing critical issues.

Note this case study outlined a relatively simple derivative update of an IP core; even more savings can be expected for developments starting from scratch or for more extensive IP updates.

Using Virtual Platforms for Functional Verification

While the main use-model for virtual platforms is pre-silicon software development, as the SoC design cycle progresses, a virtual platform can evolve to meet different needs. There are three main use models of “software driven verification”, which utilize the integration of virtual platforms with signal level simulation at the register transfer level:

• When an RTL block becomes available, for example, it can be substituted for its transaction-level model in the virtual platform. Software can then be verified on this version of the platform as a way to validate both hardware and software.
• The virtual platform can also provide a head start towards testbench development and post silicon validation tests by acting as a testbench component running actual system software. The virtual platform can be used to generate system stimuli to test RTL, and then verify that the virtual platform and RTL function in the same way.
• Additionally, as portions of the virtual platform are verified as equivalent to their corresponding RTL, the virtual platform can become a golden or reference executable specification.

Figure 5: USB Example in Synopsys Innovator


Figure 6: USB Verification environment

The interface from virtual platforms to traditional RTL simulation can be done using transaction-level interfaces, allowing the actual transactor to be written in SystemVerilog and the bus functional model to be synthesizable in order to allow co-execution with hardware based environments. Alternatively, the transactor can be written in SystemC and the interface to RTL simulation can be at the signal level.

The first use model – using TLM models to generate stimulus for RTL verification – allows early software validation on the actual hardware implementation, as well as efficient scalable system validation, for which software becomes part of the verification setup. Knowing that real system scenarios are used, does increase verification confidence. Furthermore, simulation used in verification is faster, given that as much of the system as possible is simulated at the transaction level.

The second use model – early test bench creation and development of post silicon validation tests on a virtual platform – allows development of all test bench and validation infrastructure on a virtual platform, as well as early scenario and test-case creation. Users can efficiently develop on the TLM model “embedded directed software” tests, which can be used for system integration testing. As a result productivity of verification test case development increases.

The third use model – verifying TLM platform and RTL equivalence – helps to validate the correctness of the software development platform against the RTL once it becomes available. As a result users gain a single golden test bench for the transaction-level and the RT level.

Figure 5 and Figure 6 illustrate the USB example of the case study in the Synopsys Innovator virtual platform development environment and the USB verification environment, respectively.

Summary

The case study for the Synopsys USB OTG driver development demonstrated an overall project savings was about 8 weeks. A savings of several staff-years of effort and months from the schedule can be realized if this is scaled to a more complex device like the i.MX31, which has more than 40 drivers to be developed and tested.

In addition to software driver development, virtual platforms have been successfully used for the development and porting of operating systems, middleware and all the way up to applications.

Sources

[1] Jobs: App Store could become a billion dollar marketplace, August 2008

[2] Global System IC (ASSP/ASIC) Service Management Report, Software Trends, November 2006