23 Replies Latest reply on Jun 15, 2016 9:58 PM by smekalmi

    Intel® 5- (and up) Series Chipset, USB Asynchronous Retry timing

    MikeW Green Belt

      This question is regarding the 5-Series Chipset Platform Controller Hub (PCH), although I suspect the same answer would apply to the 7-, 8-, and 100-Series chipsets as well.  The datasheet for the 5-Series Chipset is here:

       

      http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/5-chipset-3400-chipset-datasheet.pdf

       

      Section 5.18 describes the USB EHCI Host Controller; Section 5.18.3 describes the priority order that the PCH USB 2.0 Enhanced Host Controller (EHC) uses for processing USB Transfer Descriptors (TDs):

       

      1.The USB 2.0 Debug Port (see Section USB 2.0 Based Debug Port),

      2.The Periodic DMA engine, and

      3.The Asynchronous DMA engine.

       

      My question is specifically related to the 3rd option there, the Asynchronous DMA engine dedicated to Control and Bulk transfers.  Once the Periodic transfers have been processed, any remaining time in the 125us microframe is dedicated to the Asynchronous transfers.

       

      If an Asynchronous transfer from the USB Host is NAK'ed by the downstream USB Device, the associated Transfer Descriptor remains in the Asynchronous DMA Schedule.

       

      Assume there are no Debug or Periodic USB transfers.  The particular case I am concerned with is where there is a single Function-to-Host (IN) Transfer Descriptor in the Asynchronous Schedule.  If the targeted USB Device takes some time to build the appropriate DATA response, it will NAK the received IN packets (which will remain in the Asynchronous Schedule).

       

      1) Will the NAK'ed IN packet in the Asynchronous Schedule be retried immediately during the same microframe, using the min Inter Packet Delay from the USB spec (or something close to that) to determine when to resend the next IN packet to the USB Device?

       

      2) Is there some way to program the 5-Series PCH or a Queue Head or Transfer Descriptor setting that would cause the next retry of the IN packet to occur in the next microframe (~120us later) or in the next Frame (~1ms later)?  This would give the USB Device more time to build its response before having to service the IN packet again.

       

      Thank you,

      Mike

       

      Carlos_A

        • Re: Intel® 5- (and up) Series Chipset, USB Asynchronous Retry timing
          Carlos_A Brown Belt

          Hello MikeW,

           

          Thank your for contacting the Intel Embedded Community,

           

          In order to help you, we will contact you via email.

           

          Best Regards,

          Carlos_A.

          • Re: Intel® 5- (and up) Series Chipset, USB Asynchronous Retry timing
            Carlos_A Brown Belt

            Hello MikeW,

             

            Thanks again for contacting the Intel Embedded Community.

             

            Reviewing the document that you have mentioned, specifically in section 5.18.3 is stated the following information:

             

            ”The PCH always performs any currently-pending debug port transaction at the beginning of a microframe, followed by any pending periodic traffic for the current microframe. If there is time left in the microframe, then the EHC performs any pending asynchronous traffic until the end of the microframe (EOF1). Note that the debug port traffic is only presented on Port #1 and Port #9, while the other ports are idle during this time.”

             

            Based on this info, the answer to first question is the PCH always performs any currently-pending debug port transaction at the beginning of a microframe. By the way, the answer to your second question is the implementation that you need to develop is how this transaction works.


            Please let us know if this information is useful to you.

             

            Best Regards,

            Carlos_A.

              • Re: Intel® 5- (and up) Series Chipset, USB Asynchronous Retry timing
                MikeW Green Belt

                What you stated in the above post is exactly what I stated in my original post, that the Debug Port and Synchronous TDs are processed first and the remainder of the 125us microframe is dedicated to stepping through Asynchronous TDs.

                 

                And I do not understand this part of your post: “By the way, the answer to your second question is the implementation that you need to develop is how this transactions work.”

                 

                What is still outstanding is an explanation as to what happens when an Asynchronous Transfer Descriptor (TD) for an IN packet is NAK’ed.  The TD remains in the Asynchronous Schedule.  Is it serviced again (retried) during the same microframe when it is NAK’ed? How long before the IN packet is transmitted again?  Is there a setting in the TD or in the QM57 chipset that would schedule the retry for a NAK’ed Asynch TD in the next USB microframe (~125us) or the next Frame (~1ms) ?  I know from the data I have collected that there are some EHCI controllers that do this.

                 

                Carlos_A