Come Together Right Now Over… Virtual Prototypes

As a frequent traveler and gadgets enthusiast I love the concept of all my devices being connected. However, more often than not I experience a divide which is sometimes caused by bad software and sometimes caused by missing hardware interfaces. My recent frustration was related to my tablet missing a USB port to upload new maps to my GPS device. The GPS device became a divided, isolated piece of hardware without much use. Embedded software developers are faced with similar challenges when using SoC prototyping methods. To use the prototype for a certain stage of software development, there needs to be connectivity to other devices and host environments.

The increased importance of device to device connectivity in today’s SoCs also increases the demands for software development. Interfaces like PCIe and USB need to run complex software stacks to manage the communication and enabling services across device boundaries. From a terminology standpoint, the side that offers a service is typically referred to as “Device” and the side that requests the service is called “Host”. Bringing different devices together in a prototyping environment can be a challenge. Let’s look at how virtual prototyping solves this problem.

One key value of virtual prototyping is the enablement of an incremental and agile development approach. The virtual prototype is developed in lock-step with the needs of the embedded software. This means that initially the virtual prototype developer can “stub away” unused devices or “mock up” device interfaces with simple python scripting.  However, as the software development progresses and “touches” inter-device communication the need for a virtual prototype becomes more elaborate. Also, to limit the virtual prototype modeling efforts we can leverage existing hosts and devices with two technologies, called “Real World I/O” and “Virtual World I/O”. For standard interfaces like PCIe, USB or Ethernet this works out of the box – “right now”. Let’s look at the concepts in a bit more detail.

Real World I/O allows a controller inside the virtual prototype to connect a physical device that is plugged into the host machine. Let’s look at two examples:

• Example 1 shows a virtual prototype with a USB controller (Host) that connects and reads data from a physical USB memory stick (Device) that is plugged into the same Host PC. The developer can now develop USB Host software on the virtual prototype leveraging an existing physical device.

• Example 2 shows a virtual prototype with a PCIe root complex that connects to a physical GPU card plugged into a PCIe slot of the same host PC. The developer can now develop PCIe Host software on the virtual prototype utilizing the physical GPU and also visualize the frame buffer on virtual display terminals.

Virtual World I/O allows a Host OS to connect to a device controller inside the virtual prototype. Let’s look at the following example:

• Example 3 shows a Host OS that connects to a virtual SSD Device containing a virtual PCIe EndPoint. Initially, the developer used the virtual prototype to develop a SSD FTL software stack that runs on the virtual SSD Device. The developer can now also develop Host PCIe driver code for this virtual SSD Device and additionally debug the SSD software stack in parallel to the Host code.

By adding “Virtual World I/O” and “Real World I/O” we have now significantly extended the value of the virtual prototype for software development tasks with very little additional effort.  These two technologies truly enable the “come together” of different development vehicles while maintaining all virtual prototype features – namely: early development, full visibility, speed and fault injection capabilities.