[usbdpi] Proper separation of transactions and transfers

[alees24]

Description

Some initial work has been done on the DPI model to sever the fixed timing relationship between bus frames and control transfers performed, but it is still not possible to split control transfers across bus frames, interleave them with other transfers, or have the DPI code be properly responsive to the device responses.

In particular:

• eliminate the use of fixed delay intervals before assuming the response to have occurred; instead wait with a timeout or
• support retrying where the host must check for the presence of the response
• introduce proper delays for the transmission/reception of packets, based upon the number of bytes being transferred and any handover intervals. eg. required for isochronous testing, where no response occurs
• implement generic Control Read and Control Write transfers to perform the host behavior, rather than having separate functions for each control transfer that is performed

Later:

• extend usbdpi_transfer_t to support multiple transactions and phased transmission/reception? (Dependent upon how much additional testing we want to perform in t-l sim; let's not expend too much effort verifying higher-level USB behavior, since that must be implemented in software with our packet-level usbdev implementation)

estimate 16

[johngt]

The effort remaining here is in the DV / tooling side and so can be considered a V2 effort.

[andreaskurth]

Discussed in triage, not clear that this will improve coverage, so moving to M5 with P3. Please object if you think it should be higher prio