Effect of High Latency descriptor read by Host on Async Schedule

[Vinesh]

Jan,
Have a question on USB Host controller EHCI on chip I am using.
 
In host mode It looks like there is too much latency in the read operations to fetch the Queue Head and the transfer descriptors due to extensive traffic in the system. (HREADY is low for a long periods and asserted for short periods).The controller DMA state machine fetches the Queue Head (QH) and the transfer descriptor (qTD) and moves to the state where it would execute the transfer, but it does not execute the transfer if it has the indication that there is not enough time in the current micro frame to execute Asynchronous schedule transfers. In that case the state machine moves back to idle state and reads the QH again, moves to executing the transfer and again it cannot execute the transfer within the current micro frame.
 
Due to this phenomemon, I see indefinite starvation, so Is it a host controller bug or host controller is not expected to deal with such a slow memory ?

[Barry Twycross]

I wouldn't call it a bug, EHCI controllers aren't designed to cope with latencies like that, and they do tend to fail in ungraceful ways in those circumstances. I'd say this was a system integration issue.

Do you have any way to raise the priority of EHCI's accesses?

[Vinesh]

Barry,
Thanks . could you also clarify below behaviour:
The asynchronous schedule wishes to perform an OUT of 512 bytes.  Does the controller require that the read of the QH and the read from memory of 512 bytes of data to occur within the 125usec micro-frame window as well?  And if it misses it, the data is all discarded, and operation starts again in the next micro-frame?