[usbdev] Test operation at frequency corners

[alees24]

Description

With the chip-level usb suspend-resume test the DPI model has ended up operating on a separate clock in order that it remains operable whilst the chip is powered down. (Local branch at present)

This permits us to try quickly a simple experiment with the usbdev and host (DPI) at opposite frequency extremes to see whether the device can still correctly receive maximum-length packets, and perhaps whether calibrating the 48MHz usbclk operates as intended using SOF packets.

@a-will for awareness; you have often mentioned this, and the chip-level suspend-resume is not yet ready to create a PR

Estimation: 4 for the initial experiment at frequency extremes; 12 for both that and oscillator calibration (reading, learning and experimentation required)

@johngt

estimate 12 remaining 2023-06-26 4

[msfschaffner]

@alees24 @johngt is this something you still planned to do for M2.5.2, or is it ok from your end if we do this at a later point?

[alees24]

I'd still like to try this experiment this week, and there should be time. Perhaps not for the calibration component, but at least some quick manual experiments with different clock frequencies.

[alees24]

Thus far: usbdev synchronizes to host if +/-18.5kHz, fails somewhere between 18.5kHz and 30kHz...the specification requires +/-240kHz but usb_clk calibration not yet possible in simulation.

Test bench modified to present usbdpi model with a clock of different frequency to that which usbdev receives, and asynchronous to it. The DPI model has been modified to observe line transitions away from Idle at the start of a packet being transmitted by the device, and to resynchronize its behavior accordingly.

Two new top level tests have been created with the usbdev at frequencies above and below that of the DPI model. These both employ the existing LFSR-based streaming test but - crucially - with maximum length packets to achieve maximal drift and thus the greatest chance of failure. With a 18.5kHz offset the test is observed to complete, and with a 30kHz offset the test will fail with data corruption and CRC errors.

A simple estimate gives an idea of the maximum frequency delta that we cant tolerate without relying upon the USB clock calibration:

SYNC DATA <> 2CRC + 2 EOP bits
18 bits overhead + (66 x 8 bits payload) *6/5 for worst case bit stuffing = 652 bit intervals in max length packet
Aim to drift by no more than one quarter of a bit interval over the entire packet duration 0.083us/4 = 0.021us
21ns out of 54.3us
about 4.6kHz difference on 12MHz clock....18.5kHz variation on 48MHz clock

Re SOF detection, which is just 32 bits:
21ns out of 2.7us 93.3kHz; 373kHz on 48MHz clock

The specification requires us to be able to cope with a 240kHz difference

It would be good to be able to test usb_clk calibration within a top-level test and observe the clock drifting into line with the received Start Of Frame 'heartbeat' messages from the DPI host, but this is presently not possible since the current open source usb_osc is a placeholder/model.

@jdonjdon, @a-will Is there any way that I can test/model this more completely?

Draft PR to follow, once cleaved from the suspend-resume work upon which it is currently built.

[msfschaffner]

@alees24 is there something specific that does not work correctly with the open-source model? according to Nuvoton, the open-source model may not be fully accurate, but it should capture the functionality.

[alees24]

@alees24 is there something specific that does not work correctly with the open-source model? according to Nuvoton, the open-source model may not be fully accurate, but it should capture the functionality.

Well, it starts at 48MHz + a frequency delta and then uses the reference pulses only to drift towards a fixed 48MHz frequency ie. freq = 48 + delta * (max(N - pulse count, 0) / N) .... so it's not measuring the intervals between the pulses and the end result is a fixed 48MHz clock frequency not influenced by the host timing.

I presume the intent is that we continually track the frequency of the host using the 1ms SOF pulses. Since the open source model presently doesn't do that, I can't move the DPI clock more than about 18kHz from 48MHz without inducing errors, but the specification requires us to support +/-240kHz.

[alees24]

estimate 4

[msfschaffner]

Moved to V3 / M2.5 backlog since the USB device DV is best effort for ES.

[alees24]

Draft PR https://github.com/lowRISC/opentitan/pull/19093 includes work so far.

[johngt]

Moved to M2 until we can confirm observed behaviour via SIVAL. Depending on results this can then move back.

[johngt]

@pamaury - for reference

[johngt]

As mentioned previously - there is a draft PR in play - https://github.com/lowRISC/opentitan/pull/19093 Leaving as one day of effort remaining for now

[andreaskurth]

@johngt to update after discussion next Monday

[andreaskurth]

Discussed in triage: de-prioritized to M5.

[andreaskurth]

@sha-ron: assigning you from Nuvoton's DV team; to be discussed at our next sync

[a-will]

Thus far: usbdev synchronizes to host if +/-18.5kHz, fails somewhere between 18.5kHz and 30kHz...the specification requires +/-240kHz but usb_clk calibration not yet possible in simulation.

Test bench modified to present usbdpi model with a clock of different frequency to that which usbdev receives, and asynchronous to it. The DPI model has been modified to observe line transitions away from Idle at the start of a packet being transmitted by the device, and to resynchronize its behavior accordingly.

I'll just note that at this point, the DPI model isn't quite as sophisticated as usbdev, which adapts the sampling point on every transition. I'm not sure we can get away without it, if we're going to test the limits.

At the 48 MHz sampling clock and for 64 raw bytes without bitstuffing (64 bytes 8 bits / byte 4 clocks / bit), we end up sampling 1 clock early for the next bit with only a 24 kHz offset (0.049%, 488 ppm). USB guarantees a transition at least every 7 bits, and in usbdev, we make use of that for keeping in sync with the incoming data.

It's kind of an awkward problem for simulation, though: I feel like the monitor will have to implement effectively the same logic we are testing.

[alees24]

The DPI model could just wait for a deviation from Idle, and then implement a DPLL by having more logic in usbdpi.sv.

I must remark that USBDEV itself, even with its transition detection and phase adjustment, does not cope with the maximum permitted frequency delta between host and device; in fact as noted we were able only to accommodate +/-18kHz deviation rather than the +/-240kHz ultimately, so we are reliant upon the 'usb_ref_pulse_o' timing reference pulse, oscillator adjustment and the >= 10ms 'reset recovery' time during which only SOF packets are transmitted to the DUT.

This top-level tests has been somewhat superseded, at least for now, by the block level DV testing; open PR at #23836

[andreaskurth]

@alees24 Now that PR #23836 is merged and covers this issue in a block-level test, is there any need for keeping this chip-level test issue open? If not, suggestion is to close as not planned.

[andreaskurth]

Adrian and I just discussed this out of band: this can be deprioritized out of M5. Moving to M7 as part of V3 efforts