[usbdev] usbdev does not tolerate 'dribble'

[alees24]

Description

Overview

usbdev does not properly tolerate long 'dribble' (USB 2.0 Specification section 7.1.9.1) that may result from skew in the propagation of Full Speed signaling through USB hubs. This is anticipated to be observed only in the presence of multiple older/budget (USB 2.0-only?) hubs being connected between the host controller and device. Presently it has been observed only in simulation.

Workaround

If CRC errors are observed, use fewer levels of hub hierarchy, or faster/more recent hubs which are expected to be less likely to introduce skew in the propagation of Full Signals. There may also be some benefit to reducing cable lengths.

Details

The specification permits the propagation of the EOP signaling to take up to 15ns longer than the propagation of J-K or K-J transitions (whichever is the longer), as also annotated here and usbdev tolerates accommodates only half a bit interval of delay in the EOP signaling before it will sample another bit which then becomes part of the CRC calculation.

With two USB hubs introducing 15ns of skew each between the host controller and the USB device, operation can be maintained. With 3 or more hubs there is a risk of communications failing because usbdev is sampling an additional bit and raising CRC errors.

The issue may be anticipated to be worse with longer received DATA packets and the presence of frequency mismatch between the host and device as the sampling drifts further.

Simulating the introduction of a single 48MHz clock cycle of dribble at the end of a short SETUP DATA packet, we see correct reception of the packet, and the usbdev acknowledging the transaction from the DPI model.

With the introduction of 2 clock cycles of dribble (= half a bit interval, ie. 41.7ns) the device accepts another bit and the CRC16 mismatches.

It seems that with our present sampling/clocking scheme, we may be better aligning the CRC16 within the packet at 8n bits received (byte boundary) rather than implicitly aligning it with the final bit sampled before EOP.

The mention of dribble tolerance in the specification seems directed at preventing spurious bit stuffing errors, ie. that in this special case, the EOP detection should take precedence over the expectation of a 'bit stuffing 0' after the receipt of 6 consecutive '1's. In that regard, usbdev is robust. The specified maximum dribble does not result in packet rejection through bit stuffing error.

[a-will]

Nice find!

[alees24]

Nice find!

Thanks. Quite by accident! I had been diving into the specification again for confirmation about the malformed SYNC signaling sometimes generated by the DPI model.

[alees24]

Quickly experimented with 4 USB hubs (one USB 3.0-capable hub and 3 older, budget USB2.0 hubs) all in the chain between host controller and usbdev with no observed communication faults.