DSF Architecture

The DSF programming environment consists of a set of COM objects that implement various components of a USB device simulator, a set of run-time services, and a USB 2.0 EHCI controller simulator.

The EHCI controller simulator is implemented as a lower device filter on a DSF-specific version of the EHCI miniport (Usbehci_dsf.sys). The DSF version of the EHCI miniport communicates with the controller simulator as if it was real hardware. The controller simulator intercepts register and direct memory access (DMA) accesses and generates simulated hardware interrupts.

USB device simulators are user-mode executable files in any form (such as DLL, .exe files, COM objects, or .NET objects) and in any language that can implement COM client code. USB device simulators use the SoftUSBDevice COM object that the framework supplies. SoftUSBDevice handles all aspects of USB transactions, the device's descriptors, and interaction with the controller simulator.

The following figure illustrates how the USB device simulation architecture uses a DLL to package the USB device simulator.

 

Diagram illustrating how the USB device simulation architecture uses a DLL to package the USB device simulator

 

In the preceding figure, the USB device simulator is implemented as an in-proc COM server in a DLL. A test script creates an instance of the simulator object that uses its constructor to create and configure a SoftUSBDevice object.

The SoftUSBDevice object also exposes secondary objects (such as, SoftUSBConfiguration, SoftUSBInterface, and SoftUSBEndpoint, which are not shown in the preceding figure) that encapsulate the functionality of the various components of a USB device, including its configurations, interfaces, and endpoints. These objects expose properties that enable the objects to generate the appropriate device descriptors in response to standard device requests from the simulated controller.

The device simulator creates the secondary objects and sets their properties according to the device class specification. For example, a bulk-only storage device simulator might create two SoftUSBEndpoint objects and configure them for its bulk-IN and bulk-OUT endpoints: a SoftUSBInterface object to contain the endpoints, and a SoftUSBConfiguration object to contain the interface. The device simulation would then associate the SoftUSBConfiguration object with the SoftUSBDevice object.

After a test script creates the USB device simulator, it typically creates a DSF object. This object provides access to the simulation framework runtime. The IDSF::HotPlug method enables the script to connect the device simulator to the root hub of the simulated controller. HotPlug informs the simulated controller of the connection, and the controller simulator then manipulates its registers to reflect the new connection state and simulates a hardware interrupt. The EHCI miniport responds to the interrupt by detecting and reporting the new device as if real hardware had been attached. The miniport and the entire host system cannot detect the difference between real and simulated hardware.

When the EHCI miniport submits transactions for execution to the simulated controller, the controller reads them from the asynchronous and periodic schedules and executes them according to the USB 2.0 and EHCI specifications. Transactions are executed by calling into SoftUSBEndpoint objects that represent the target of the data transfer. When a SoftUSBEndpoint object receives notification that the controller is attempting a data transfer, it can either fire an event into the device simulator to request the data, or it can use data that has been queued previously within the SoftUSBEndpoint object to respond to the transfer request.

The test script or application can control the device simulator's behavior and initiate interaction with the simulated device within the operating system. For example, a test script for a storage device simulator can initiate I/O to the device by reading a file from the simulator while also providing the data that represents the file to the device simulator.

When performing HID simulation, the device simulator creates a SoftHIDProtocolXlator object and sets its properties by using its HID descriptors. The HID device simulator exposes an interface to test scripts and applications that enables them to initiate HID events such as moving a joystick or clicking a mouse button. The HID device simulator implements this interface by creating HID reports and calling SoftHIDProtocolXlator to transfer them to the host.

The following figure shows the USB device simulation architecture for HID devices.

 

Diagram illustrating the USB device simulation architecture for HID devices

 

For more information about HID devices, see Device Stacks for USB Keyboard, Mouse, and Joystick Devices.

 

 

Send comments about this topic to Microsoft

Build date: 9/21/2010