USB Hub Basic Transfer Test
Note This content applies to the Windows Logo Kit (WLK). For the latest information using the new Windows Hardware Certification Kit (HCK), see Windows HCK User's Guide on the Windows Hardware Dev Center.
Type: Automated Test
Overview
A hub is a USB device that connects to a host system and provides additional USB attachment points. The USB hub contains three principal components: the hub repeater, the hub controller, and the transaction translator.
The USB Hub Basic Transfer Test focuses on the transaction translator and verifies compliance with the Universal Serial Bus Specification Revision 2.0 requirements and the Microsoft Windows Logo Program System and Device Requirements. A USB 2.0 hub provides support for high-speed, full-speed, and low-speed USB peripherals.
The USB High Speed Basic Transfer test comprises a number of individual tests based upon the USB 2.0 Transaction Translator and Hub Compliance Test Specification developed by the USB-IF. These tests are described in the following sections.
Details
The USB High Speed Hub Basic Transfer Test is required only for Universal Serial Bus (USB) revision 2.0 high-speed hubs. The test verifies that the hub responds correctly to various transaction translator requests, and that the hub correctly handles a variety of transactions with high-speed, full-speed, and low-speed peripheral devices.
Note Because the USB Hub Basic Transfer Test is only designed to evaluate USB 2.0 high-speed hubs (400 Mbps) and not full-speed or USB 1.1 hubs (11 Mbps), testers should set the IsEmbeddedFullSpeedHub schedule-time parameter to TRUE in the Device Console when scheduling this test if their hub is not high speed or for any embedded hub (full or high speed). This parameter lets DTM know that the hub is not actually a high-speed hub and will therefore skip the test entirely. The job will be recorded as passing afterwards.
TD-9.29.1.11 Clear TT Buffer Test
The Clear TT Buffer Test verifies that the hub responds correctly to the Clear_TT_Buffer request to clear the state of a non-periodic buffer that is associated with a given endpoint.
The hub connects to an EHCI host controller (high-speed capable port).
A full-speed compliance device is connected to an available downstream port of the test hub. The test configures the full-speed test device to have as many Bulk OUT endpoints as the test device will support.
The test issues a Bulk OUT transaction and sends an arbitrary packet to the test device for each of the endpoints in sequence. Software manipulation through a custom EHCI driver stack is used to prevent complete splits from being issued for any of these transactions. This prevention is done by having a separate queue head for each transaction with a final dummy queue head that loops back on itself.
While the non-periodic list spins on the dummy queue head, the other transaction states can be monitored. After all of the non-periodic buffers for the transaction translator are full, the OUT transactions will not be able to advance to the complete split stage.
At this point, the test sends a Clear_TT_Buffer request to one of the endpoints that has a pending transaction. After this request is issued the test sends another OUT transaction to this endpoint. The transaction must be completed successfully.
The same test process is repeated by using control endpoints instead of bulk endpoints.
If the hub implements multiple transaction translators, the test device must be moved and the test repeated for each of the hubs available downstream ports.
The test is repeated for IN transactions.
Results Interpretation
The test writes all results to a file.
The test fails if the Clear_TT_Buffer request does not enable a transaction to be sent to the cleared endpoint when all the non-periodic buffers are in the pending state
TD-9.29.1.12 Stop TT Test
The Stop TT Test verifies that the hub responds correctly to the Stop_TT request.
For this test, you connect the hub an EHCI host controller (high-speed capable port) and connect a full-speed test device to one of the available downstream ports of the hub.
The test issues a Stop TT request to the hub. The test then attempts to run loopback tests of each transfer type to verify that the TT is stopped. Next, the test software issues a Reset TT request. The test then verifies that the loopback tests will run successfully.
The test is repeated for each downstream port on the hub if the hub implements one TT per port.
Results Interpretation
The test writes all results to a file.
The test fails if:
A transaction translator continues to generate downstream non-periodic traffic after receiving a Stop_TT request.
A transaction translator continues to generate downstream periodic traffic after receiving a Stop_TT request.
Communication to the downstream device fails after a Reset_TT request.
TD-9.29.1.13 Reset TT Test
The Reset TT Test verifies that the hub responds correctly to the Reset TT request.
For this test, you connect the hub an EHCI host controller (high-speed capable port) and connect a full-speed test device to one of the available downstream ports of the hub.
The test configures the test device to support either as many bulk loopback endpoint pairs as the device is capable of supporting, or as many non-periodic buffers as the transaction translator supports (whichever is smaller). The maximum packet size for each endpoint is configured to be 64 bytes. Each endpoint is configured to count the number of transactions that are sent to it.
The test issues a series of Bulk OUT transactions for each of the OUT endpoints in the loopback pairs.
Through software manipulation, the test prevents the host controller from issuing complete-splits for any of these transactions. The test then issues a valid Reset TT request. The complete splits for each of the Bulk OUT transactions are then allowed to complete. Each of these transactions must result in a STALL.
Next, the test repeats the same process for IN transactions to each of the IN endpoints in the loopback pairs.
In addition, this entire test is repeated on each port if the hub uses a multiple TT implementation.
Results Interpretation
The test writes all results to a file.
The test fails if:
A transaction translator continues to generate downstream non-periodic traffic after receiving a Reset_TT request.
A transaction translator continues to generate downstream periodic traffic after receiving a Reset_TT request.
The Reset_TT request does not clear all TT data/transaction buffers.
Communication to the downstream test device fails to work after the Reset_TT request is used.
TD-9.29.1.14 TT Think Time Test
The TT Think Time Test verifies that the hub correctly reports its worst-case think time to advance to the next transaction in the periodic pipeline.
For this test, you connect the hub an EHCI host controller (high-speed capable port) and connect a full-speed test device to one of the available downstream ports of the hub.
This test configures the test device to support the maximum number of isochronous OUT endpoints the test device will support.
The test sends the get descriptor request to the hub to obtain the hub descriptor. The test examines bits D6...D5 of the wHubCharacteristics field to verify the reported worst case TT Think Time of the hub. This is interpreted as follows:
00: TT requires at most 8 FS bit times of inter-transaction gap.
01: TT requires at most 16 FS bit times of inter-transaction gap.
10: TT requires at most 24 FS bit times of inter-transaction gap.
11: TT requires at most 32 FS bit times of inter-transaction gap.
The test device is configured to measure the time between transactions to any of its isochronous OUT endpoints.
The test sets up a periodic schedule to send the hub isochronous transactions. The device tracks the time between each transaction as they execute.
The test queries the device to determine the largest delay in FS bit times between the end of one isochronous OUT transaction and the start of the next.
The procedure is repeated for isochronous IN, interrupt IN, and interrupt OUT transactions (limited to the number of non-periodic buffers in the TT) and for combinations of periodic and non-periodic transactions and full- and low-speed transactions.
If the hub implements more than one transaction translator per port, this test is repeated for each of the available downstream ports on the hub.
Results Interpretation
The test writes all results to a file.
The test fails if:
The hub does not respond to the get descriptor request for the hub descriptor.
There is a longer delay between transactions to the full-speed test device than the hub reports as its worst case TT think time.
TD-9.29.1.16 Multiple Hub Tier Split Traffic Test
The Multiple Hub Tier Split Traffic Test verifies that the hub correctly repeats all high-speed traffic that is received at its upstream port to all of its high speed enabled downstream ports. In particular, the hub must repeat all high-speed split traffic to ensure that it reaches the appropriate hub with the full/low speed target device attached.
For this test, you connect the hub to an EHCI host controller (high-speed capable port). Four additional hubs are then connected in series behind the first hub. You connect a full-speed test device to the last hub in the chain.
The test configures the full speed test device to support a loopback pair of bulk endpoints and a loopback pair of interrupt endpoints. A loopback pair of endpoints is an IN endpoint and an OUT endpoint. Data that is written to the OUT endpoint may be immediately read back from the IN endpoint.
The maximum packet size for both the bulk and interrupt endpoints is set to 64 bytes.
Next, the test continuously issues a series of bulk OUT and bulk IN and interrupt OUT and interrupt IN transactions to the endpoints. The transfer sizes and data patterns are varied. In every case, the data read back from the device is compared with the data sent.
The process is repeated with a low-speed test device for each TT in the hub. The process is also repeated with a high-speed test device and high-speed loopback traffic.
The process is also repeated for isochronous and control loopback.
Results Interpretation
The test writes all results to a file.
The test fails if:
A test device cannot be configured behind a chain of five hubs.
Any full-, low-, or high-speed transactions are unsuccessful behind a chain of five hubs.
TD-9.29.1.17 Number of Non-Periodic Buffers Test
The Number of Non-Periodic Buffers Test verifies that the transaction translator implements at least two non-periodic transaction buffers.
For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.
The test configures the full-speed test device to support as many bulk OUT/IN loopback endpoint pairs as the test device supports. The maximum packet size for the endpoints is set to 64 bytes.
Next, the test sets up a series of bulk OUT transactions to each of the endpoints. Using software manipulation through a custom EHCI test stack, the test allows the transactions to issue start splits but not to issue complete splits. This is done by using a separate queue head for each transaction and a dummy queue head and the end of the list, which loops back on itself. This keeps the non-periodic buffers in the pending state. After a transaction is not able to advance to the do-complete-split stage, the non-periodic transaction buffers of the TT have been filled and the number of non-periodic buffers can be calculated. The transactions are then allowed to complete normally. Bulk IN transactions are performed for each of the bulk OUT loopback pairs that were completed. The data sent must match the data received.
This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation. The procedure is also repeated using bulk IN transactions instead of bulk OUT transactions.
Results Interpretation
The test writes all results to a file.
The test fails if:
A transaction translator does not have at least two non-periodic buffers.
A transaction translator does not correctly NAK non-periodic start splits when its non-periodic buffers are filled with pending transactions. A NAK is a handshake packet that indicates a negative acknowledgement.
Data read back from a bulk IN loopback endpoint does not match the data sent to the bulk OUT endpoint.
TD-9.29.1.18 Control Transaction Retry Handling Test
The Control Transaction Retry Handling Test verifies that the transaction translator correctly handles a start split for a control transaction when it has a non-periodic buffer in the pending state with a transaction to the same endpoint. This condition can easily result when the host loses the ACK for a start split. An ACK is a handshake packet that indicates a positive acknowledgement.
For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.
The test configures the full-speed test device to support a control endpoint with a maximum packet size of 64 bytes. The device is first queried to obtain the current transaction count for the endpoint.
Next, the test sets up a pair of control OUT transactions to the same endpoint. Using software manipulation through a custom EHCI test stack, the test enables the transactions to issue start splits but not to issue complete splits. This situation keeps the non-periodic buffer used for the first transaction in the pending state. The transaction translator should treat the second transaction as a retry of the first and respond with an ACK but not buffer the transaction. The transactions are then allowed to complete normally.
The test again queries the device for the transaction count on the control endpoint. If more than one new transaction (or zero) has been attempted on the endpoint, the test fails.
If the test device does not support transaction counting the test may be performed by issuing two small control OUT transactions with different data patterns to the endpoint. If the data read back from the endpoint through a control IN contains both pieces of data, the test fails.
The test is repeated using control IN transfers. If the hub supports a multiple TT organization, the test is repeated on each port.
The retry testing is carried out for each stage of the control transaction.
Results Interpretation
The test writes all results to a file.
The test fails if a transaction translator does not correctly treat control transfers as retries when it already has a transfer pending for the same endpoint.
TD-9.29.1.19 Bulk Transaction Retry Handling Test
The Bulk Transaction Retry Handling Test verifies that the transaction translator correctly handles a start split for a bulk transaction when it has a non-periodic buffer in the pending or ready/x state with a transaction to the same endpoint and direction. This condition can easily result when the host loses the ACK for a start split.
For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.
The test configures the full-speed test device to support a pair of bulk endpoints that support loopback transfers. The maximum packet size for each endpoint is set to 64 bytes. The test first queries the device to obtain the current transaction count for the Bulk OUT endpoint.
Next, the test sets up a pair of bulk OUT transactions to the endpoint. Using software manipulation through a custom EHCI test stack, the test allows the transactions to issue start splits but not complete splits. This situation keeps the non-periodic buffer used for the first transaction in the pending or ready/x state. The transaction translator should treat the second transaction as a retry of the first and respond with an ACK but not buffer the transaction. The transactions are then allowed to complete normally.
The test again queries the device for the transaction count on the bulk OUT endpoint. If more than one new transaction (or zero) has been attempted on the endpoint, the test fails.
If the test device does not support transaction counting, the test may be performed by issuing two small bulk OUT transactions with different data patterns to the endpoint. If the data read back from the endpoint through a bulk IN transaction contains both pieces of data, the test fails.
The test is repeated by using bulk IN transfers. If the hub supports a multiple TT organization, the test is repeated on each port.
Results Interpretation
The test writes all results to a file.
The test fails if a transaction translator does not correctly treat bulk transfers as retries when it already has a transfer pending for the same endpoint.
TD-9.29.1.20 Control Transaction Protocol Test
The Control Transaction Protocol Test verifies that the transaction translator correctly handles various device protocol response cases for control transactions.
For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.
The test configures the full-speed test device to support four additional control endpoints. The maximum packet size for the endpoints is set to 64 bytes.
The test software configures one of the endpoints to respond with a STALL, one of the endpoints to respond with a NAK, and one of the endpoints to timeout (not respond). If the test device supports it, the remaining control endpoint is also configured to generate CRC errors.
Next, the test sends a series of control transactions to each of the endpoints. The result of the transaction must resolve to STALL for the STALL, timeout, and CRC error endpoints. The test aborts the transaction to the NAK endpoint after 1 second. The test software reads the transaction count from the NAK endpoint before and after this transaction attempt. If the count has not increased in a manner that indicates repeated transaction attempts, the test fails.
The test is repeated for transactions in both directions and all valid transfer sizes.
If the hub implements multiple TT units, the test must be repeated on each port of the hub.
The entire test procedure is repeated using a low-speed compliance device for all valid transfer sizes.
Results Interpretation
The test writes all results to a file.
The test fails if:
A transaction does not correctly report a STALL for an endpoint programmed to STALL, time out, or produce CRC errors.
A transaction for an endpoint programmed to respond with a NAK responds with a state other than NAK.
A transaction is not repeatedly retried for an endpoint programmed to NAK due to an error in hub behavior.
TD-9.29.1.21 Bulk Transaction Protocol Test
The Bulk Transaction Protocol Test verifies that the transaction translator correctly handles various protocol response cases for bulk transactions.
For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.
The test configures the full-speed test device to support four bulk OUT endpoints. The maximum packet size for the endpoints is set to 64 bytes.
The test configures one of the endpoints to respond with STALL, one of the endpoints to respond with NAK, and one of the endpoints to timeout (not respond). If the test device supports it, the remaining endpoint is configured to generate CRC errors.
Next, the test sets up a series of bulk transactions to each of the endpoints. The result of the transaction must resolve to STALL for the STALL, timeout, and CRC error endpoints. The test aborts the transaction to the NAK endpoint after 1 second. The test reads the transaction count from the NAK endpoint before and after this transaction attempt. If the count has not increased in a manner that indicates repeated transaction attempts, the test fails.
The test is repeated for all valid transfer sizes.
If the hub implements multiple TT units, the test must be repeated on each port of the hub.
The four endpoints are reconfigured as bulk IN endpoints and the same procedure is repeated.
Results Interpretation
The test writes all results to a file.
The test fails if:
A transaction does not correctly report a STALL for an endpoint programmed to STALL, timeout, or produce CRC errors.
A transaction attempt for an endpoint programmed to NAK responds with a state other than NAK.
A transaction is not repeatedly retried for an endpoint programmed to NAK due to an error in hub behavior.
TD-9.29.1.22 Control Transaction Loopback Test
The Control Transaction Loopback Test performs functional testing of control transfers by exercising concurrent streams of OUT and IN transfer pairs to control endpoints. The test sets up the compliance device to support as many control endpoints as possible. Transaction streams are initiated for each endpoint that sends data through control OUT transactions and then reads it back with control IN transactions. Transfer streams are run for all possible transfer sizes and all possible data patterns.
For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.
The test configures the full-speed test device to support as many control endpoints as the test device will support. The maximum packet size for the endpoints is set to 64 bytes.
Next, the test sets up a transfer stream for each control endpoint. Each stream repeatedly executes control OUT and control IN transfers. The test compares the data received (IN) with the data sent (OUT) to make sure they are identical.
The test is repeated for all valid transfer sizes for every possible data pattern.
The same procedure is repeated with a low speed compliance device. This procedure is repeated for each downstream port on the hub if it uses a multiple TT implementation.
Results Interpretation
The test writes all results to a file.
The test fails if:
The data returned by any control IN transfer is not identical to the data that was sent with a control OUT transfer.
A control transfer cannot be successfully completed to the test device.
TD-9.29.1.23 Bulk Transaction Loopback Test
The Bulk Transaction Loopback Test performs functional testing of bulk transfers by exercising concurrent streams of OUT and IN transfer pairs to bulk endpoints. The test sets up the compliance device to support as many bulk endpoints as possible. Transaction streams are initiated for each endpoint that sends data through bulk OUT transactions and then reads it back with bulk IN transactions. Transfer streams are run for all possible transfer sizes and all possible data patterns.
For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.
The test configures the full-speed test device to support as many bulk endpoint pairs as the test device will support. The maximum packet size for the endpoints is set to 64 bytes.
Next, the test sets up a transfer stream for each bulk endpoint pair. Each stream repeatedly executes bulk OUT and bulk IN transfers. The test compares the data received (IN) with the data sent (OUT) to make sure they are identical.
The test is repeated for all valid transfer sizes for every possible data pattern.
This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.
Results Interpretation
The test writes all results to a file.
The test fails if:
The data returned by any bulk IN transfer is not identical to the data that was sent with a bulk OUT transfer.
A bulk transfer cannot be successfully completed to the test device.
TD-9.29.1.24 Control Transaction Unpaired Complete Split Test
The Control Transaction Unpaired Complete Split Test verifies that the transaction translator correctly handles the case where a complete split for a control transaction is received for an endpoint that does not currently have a non-periodic buffer assigned to it.
For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub. The test device is configured to have only a default control endpoint.
Next, the test sets up a control OUT transaction to the control endpoint of the test device. Using software manipulation through a custom EHCI test stack, the test allows the transaction to issue a start split but not a complete split. The test software then issues a Clear_TT_Buffer request for the control endpoint of the test device. Once this request is completed, the transaction that has been in the ready/x state without issuing a complete split is allowed to complete. This transaction should result in a STALL on the control OUT endpoint for the test device.
The test is repeated for a control IN transfer.
If the hub implements multiple TT units, the test must run on each port of the hub.
Results Interpretation
The test writes all results to a file.
The test fails if a transaction translator does not return a STALL when it receives a control transaction for an endpoint and a direction that is not currently assigned to one of the non-periodic buffers.
TD-9.29.1.25 Bulk Transaction Unpaired Complete Split Test
The Bulk Transaction Unpaired Complete Split Test verifies that the transaction translator correctly handles the case where a complete split for a bulk transaction is received for an endpoint and direction that does not currently have a non-periodic buffer assigned to it.
For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub. The test device is configured to have a pair of loopback bulk endpoints.
The test sets up a bulk OUT transaction to the bulk OUT endpoint of the test device. Using software manipulation through a custom EHCI test stack, the test allows the transaction to issue a start split but not allowed to issue a complete split. The test then issues a Clear_TT_Buffer request for the bulk OUT endpoint of the test device. Once this request is complete, the transaction that was in the ready/x state without issuing a complete split is allowed to complete. This transaction should result in a STALL.
The test is repeated for a bulk IN transfer.
If the hub implements multiple TT units the test must be repeated on each port of the hub.
Results Interpretation
The test writes all results to a file.
The test fails if a transaction translator does not return a STALL when it receives a bulk transaction for an endpoint and a direction that is not currently assigned to one of the non-periodic buffers
TD-9.29.1.26 Number of Local Retries Test
The Number of Local Retries Test verifies that the transaction translator performs local retries of non-periodic transactions if the transactions produce timeouts or CRC errors on the full/low speed bus. The test verifies the transactions are tried exactly three times.
For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub. The test configures the full-speed test device to support two bulk OUT endpoints. The maximum packet size for the endpoints is set to 64 bytes. One endpoint is configured to timeout and the other to respond with CRC errors (if the device supports this mode). Both endpoints are configured to track and return a transaction count on request.
The test obtains the current transaction count for both endpoints.
Next, the test sets up two bulk OUT transactions to each of the endpoints. The transactions must produce a STALL response for the test to pass. Once the transactions are complete, the test reads the transaction count for both of the bulk endpoints. If either transaction count has not increased by three, the test fails.
This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.
The procedure is repeated for endpoints that NAK and STALL. In this case, there must only be one local attempt per transfers.
The same tests are repeated for control endpoints.
The test is repeated for an isochronous endpoint for timeout mode only.
The test is repeated for interrupt endpoints. These cases are the same as bulk/control endpoints except for the timeout case, which must produce an ERR response. There must only be one local attempt per transfer for the periodic endpoints.
Results Interpretation
The test writes all results to a file.
The test fails if:
A transaction translator does not attempt local retries of a non-periodic transaction that resulted in a timeout or CRC error.
A transaction translator attempts a non-periodic transaction less than or more than three times when it consistently results in a timeout or CRC error.
The correct transfer status is not returned for any transfer.
The correct number of local transfers is not attempted for transfer to a fixed response endpoint.
TD-9.29.1.27 Start Split Pipeline Size Test
The Start Split Pipelie Size Test verifies that the transaction translator can successfully accept as many as 16 start-splits in a single microframe.
For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.
The test configures the full speed test device to support 16 isochronous OUT endpoints (or as many as the test device supports). The maximum packet size for the endpoints is set to 1024 bytes. Each endpoint is configured to keep a transaction count. The test sets up a series of small isochronous OUT transactions to each of the endpoints. The test uses a custom EHCI test stack to allow complete control of transaction scheduling.
All of the transactions are scheduled for execution in the same microframe and then periodic transactions are enabled for the host controller. After a sufficient delay, the periodic list is disabled to prevent the host controller from attempting any of the transactions that were not able to execute in the specified microframe. The transaction descriptors are examined to see how many of the transactions were executed (the host sends a start-split transaction).
Next, the test queries the device to obtain the transaction count for each of the endpoints on the test device. If any endpoint has received more than one transaction or the total number of transactions received by the endpoints does not match the number of start-splits sent by the host controller, the test fails.
This procedure is repeated with the start-split transactions sent in each possible microframe (all except microframe 6).
If supported by the test device, the procedure is also repeated with one-byte isochronous OUT transfers. Each endpoint is sent a different byte. The device is required to assemble the bytes in the order that they were received. At the end of the test, the data is read back from the bytes. If all the bytes are not present and in the order they were sent, the test fails.
This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.
Results Interpretation
The test writes all results to a file.
The test fails if:
A transaction translator does not issue full/low-speed periodic transactions in the order start-splits were received.
A transaction translator does not handle receiving up to 16 start-splits in a single microframe.
TD-9.29.1.28 Interrupt Transaction Protocol Test
The Interrupt Transaction Protocol Test verifies that the transaction translator correctly handles various device protocol response cases for interrupt transactions.
For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.
The test configures the full-speed test device to support four interrupt OUT endpoints. The maximum packet size for the endpoints is set to 64 bytes. The endpoints are also configured to keep a transaction count. The current count for each endpoint is read.
The test software configures one of the endpoints to respond with STALL, one of the endpoints to respond with NAK, and one of the endpoints to timeout (not respond). If the test device supports CRC checks, the remaining interrupt endpoint is configured to generate CRC errors.
Next, the test sets up a series of interrupt OUT transactions to each of the endpoints. The test uses a custom EHCI test stack to allow complete control of the periodic schedule. In turn, the test sets up and runs periodic schedules that attempt 100 transactions to the current endpoint being tested. After the transaction attempts are made, the transaction count for each endpoint is read and must have increased by 100.
The result of the each transaction must resolve to STALL for the STALL endpoint. The transaction attempt to the NAK endpoint should eventually time out. The CRC and timeout endpoints should result in ERR responses.
The test is repeated for transactions in both directions and for all valid transfer sizes. If the hub implements multiple TT units, the test must be repeated on each port of the hub.
The entire test procedure is repeated using a low-speed compliance device for all valid transfer sizes.
Results Interpretation
The test writes all results to a file.
The test fails if:
A transaction translator attempts local retries of an interrupt transaction.
A transaction attempt completes for an endpoint programmed to NAK.
A transaction attempt to an endpoint programmed to respond with CRC errors or to timeout does not result in an ERR response.
TD-9.29.1.29 Isochronous Transaction Protocol Test
The Isochronous Transaction Protocol Test verifies that the transaction translator correctly handles various device protocol response cases for isochronous IN transactions.
For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.
The test configures the full-speed test device to support two isochronous IN endpoints. The maximum packet size for the endpoints is set to 1024 bytes. The endpoints are also configured to keep a transaction count. The current count for each endpoint is read.
The test configures one of the endpoints to not respond (timeout). If the test device supports it the remaining isochronous endpoint is configured to generate CRC errors.
Next, the test sets up a series of isochronous IN transactions to each of the endpoints. The test uses a custom EHCI test stack to allow complete control of the periodic schedule. In turn, the test sets up and runs periodic schedules that attempt 100 transactions to the current endpoint being tested. After the transaction attempts are made, the transaction count for each endpoint is read and must have increased by 100. Each transaction should result in an ERR response.
The test is repeated for transactions in both directions and for all valid transfer sizes.
If the hub implements multiple TT units, the test must be repeated on each port of the hub.
Results Interpretation
The test writes all results to a file.
The test fails if:
A transaction translator attempts local retries of an isochronous transaction.
A transaction attempt to an endpoint programmed to respond with CRC errors or to timeout does not result in an ERR response.
TD-9.29.1.30 Interrupt Transaction Loopback Test
The Interrupt Transaction Loopback Test performs functional testing of interrupt transfers by exercising concurrent streams of OUT and IN transfer pairs to pairs of interrupt endpoints. The test sets up the compliance device to support as many pairs of interrupt loopback endpoints as possible. Transaction streams are initiated for each endpoint that send data through interrupt OUT transactions and then read it back with interrupt IN transactions. Transfer streams are run for a variety of transfer sizes and with all possible data patterns for those sizes.
For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.
The test configures the full-speed test device to support as many interrupt loopback pairs of endpoints as the test device will support. The maximum packet size for the endpoints is set to 64 bytes. The bInterval value for each endpoint is set to the minimum allowable time.
Next, the test sets up a transfer stream for each pair of interrupt endpoints. Each stream repeatedly executes interrupt OUT and interrupt IN transactions. The test compares the data received from the IN transaction with the data sent with the OUT transaction to make sure the data is identical.
The test is repeated for all possible transfer sizes for every possible data pattern.
The data read by an interrupt IN transaction should always match the data sent by an interrupt OUT transaction.
The same procedure is repeated with a low speed compliance device.
This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.
Results Interpretation
The test writes all results to a file.
The test fails if:
The data returned by any interrupt IN transfer is not identical to the data that was sent with an interrupt OUT transfer.
An interrupt transfer cannot be successfully completed to the test device.
TD-9.29.1.31 Isochronous Transaction Loopback Test
The Isochronous Transaction Loopback Test performs functional testing of isochronous transfers by exercising concurrent streams of OUT and IN transfer pairs to isochronous loopback endpoint pairs. The test sets up the compliance device to support as many pairs of isochronous loopback endpoints as possible. Transaction streams are initiated for each endpoint pair that sends data through isochronous OUT transactions and then reads it back with isochronous IN transactions. Transfer streams are run for a variety of transfer sizes and with all possible data patterns for those sizes.
For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.
The test configures the full-speed test device to support as many isochronous loopback pairs of endpoints as the test device supports. The maximum packet size for the endpoints is set to 1024 bytes (or the maximum supported by the test device). The bInterval value for each endpoint is set to the minimum allowable time.
Next, the test sets up a transfer stream for each pair of isochronous endpoints. Each stream repeatedly executes isochronous OUT and isochronous IN transactions. The test compares the data received from the IN transaction to the data sent with each OUT transaction to make sure the data is identical.
The test is repeated for all valid transfer sizes for every possible data pattern.
The data read by an isochronous IN transaction should always match the data sent by an isochronous OUT transaction.
This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.
Results Interpretation
The test writes all results to a file.
The test fails if:
The data returned by any isochronous IN transfer is not identical to the data that was sent with an isochronous OUT transfer.
An isochronous transfer cannot be successfully completed to the test device
Run Time: 45 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:
Windows 7
Windows Server 2008 R2
Windows Vista
Windows Server 2008
Windows Server 2003
Windows XP
Program:
Requirements
Software Requirements
The test tool requires the following software:
- Supported operating system (see list above).
- Software components included with the device that is being tested
Hardware Requirements
- Device to be tested
- One USB 2.0 controller PCI adapter, if system does not contain a USB 2.0 controller
- One test USB 2.0 high-speed hub
- One test USB 1.1 hub
- One Functional Compliance test low-speed device (low-speed USB 2.0 Compliance test board)
- One Functional Compliance test full-speed device (full-speed USB 2.0 Compliance test board)
- One high speed compliance device
Processor
- x86
- x64
- Itanium
Troubleshooting
The following list describes USB High Speed Hub Test Assertions.
Hub Connected Upstream to High Speed Capable Port
1.1.1 When a hub's upstream port is connected to a high speed capable port, control of a full speed device connected to a downstream port must be routed to the transaction translator by the hub port routing logic.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
1.1.2 When a hub's upstream port is connected to a high speed capable port, control of a low speed device must be routed to the transaction translator by the hub port routing logic.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
1.1.3 When a hub's upstream port is connected to a high speed capable port, a USB-IF compliant full speed device must enumerate properly when connected to a downstream port.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
1.1.4 When a hub's upstream port is connected to a high speed capable port, a USB-IF compliant low speed device must enumerate properly when connected to a downstream port.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.1.1.5 When a hub's upstream port is connected to a high speed capable port, a USB-IF compliant high speed device must enumerate properly when connected to a downstream port.
Hub Connected Upstream to Full/Low Speed Only Capable Port
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
1.2.1 When a hub's upstream port is connected to a full/low speed only capable port, a USB-IF compliant high speed device must enumerate properly when connected to a downstream port (as a full speed device).
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
1.2.2 When a hub's upstream port is connected to a full/low speed only capable port, a USB-IF compliant full speed device must enumerate properly when connected to a downstream port.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
1.2.3 When a hub's upstream port is connected to a full/low speed-only capable port, a USB-IF compliant low speed device must enumerate properly when connected to a downstream port.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
1.2.4 When a hub's upstream port is connected to a full/low speed-only capable port, the transaction translator must be disabled and must not be used. The hub repeater must operate as a full/low speed repeater.
General Device Detection
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
1.3.1 Bit 9 of the Port Status Bits should be set to one If and only if a low speed device is attached to the downstream port of a hub.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.
1.3.2 Bit 10 of the Port Status Bits should be set to one if, and only if, a high speed device is attached to the downstream port of a hub that is operating in a high speed environment.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.
Port Indicators. The port indicators are optional for USB 2.0 hubs. However, if they are implemented all of the following assertions must be met.
1.4.1 A hub must accurately indicate whether it supports port indicators through bit D7 of the wHubCharacteristics field of the hub class descriptor.
Reference document: Universal Serial Bus Specification, Revision 2.0, Sections 11.5.3, 11.23.2.1; TD-9.28.1.4 Port Indicator Automatic Mode Test
1.4.2 If a high speed capable hub implements port indicators they must be as specified in the Universal Serial Bus Specification, Revision 2.0. Custom port indicators are not allowed.
Reference document: Universal Serial Bus Specification, Revision 2.0; TD-9.28.1.4 Port Indicator Automatic Mode Test
1.4.3 When a hub is suspended or not configured all of its port indicators must be off.
Reference document: Universal Serial Bus Specification, Revision 2.0, Sections 11.5.3, 11.23.2.1; TD-9.28.1.4 Port Indicator Automatic Mode Test
1.4.4 When a hub makes the transition out of a not configured state, its port indicators must be in Automatic control mode (as defined in section 11.5.3 of the Universal Serial Bus Specification, Revision 2.0) by default.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3
1.4.5 A hub port indictor must be off when it is under automatic control and the port is in the Suspended, Resuming, SendEOR, Restart_E, or Restart_S state.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.
1.4.6 A hub port indictor must be Green when it is under automatic control and the port is in the Enabled, Transmit, or TransmitR state.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.
1.4.7 A hub port indictor for a hub with Port Power Switching must be off when it is under automatic control and the port is in the Disconnected, Disabled, Not Configured, Resetting, or Testing state.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.
1.4.8 The following rule applies to a hub port indictor for a hub without Port Power Switching. It must be off or amber if there is an over-current condition when it is under automatic control and the port is in the Disconnected, Disabled, Not Configured, Resetting, or Testing state.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.
1.4.9 A hub port indictor for a hub with Port Power Switching must be off or amber if there is an over-current condition. This rule applies when it is under automatic control and the port is in the powered-off state.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.
1.4.10 A hub port indictor for a hub without Port Power Switching must be off when it is under automatic control and the port is in the powered-off state.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.
1.4.11 Bit 12 of a hub's Port Status bits must accurately indicate whether the port indicator is currently under Automatic or Software control.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.1; TD-9.28.1.4 Port Indicator Automatic Mode Test
1.4.12 A port indicator must make the transition to manual mode and display amber in response to a Set Port Feature command with feature selector PORT_INDICATOR and Port Indicator Selector 1.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.
1.4.13 A port indicator must make the transition to manual mode and display green in response to a Set Port Feature command with feature selector PORT_INDICATOR and Port Indicator Selector 2.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.
1.4.14 A port indicator must make the transition to manual mode and display off in response to a Set Port Feature command with feature selector PORT_INDICATOR and Port Indicator Selector 3.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.
1.4.15 A port indicator must make the transition to automatic mode in response to a Set Port Feature command with feature selector PORT_INDICATOR and Port Indicator Selector 0.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.
1.4.16 A hub must respond to a Clear Port Feature command with feature selector PORT_INDICATOR by transitioning the port indicator for that port to Automatic Mode.
Reference document: Universal Serial Bus Specification, Revision 2.0, 12/07/00 Errata.
Number of Transaction Translators
- Reporting of Number of Transaction Translator in Implementation
1.5.1 A hub must implement either one transaction translator or one transaction translator per downstream port.
Reference document: Universal Serial Bus Specification, Revision 2.0, 11.14.1.3.
1.5.2 A hub operating at full/low speed must set the bDeviceProtocol field of its Device_Qualifer Descriptor to 1 if its implements a single transaction translator or 2 if it implements one transaction translator per port.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.
1.5.3 A hub operating at high speed must set the bInterfaceProtocol field of its Interface Descriptor to 0 if its implements a single transaction translator or 1 if it implements one transaction translator per port.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.
1.5.4 A hub operating at high speed that implements one transaction translator per port must provide an alternate setting for its interface with all fields identical to those for the default interface except for bInterfaceProtocol which must be set to 2.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.
1.5.5 By default a hub with multiple transaction translators (1 per port) must only use one transaction translator (single TT mode by default).
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.
1.5.6 A multiple transaction translator capable port (1 per port) must only use more than one transaction translator if its alternate interface setting is set through a SET_INTERFACE request. A hub with multiple transaction translators must support SET_INTERFACE when operating in a high-speed capable environment.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.
1.5.7 A hub with multiple transaction translators (1 per port) must support GET_INTERFACE when operating in a high speed environment.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.
Descriptors and Commands
Transaction Translator Commands and Transaction Translator Think Time
1.6.1 A hub must implement its Device, Device Qualifier, Configuration, Interface, Other Speed Configuration, and Endpoint descriptors when connected in a full speed electrical environment as specified in the Universal Serial Bus Specification, Revision 2.0.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.
1.6.2 A hub must implement its Device, Device Qualifier, Configuration, Interface, Other Speed Configuration and Endpoint descriptors when connected in a high speed electrical environment as specified in the Universal Serial Bus Specification, Revision 2.0.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.
1.6.3 A hub must respond to a valid Get_TT_State request with bits 0 to 15 of the TT_Return_Flags field set to zero.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.8.
1.6.4 A transaction translator must return to its initial state after configuration in response to the Reset_TT request.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.9.
1.6.5 A transaction translator must halt operation in response to a valid Stop_TT request.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.11.
1.6.6 A transaction translator that has been stopped via a Stop_TT request must only resume operation after being reset through a Reset_TT request or an overall reset of the hub.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.11.
1.6.7 A transaction translator must clear an asynchronous (non-periodic) buffer associated with the given endpoint in response to a valid Clear TT Buffer request.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.11.
1.6.8 A transaction translator must treat an otherwise correct Clear_TT_Buffer response that specifies a non-existent transaction as a functional no-op.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.11.
1.6.9 A transaction translator must accurately indicate its worst case Think Time to advance to the next full/low speed transaction.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.11.
1.6.10 A multi-TT hub must respond with a Request Error to a Clear TT Buffer, Stop TT, Reset TT, or Get TT State request with an invalid port number. A single TT hub must respond with a Request Error to a Clear TT Buffer or Get TT State request with an invalid port number. A single TT hub may ignore the port number in Stop TT and Reset TT requests.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.
1.6.11 A hub must respond with a Request Error to a Clear TT Buffer, Stop TT, Reset TT, or request with an incorrect wLength field.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.
1.6.12 A hub must support the PING protocol on its control endpoint. This includes the possibility of a host that PINGs before attempting an OUT transaction.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 8.5.1.1.
1.6.13 The bHubContrCurrent field in the hub descriptor must indicate the current draw of the hub circuitry from VBUS. It must not include the current draw of any embedded downstream devices.
Reference document: WLP# B2.6.4.6. Note: This is currently a proposed erratum to the Universal Serial Bus Specification, Revision 2.0. The current (as of 3/29/02) specification does not clearly define the meaning of this field.
1.6.14 A TT that has been stopped with a Stop TT command must continue to generate SOFs to enabled downstream ports under its control.
USB 2.0 Test Modes Assertions
Reference document: WLP# B2.6.4.6. Note: This document is currently a proposed erratum to the Universal Serial Bus Specification, Revision 2.0. The current (as of 3/29/02) specification does not clearly define the meaning of this field.
1.7.1 A hub must place its upstream port in test mode TEST_J in response to a valid SET_FEATURE command with feature selector TEST_MODE and test selector Test_J.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.9.
1.7.2 A hub must place its upstream port in test mode TEST_K in response to a valid SET_FEATURE command with feature selector TEST_MODE and test selector Test_K.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.9.
1.7.3 A hub must place its upstream port in test mode TEST_SEO_NAK in response to a valid SET_FEATURE command with feature selector TEST_MODE and test selector Test_SEO_NAK.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.9.
1.7.4 A hub must place its upstream port in test mode TEST_PACKET in response to a valid SET_FEATURE command with feature selector TEST_MODE and test selector Test_Packet.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.9.
1.7.5 A hub must respond with a request error to a valid SET_FEATURE command with feature selector TEST_MODE and test selector Test_Force_Enable.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.9, 7.1.20.
1.7.6 Once a hub has its upstream port in a test mode it must only exit the test mode if the power is cycled for the hub.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 7.1.20.
1.7.7 A hub must transition a downstream port out of test mode in response to a reset.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.
1.7.8 A hub with a downstream port in a test mode must still report port disconnects or port resume status changes for all other downstream ports.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.
1.7.9 A downstream facing port that has been placed in a test mode may only exit the mode when the hub is reset.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 7.1.20.
1.7.10 A hub must place the designated downstream facing port in test mode TEST_J in response to a valid SET_PORT_FEATURE command with feature selector PORT_TEST and test selector Test_J.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.
1.7.11 A hub must place the designated downstream facing port in test mode TEST_K in response to a valid SET_PORT_FEATURE command with feature selector PORT_TEST and test selector Test_K.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.
1.7.12 A hub must place the designated downstream facing port in test mode TEST_SEO_NAK in response to a valid SET_PORT_FEATURE command with feature selector PORT_TEST and test selector Test_SE0_NAK.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.
1.7.13 A hub must place the designated downstream facing port in test mode TEST_PACKET in response to a valid SET_PORT_FEATURE command with feature selector PORT_TEST and test selector Test_Packet.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.
1.7.14 A hub must place the designated downstream facing port in test mode TEST_Force_Enable in response to a valid SET_PORT_FEATURE command with feature selector PORT_TEST and test selector Test_Force_Enable.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.
1.7.15 A downstream port in test mode Test_Force_Enable must still indicate disconnect events.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 7.1.20.
1.7.16 A hub must respond with a request error (STALL) to a CLEAR_FEATURE command with feature selector TEST_MODE.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.1.
1.7.17 A hub must respond with a request error (STALL) to a CLEAR_PORT_FEATURE command with feature selector PORT_TEST.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.2.
Miscellaneous
- Hub and Transaction Translator Requirements
1.8.1 If a transaction translator is receiving a packet at EOF2 of the downstream facing bus it must disable the downstream facing port that is currently transmitting.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.
1.8.2 If the transaction translator is transmitting a packet near EOF1 of the downstream facing bus it must force and abnormal termination sequence as defined in Section 11.3.3 of the Universal Serial Bus Specification, Revision 2.0 and stop transmitting.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.
1.8.3 A port with a high-speed device connected must still indicate high-speed operation through descriptors when it is suspended and the device reverts to full speed terminations.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.1.9.
1.8.4 If a hub misses Start-of-Frame (SOF) packets for three consecutive microframes when operating in a high speed environment it also loses synchronization for its full speed timers. Any transaction translators in operation must stop generating full speed SOF packets until synchronization is regained.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
1.8.5 Frame timers used by transaction translator units in hubs must maintain synchronization unless the hub microframe timer loses synchronization.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
1.8.6 If a hub misses Start-of-Frame (SOF) packets for three consecutive microframes when operating in a high speed environment it loses synchronization for its microframe timer and all related frame timers used by transaction translators.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
1.8.7 If a hub loses microframe synchronization its transaction translators must respond to periodic complete splits with results buffered in the periodic complete split pipeline.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
1.8.8 If a hub loses microframe synchronization its transaction translators must abort any buffered periodic start-split transactions in the periodic start split pipeline.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
1.8.9 If a hub loses microframe synchronization its high speed handler must ignore any high-speed periodic start splits.
1.8.10 If a hub loses microframe synchronization its transaction translators must stop issuing low speed keep alive on any low speed enabled ports.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
1.8.11 If a hub loses microframe synchronization, its transaction translators must stop issuing full speed SOFs on any full speed enabled downstream ports.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
1.8.12 If a hub loses microframe synchronization, its transaction translators must not start issuing any subsequent periodic full/low speed transactions.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
1.8.13 If a hub loses microframe synchronization, its high-speed handler must respond to any high speed start splits for bulk/control transactions normally. (NAK if buffers full - place transactions in available non-periodic buffers as it normally would.)
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
1.8.14 If a hub loses microframe synchronization it must respond normally to any complete splits for bulk/control transactions.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
1.8.15 If a hub loses microframe synchronization it must not issue any pending bulk/control transactions on the full/low speed bus. It must preserve the buffers for these transactions until synchronization is regained.
1.8.16 A hub must repeat all high speed traffic, including start and complete splits, to all high speed enabled downstream ports. In particular, a hub may not prevent split traffic from reaching a hub further downstream with a full or low speed device connected.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
Bulk and Control (Non-Periodic) Transfers. The following assertions use the notation described in the Universal Serial Bus Specification, Revision 2.0 to describe the possible states of a buffer for a bulk or control transfer being executed through a transaction translator.
| General
2.1.1 A transaction translator must have at least two bulk/control transaction buffers. Each one must be capable of holding the Start Split and related data for an OUT or data from the full/low speed bus for an IN.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.
2.1.2 If the transaction translator has an available Non-Periodic buffer (not in the Ready/X or Pending state) the high speed handler must accept the Start Split for a bulk or control transaction.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.
2.1.3 If the transaction translator does not have an available Non-Periodic buffer (not in the Ready/X or Pending state) the high speed handler must NAK the start split for a bulk or control transfer.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.
2.1.4 If the high speed handler for a transaction translator times out or receives a CRC error anywhere in the <Start Split - Token - Data> sequence for a bulk or control transfer it must timeout and not buffer the transaction in one of its non-periodic buffers.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.
2.1.5 If the high speed handler for a transaction translator times out or receives a bad CRC anywhere in the <Complete Split - Token> sequence it must time out and not respond.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.1.6 If a full or low speed non-periodic transaction results in a NAK, STALL, or ACK response the transaction translator must update the transaction buffer to the corresponding status and must not retry the transaction.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.1.7 A full or low speed non periodic transaction that produces a timeout or transaction error must be retried locally by the transaction translator.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.1.8 A full or low speed non-periodic transaction must not be tried more than three times locally by the transaction translator.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.1.9 A full or low speed non periodic transaction that has been tried three times locally by the transaction translator without success must be resolved to a STALL response.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.1.10 The integrity of all data associated with non periodic transactions must be preserved as it is transferred into and out of any of the non-periodic buffer space used by the transaction translator.
Control Transactions
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.2.1 The high-speed handler for a transaction translator receives a Start Split for a control transfer to an endpoint. There is already a control transaction for that endpoint whose non-periodic buffer is in the pending or ready/x state. In this case, the transaction translator must respond with an ACK but disregard the information.*
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.2.2 If the high speed handler for a transaction translator receives a Start Split for a control transfer and already has a non-periodic buffer in the old/x state for the same endpoint it must re-use the same buffer for the new transaction.
2.2.3 If the high speed handler for a transaction translator receives a Complete Split for a control transfer and has a non-periodic buffer for the same endpoint in the pending state it must respond with a NYET handshake.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.2.4 If the high speed handler for a transaction translator receives a complete split for a control transfer and does not have a non-periodic buffer for that endpoint it must respond with a STALL.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.2.5 The high-speed handler for a transaction translator receives a complete split for a control transfer. If it has a non-periodic buffer for the same endpoint in the ready/STALL state, it must return STALL and transition the buffer to the old/STALL state.*
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.2.6 If the high speed handler for a transaction translator receives a complete split for a control transfer and has a non periodic buffer for the same endpoint in the old/STALL state it must return STALL.*
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.2.7 The high speed handler for a transaction translator receives a complete split for a control OUT transfer. If it has a non-periodic buffer for the same endpoint in the ready/ACK state it must return ACK and transition the buffer to the old/ACK state.*
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.2.8 If the high speed handler for a transaction translator receives a complete split for a control OUT transfer and has a non-periodic buffer for the same endpoint in the old/ACK state it must return ACK.*
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.2.9 The high speed handler for a transaction translator receives a complete split for a control IN transfer. If it has a non-periodic buffer for the same endpoint in the ready/DataX state it must return DataX and transition the buffer to the old/DataX state.*
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.2.10 If the high speed handler for a transaction translator receives a complete split for a control IN transfer and has a non periodic buffer for the same endpoint in the old/Data state it must return Data.*
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.2.11 The high speed handler for a transaction translator receives a complete split for a control transfer. If it has a non-periodic buffer for the same endpoint in the ready/NAK state it must return NAK and transition the buffer to the old/NAK state.*
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.2.12 If the high-speed handler for a transaction translator receives a complete split for a control transfer and has a non periodic buffer for the same endpoint in the old/NAK state, it must return NAK.*
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.2.13 A transaction translator must correctly handle full speed control transfers in both directions of up to 64 bytes.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.2.14 A transaction translator must correctly handle low speed control transfers in both directions of up to 8 bytes.
Note The USB core specification stipulates that direction should not be checked as part of buffer matching for control endpoints. Some vendors have implemented checking that does not match for Setup/In, Setup/Out, Out/In mismatches. These implementations are also acceptable.
Bulk Transactions
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.3.1 The high speed handler for a transaction translator receives a Start Split for a bulk transfer. If there is already a buffer for that endpoint and direction already in the pending or ready/x state it must respond with an ACK but disregard the information.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.3.2 The high speed handler for a transaction translator receives a Start Split for a bulk transfer. If it already has a non-periodic buffer for that endpoint and direction in the old/x state it must re-use the same buffer for the new transaction.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.3.3 The high speed handler for a transaction translator receives a Complete Split for a bulk transfer. If it already has a non-periodic buffer for the same endpoint and direction that is in the pending state it must respond with a NYET handshake.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.3.4 The high speed handler for a transaction translator receives a complete split for a bulk transfer. If it does not have a non-periodic buffer for that endpoint and direction it must respond with a STALL.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.3.5 The high speed handler for a transaction translator receives a complete split for a bulk transfer. If it has a non-periodic buffer for the same endpoint and direction in the ready/STALL state it must return STALL and transition the buffer to the old/STALL state.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.3.6 If the high speed handler for a transaction translator receives a complete split for a bulk transfer and has a non periodic buffer for the same endpoint and direction in the old/STALL state it must return STALL.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.3.7 The high speed handler for a transaction translator receives a complete split for a bulk out transfer. If it has a non-periodic buffer for the same endpoint and direction in the ready/ACK state it must return ACK and transition the buffer to the old/ACK state.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.3.8 If the high speed handler for a transaction translator receives a complete split for a bulk out transfer and has a non periodic buffer for the same endpoint and direction in the old/ACK state it must return ACK.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.3.9 I The high speed handler for a transaction translator receives a complete split for a bulk in transfer. If it has a non-periodic buffer for the same endpoint and direction in the ready/Data state it must return Data and transition the buffer to the old/Data state.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.3.10 If the high speed handler for a transaction translator receives a complete split for a bulk in transfer and has a non periodic buffer for the same endpoint and direction in the old/DataX state it must return DataX.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.3.11 The high speed handler for a transaction translator receives a complete split for a bulk transfer. If it has a non-periodic buffer for the same endpoint and direction in the ready/NAK state it must return NAK and transition the buffer to the old/NAK state.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.3.12 If the high speed handler for a transaction translator receives a complete split for a bulk transfer and has a non periodic buffer for the same endpoint and direction in the old/NAK state it must return NAK.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
2.3.13 A transaction translator must correctly handle full speed bulk transfers in both directions of up to 64 bytes.
Reference document: Universal Serial Bus Specification, Revision 2.0, Chapter 5, 11.
Isochronous and Interrupt (Periodic) Transfers
In the following assertions, the high-speed bus microframes are referenced as follows:
| Y0 | Y1 | Y2 | Y3 | Y4 | Y5 Y6 | Y7 |
Frame X-1 Frame X
3.1.1 A transaction translator must be able to receive and correctly buffer up to 16 start splits for periodic transfers in a single microframe.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.4.
3.1.2 When the high speed handler of a transaction translator receives a valid Start Split for a periodic transaction, it must place the start split into the start split pipeline.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.4.
9.29.1.29 Isochronous Transaction Protocol Test, TD-9.29.1.30 Interrupt Transaction Loopback Test
3.1.3 The high speed handler must accept and handle all valid Start Splits for periodic transfers received in any microframe except during microframe Y6.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.5.
3.1.4 The transaction translator must not start any periodic transaction on the full/low speed bus during the same microframe the Start Split for that transaction arrived.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.5.
3.1.5 The transaction translator (high speed handler) must never send any response packet to a periodic start split.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.5.
3.1.6 The transaction translator (high speed handler) must place periodic start splits in the start split pipeline in the order in which they are received.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.3.
3.1.7 The transaction translator (high speed handler) must execute periodic transactions on the full/low speed bus in the same order as the start splits in the microframe pipeline.
Abort Rules - Section 11.18.6.1
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.3.
3.2.1 If a full or low speed periodic transaction is in progress when EOF occurs, it must be aborted by the transaction translator.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.1.
3.2.2 If an interrupt transaction is in progress and the microframe timer indicates microframe X+4, where X is the microframe in which the start split for the transaction arrived, it must be aborted.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.1.
3.2.3 If a periodic transaction is aborted it must not have a complete split response in the complete split stage pipeline. This means that the transaction translator will respond with a NYET to any Complete Splits for the transaction.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.1.
3.2.4 When a transaction translator aborts a periodic IN transaction, it must not issue the handshake packet for the transaction on the full/low speed bus.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.1.
3.2.5 When a transaction translator aborts an OUT transaction and is in the middle of a DATA packet, it must stop issuing data bytes and force a bit stuffing error on the downstream facing bus.
Free Rules - Section 11.18.6.2
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.1.
3.3.1 If a periodic start split received in microframe X has still not been executed when the microframe timer indicates the X+4 microframe it must be removed from the start split pipeline.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.2.
3.3.2 All start splits in the start split pipeline for unexecuted transfers, except those received in microframe Y7 must be removed from the start split pipeline at the beginning of a new full speed frame.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.2.
3.3.3 The entry for a transaction in the periodic Complete Split pipeline must only live for one microframe after the transaction is executed on the full/low speed bus. At the beginning of the second microframe after the execution the buffer space in the complete split transaction pipeline must be freed for re-use.
Complete-Split Pipeline Search Rules - Section 11.18.8
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.7.
3.4.1 If the high speed handler for a transaction translator receives a periodic complete split that matches the first entry of the complete split pipeline the handler must respond with the indicated data and/or status.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.
3.4.2 The high speed handler for a transaction translator receives a periodic complete split that matches the first entry in the complete split pipeline multiple times. In this case it must continue to respond with the indicated data and/or status until it receives a periodic complete split for a different transaction.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.
3.4.3 If the high speed handler receives a complete split for a periodic transaction that does not match the first entry in the complete split pipeline it must search all other entries in the complete split pipeline.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.
3.4.4 The high speed handler receives a complete split for a periodic transaction that does not match the first entry in the complete split pipeline and does not find a match in the pipeline. In this case it must return the pipeline to its state at the start of the search and return NYET.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.
3.4.5 If the high speed handler receives a complete split for a periodic transaction that does not match the first entry in the complete split pipeline it must search all other entries. If it finds a match it must advance the pipeline to the matching transaction and free all entries it passes in the advance. It must return the status and/or data for the matching entry.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.
3.4.6 If the high-speed handler receives a first periodic complete split for a transaction and has not finished searching the periodic complete split pipeline for a match, it must not respond to the complete split and continue to search for the match. It must respond correctly to the next complete split for the transaction.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.
3.4.7 The transaction translator must not start a periodic transaction until it has space available in the complete split pipeline stage to hold the results of the transaction.
Interrupt Transactions - Sections 11.20.x
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.3.
3.5.1 A transaction translator must never locally retry an interrupt transfer on the full/low speed bus.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.
3.5.2 If the high speed handler for a transaction translator receives a complete split for an interrupt transfer and has a periodic complete split pipeline entry for the same endpoint and direction in the old/NAK state it must return NAK.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.
3.5.3 If the high speed handler for a transaction translator receives a complete split for an interrupt transfer and has a periodic complete split pipeline entry for the same endpoint and direction in the old/STALL state it must return STALL.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.
3.5.4 The high speed handler for a transaction translator receives a complete split for an interrupt transfer. If it has a periodic complete split pipeline entry for the same endpoint and direction in the old/trans_err state it must return ERR.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.
3.5.5 If the high speed handler for a transaction translator receives a complete split for an interrupt OUT transfer and has a periodic complete split pipeline entry for the same endpoint and direction in the old/ACK state it must return ACK.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.
3.5.6 The high speed handler for a transaction translator receives a complete split for an interrupt IN transfer. If it has a periodic complete split pipeline entry for the same endpoint and direction in the old/DATAX state it must return DATAX.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.
3.5.7 The high speed handler for a transaction translator receives a complete split for an interrupt IN transfer. If it has a periodic complete split pipeline entry for the same endpoint and direction in the old/MDATA state it must return MDATA.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.
3.5.8 If the full/low speed CRC check fails, an ERR handshake must be returned to the host for the transaction by the transaction translator. No data can be returned for the current microframe.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.
3.5.9 The full/low speed CRC must not be returned in response to a complete split for an interrupt IN transaction.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.
3.5.10 The full/low speed interrupt IN transaction is still in progress at a microframe boundary and at least 3 data bytes have been received. In this case, the transaction translator must update the appropriate complete split pipeline entry with the current data except the latest two bytes and place the entry in the old/MDATA state. It must not perform a full/low speed CRC check. The transaction translator is allowed to carry forward up to the last 6 bytes in the microframe (2 bytes for the potential CRC plus up to an additional 4 bytes).
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.4. (Currently pending in proposed errata as of 6/26/2001.)
3.5.11 The full/low speed interrupt IN transaction is still in progress at a microframe boundary and less than 3 data bytes have been received. In this case the transaction translator must return NYET to the corresponding complete split. The transaction translator may return NYET and carry forward up to the first 6 data bytes.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.4. (Currently pending in proposed errata as of 6/26/2001.)
3.5.12 A transaction translator returns MDATA for the complete split for an Interrupt IN. It must return the remaining data with the appropriate DATA0/1 PID or ERR if the CRC check fails in response to the next complete split for that endpoint and direction.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.4.
3.5.13 The transaction translator high speed handler receives a CRC error, bit stuffing error, or timeout in the Start Split - IN sequence for an interrupt IN transaction. In this case it must disregard the start split and not place it into the Start Split microframe pipeline.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.
3.5.14 The transaction translator high speed handler receives a CRC error, bit stuffing error, or timeout in the Start Split - OUT - DATA/X sequence for an interrupt OUT transaction. In this case it must disregard the start split and not place it into the Start Split microframe pipeline.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.
3.5.15 If the full/low speed transaction completes before the end of a microframe (no matter how close to the end) the transaction translator must return all data in response to the complete split in the next microframe.
Isochronous Transactions - Sections 11.21.x
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.
3.6.1 A transaction translator must never locally retry an isochronous transfer on the full/low speed bus.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.
3.6.2 The high speed handler for a transaction translator receives a timeout, bit stuffing error, or CRC error in the Start Split-all - OUT - DATA sequence for an isochronous OUT. In this case it must disregard the start split and not attempt the transaction on the full/low speed bus.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.
3.6.3 If the high speed handler for a transaction translator receives a timeout, bit stuffing, or CRC error anywhere in the Start Split-begin - OUT - DATA sequence for an isochronous OUT it must disregard the Start Split and not attempt the transaction on the full/low speed bus.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.
3.6.4 The high speed handler receives an error or times out in the Start Split-begin - OUT - DATA sequence. In this case it must disregard any subsequent Start Split-middles or Start Split-ends for the same endpoint until it receives a Start Split-begin or any Start Split for a different endpoint.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.
3.6.5 The transaction translator must generate the full/low speed CRC for all Isochronous OUT transactions that it generates.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.
3.6.6 If the transaction translator receives a Start Split-begin for an Isochronous OUT transaction it must start the transaction on the full/low speed bus and continue to look for isochronous OUT start splits to the same endpoint in each subsequent microframe.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.
3.6.7 The transaction translator does not receive a Start Split-middle or Start Split-end in a successive microframe after receiving a Start Split-begin for an isochronous OUT endpoint. In this case, it must force a bit stuff error in full/low speed transaction.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.
3.6.8 The high speed handler does not receive a Start Split-middle or Start Split-end in an expected microframe. In this case it must disregard any subsequent Start Split-middles or Start Split-ends for the same endpoint until it receives a Start Split-begin or any Start Split for a different endpoint.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.
3.6.9 The transaction translator receives a Start Split-middle or Start Split-end with a bad CRC in a successive microframe after receiving a Start Split-begin for an isochronous OUT endpoint. In this case it must force a bit stuffing error on the full/low speed transaction.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.
3.6.10 If the high speed handler receives a Start Split-middle or Start Split-end with an error it must disregard any subsequent Start Split-middles or Start Split-ends for the same endpoint until it receives a Start Split-begin or any Start Split for a different endpoint.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.
3.6.11 The high speed handler receives a Start Split-middle or Start Split-end for an Isochronous OUT transaction and does not already have a full/low speed transaction pending for that endpoint. In this case, it must disregard that Start Split and any subsequent Start-Split middles or Start Split-ends for the same endpoint until it receives a Start Split-begin or any Start Split for a different endpoint.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.
3.6.12 The transaction translator high speed handler receives a CRC error, bit stuffing error, or timeout anywhere in the Start Split - IN sequence for an isochronous IN transaction it must disregard the start split and not place it into the Start Split microframe pipeline.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.
3.6.13 The transaction translator must never return the full/low speed CRC as part of the data for an isochronous IN transaction.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.4.
3.6.14 The high speed handler for a transaction translator receives a complete split for an isochronous IN transfer. If it has a periodic complete split pipeline entry for the same endpoint and direction in the old/DATAX state it must return DATAX.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.
3.6.15 The high speed handler for a transaction translator receives a complete split for an isochronous IN transfer and has a periodic complete split pipeline entry for the same endpoint and direction in the old/Trans_err state. It must return ERR.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.
3.6.17 A full speed isochronous IN transaction is still in progress at a microframe boundary and at least three data bytes have been received. In this case, the transaction translator must update the appropriate complete split pipeline entry with the current data except the latest two bytes and place the entry in the old/MDATA state. It must not perform a full speed CRC check. The transaction translator is allowed to carry forward up to the last 6 bytes in the microframe (2 bytes for the potential CRC plus up to an additional 4 bytes).
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.4. (Currently pending in proposed errata as of 6/26/2001.)
3.6.18 A full speed isochronous IN transaction is still in progress at a microframe boundary and less than 3 data bytes have been received. The transaction translator must return NYET to the corresponding complete split. The transaction translator may return NYET and carry forward up to the first 6 data bytes.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.4. (Currently pending in proposed errata as of 6/26/2001.)
3.6.19 If the full/low speed transaction completes before the end of a microframe (no matter how close to the end) the transaction translator must return all data in response to the complete split in the next microframe.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.
3.6.20 The TT high-speed handler must return isochronous data with the same data toggle used by the device. Alternately, the TT high speed handler may always use DATA0.
Reference document: Universal Serial Bus Specification, Revision 2.0, proposed errata as of 3/29/02.
General Transaction Translator (HUB) Data Integrity
- General Host Controller Interaction Assertions
3.7.1 A USB 2.0 hub must not corrupt data moving from a host system to any USB device.
Reference document: Universal Serial Bus Specification, Revision 2.0, Chapter 11.
3.7.2 A USB 2.0 hub must not corrupt data moving from any USB device into the host.
Reference document: Universal Serial Bus Specification, Revision 2.0, Chapter 11.
Transaction Translator Full/Low Speed Transaction Scheduling
- Transaction Scheduling Assertions
3.8.1 The transaction translator full/low speed handler must start executing the next periodic full/low speed transaction for the current microframe whenever it is idle.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.14.2.3.
3.8.2 Whenever the transaction translator full/low speed handler is idle, and there are no periodic transactions available, it must execute an available non-periodic transaction selected in round robin fashion. It must only execute a non-periodic transaction if it can be finished before the end of the current full speed frame. For IN transactions this calculation must be made using the maximum transaction size.
Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.14.2.3.
Multiple Stream Interoperability
- Transaction Scheduling Assertions
3.9.1 The transaction translator must correctly process all valid combinations of periodic and non-periodic transactions running in unison.
Reference document: Universal Serial Bus Specification, Revision 2.0, Chapter 11.
3.9.2 The transaction translator must correctly process all valid combinations of non-periodic transactions running in unison.
Reference document: Universal Serial Bus Specification, Revision 2.0, Chapter 11.
3.9.3 The transaction translator must correctly process all valid combinations of periodic transactions running in unison.
Reference document: Universal Serial Bus Specification, Revision 2.0, Chapter 11.
Build date: 9/14/2012