opentitan icon indicating copy to clipboard operation
opentitan copied to clipboard

[dv,usbdev] Remaining DV improvements

Open alees24 opened this issue 1 year ago • 1 comments

Description

This item gathers a few lingering, perfective DV improvements following the push for V2:

  • [ ] usbdev_iso_retraction probably deserved a little experimental adjustment of time delays to achieve the desired frequency of collisions between device- and host-side activity, although they have been seen to occur often with the current numbers.
  • [ ] usbdev_iso_retraction could perhaps be more effective if the packet size is variable rather than maximum length; the latter increases the chance of attempting retraction whilst transmitting, though.
  • [ ] host-side code is frequently waiting on the wrong clock; this is not ideal now that there are multiple independent clocks within the DV and we have the capacity to vary host clock relative to the DUT clock.
  • [ ] max_usb_traffic sequence is very flexible but presently does not support Isochronous traffic too. Obviously this is covered in a number of other sequences, but it would be good to intermix Iso streams too.
  • [ ] the driver and monitor should perhaps not be operating synchronously on a 4x oversampled clock; there is no particular reason to have periodicity in the operation of this logic; it could just await transitions on the USB and respond as per a real DPLL. This could perhaps give is greater confidence in the frequency/phase adjustment of the DUT.
  • [ ] move the observation of inter-packet and turn-around delays to the driver itself rather than the vseqs, to simplify things and to reduce the likelihood of unintended violations; support any intentional violations using meta data to the driver.
  • [ ] the monitor steals the driver output enable from the DUT to ascertain whether the driver or the DUT is producing the traffic; at the very least it would be preferable to use information from the driver itself, and them make absolutely sure that we can detect a bus clash.
  • [ ] consideration must be given to the running of multiple sequences back-to-back and the impact of configuration plusargs switches to enable/disable any checking (if it cannot always be enabled in time), and to ensure that everything handles random resets properly.

alees24 avatar Jul 05 '24 11:07 alees24

max_usb_traffic sequence is very flexible but presently does not support Isochronous traffic too. Obviously this is covered in a number of other sequences, but it would be good to intermix Iso streams too.

This should get addressed in #24187 IIUC.

andreaskurth avatar Aug 01 '24 09:08 andreaskurth