Universal Serial Bus Specification Revision 2.0
`
`11.20.2 Interrupt Split Transaction State Machines
` st
`_ Issue_packet(HSD1, SSPLIT);
`
`
`
`
`
`RespondHC(Do_complete);
`
`
`
`HC_Do_intOS$
`
`Figure 11-72. Interrupt OUTStart-split Transaction Host State Machine
`
`386
`
`ZTE/SAMSUNG 1008-0414
`ZTE/SAMSUNG 1008-0414
`IPR2018-00110
`IPR2018-00110
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
` HSU2.PID=NAK
`
`/
`
`
`
`_Issue_packet(HSD1, CSPLIT);
`
`
`
`
`
`___HSU2,PID = ACK
`RespondHC(Do_next_cmd);
`
`
`
`-HSU2.PID=NYET ©
`
`
`
`
`not HC_cmd.last
`espondHC(Do_next_complete);
`
`
`
` _(HSU2.PID /= STALL and
`
`_ HSU2.PID /= NAK and
`
`_ HSU2.PID /= ACK and
`
`'HSU2.PID /= ERR and
`
`
`
` HSU2.PID /= NYET) or
`
`
` _ ErrorCount >= 3
`HSU2.timeout
`
`
`
`
`
`
`
`-HSU2.PID=ERR
`
` _ Issue_packet(HSD1, tokenOUT);
`
`
`_RespondHC(Do_comp_immed_now);
`
`ErrorCount < 3
`
`HC_Do_IntOCS
`
`Figure 11-73. Interrupt OUT Complete-split Transaction Host State Machine
`
`387
`
`ZTE/SAMSUNG 1008-0415
`ZTE/SAMSUNG 1008-0415
`IPR2018-00110
`IPR2018-00110
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`-HSD2.PID /= DATAx or
`
`-HSD2.timeout
`
` ~ HSD2.CRC16 =
`
`ok
`
`pipe; shi
`- Data_into_SS_
`
`
`
`/HSD2.CRC16 = bad
`
`_
`
`Figure 11-74. Interrupt OUTStart-split Transaction TT State Machine
`
`388
`
`ZTE/SAMSUNG 1008-0416
`ZTE/SAMSUNG 1008-0416
`IPR2018-00110
`IPR2018-00110
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`| CS_Buff.match.down_result = r_trans_err
`Issue_packet(HSU1, ERR);
`
` =r_nak
`
`Issue_packet(HSU1, NAK);
`
`
`
`_CS_Buff.match.down_result = r_stall
`-
`Issue_packet(HSU1, STALL);
`
`
`
`|
`
`TT_Do_IntOCS
`
`
`
`Figure 11-75. Interrupt OUT Complete-split Transaction TT State Machine
`
`| RespondHC(Do_complete);
`
`
`HC_Do_IntiSS
`
`
`
`|
`
`Figure 11-76. Interrupt IN Start-split Transaction Host State Machine
`
`389
`
`ZTE/SAMSUNG 1008-0417
`ZTE/SAMSUNG 1008-0417
`IPR2018-00110
`IPR2018-00110
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`ce2
`
`
`
`
`
`
`ErrorCount < 3
`RespondHC(Do_start);
`
`
`not HC_cmd.last
`
`
`
`
`
`
`
`
`
`FUSU2PID= NVET |
`HSU2.PID = NAK
`-RespondHC(Do_start);
`
`
`
`
`- HSU2.PID = STALL
`_ RespondHC(Do_halt);
`
`_RespondHC(Do_next_complete);
`
`| Issue_packet(HSD1, tokenIN);
`
` ‘Packet_ready(HSU2)
`
`
`HSU2.PID /= STALL and
`
`HSU2.PID /= ERR)or
`HSU2.timeout
`
`HC_Do_intiCS
`
`Figure 11-77. Interrupt IN Complete-split Transaction Host State Machine
`
`390
`
`ZTE/SAMSUNG 1008-0418
`ZTE/SAMSUNG 1008-0418
`IPR2018-00110
`IPR2018-00110
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`HSU2.x=HC_cmd.toggle
`
`
`
`
`
`
`
`RespondHC(Do_start);
`
`“RespondHC(Do_next_cmd);
`
`
`
`
`
`HSU2.x /=HC_cmd.toggle
`HC_Reject_data;
`
`ieeeoo
`
`~RespondHC(Do_halt);
`
`
`HC_Accept_data; - RespondHC(Do_comp_immed_now);
`
`
`
`
`
`_ HSU2.PID = DATAx and
`:
`_HSU2.CRC16 = ok
`_
`
`|
`
`EHD
`
`ErrorCount < 3
`
`|
`
`-HSU2.PID = MDATA and
`_HSU2.CRC16 = ok
`
`HC_Accept_data;
`
`(HSU2.PID = MDATAor
`HSU2.PID = DATAx) and
`HSU2.CRC16 = bad
`
`-(HSU2.PID /= MDATA and
`HSU2.PID /= DATAx) or
`HSU2.timeout
`
`HC_Data_or_error
`
`Figure 11-78. HC_Data_or_Error State Machine
`
` Data_into_SS_pipe;
`
`TT_Do_IntiSs
`
`Figure 11-79. Interrupt IN Start-split Transaction TT State Machine
`
`391
`
`ZTE/SAMSUNG 1008-0419
`ZTE/SAMSUNG 1008-0419
`IPR2018-00110
`IPR2018-00110
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`| CS_Buff.match.down_result = r_moredata
`Issue_packet(HSU1, MDATA);
`
`|
`
`
`
` CS_Buff.match.down_result = r_lastdata
`Issue_packet(HSU1, DATAx):
`
`
`CS_Buff.match.down_result = r_trans_err
`
`Issue_packet(HSU1,ERR);
`
`
`
`
`
`
`
`
`
`
`
`
`Issue_packet(HSU1, NYET);
`|
`
` _CS_Buff.match.state match_busy
`
`_CS_Buff.match.state = old
`
`Issue_packet(HSU1, NAK);
`
`|
`
`ch2
`
`
`CS_Buff.match.down_result = r_stall
`
`Issue_packet(HSU1, STALL);
`
`S_Buff.match.state = no_match
`
`TT_Do_IntiCS
`
`Figure 11-80. Interrupt IN Complete-split Transaction TT State Machine
`
`11.20.3 Interrupt OUT Sequencing
`Interrupt OUTsplit transactions are scheduled by the host controller as normal high-speed transactions with
`the start- and complete-splits scheduled as described previously.
`
`Whenthere are several full-/low-speed transactions allocated for a given microframe,they are saved by the
`high-speed handlerin the TT in the start-split pipeline stage. The start-splits are saved in the order they are
`received until the end of the microframe. At the end of the microframe, these transactions are available to
`be issued by the full-/low-speed handler on the full-/low-speed bus in the order they were received.
`
`In a following microframe (as described previously), the full-/low-speed handler issues the transactions that
`had been savedin the start-split pipeline stage on the downstream facing full-/low-speed bus. Some
`transactions could be leftover from a previous microframesince the high-speed schedule wasbuilt assuming
`best case bit stuffing and the full-/low-speed transactions could be taking longer on the full-/low-speed bus.
`As the full-/low-speed handler issues transactions on the downstream facing full-/low-speed bus,it saves the
`results in the periodic complete-split pipeline stage and then advancesto the next transaction in the start-
`split pipeline.
`
`In a following microframe (as described previously), the host controller issues a high-speed complete-split
`transaction and the TT responds appropriately.
`
`392
`
`ZTE/SAMSUNG 1008-0420
`ZTE/SAMSUNG 1008-0420
`IPR2018-00110
`IPR2018-00110
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`
`
`— 6
`
`4 bytes
`
`High
`Speed
`Bus
`| 64 bytes w/
`| HS CRC16
`
`
`
`
`
`(125us microframe,
`
`Full/Low-
`Speed
`Bus
`
`Figure 11-81. Example of CRC16 Handling for Interrupt OUT
`
`Thestart-split transaction for an interrupt OUTtransaction includes a normal CRC16 field for the high-
`speed data packetof the data phaseofthe start-split transaction. However, the data payload of the data
`packet containsonly the data payload of the corresponding full-/low-speed data packet; i.e., there is only a
`single CRC16 in the data packetofthe start-split transaction. The TT high-speed handler must check the
`CRConthestart-split and ignore the start-split if there is a failure in the CRC checkof the data packet. If
`the start-split has a CRC checkfailure, the full-speed transaction must not be started on the downstream bus.
`Figure 11-81 shows an example of the CRC16 handling for an interrupt OUTtransaction andits start-split.
`
`11.20.4 Interrupt IN Sequencing
`Whenthe high-speed handler receives an interrupt start-split transaction, it saves the packet in the start-split
`Pipeline stage.
`In this fashion, it accumulates some numberofstart-split transactions for a following
`microframe.
`
`At the beginning of the next microframe (as described previously), these transactions are available to be
`issued by the full-/low-speed handler on the downstream full-/low-speed bus in the order they were saved in
`the start-split pipeline stage. The full-/low-speed handler issues each transaction on the downstream facing
`bus. The full-/low-speed handler responds tothe full-/low-speed transaction with an appropriate handshake
`as described in Chapter 8. Thefull-/low-speed handler saves the results of the transaction (data, NAK,
`STALL,trans_err) in the complete-split pipeline stage.
`
`During following microframes, the host controller issues high-speed complete-split transactions to retrieve
`the data/handshake from the high-speed handler. Whenthe high-speed handler receives s complete-split
`transaction, the TT returns whatever data it has received during a microframe. If the full-/low-speed
`transaction wasstarted and completed in a single microframe, the TT returnsall the data for the transaction
`in the complete-split response occurring in the following microframe. If the full-/low-speed CRC check
`passes, the appropriate DATAO/I PID for the data packetis used. If the full-/low-speed CRC checkfails, an
`ERR handshakeis used and there is no data packet as part of the complete-split transaction.
`
`If the full-/low-speed transaction spanned a microframe, the TT requires two complete-splits (in two
`subsequent microframes) to return al] the data for the full-/low-speed transaction. The data packet PID for
`the first complete-split must be an MDATAto tell the host controller that another complete-split is required
`for this endpoint. This MDATA response is made without performing a CRC check(since the CRC16 field
`has not yet been received onthefull-/low-speed bus). The complete-split in the next microframe must use a
`DATAO/I1 PID if the CRC checkpasses. If the CRC check fails, an ERR handshake response is made
`instead and there is no data packet as part of the complete-split transaction. Since full-speed interrupt
`transactions are limited to 64 data bytes or less (and low-speed interrupt transactions are limited to 8 data
`
`393
`
`ZTE/SAMSUNG 1008-0421
`ZTE/SAMSUNG 1008-0421
`IPR2018-00110
`IPR2018-00110
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`bytes or less), no full-/low-speed interrupt transaction can span morethan a single microframe boundary;
`i.e., no more than two microframesare ever required to complete the transaction.
`
`The complete-split transaction for an interrupt IN transaction must not include the CRC16 field received
`from the full-/low-speed data packet(i.e., only a high-speed CRC16 field is usedin split transactions). The
`TT must use a high-speed CRC16 on each complete-split data packet. Ifthe full-speed handler detects a
`failed CRC check,it must use an ERR handshakeresponse in the complete-split transaction to reflect that
`error to the high-speed host controller. The host controller must check the CRC16 on each returned
`complete-split data packet. A CRCfailure (or ERR handshake) on any (partial) complete-split is reflected
`as a CRCfailure onthetotal full-/low-speed transaction. This meansthat for a case wherea full-/low-speed
`interrupt spans a microframe boundary,
`the host controller can acceptthe first complete-split without
`errors, then the second complete-split can indicate that the data from the first complete-split must be
`rejected asif it were never received by the host controller. Figure 11-82 shows an example ofan interrupt
`IN and its CRC16 handling with corresponding complete-split responses.
`
`Bus
`
`
`
`
`64 bytes w/
`HS CRC16
`
`High
`Speed
`
`125us microframe
`Full/Law-
`Speed
`Bus
`
`2bytes
`
`62 bytes
`
`Figure 11-82. Example of CRC16 Handling for Interrupt IN
`
`11.21 Isochronous Transaction Translation Overview
`
`Isochronoussplit transactions are handled by the host by scheduling start- and complete-split transactions as
`described previously. Isochronous JN split transactions have more than two schedule entries:
`
`*
`
`«
`
`Oneentry for the start-split transaction in the microframe before the earliest the full-speed transaction
`can occur
`
`Other entries for the complete-splits in microframes after the data can occur on the full-speed bus
`(similar to interrupt IN scheduling)
`
`Furthermore, isochronoustransactionsare split into microframe sizedpieces; e.g., a 300 byte full-speed
`transaction is budgeted multiple high-speed split transactions to move data to/from the TT. This allows any
`alignmentof the data for each microframe.
`
`Full-speed isochronous OUTtransactions issued by a TT do not have corresponding complete-split
`transactions. They must only havestart-split transaction(s).
`
`The host controller must preserve the same order for the complete-split transactions(as for the start-split
`transactions) for IN handling.
`
`394
`
`ZTE/SAMSUNG 1008-0422
`ZTE/SAMSUNG 1008-0422
`IPR2018-00110
`IPR2018-00110
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Isochronous INshavestart- and complete- split transactions. The “first” high-speedsplit transaction for a
`full-speed endpointis alwaysa start-split transaction and the second (and others as required) is always a
`complete-split no matter what the high-speed handler ofthe TT responds.
`
`The full-/low-speed handler recombines OUTdata in its local buffers to recreate the single full-speed data
`transaction and handle the microframeerror cases. The full-/low-speed handler splits IN response data on
`microframe boundaries.
`\
`
`Microframe buffers always advance no matter what the interactions with the host controller or the full-speed
`handler.
`
`11.21.1 lsochronous Split Transaction Sequences
`The flow sequence and state machinefigures show the transitions required for high-speed split transactions
`for a full-speed isochronoustransfer type for a single endpoint. These figures must not be interpreted as
`showing any particular specific timing. In particular, high-speed or full-speed transactions for other
`endpoints may occurbefore orafter these split transactions. Specific details are described as appropriate.
`
`In contrast to bulk/control processing, the full-speed handler must not do localretry processing onthe full-
`speed busin responseto transaction errors (including timeout) of an isochronoustransaction.
`
`Start split
`
`eeeere]
`|
`|
`|
`|
`If all of
`If beginning
`If middle
`If last
`payload
`of payload
`of payload
`of payload
`|
`|
`|
`|
`
`stl |
`
`st2}
`
`st3
`
`st4j
`
`SSPLIT-all||SSPLIT -begin||SSPLIT -mid]
`
`
`|SSPLIT -end
`
`
`ATAO
`
`Trans_err
`sel
`
`Trans.err
`not trans_err,
`Data_into_SSpipe Down_error
`sh
`se2:
`v
`
`Go to next
`
`cmd
`
`Figure 11-83. Isochronous OUTStart-split Transaction Sequence
`
`395
`
`ZTE/SAMSUNG 1008-0423
`ZTE/SAMSUNG 1008-0423
`IPR2018-00110
`IPR2018-00110
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Start split
`
`
`
`Data_into_SS'_pipe
`
`|
`
`Go to
`complete split
`
`Figure 11-84. Isochronous IN Start-split Transaction Sequence
`
`In Figure 11-85, the high-speed handler returns an ERR handshake for a “transaction error”of the full-speed
`transaction.
`
`The high-speed handler returns an NYEThandshake whenit cannot find a matching entry in the complete-
`split pipeline stage. This handles the case wherethe host controller issued the first high-speed complete-
`split transaction, but the full-/low-speed handler has not started the transaction yet or has not yet received
`data back from the full-speed device. This can be due to a delay from starting previous full-speed
`transactions.
`
`The transition labeled "TAdvance"indicates that the host advancesto the next transaction for this full-speed
`endpoint.
`
`Thetransition labeled "DAdvance"indicates that the host advances to the next data area of the current
`transaction for the current full-speed endpoint.
`
`396
`
`ZTE/SAMSUNG 1008-0424
`ZTE/SAMSUNG 1008-0424
`IPR2018-00110
`IPR2018-00110
`
`

`

`UniversalSerial Bus Specification Revision 2.0
`
`Complete split
`
`Trans_err [a]
`
`Cr
`
`
`
`intimeNosplitresponsefound
`
`DAMSOTpny
`old/Tvans_err oaaia oldfmor-edata
`:
`4
`od
`anna:
`ch
`ne7|ERR|DATAO||MDATA||NYET
`cour
`coy
`ce4j
`|
`i
`WH.yyNotfrans_err |re
`|
`[OD ee
`ro
`--4
`|
`|
`|
`:
`not
`iferr_count<3
`iferr_count>=3
`|
`Pratserr ue peace
`|
`|
`retry immed.
`|
`|
` ‘rans_err
`=
`Last Not jast
`comp.
`split
`|
`lakt
`|
`i
`p-
`sp
`4
`4
`|
`co
`i
`toce7 ce
`) Ne Leaay 2a
`|
`Recofd error
`chil
`|
`1
`ch3
`NN
`Notlast
`T
`ch4y
`TAdvance
`
`|v
`
`Go to next
`cmd
`
`Go to next
`comp.split
`
`Figure 11-85. Isochronous IN Complete-split Transaction Sequence
`
`397
`
`ZTE/SAMSUNG 1008-0425
`ZTE/SAMSUNG 1008-0425
`IPR2018-00110
`IPR2018-00110
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`11.21.2 IsochronousSplit Transaction State Machines
`
`
`HC_cmd.datapart = alldata
` Issue_packet(HSD1, SSPLIT); -- all
`
` :
`
`
`
`
`
`HC_cmd.datapart = enddata
`i
`_Issue_packet(HSD1, SSPLIT); ~end -
`
`
`
`
`HC_omd.datapart = begindata
`»_
`
`
`Issue_packet(HSD1, SSPLIT);
`-- begin
`
`
`
`
`HC_cmd.datapart = middata
`Issue_packet(HSD1, SSPLIT);
`-- middata
`
`
`
`HC_Do_IsochOSS
`
`Figure 11-86. Isochronous OUT Start-split Transaction Host State Machine
`
`398
`
`ZTE/SAMSUNG 1008-0426
`ZTE/SAMSUNG 1008-0426
`IPR2018-00110
`IPR2018-00110
`
`

`

`SS_Buff.lastdata <= middata;
`SS_Buff.saw_split <= true;
`Data_into_SS_pipe;
`
`:
`
`
`
`
`
`std
`
`HSD2.PID = DATAx and
`HSD2.CRC16 = ok and
`split. datapart = begindata and
`(not SS_Buff.isochO)
`
`
`
`
`
`! HSD2.PID = DATAx and HSD2.CRC16 = ok and
`
`
`- split.datapart = alldata and (not SS_Buff.isochO)
`
`
`
`- HSD2.PID /= DATAx or
`' HSD2.timeout or
`Packet_ready(HSD2) chocRoig=bador0ener
`
`
`_ Bad_lsochOut(SS_Buff,split)
`
`Universal Serial Bus Specification Revision 2.0
`
`i HSD2.PID = DATAx and HSD2.CRC16 = ok and
`' split.datapart = enddata and SS_Buff.isochO and
`_(SS_Buff.lastdata = middata or
`_SS_Bufflastdata = begindata)
`DeaEero spacer peeg
`
`i Fe
`i
`-
`
`SRRTOTS
`SS_Buff.isochO <=false;
`i
`’ SS_Buff.saw_split <=false;
`| Data_intoSS.pipe:
`
`|
`
`
`
`
`
`_ SS_Buff.lastdata = middata)
`
`
`
`
`HSD2.PID = DATAx and HSD2.CRC16 = ok and
`split.datapart = middata and SS_Buff.isochO and
`_ (SS_Buff.lastdata = begindata or
`
`
`
`
`'SS_BuffisochO <= true;
`| SS_Buff.lastdata <= begindata;
`_SS_Buff.saw_split <= true;
`: Data_into_SS_pipe;
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`SS_Buff.isochO
`
`SS_Buff.isochO <= false;
`
`
`
`
`Figure 11-87. Isochronous OUTStart-split Transaction TT State Machine
`
`TT_Do_IsochOSS
`
`There is a condition in Figure 11-87 on transition se1/se2 labeled “Bad_IsochOut”. This conditionis true
`when noneofthe conditionsontransitions st] through st4 are true. The action labeled “Down_error”
`records an errorto be indicated on the downstream facing full-speed bus for the transaction corresponding
`to this start-split.
`
`399
`
`ZTE/SAMSUNG 1008-0427
`ZTE/SAMSUNG 1008-0427
`IPR2018-00110
`IPR2018-00110
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`
`
`
`
`_Issue_packet(HSD1, SSPLIT);
`
`
`
`
`
`
`
`-Issue_packet(HSD1, tokenIN);
`
`|
`
`| RespondHC(Do_complete);
`
`
`
`
`
`HC_Do_IsochiSS
`
`Figure 11-88. Isochronous IN Start-split Transaction Host State Machine
`
`400
`
`ZTE/SAMSUNG 1008-0428
`ZTE/SAMSUNG 1008-0428
`IPR2018-00110
`IPR2018-00110
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`HSU2.PID = DATAx and
`HSU2.CRC16 = ok
`
`HC_Accept_data:
`aes
`
`
`
`
`—_—eee}
`RespondHC(Do_next_cmd);
`
`
`
`
`
`| eSUSPIEMDATA@R|«<<"=:idseae
`
` 2 HSU2.CRC16 = ok RespondHC(Do_next_complete);
`
`
`
`
`
`: (HSU2.PID = MDATAor
`
`_ HSU2.PID = DATAx) and
`HSU2.CRCi16 = bad
`
`
` ErrorCount <3
`
`RespondHC(Do_comp_immed_now);
`
`
`_HSU2.PID /= DATAx and
`_HSU2.PID /= MDATA and
`_HSU2.PID /= ERR)or
`-HSU2.timeout
`
`);
`
` _(HSU2.PID /= NYET and
`
`
`
`
`
`ctt
`
`Issue_packet(HSD1, CSPLIT);
`
`HC_Do_IsochiCs
`
`Figure 11-89. Isochronous IN Complete-split Transaction Host State Machine
`
`In Figure 11-89, the transition “ce8” occurs when the high-speed handler responds with an MDATAto
`indicate there is more data for the full-speed transaction, but the host controller knows that this is the last
`scheduled complete-split for this endpointfor this frame. Ifa DATAO response from the high-speed
`handler is not received before the last scheduled complete-split, the host controller records an error and
`proceedsto the next transaction for this endpoint (in the next frame).
`
`401
`
`ZTE/SAMSUNG 1008-0429
`ZTE/SAMSUNG 1008-0429
`IPR2018-00110
`IPR2018-00110
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`
`
`TT_Do_lIsochiSS
`
`Figure 11-90. Isochronous IN Start-split Transaction TT State Machine
`
`_CS_Buff.match.down_result = r_moredata
`Issue_packet(HSU1, MDATA);
`
` CS_Buff.match.state = old
`
`
`
`
`
`
`
`CS_Buff.match.down_result = r_trans_err
`Issue_packet(HSU1, ERR);
`
`
`CS_Buff.match.state = no_match
`Issue_packet(HSU1, NYET);
`
`|
`TT_IsochICS
`
`Figure 11-91. Isochronous IN Complete-split Transaction TT State Machine
`
`402
`
`ZTE/SAMSUNG 1008-0430
`ZTE/SAMSUNG 1008-0430
`IPR2018-00110
`IPR2018-00110
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`11.21.3 Isochronous OUT Sequencing
`The host controller and TT must ensurethat errors that can occurin split transactions of an isochronousfull-
`speed transaction translate into a detectable error. For isochronous OUTsplit transactions, once the high-
`speed handler has received an “SSPLIT-begin”start-split transaction token packet, the high-speed handler
`musttrack start-split transactions that are received for this endpoint. The high-speed handler musttrack that
`a start-split transaction is received each and every microframe until an “SSPLIT-end”split transaction token
`packet is received for this endpoint. If a microframe passes without the high-speed handler receiving a
`start-split for this full-speed endpoint, it must ensure that the full-speed handler forcesa bitstuff error on the
`full-speed transaction. Any subsequent “SPLIT-middle” or “SPLIT-end”start-splits for the same endpoint
`must be ignored until the next non “SPLIT-middle” and non “SPLIT-end”is received (for any endpoint
`supported by this TT).
`
`The start-split transaction for an isochronous OUTtransaction must not include the CRC16 field for the full-
`speed data packet. Fora full-speed transaction, the host would compute the CRC16 ofthe data packet for
`the full data packet (e.g., a 1023 byte data packet uses a single CRC16 field that is computed once by the
`host controller). For a split transaction, any isochronous OUTfull-speed transaction is subdivided into
`multiple start-splits, each with a data payload of 188 bytes or less. For each of these start-splits, the host
`computes a high-speed CRC16 field for each start-split data packet. The TT high-speed handler must check
`each high-speed CRC16 value oneachstart-split. The TT full-speed handler mustlocally generate the
`CRC16 value for the complete full-speed data packet. Figure 11-92 shows an exampleofa full-speed
`isochronous OUTpacketand the high-speedstart-splits with their CRC16 fields.
`
`If there is a CRC checkfailure on the high-speedstart-split, the high-speed handler must indicate to the full-
`speed handlerthat there was an error in the start-split for the full-speed transaction. If the transaction has
`been indicated as having a CRCfailure (or if there is a missed start-split), the full-speed handler uses the
`defined mechanism for forcing a downstream corrupted packet.
`Ifthe first start-split has a CRC check
`failure, the full-speed transaction mustnot be started on the downstream bus.
`
`Additional high-speed start-split transactions for the same endpoint must be ignored after a CRC checkfails,
`until the high-speed handler receives either an “SSPLIT-end”start-split transaction token packet for that
`endpoint ora start-split for a different endpoint.
`
`
` | 2 bytes w/
`
`HS CRCI6
`
`2 bytes
`188 bytes
`Figure 11-92, Example of CRC16 Isochronous OUT Data Packet Handling
`
`403
`
`ZTE/SAMSUNG 1008-0431
`ZTE/SAMSUNG 1008-0431
`IPR2018-00110
`IPR2018-00110
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`11.21.4 Isochronous IN Sequencing
`The complete-split transaction for an isochronousIN transaction must not include the CRC16 field for the
`full-speed data packet (e.g., only a high-speed CRC16 field is used in split transactions). The TT must not
`pass the full-speed value received from the device and instead only use high-speed CRC16 values for
`complete-split transactions. If the full-speed handler detects a failed CRC check at the end of the data
`packet(e.g., after potentially several complete-split transactions on high-speed), the handler must use an
`ERR handshakeresponseto reflect that error to the high-speed host controller. The host controller must
`check the CRC16 on each returned high-speed complete-split. A CRC failure (or ERR handshake) on any
`(partial) complete-split is reflected by the host controller as a CRC failure on thetotal full-speed transaction.
`Figure 11-93 shows an example ofthe relationships of the full-speed data packet and the high-speed
`complete-splits and their CRC16 fields.
`
`High
`Speed
`
`1 byte w/
`HS CRCI6
`
` 2+186 bytes w/
`+
`HS CRC16
`i
`1 byte w/
`HS CRC16
`
`| 1
`
`
`25us microframe i/
`
`Bus
`
`
`Full
`Speed
`Bus
`
`3 bytes
`
`188 bytes
`
`Figure 11-93. Example of CRC16 Isochronous IN Data Packet Handling
`
`11.22 TT Error Handling
`The TT has the same requirements for handling errors as a host controller or hub. In particular:
`
`e
`
`e
`
`e
`
`Ifthe TT is receiving a packet at EOF2 of the downstream facing bus, it must disable the downstream
`facing port that is currently transmitting.
`
`Ifthe TT is transmitting a packet near EOF1 of the downstream facing bus, it must force an abnormal
`termination sequence as defined in Section 11.3.3 and stop transmitting.
`
`Ifthe TT is going to transmit a non-periodic full-/low-speed transaction, it must determinethat thereis
`sufficient time remaining before EOF] to complete the transaction. This determination is based on
`normal sequencing of the packets in the transaction. Since the TT has no information about data
`payload size for INs, it must use the maximum allowedsize allowed for the transfertype in its
`determination. Periodic transactions do not need to be included in this test since the microframe
`pipeline is maintained separately.
`
`11.22.1 Loss of TT Synchronization With HS SOFs
`The hub hasa timer it uses for (micro)frame maintenance.
`It has a | ms frame timer when operatingat full-
`/low-speed for enforcing EOF with downstream connected devices. It has a 125 tts microframe timer when
`operating at high-speed for enforcing EOF with high-speed devices. It also uses the 125 ts microframe
`timer to create a 1 ms frametimer for enforcing EOF with downstream full-/low-speed devices when
`operating at high-speed. The hub (micro)frame timer must always stay synchronized with host generated
`SOFsto keep the bus operating correctly
`
`404
`
`ZTE/SAMSUNG 1008-0432
`ZTE/SAMSUNG 1008-0432
`IPR2018-00110
`IPR2018-00110
`
`

`

`Universal Seria] Bus Specification Revision 2.0
`
`In normal hubrepeater(full- or high-speed) operation (e.g., not involving a TT), the (micro)frame timer
`loses synchronization wheneverit has missed SOFsfor three consecutive microframes. While timer
`synchronization is lost, the hub does not establish upstream connectivity. Downstream connectivity is
`established normally, even when timer synchronization is lost. When the timer is synchronized, the hub
`allows upstream connectivity to be established when required. The hubis responsible for ensuring that
`there is no signaling being repeated/transmitted upstream from a device after the EOF2 point in any
`(micro)frame. The hub must notestablish upstream connectivity if it has lost (micro)frame timer
`synchronization since it no longer knows accurately where the EOF2pointis.
`
`11.22.2 TT Frame and Microframe Timer Synchronization Requirements
`Whenthe hubis operating at high-speed and hasfull-/low-speed devices connected on its downstream
`facing ports (e.g., a TT is active), the hub has additional responsibilities beyond enforcementofthe (high-
`speed) EOF2 point onits upstream facing port in every microframe. The TT must also generate full-speed
`SOFs downstream and ensure that the TT operates correctly (in bridging high-speed andfull-/low-speed
`operation).
`
`A high-speed operating hub synchronizesits microframe timer to 125 jis SOFs. However,in orderto
`generate full-speed downstream SOFs,it must also have a | ms frame timer.
`It generates this | ms frame
`timer by recognizing zeroth microframe SOFs,e.g., a high-speed SOF when the frame numbervalue
`changes compared to SOF ofthe immediately previous microframe.
`
`In order to create the | ms frame timer, the hub must successfully receive a zeroth microframe SOFafterits
`microframetimer is synchronized.
`In order to recognize a zeroth microframe SOF, the hub must
`successfully receive SOFs for two consecutive microframes where the frame number increments by 1 (mod
`2°11). When the hub has donethis, it knows that the second SOFis a zeroth microframe SOFand thereby
`establishes a 1 ms frametimerstarting time. Note that a hub can synchronize both timers with as few as
`two SOFsif the SOFs are for microframe 7 and microframe 0, i.e., if the second SOFis a zeroth
`microframe SOF.
`
`Oncethe hub has synchronizedits 1 ms frametimer, it can keep that timer synchronizedas long as it keeps
`its 125 jis microframe timer synchronized (since it knows that every 8 microframes from the zeroth
`microframe SOFis a 1 ms frame).
`In particular, the hub can keepits frame timer synchronized evenifit
`misses zeroth microframe SOFs(as long as the microframe timer stays synchronized).
`
`So in summary, the hub can synchronize its 125 ts microframetimerafter receiving SOFs of two
`consecutive microframes. It synchronizes its 1 ms frame timer whenit receives a zeroth microframe SOF
`(and the microframe timer is synchronized). The 125 js microframe timer loses synchronization after three
`SOFsfor consecutive microframes have been missed. This also causes the 1 ms frame timerto lose
`synchronization at the same time.
`
`The TT must only generate full-speed SOFs downstream whenits 1 ms frame timer is synchronized.
`
`Correct internal operation ofthe TT is dependent on both timers. The TT must accurately know when
`microframes occurto enforce its microframe pipeline abort/free rules.
`It knowsthis based on a
`synchronized microframe timer (for generally incrementing the microframe number) and a synchronized
`frame timer (to know whenthe zeroth microframeoccurs).
`
`Since loss of microframe timer synchronization immediately causes loss of frame timer synchronization, the
`TT stops normal!operation once the microframe timer loses synchronization.
`In an error free environment,
`microframe timer synchronization can berestored after receiving the two SOFsfor the next two consecutive
`microframes(e.g., synchronization is restored at least 250 is after synchronization loss). As long as SOFs
`are not missed, frame timer synchronization will be restored in less than 1 ms after microframe
`synchronization. Note that frame timer synchronization can be restored in a high-speed operating case in
`muchless time (0.250-1.250 ms) than the 2-3 ms required in full-speed operation. Once the frame timeris
`synchronized, SOFs can be issued on downstream facing full-speed ports for the beginning of the next
`frame.
`
`405
`
`ZTE/SAMSUNG 1008-0433
`ZTE/SAMSUNG 1008-0433
`IPR2018-00110
`IPR2018-00110
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Once the hub detects loss of microframe timer synchronization, its TT(s):
`
`1. Must respond to periodic complete-splits with any responses buffered in the periodic pipeline (only
`good for at most 1 microframe of complete-splits).
`
`2. Must abort any buffered periodic start-split transactions in the periodic pipeline.
`
`3. Must ignore any high-speed periodic start-splits.
`
`4, Muststop issuing full-speed SOFs on downstream facing full-speed ports (and low-speed keep-alives
`on low-speed ports).
`
`5. Mustnotstart issuing subsequent periodic full-/low-speed transactions on downstream facing full-/low-
`speed ports.
`
`6. Must respond to high-speedstart-split bulk/control transactions.
`
`7. Buffered bulk/control results must respond to high-speed complete-split transactions.
`
`8.
`
`Pending bulk/control transactions must not be issued to full-/low-speed downstream facing ports. The
`TT buffers used to hold bulk/control transactions must be preserved until the microframetimeris re-
`synchronized. (Or unti] a Clear_TT_Buffer request is received for the transaction).
`
`Note that in any case a TT mustnot issue transactions of any speed on downstream facing ports when its
`upstream facing port is suspended.
`
`A TTonly restores normal operation on downstream facing full-/low-speed ports after both microframe and
`frame timers are synchronized. Figure Figure 11-94 summarizes the relationship between high-speed SOFs
`and the TT frame and microframetimer synchronization requirementsonstart-splits.
`
`For suspend sequencing of a hub, a hubwill first lose microframe/frame timer synchronization at the same
`time. This will cause its TT(s) to stop issuing SOFs (which should be the only transactions keeping the
`downstream facing full-/low-speed ports out of suspend). Then the hub (along with any downstream
`devices) will enter suspend.
`
`Upon a resume,the hub will first restore its microframe timer synchronization (after high-speed transactions
`continue). Then in less than 1 ms (assuming noerrors), the frame timer will be synchronized and the TT
`canstart normal operation (including SOFs/keep-alives on downstream facing full-/low-speed ports).
`
`Microframes
`
`Yo
`
`}
`
`:
`No
`SOF
`
`|
`;
`SOF
`
`Y,
`
`i
`
`Y;
`
`i
`
`Y,
`
`|
`i
`No
`SOF
`
`:
`:
`No
`SOF
`
`|
`
`i
`SOF
`
`Y,
`
`i
`
`Y; Ye
`
`Y,
`
`i
`
`(Y+T),
`
`|
`}
`SOF
`
`g
`SOF
`
`1
`SOF
`
`i
`SOF
`
` ¢
`
`:
`
`t
`SOF
`
`v
`v
`v
`Microframe & Frame
`Microframe Timer
`Lose Microframe & Frame
`Timer Synchronized,
`Re-synchronized;
`Timer Synchronization,
`
`Ignore start-splits Frame timer unsynchronized,=Acceptstart-splits
`Ignore start-splits
`
`Figure 11-94. Example Frame/Microframe Synchronization Events
`
`406
`
`ZTE/SAMSUNG 1008-0434
`ZTE/SAMSUNG 1008-0434 —
`IPR2018-00110
`IPR2018-00110
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`11.
`
`23 Descriptors
`Hubdescriptors are derived from the general USB device framework. Hub descriptors define a hub device
`and the ports on that hub. The host accesses hub descriptors through the hub’s default pipe.
`
`The USBspecification (refer to Chapter 9) defines the following descriptors:
`
`e Device
`
`e
`
`e
`
`e
`
`e
`
`Configuration
`
`Interface
`
`Endpoint
`
`String (optional)
`
`The hubclass defines add