[usbdev] prim_cdc_rand_delay induces sampling errors with usb_fs_rx

[alees24]

Description

The CDC modeling in prim_cdc_rand_delay has a massive impact upon the ability of the usbdev IP block (specifically the logic in usb_fs_rx) to sample the input data correctly, whether or not the external differential receiver is utilized. Even a small difference between the host and device frequency will lead to long OUT DATA packets being rejected with CRC16 mismatch, and a substantial frequency difference can readily lead to even SOF packets being mis-sampled as the usbdev receiver logic tries to accommodate a frequency mismatch but is actually responding to the variable delay on the DP and DN inputs to the logic.

This impacts non-differential reception too, where there is an external receiver, because the DP/DN lines are still consulted to look for transition states and to attempt to accommodate frequency mismatches.

At the very least this is going to present a problem for V2/3 sign-off, but there is also reason to be concerned if the CDC modeling cannot fairly be considered overly-conservative and/or unrealistic.

With usbdev employing (only?) 4 x oversampling, a cycle delay on just one signal of a DP/DN transition, followed by a cycle delay only on the other signal one bit interval (4 clocks) later, can result in one signal being - say - high for 3 cycles - whilst its counterpart is low for 5 cycles, centred on those 3.

LLLHHHLLL
HHLLLLLHH

[andreaskurth]

Can't we just disable these random additional cycles in this instance of prim_rand_cdc_delay, because the USB protocol mandates delay balancing and clock tuning such that the modeled problems cannot happen -- right?

[a-will]

Can't we just disable these random additional cycles in this instance of prim_rand_cdc_delay, because the USB protocol mandates delay balancing and clock tuning such that the modeled problems cannot happen -- right?

We can sample a transition on DP on a different cycle from DM, but they definitely can't be two cycles away . usbdev specifically requires DP/DM matching within tight enough bounds to make that true (to accommodate T_FST

opentitan/hw/ip/usbdev/rtl/usb_fs_rx.sv

Lines 96 to 102 in 84c5f69

	// Both D+ and D- may temporarily be less than VIH (min) during differential
	// signal transitions. This period can be up to 14 ns (TFST) for full-speed
	// transitions and up to 210 ns (TLST) for low-speed transitions. Logic in the
	// receiver must ensure that this is not interpreted as an SE0.
	// Since the 48MHz sample clock is 20.833ns period we will either miss this or
	// sample it only once, so it will be covered by line_state=DT and the next
	// sample will not be SE0 unless this was a real SE0 transition

)

If the USB host agent is already playing with clock phases and DP/DM mismatch, then I'd certainly agree with disabling the randomized delay model in prim_rand_cdc_delay.

[andreaskurth]

Just discussed in triage and agreed to move to M7 because there's no evidence of an RTL bug; this is a DV improvement.