Virtualizer Development Kits: Fast Track to DesignWare IP Software Prototyping

Abstract

This article will introduce how Virtualizer Development Kits (VDKs) enable software prototyping and bring up for DesignWare IP. The article will illustrate the innovative board-level VDK construction concept which accelerates virtual prototype creation and illustrates how VDKs sit in the comfort zone of embedded software developers by leveraging the embedded software ecosystem for ARM’s Versatile Express reference board, including standard 3rd-party debug tools. The specific VDK software enablement capabilities for Synopsys' DesignWare IP will be explained by means of interface peripherals such as MMC, GMAC, USB and I2C.

Introduction

Virtual prototypes are unique in their capability to enable software development before hardware is available. Their exceptional debugging capabilities, which are enabled through their high degree of control and visibility, are crucial to getting software up and running in a timely manner. However, the step of creating a virtual prototype as a tool for earlier software development has been an uncomfortable hurdle. The building block of a virtual prototype is a TLM (Transaction Level Model) piece of IP. Creating virtual prototypes at the granularity of a TLM is the right approach to enable SoC-specific software development. But very often, the scope of embedded software development is not targeting an entire SoC, but a collection of IP. For example, a software developer may only need to focus on the development of the Linux driver and/or middleware revision of a mobile storage card. In this case the developer does not want to be concerned with creating a baseline virtual prototype with an embedded processor, timers, interrupt controllers, interfaces - all of which are needed just to boot the Linux kernel. Also, the developer does not want to be concerned with re-targeting the OS kernel to the specifics of this artificial system. Instead, the developer is looking for a working system that can be extended with the specific IP of interest in order to start immediate software development.

Virtualizer Development Kits

In order to address the software developer’s need to get to a usable virtual prototype as quickly as possible, virtual prototype granularity has increased for easier creation. Synopsys’ CoStart for Virtualizer Development Kit (VDK) packages enable the assembly of virtual prototypes in minutes using predefined virtual daughter boards instead of using atomic models.

Synopsys provides different families of VDKs for different vertical markets and application domains. The VDK families differ in the type of processor and peripheral IP they contain, as well as how they connect to the domain specific 3rd-party software ecosystem. In this article we will focus on the VDK family for ARM Cortex™, which is the virtual equivalent of ARM’s Versatile Express prototyping system. In the context of mobile and consumer software, this system is a de facto reference for the software development community when targeting the ARM Cortex-A CPU family. The Linux kernel, as well as Android, is continuously being maintained and enhanced by the ARM software community and this platform serves as a reference for mobile consumer SoC software development. The Synopsys VDK family for ARM Cortex extends this system with predefined virtual daughter boards for Synopsys DesignWare IP using models of the DesignWare TLM Library shown in Table 1.

Users of the family for ARM Cortex will benefit from the combined merit of always up-to-date OS support through the ARM community along with earliest access to DesignWare IP models and working reference software such as drivers and middleware. Furthermore, software developers will be able to take advantage of the debug capabilities provided by a VDK which allow non-intrusive, repeatable, deterministic debugging and system wide visibility into all hardware and software aspects.

Customizing the VDK

As introduced earlier, a VDK can be customized using the CoStart for VDK package. The CoStart for VDK for ARM provides the following virtual daughter boards which can be assembled and configured by the user:

• A virtual motherboard of the ARM µATX Motherboard Express
• Virtual daughter boards (CoreTile Express) for ARM Cortex CPUs including Cortex-A15 and big.LITTLE
• Virtual daughter boards for Synopsys DesignWare IP such as USB 2.0, USB 3.0, SATA, Ethernet GMAC, Mobile Storage, I2C etc.

The Motherboard Express µATX has been defined by ARM to support future generations of ARM processors. It includes all the necessary peripherals to enable porting, developing, and validating operating systems and applications for new ARM processors. The VDK’s virtual motherboard replicates all peripherals which are relevant for software development. The virtual CoreTile Express daughter boards are used together with the virtual Motherboard Express µATX for prototyping with the Cortex™-A processors. The virtual daughter boards for Synopsys' DesignWare IP plug into the virtual Motherboard Express µATX using the custom logic expansion capability of the Versatile Express system. In real hardware this is done through so called “LogicTiles”. LogicTiles are daughter boards with different sized FPGAs. The virtual daughter boards for Synopsys' DesignWare IP provide the same interfaces as LogicTiles. However, instead of providing FPGAs, models of the DesignWare TLM Library are hosted on the daughter boards. In the remaining article we will describe the details and use cases for DesignWare daughter boards.

The CoStart for VDK provides a GUI for the configuration of the VDK. As shown in Figure 3, the user can select virtual boards from a library of ARM and Synopsys boards.

Each daughter board can be easily configured with a set of parameters such as interrupt, address offset and other IP specific parameters. Once the configuration is complete, a VDK is generated and immediately ready to use for software development. A packaging flow also allows the creation of self-contained installers which can be passed along to the software end users and doesn’t require installing other Synopsys or ARM tools. 

Custom Daughter Boards

The user is also able to modify and extend all daughter boards. As an example, the user is able to add additional I2C devices such as an accelerometer and attach them the DesignWare I2C controller. The user can even create custom daughter boards. For this purpose, the Synopsys Virtualizer™ tool set provides graphical authoring tools and access to the DesignWare TLM Library. Daughter boards can be of arbitrary complexity and host multiple processor cores and mix of DesignWare IP and/or any other TLM models. For example, the DesignWare ARC AS221BD processor daughter board for the ARM VDK is hosting a DesignWare SoundWave Audio Subsystem containing the ARC AS221BD dual core processor. Daughter boards have well-defined interfaces to the high speed memory bus, peripheral bus, configuration and system bus of the motherboard, so the developer isn’t burdened with having to know the deep details of these interfaces; instead, the developer leverages an easy to use API that allows the connection to these interfaces. This way, daughter boards are highly reusable for different and future motherboards and can be even used as a subsystem for a custom SoC connecting to the specific interfaces of the SoC. The advantage of creating a VDK daughter board for an IP subsystem is the ability to immediately leverage the application processor subsystem of the CoreTile daughter board and ARM-based motherboard and begin embedded software development earlier with the readily available Linux and Android software images and build system. As an additional reference, we have introduced the process of creating a custom daughter board for an ARM Cortex-M3 based sensor subsystem in a recent article. 

Embedded Software

All virtual boards come with ready-to-use reference drivers and middleware to illustrate DesignWare IP usage in the context of Linux and Android. For example, a working USB 3.0 driver and a gadget file system application serves as a reference for further extension, updates or porting to a different OS. As introduced earlier, users can take advantage of a broad embedded software ecosystem. All embedded software, OSes or application notes around the ARM Versatile Express prototyping system can be applied identically to the VDK, without any rework. The VDK is able to run the same binary software images (e.g. a kernel or file system image) that a hardware based system would run. Thus, Versatile Express Linux and Android software images from organizations such as Linaro can be directly executed on the VDK.

Currently, the VDK for ARM Cortex is provided with Linux 2.6.38 and Android 2.3 (Gingerbread). In the first quarter of 2013, Linux 3.6 as well as Android 4.2 (Jellybean) will be included, along with an upgrade to the novel Linux Device Tree system which aims to ease support for new SoCs through a runtime configuration. Also, the drivers for the DesignWare daughter board are upgraded in context of the VDK. The VDK includes a typical Linux development file system which is based on the buildroot project. All of the above mentioned software comes as ready-to-use compiled binary images in combination with source code and scripts to download and build all open source components.

Software Debugging

The VDK provides dedicated debug and analysis tools, which allow the software developer to take full advantage of a virtual prototype. Given the primary goal of VDKs is to sit in the comfort zone of the embedded software developer, the most popular software debug tools and IDEs are supported by a VDK. This comprises open source tools such as GDB/Eclipse, as well as commercial tools such as ARM’s DS-5, Lauterbach’s TRACE32, Google’s SDK for Android and others. When working with debug tools and the VDK, a compelling advantage of virtual prototypes becomes accessible to the software developer: non-intrusive debugging. If the system is suspended by one debugger, it means that the entire system is suspended. During this time, all components of the system halt-no timers expire, no watchdog peripherals time out. This is specifically beneficial for debugging aspects such as interrupt handlers, an integral part of almost every driver. A breakpoint in an interrupt handler, within a hardware system, can be very dangerous. Since the OS kernel is halted, it will not be able to handle the expiring watchdog timer forcing the system to reset during debugging. Using a VDK, the watchdog timer is also stopped and interference through debugging will not occur. 

To learn more about debugging using VDKs, refer to our web page.

DesignWare IP

This is an example of a VDK for ARM Cortex for software development in the context of several DesignWare IP cores. For interface IP, it will specifically highlight how the connection to the real world is established. We will also introduce debugging and testing aspects via a VDK. 

USB

The DesignWare TLM library for USB is comprised of USB 2.0 and 3.0 controller cores as well as physical interfaces (PHYs). The VDK for ARM Cortex provides the following virtual daughter boards:

• USB 3.0/USB 2.0 OTG: The USB 3.0 daughter board assembles a USB 2.0/3.0 controller model along with a USB3300 PHY model
• USB 2.0 Host: The USB 2.0 Host daughter board assembles a DesignWare USB 2.0 host controller model along with a model of the DesignWare USB 2.0 nanoPHY

Both, the controller and PHY models are highly parameterized in order to match the application in hardware set up through IP configuration via the Synopsys coreConsultant™ tool. In host mode, the PHY models feature real world I/O also known as virtual I/O. This allows the models to connect to and control a physical USB device plugged into the computer hosting the VDK. In device mode, the model features virtual I/O which allows the model to appear as a device plugged into the computer hosting the VDK. The virtual I/O can be controlled using a graphical user interface as shown in Figure 5.

When launching the VDK and booting up the prebuilt Linux distribution, the kernel automatically detects the USB daughter board via information provided through the daughter board configuration bus. This includes the detection of the base address and interrupt. Via the ability to auto-detect, the user can define arbitrary daughter board combinations and configurations without having to edit and rebuild the Linux kernel. The VDK’s Linux file system provides the necessary scripts to easily launch the USB 3.0 gadget driver as shown in Figure 6. Here, the virtual VGA console of the VDK is used to issue commands. Shortly after plugging in the cable using the control GUI, the Windows host which runs the VDK recognizes a new device: the USB mass storage provided by the Linux running on the VDK.

Based on the ability to provide virtual I/O, the DesignWare controller and PHY models allow interaction within the environment - in this case, the Windows host OS shown in Figure 6 above. Now, the user can populate the device using the standard Microsoft Windows explorer tool and files become visible to the Linux kernel running on the VDK.

DesignWare Software Debugging

VDKs provide a rich set of features which ease and accelerate bringing up drivers and middleware for DesignWare IP cores. Models are developed to provide clear information providing the software developer with log messages directly generated from the model. These log messages are very useful when it comes to spotting unexpected behavior through errors in low level drivers. For example, a model is able to inform that no power and/or frequency are supplied while the driver is trying to access a register. Furthermore, models are even able to catch problems in the programming sequence such as changing a control register while interrupts are enabled. Both flaws are typical mistakes in low level drivers and can easily cost days, if not weeks of debugging. The model log capabilities are able to pinpoint the user to a large amount of mistakes.

In order to narrow down the problem from the symptom to the root cause, the VDK provides a debug environment (called Virtual Prototype Analyzer) allowing the user to control and inspect the hardware and software aspects. Let’s assume that the CPU would not trigger the interrupt handler once the USB cable is plugged in. Using the VDK, we can put a watchpoint on the “attach-signal” of the USB PHY model such as shown in Figure 5. Thus, from the exact point in time when the cable is connected, the user can follow the chain of events through raising an interrupt, propagating the interrupt to the interrupt controller and causing an exception in the OS running on the CPU. Here, the user is able to inspect and watch each and every register and all signal components.

In order to perform efficient driver debugging, such as the USB 3.0 - interrupt handler, the VDK provides the capability to automatically load the DesignWare driver symbols on demand. This is enabled through an extension of the VDK via the Tcl scripting framework. All actions in the VDK can be entirely scripted for debugging and analysis. In this case, the Linux kernel module load function triggers the VDK to execute a Tcl function which loads the DesignWare driver symbols from the host. Thus, with just one click, the user can launch their favorite debugger and conduct source level debugging as shown in Figure 4.

Next to that, the VDK allows tracing of all hardware and software activities as shown in Figure 8. Through OS awareness, the software developer can follow a top-down debugging process. Starting with determining the interrupt, the thread trace exposes the point in time when the USB interrupt (IRQ 54) is handled. Then, the user can drill down to the function trace level and even inspect the registers which are read and written by the USB interrupt handler.

This level of visibility and tracing is crucial for a fast and efficient root cause analysis and is available for all types of VDKs and DesignWare daughter boards. In the following paragraphs we will outline some capabilities which are specific to additional DesignWare interface IP TLM.

Mobile Storage

The DesignWare Mobile Storage Host Controller core supporting Secure Digital (SD), Multimedia Card (MMC) and CE-ATA that can be configured and synthesized in order to control:

• Secure Digital memory
• Secure Digital I/O
• Consumer Electronics Advanced Transport Architecture
• Multimedia Cards

The DesignWare TLM Library includes models of the DesignWare Mobile Storage Host core, as well as models of consumer flash memory devices such as a MMC and SD card. Currently, the DesignWare Mobile Storage Host core model supports MMC cards up to and including version 4.4 and SD cards up to and including version 3.0. The respective daughter board for the VDK provides an instance of the mobile storage host and two card instances. As introduced before, the daughter board can be easily extended or modified to adapt to the needs of the end user. Using a parameter editor, the user can configure the controller either as Multimedia Card Ver3.3 only controller or as SD/MMC controller that supports SD Memory, SDIO and MMC simultaneously. Similar to the USB case, the user can control the insertion of a card at system runtime, as the Linux kernel includes the drivers for the MMC. Using the virtual VGA console and keyboard, the user is able to mount a virtual SD card as shown in Figure 9.

For this purpose, the user is able to load a binary image of the card contents (partition table and file system) at startup time of the VDK. Similar to the USB and all other DesignWare TLMs, the MMC TLM provides helpful diagnostic messages and tracing capabilities as shown in Figure 10.

In this case, the Linux driver attempts to communicate with the SD card while the power is not turned on. The end user will only see that the Linux mount command times out, but doesn’t immediately know the root cause without more investigation. Is the problem located in the Linux driver, the device driver integration or the application? The model immediately flags where the problem is rooted. This can save the software developer a lot of debugging work.

Ethernet GMAC

The Ethernet GMAC daughter board for the VDK includes a model of the Synopsys DesignWare Gigabit Ethernet MAC for SoC integration. Furthermore, a model of a generic Ethernet PHY is contained, which supports 10, 100 and 1000 Mbps operation in full- or half-duplex modes. The Ethernet PHY is able to provide interaction with the real world through the host PC’s network interface card. This is achieved using Synopsys VHub (Virtual Hub) tool and additional protocol stack drivers, which transfer Ethernet frames between the simulation and the host’s network stack. 

The VHub tool represents a virtual network hub and each VDK is assigned a separate IP address. This way, a virtual network can be created with multiple VDKs communicating and interacting via Ethernet as shown in Figure 11.

I2C

I2C is a very important off-chip interface that is used to control and communicate with PHYs, sensors, modems etc. The I2C daughter board for the VDK hosts a model of the DesignWare I2C Controller core for the AMBA peripheral bus (APB). The I2C controller allows connecting arbitrary I2C devices. In context of the VDK, the I2C devices can be represented through I2C device TLMs which can be added to a daughter board and then connected to the DesignWare I2C Controller model. I2C TLMs, which are part of the VDK, include the Jedec 42.4 compliant temperature sensor and others. But, most important for the I2C daughter board, is the ability to easily prototype I2C devices using a very simple read/write API, as well as the ability to co-simulate with external I2C simulators. Therefore, the I2C daughter board is equipped with a set of generic I2C devices which serve as a hub as shown in Figure 12.

Using the TcL scripting infrastructure provided by the VDK, the user is able to react to data which is transmitted to the I2C device and inject data to be transmitted to the controller. This process can be automated using watchpoints and Tcl callback routines in the VDK runtime environment, enabling the user to prototype complete I2C device models via scripting capabilities. Furthermore, generic I2C devices allow co-simulation with external tools using a co-simulation API. In this case, the I2C device can be implemented in a native programming language such as C/C++ and compiled for the host. With very basic knowledge of SystemC or TLM, the user can also create a custom TLM I2C model and incorporate the new model onto the daughter board by implementing the device’s read- and write-behavior from the I2C base class.

The Linux kernel is configured with ready to use DesignWare I2C controller drivers. Also, the file system contains the popular I2C tools that allow the software developer to do software prototyping without writing I2C device drivers. As an example application, the VDK provides a DVFS (Dynamic Voltage Frequency Control) control daemon. This daemon observes the temperature obtained from an I2C temperature sensor device. If the temperature is over the alarm limit the daemon selects a lower frequency operation point for the ARM big.LITTLE CPU. For testing purposes, the temperature can be injected by the user through a VDK GUI or a batch script for testing.

Summary

VDKs provide the right level of granularity for constructing prototypes for IP specific embedded software development such as Synopsys' DesignWare IP. The CoStart for VDK provides an easy to use board-level assembly tool, which eliminates the concern of how to connect and validate a large amount of individual models to create a system of IP. Within minutes, a working VDK is configured, generated and ready for software development. All virtual boards come with reference drivers and middleware along with reference OSes such as Linux and Android. Using a VDK preserves the software developer’s comfort zone by ensuring major open source and commercial debug tools are supported. On top of that, the software developer can take advantage of unique capabilities such as non-intrusive debugging, helpful model log messages and system wide hardware and software visibility, translating to easier, better and earlier IP software development.

Further information about the VDK for ARM Cortex can be found here.

Bibliography

¹ ARM Versatile Express Product Family. ARM. [Online]

https://developer.arm.com/products/system-design/development-boards/juno-development-board

² DesignWare IP. Synopsys. [Online]

³ DesignWare TLM Library . Synopsys. [Online] 

⁴ Achim Nohl. Building a sensor subsystem. Embedded.com.

http://www.embedded.com/design/prototyping-and-development/4400771/Android-hardware-software-design-using-virtual-prototypes---Part-2--Building-a-sensor-subsystem

⁵  VDK Family for ARM® Cortex™ Processors. Synopsys.com. [Online]