Datasheet

Functional Description
138 Intel® Xeon® Processor D-1500 Product Family
Datasheet - Volume 1 of 4: Integrated Platform Controller Hub
March 2015
Allows normal system USB 2.0 traffic in a system that may only have one USB port.
Debug Port device (DPD) must be high-speed capable and connect directly to Port 1
on Intel® Xeon® Processor D-1500 Product Family-based systems (such as, the
DPD cannot be connected to
Port 1 through a hub. When a DPD is detected Intel® Xeon® Processor D-1500
Product Family EHCI will bypass the integrated Rate Matching Hub and connect
directly to the port and the DPD.).
Debug Port FIFO always makes forward progress (a bad status on USB is simply
presented back to software).
The Debug Port FIFO is only given one USB access per microframe.
The Debug port facilitates operating system and device driver debug. It allows the
software to communicate with an external console using a USB 2.0 connection.
Because the interface to this link does not go through the normal USB 2.0 stack, it
allows communication with the external console during cases where the operating
system is not loaded, the USB 2.0 software is broken, or where the USB 2.0 software is
being debugged. Specific features of this implementation of a debug port are:
Only works with an external USB 2.0 debug device (console)
Implemented for a specific port on the host controller
Operational anytime the port is not suspended AND the host controller is in D0
power state.
Capability is interrupted when port is driving USB RESET
3.17.9.1 Theory of Operation
There are two operational modes for the USB debug port:
1. Mode 1 is when the USB port is in a disabled state from the viewpoint of a standard
host controller driver. In Mode 1, the Debug Port controller is required to generate a
“keepalive” packets less than 2 ms apart to keep the attached debug device from
suspending. The keepalive packet should be a standalone 32-bit SYNC field.
2. Mode 2 is when the host controller is running (that is, host controllers Run/Stop#
bit is 1). In Mode 2, the normal transmission of SOF packets will keep the debug
device from suspending.
Behavioral Rules
1. In both modes 1 and 2, the Debug Port controller must check for software
requested debug transactions at least every 125 microseconds.
2. If the debug port is enabled by the debug driver, and the standard host controller
driver resets the USB port, USB debug transactions are held off for the duration of
the reset and until after the first SOF is sent.
3. If the standard host controller driver suspends the USB port, then USB debug
transactions are held off for the duration of the suspend/resume sequence and until
after the first SOF is sent.
4. The ENABLED_CNT bit in the debug register space is independent of the similar
port control bit in the associated Port Status and Control register.
Tab l e 3- 3 9 shows the debug port behavior related to the state of bits in the debug
registers as well as bits in the associated Port Status and Control register.