Universal Serial Bus Specification Revision 2.0
`
`1120.2 Interrupt Split Transaction State Machines
`
`
`Issue_packet{HSD1. SSPLIU;
`
`
`
`
`
`
`
`RespondHC{Do_complete);
`
`
`Hc_oo_:ntoss
`
`Figure 11-72. Interrupt OUT Start-split Transaction Host State Machine
`
`386
`
`ZTE/SAMSUNG 1008-0414
`ZTE/SAMSUNG 1008-0414
`IPR2018-00110
`|PR201 8-001 10
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`HSU2.PID = NAK .
`
`
`
`
`
`
`
`; lssue_packet(HSD1. CSPLIT);
`
`
`
`__ Issue__packet(HSD1, tokenOUT];
`
`Packet read (HSUZ)
`
`
`
` (HSUZPID i: STALL and
`
`
`HSU2.P1D r: NAK and
`Hsu2.Plor=AcK and
`HSU2.PID!= ERR and
`HSUZHD r= NYEI'] or
`HSU2.timeout
`
`
`
`
` . ErrorCount >= 3
`
`
`
`
`
`
`5 RespondHC(Do_corrlp_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
`|PR2018-00110
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`_ HSD2.P|D {3 DATAX or
`_ HSD2.timeout
`
`
`
`
`: HSD2.CRC16 - 0k
`5?” 3 Data into 53 i e'
`
`
`$22
`
`
`
`
`
`
`HSD2.CRC16 :- bad
`
`Figure 11-74. Interrupt OUT Start-split Transaction TT State Machine
`
`388
`
`ZTE/SAMSUNG 1008-0416
`ZTE/SAMSUNG 1008-0416
`IPR2018-00110
`|PR201 8-001 10
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`
`CS_Buff.match.down_result = r_trans*err
`IssuejackeflHSUL ERR);
`
` = r_nak
`
`IssuejackeKHSUL NAK);
`
`_ CS_Buff.match.down_result = r_sial|
`
`
`
`:
`
`Issue_packe1(HSU1, STALL);
`
`
`
`I
`
`TT_Do_lntOCS
`
`
`
`Figure 11—75. Interrupt OUT Complete-split Transaction ”IT State Machine
`
`
`
`RespondHC(Do_eomplete);
`
`HC_Do_lntISS
`
`
`
`Figure 11-76. Interrupt IN Start-split Transaction Host State Machine
`
`389
`
`ZTE/SAMSUNG 1008-0417
`ZTE/SAMSUNG 1008-0417
`IPR2018-00110
`|PR201 8-001 10
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`
` ErrorCount < 3
`
`RespondHC(Do_-stan);
`
`!
`
`
`
`not HC_cmd.last
`RespondHC(Do_next_complete);
`
`
`
`
`
`
`
` 5
`
`.
`
`HSU2.P|D = NAK
`RespondHC{Do_starl);
`
`
`
`
`: HSU2.F'|D = STALL
`; RespondHC(Do_ha[t);
`
`
`
`
`
`(HSUZPID I: NAK and
`HSU2.P|D :‘= STALL and
`HSUZPID l= NYET and
`HSU2.PID I: ERR] or
`HSU2.timeout
`
`HC_Do_!ntICS
`
`Figure 11-77. Interrupt IN Complete-split Transaction Host State Machine
`
`390
`
`ZTE/SAMSUNG 1008-0418
`ZTE/SAMSUNG 1008-0418
`IPR2018-00110
`|PR2018-00110
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`
`
`HSU2.x = HC_cmd.toggle
`
`5 RespondHC(Do_next_cmd);
`
`
`
`
`HSU2.x l= HC_cmd.toggle
`
`:
`
`HC_Reject_data;
`
`
`
`:
`
`ReapondHC(Do_start);
`
`..
`
`1
`
`
`
`_— EFFOFCDUntb=3
`
`
`
`ERespmndHC‘.(Dcn_halt);
`
`HSU2.P|D = DATAx and
`Hsuzcrzme = 0k
`
`HC_Accept_wdata:
`
`
`
`ErrorCount < 3
`
`' RespondHC(Do_comp_immed_now);
`
`E
`
`
`
`
`HSU2.PID = MDATA and
`HSU2.CRC16 = 0k
`
`HC_Accept'_data;
`
`(HSUZPID = MDATA or
`HSU2.PID = DATAX) and
`HSU2,CRC16 = bad
`
`
`
`
`' (HSU2.PlD 1: MDATA and
`HSU2.PID f: DATAX) or
`HSU2.timeout
`
`'
`
`HCWD atavorfierror
`
`Figure 11-78. HC_Data_nr_Error State Machine
`
` DataFintouSSJipe;
`
`TT_Do_|ntISS
`
`Figure 11-79. Interrupt IN Start-split Transaction TT State Machine
`
`391
`
`ZTE/SAMSUNG 1008-0419
`ZTE/SAMSUNG 1008-0419
`IPR2018-00110
`|PR2018—001 1O
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`: CS_Buff.match.down_result = r_moredata
`lssue_packet(HSU1, MDATA);
`
`E
`
`
`
`CS_Buff.match.down_result = r_|astdata
`Issue_packet(HSU1. DATAx);
`
`
`CS_Buff.match.down_result = r_trans_err
`
`"
`
`Issuejacket(HSU1 ,ERR);
`
`
`
`
`
`
`
`
`
`
`CSWBuffmatchstate = old
`
`lssue_packet(HSU1, NAK};
`
`i
`
`6,12
`
`
`CS_Bufi.match.down_result = r_stali
`
`
`
`
`issuejackem HSU1, STALL)‘
`
`
`
`S_Buff.match.state = no_rnatch
`lssuejackeflHSUL NYET);
`_
`
` iCS_Buff.match.state match_busy
`
`_
`
`'|'|'_Do_int|CS
`
`Figure 11-80. Interrupt IN Corn plete-split Transaction TT State Machine
`
`1120.3 Interrupt OUT Sequencing
`
`Interrupt OUT split transactions are scheduled by the host controller as norlnal high—speed transactions with
`the start- and complete-splits scheduled as described previously.
`
`When there are several full-flow-speed transactions allocated for a given microfi'ame, they are saved by the
`high-speed handler in the 'IT in the start-split pipeline stage.
`'[he 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-flow-speed handler on the full-flow-speed bus in the order they were received.
`
`In a following microframe (as described previously), the full-flow-speed handler issues the transactions that
`had been saved in the start-split pipeline stage on the downstream facing full-flow-speed bus. Some
`transactions could be leftover from a previous microframe since the high-speed schedule was built assuming
`best case bit stuffing and the full-flow—speed transactions could be taking longer on the full-flow-speed bus.
`As the fiJll-flow-speed handler issues transactions on the dowustream facing full-flow-speed bus, it saves the
`results in the periodic complete—split pipeline stage and then advances to 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
`|PR201 8-001 10
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`High
`
`Speed
`
`
`mm5
`
`E 64 bytes w!
`HS CRC16
`
`Full/Low—
`
`Speed
`Bus
`
`
`
`64 bytes
`
`Figure 11-8]. Example of CRC16 Handling for Interrupt OUT
`
`The start-split transaction for an interrupt OUT transaction includes a normal CRC 1 6 field for the high-
`speed data packet of the data phase of the start-split transaction. However, the data payload of the data
`packet contains only the data payload of the corresponding full-tlow-speed data packet; i.e., there is only a
`single CRC] 6 in the data packet of the statt—spl it transaction. The TT high-speed handler must check the
`CRC on the start-split and ignore the start-split if there is a failure in the CRC check of the data packet. If
`the start-split has a CRC check failure, the full-speed transaction must not be started on the downstream bus.
`Figure ll-SI shows an example ofthe CRCl6 handling for an interrupt OUT transaction and its start-split.
`
`1120.4 Interrupt IN Sequencing
`When the 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 number of start-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-llow-speed handler on the dDWnstream full-flow-speed bus in the order they were saved in
`the start-split pipeline stage. The full-flow-speed handler issues each transaction on the downstream facing
`bus. The full-llow-speed handler responds to the full-flow-speed transaction with an appropriate handshake
`as described in Chapter 8. The full-flow-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)Irhandshake from the high-speed handler. When the high-speed handler receives 5 complete-split
`transaction, the TT returns whatever data it has received during a microframe. If the full-flow-speed
`transaction was Started and completed in a single microframe, the "IT returns all the data for the transaction
`in the complete-Sp] it response occurring in the following microframe. If the full-{Iow-speed CRC check
`passes, the appropriate DATAOI‘ I PID for the data packet is used. if the full-llow-speed CRC check fails, an
`ERR handshake is used and there is no data packet as part of the com plete-split transaction.
`
`If the full—flow—speed transaction spanned a microframe, the TT requires two complete-splits (in two
`subsequent microfram es) to return all the data for the full-Klow«speed transaction. The data packet PID for
`the first complete-split must be an MDATA to 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 CRC l 6 field
`has not yet been received on the full-flow-speed bus}. The complete-split in the next microframe must use a
`DATACI:r l PID if the CRC check passes. If the CRC check fails, an ER handshake response is made
`instead and there is no data packet as part of the complete-5p] it 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
`|PR201 8-001 10
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`bytes or less), no full-flow-speed interrupt transaction can span more than a single microfr‘ame boundary;
`i.e., no more than two mi croframes are 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-flow-speed data packet (i.e., only a hi gh-speed CRC16 field is used in split transactions). The
`TT must use a high-speed CRC16 on each complete-split data packet. If the full-speed handler detects a
`failed CRC check, it must use an ER handshake reSponse 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 CRC failure (or ERR handshake) on any (partial) complete—split is reflected
`as a CRC failure on the total full-flow-speed transaction. This means that for a case where a full-flow-speed
`interrupt spans a microframe boundary,
`the host controller can accept the first complete-split without
`errors, then the second complete-split can indicate that the data from the first complete-split must be
`rejected as if it were never received by the host controller. Figure “-82 shows an example of an interrupt
`IN and its CRC16 handling with corresponding complete-split re5ponses.
`
`High
`Speed
`Bus
`
`l
`
`125us microfiame
`
`Full/Low-
`
`Speed
`Bus
`
`
`
`
`
`
`64 bytes wt
`HS CRC16
`
`
`
`2 bytes
`
`62 bytes
`
`Figure 11-82. Example of CRClfi Handling for Interrupt [N
`
`11.21 Isochronous Transaction Translation Overview
`
`Isochronous spl it transactions are handled by the host by scheduling start- and complete-split transactions as
`described previously. Isochronous IN split transactions have more than two schedule entries:
`
`II
`
`II
`
`One entry for the start-split transaction in the microfi'ame 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, isochronous transactions are split into microframe sized pieces; e.g., a 300 byte full~speed
`transaction is budgeted multiple high-speed split transactions to move data toffrom the "IT. This allows any
`alignment of the data for each microframe.
`
`Full-speed isochronous OUT transactions issued by a TT do not have corresponding complete-split
`transactions. They must only have start-split transaction(s).
`
`The host controller must preserve the same order for the complete-split transactions (as for the start-spl it
`transactions) for IN handling.
`
`394
`
`ZTE/SAMSUNG 1008-0422
`ZTE/SAMSUNG 1008-0422
`IPR2018-00110
`|PR201 8-001 10
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Isochronous INs have start- and complete- split transactions. The “first” high-speed split transaction for a
`full-speed endpoint is always a start-split transaction and the second (and others as required) is always a
`complete—split no matter what the high—speed handler of the TT responds.
`
`The fiill-r’low-speed handler recombines OUT data in its local buffers to recreate the single full-speed data
`transaction and handle the microframe error cases. The filll-J'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 machine figures show the transitions required for high-speed split transactions
`for a full-speed isochronous transfer 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 occur before or after these split transactions. Specific details are described as appropriate.
`
`In contrast to bulkfcontrol processing, the full-«speed handler must not do local retry processing on the full-
`speed bus in response to transaction errors (including timeout) of an isochronous transaction.
`
`Start split
`
`!_'''''''''''''''_!''''''''''l______!'''''''''''''''''1.
`
`I
`If a'll of
`payiload
`|
`
`|
`If beginning
`of paj'Ioad
`|
`
`|
`If middle
`of payload
`l
`
`|
`Ifliist
`of payload
`I
`
`st] '
`
`st2'
`
`st3 '
`
`st4'
`
`
`
`SSPLIT-all
`
`SSPLTT ~begin SSPLIT -rnid
`
`SSPLIT -end
`
`
`
`
`
`
`
`.............................................................
`
`DATAO
`
`Tréansyrr
`set;
`
`Transierr
`not Ironic”,
`Data_t'n§‘0_SS_pipe Domierror
`shli
`se2§
`V
`Y
`Go to next
`
`cmd
`
`Figure 11-83.
`
`lsoehronous OUT Start-split Transaction Sequence
`
`
`
`395
`
`ZTE/SAMSUNG 1008-0423
`ZTE/SAMSUNG 1008—0423
`IPR2018-00110
`|PR2018—001 10
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Start split
`
`51]
`
`
`
`Data_in%0_SS_pipe
`
`!v
`
`Go to
`
`complete split
`
`Figure 11-84.
`
`lsochronous 1N Start-split Transaction Sequence
`
`In Figure 11-85, the high-speed handler returns an ERR handshake for a “transaction error” of the fiill-speed
`transaction.
`
`The high-speed handler retums an NYET handshake when it cannot find a matching entry in the complete-
`split pipeline stage. This handles the case where the host controller issued the first hi gh-speed complete-
`split transaction, but the full-flow-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 advances to the next transaction for this full-speed
`endpoint.
`
`The transition 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
`|PR201 8-001 10
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`Complete split
`
`ct]
`
`TranLerr
`_E".................................................... Ct2
`
`
`
`Fastimarch
`_
`
`'
`
`eel;
`Searchnofcompfew.........
`:
`inn'me
`$ Tra-z-s_err
`¢
`+
`ce7i
`'“° 1?“
`couq
`r———————————1
`cef};
`0641'
`i
`if err_count < 3
`if err_c¢:tunt >= 3
`retry immed.
`!
`com s lit
`!
`P. P
`i
`
`
`
`........NOSPt'Irr-eb'pomfmd
`t....................................1.............................................=
`ofd/Téanterr
`ofdé’lastdam
`oia’é’moredara
`
`ceZLi
`Cd 1%
`cdzv
`ch41;
`DA TAO
`MDATA
`1 NYET 1
`r' "I
`r' “1
`i.____
`i
`-:
`i
`' ______Y Not lrans_err il—
`i
`.
`I
`'
`.
`i
`!
`i Traus_err 33 vance
`!
`not
`i
`trans_?rr
`__Y
`L+st Not last
`!
`Ink—t
`!
`'
`'
`i
`!
`ceg
`to ce?
`!
`:
`cc;
`i
`‘I'
`-—'—-—-T-— —-—-_-_\-..__ L_/'r—’————————!\-..__ i _/'r—————
`i
`Record error
`chli
`1—
`l
`i___________Y
`Not last
`6113 !
`T
`ch4+_________ ________+
`TAddance
`
`!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
`|PR201 8-001 10
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`11.21.2 lsochronous Split Transaction State Machines
`
`
`HC_cmd.datapart = alldata
`E
`glssue_packe1(HSD1, SSPLlT);—all
`
`.—
`
`
` st1
` _:
`HC_cmd.datapart = enddata
`-- end
`glssueJJackeflHsm SSPLIT)‘
`
`
`
`
`
`HC_cmd.datapart = begindata
` 313
`glssueJaackeflHsm, SSPLIT);
`-~ begin
`
` HC_cmd.datapart middata
`
`IssueJaacket(HSD1, SSPLIT); "middata
`
`
`
`HCHDcLIsochOSS
`
`Figure 11-36. Isochronous OUT Start-split Transaction Host State Machine
`
`398
`
`ZTE/SAMSUNG 1008-0426
`ZTE/SAMSUNG 1008-0426
`IPR2018-00110
`|PR201 8-001 10
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`HSD2.PID = DATAX and HSDZCRC16 = 0k and
`splitdatapart = enddata and SSHBufstochO and
`(SS_Bufi.Iastdata = middata or
`SS_Buff.lastdata = begindata)
`.. .
`
`..
`
`.
`
`............
`
`-E
`E
`
`_
`
`g
`{ii
`
`SS_Buff.isoch0 <= false;
`—. SS_Buff.saw_split <=fa|se;
`Data_into_SS_pipe;
`
`'—
`.
`:
`
`
`
`
`
`
`
`splitdatapart = middata and SS_Buff.isochO and
`(SS_Buff.Iastdata = begindata or
`SS_Buff.lastdata = middata)
`
`
`
`
`
`
`
`
`
`
`HSDZPID = DATAx and
`HSD2.CRC16 = ok and
`
`splitdatapart = begindata and
`{not SS_Buff.isoch0)
`
`st4
`
`
`
`SS_Buff.lastdata <= middata:
`SS_Buff.saw_split <= true;
`DatafiintcHSSjipe;
`
`
`
`
`
`
`SS_Buff.isoch0 <3 true;
`SS_Buff.Iastdata <= begindata;
`SS_Buff.saw_split <: true;
`Data_into_SSJ3ipe;
`
`
`
`HSD2.PID = DATAX and HSD2.CRC16 = 0k and
`
`spliLdatapart 3 alldata and {not SS_Buff.isochO)
`
`
`
`
`
`
`
`
`
`
`m1..‘.'§fi?........
`HSD2.PID I: mm or
`HSDZ.timeout or
`_ HSD2.CRC16 : bad or
`_..........................................
`
`Bad_lsoch0ut(SS_Bufi, split)
`
`
`PackeLreadytHSDZ)
`
`
`
`
`
`
`
`SS_Buff.isochO
`
`SS_Buff.isochO <= false;
`
`I
`
`
`
`I T?_Do_lsochOSS
`
`
`
`Figure 11-87. lsochronous OUT Start-split Transaction TT State Machine
`
`There is a condition in Figure 11—8? on transition selr‘se2 labeled “Bad_IsochOut". This condition is true
`when none of the conditions on transitions st] through s14 are true. The action labeled “Down_error”
`records an error to 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
`|PR201 8-001 10
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`
`
`ssue_packet(HSD1. SSPLIT);
`
`
`
`'
`
`|ssue_packet(HSD1. tokenlN};
`
`
`
`
`ReapondHC(Do_complete);
`
`HCuDomlsochISS
`
`
`
`Figure 11-88.
`
`lsochronous IN Start-split Transaction Host State Machine
`
`400
`
`ZTE/SAMSUNG 1008-0428
`ZTE/SAMSUNG 1008-0428
`IPR2018-00110
`|PR201 8-001 10
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`HSU2.P|D = DATAX and
`HSU2.CRC16 = 0k
`
`HC_Accept_data;
`
`RespondHC(Do_next_cn1d);
`
`not HC_ond.last
`
`RespondHC{Do next complete}
`
`
`
`_
`
`
`
`
`
`
`HSUZPID = MDATA and
`HSU2.CRC16 = ok
`
`
`
`
`
`
`
`(HSU2.P|D = MDATA or
`
`E HSU2.PID = DATAX) and
`
`
`ErrorCount < 3
`RespondHC(Do_oomp_immed_now};
`
`.
`ErrorCount >= 3
`I........................................................_i
`
`(:93
`
`HSU2 CRC16 — bad
`
`Iced
`
`
`
`
`' (HSU2.P|D I: NYET and
`HSU2.PID I: DATAx and
`
`; HSU2.PID I: MDATA and
`; HSU2.PID t: ERR) or
`' HSU2.timeout
`
`
`
`ct1
`
`IssueJackeflHSD‘l. CSPLIT};
`
`HC_Do_lsochECS
`
`Figure 11—89. Isochronous [N Complete-split Transaction Host State Machine
`
`In Figure 11—89, the transition “ceS” occurs when the high-speed handler responds with an MDATA to
`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 endpoint for this frame. If a DATAO response from the high-speed
`handler is not received before the last scheduled complete-split, the host controller records an error and
`proceeds to the next transaction for this endpoint (in the next frame}.
`
`401
`
`ZTE/SAMSUNG 1008-0429
`ZTE/SAMSUNG 1008-0429
`IPR2018-00110
`|PR201 8-001 10
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`
`
`'I'l'_§30_lsochiSS
`
`Figure 11-90. Isoehronous IN Start-split Transaction 'I‘T State Machine
`
`
`
` CS Buff match state = old
`
`
`
`S__Buff.match.down_result = r_moredata
`
`Issue
`
`acket(HSU1 MDATA)‘
`
`Gag
`
`
`CS_Buff.match.down__result = rfllastdata
`Issue_packet(HSU1, DATAX);
`-- Datao
`
`
`
`CS_Buff.match.state = no_match
`Issuerpacket{HSU1, NYED;
`
`
`CS_Buff.match.down_result 2 r_trans_err
`
`Issue_packet(HSU1, ERR};
`
`
`
`
`
`
`'l'l'_lsoch|CS
`
`]
`
`Figure 11-9]. Isochronous IN Complete-split Transaction Tl" State Machine
`
`402
`
`ZTE/SAMSUNG 1008-0430
`ZTE/SAMSUNG 1008-0430
`IPR2018-00110
`|PR201 8-001 10
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`11.213 lsochronous OUT Sequencing
`
`The host controller and TT must ensure that errors that can occur in split transactions of an isochrOnous full-
`speed transaction translate into a detectable error. For isochronous OUT split transactions, once the high-
`specd handler has received an “SSPLlT-begin” start-split transaction token packet, the hi gh-speed handler
`must track start-split transactions that are received for this endpoint. The high-speed handler must track that
`a start-split transaction is received each and every microframe until an “SSPLlT-end” split transaction token
`packet is received for this endpoint. If a microfiame passes without the high-speed handler receiving a
`start-split for this full-Speed endpoint, it must ensure that the full-speed handler forces a bitstuff error on the
`full—speed transaction. Any subsequent “SPLIT~middle” or “SPLIT-end” start-spl its 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 OUT transaction must not include the CRC16 field for the full-
`speed data packet. For a full-speed transaction, the host would compute the CRC16 of the 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 OUT full-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 CRC 16 field for each start-split data packet. The TT high-speed handler must check
`each high-speed CRC16 value on each start-split. The TT full-speed handler must locally generate the
`CRCl 6 value for the complete fiJll-speed data packet. Figure 11—92 shows an example of a full-speed
`isochronous OUT packet and the high-speed start-splits with their CRC16 fields.
`
`if there is a CRC check failure on the high-speed start-split, the high—speed handler must indicate to the full-
`speed handler that there was an error in the start-spl it for the full-speed transaction. If the transaction has
`been indicated as having a CRC failure {or if there is a missed start-split}, the full-speed handler uses the
`defined mechanism for forcing a downstream corrupted packet. If the first start-split has a CRC check
`failure, the fullvspeed transaction must not be started on the downstream bus.
`
`Additional high-speed start~split transactions for the same endpoint must be ignored after a CRC check fails,
`until the high-speed handler receives either an “SSPLIT—end” start-split transaction token packet for that
`endpoint or a start-split for a different endpoint.
`
`High
`Speed
`
`183 byte w
`HS CRCIG
`
`2 bytes w!
`HS CRC16
`
`Bus
`
`
`
`
`E
`
`Full
`
`Speed
`Bus
`
`Cf; ;—/'WW L9
`
`188 bytes
`
`2 bytes
`
`Figure “-92. Example of CRC16 lsochronous OUT Data Packet Handling
`
`403
`
`ZTE/SAMSUNG 1008-0431
`ZTE/SAMSUNG 1008-0431
`IPR2018-00110
`|PR2018-001 1O
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`1121.4 Isochronous IN Sequencing
`
`The complete-split transaction for an isochronous IN transaction must not include the CRC16 field for the
`full-speed data packet (e.g., only a high-speed CRC] 6 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 CRC 1 6 values for
`complete-split transactions. If the full-speed handler detects a failed CRC check at the end of the data
`packet (e.g., afier potentially several complete-split transactions on hi gh-speed), the handler must use an
`ER handshake response to 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-5p] it is reflected by the host controller as a CRC failure on the total full-speed transaction.
`Figure 1 1-93 shows an example of the relationships of the full-speed data packet and the high-speed
`complete—splits and their CRCJG fields.
`
`High
`Speed
`Bus
`
`
`
`ilZSus microframc
`
`
`
`
`
` 2+] 86 bytes wt
`HS CRC16
`1 byte w!
`HS CRC16
`
`1 byte wt
`HS CRC16
`
`Full
`
`Speed
`Bus
`
`
`
`3 bytes
`
`188 bytes
`
`Figure 11-93. Example of CRC16 lsoehronous 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:
`
`I
`
`a
`
`I
`
`If the TT is receiving a packet at EOF2 of the downstream facing bus, it must disable the downstream
`facing port that is currently transmitting.
`
`If the TT is transmitting a packet near EOFl of the dowustream facing bus, it must force an abnormal
`termination sequence as defined in Section 11.3.3 and stop transmitting.
`
`If the TT is going to transmit a non-periodic full-flow-speed transaction, it must determine that there is
`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 allowed size allowed for the transfer type in its
`determination. Periodic transactions do not need to be included in this test since the microframe
`
`pipeline is maintained separately.
`
`1122.1 Loss of TT Synchronization With HS SOFs
`
`It has a 1 ms frame timer when operating at full-
`The hub has a timer it uses for (m icro)fi'ame maintenance.
`flow-speed for enforcing EOF with downstream connected devices. It has a 125 1.15 microfiame timer when
`operating at high-speed for enforcing EOF with high-speed devices. It also uses the 125 ps microframe
`timer to create a 1 ms frame timer for enforcing EOF with dowustream full-r‘low-speed devices when
`operating at hi gh-speed. The hub (micro)frame timer must always stay synchronized with host generated
`SOFs to keep the bus operating correctly
`
`404
`
`ZTE/SAMSUNG 1008-0432
`ZTE/SAMSUNG 1008-0432
`IPR2018-00110
`|PR201 8-001 10
`
`

`

`Universal Serial Bus Specification Revision 2.0
`
`In normal hub repeater (full- or high-speed) operation (e.g., not involving a T1), the (micro)frame timer
`loses synchronization whenever it has missed SOFs for three consecutive microframes. While timer
`synchronization is lost, the hub does not establish upstream connectivity. Downstream connectivity is
`established nonnally, even when timer synchronization is lost. When the timer is synchronized, the hub
`allows upstream connectivity to be established when required. The hub is responsible for ensuring that
`there is no signaling being repeatedftransmitted upstream from a device atter the EOF2 point in any
`(micro)frame. The hub must not establish upstream connectivity if it has lost (micro)fi'ame timer
`synchronization since it no longer knows accurately where the EOF2 point is.
`
`1122.2 TT Frame and Microframe Timer Synchronization Requirements
`
`When the hub is operating at high-speed and has full-llow-speed devices connected on its downstream
`facing ports (e.g., a TT is active), the hub has additional responsibilities beyond enforcement of the (high-
`speed) EOF2 point on its 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 and full-llow-speed
`operation).
`
`A high-speed operating hub synchronizes its microframe timer to 125 tls SOFs. However, in order to
`generate full-speed downstream SOFs, it must also have a 1 ms frame timer.
`It generates this 1 ms frame
`timer by recognizing zeroth microframe SOFs, e.g., a high-speed SOF when the frame number value
`changes compared to SOF of the immediately previous microframe.
`
`In order to create the 1 ms frame timer, the hub must successfiilly receive a zeroth microframe SOF after its
`microframe timer 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"] I). When the hub has done this, it knows that the second SOF is a zeroth microframe SOF and thereby
`establishes a 1 ms frame timer starting time. Note that a hub can synchronize both timers with as few as
`two SOFs if the SOFs are for microframe 7 and microframe 0, i.e., if the second SOF is a zeroth
`microframe SOF.
`
`Once the hub has synchronized its 1 ms frame timer, it can keep that timer synchronized as long as it keeps
`its 125 ps microframe timer synchronized (since it knows that every 8 microframes from the zeroth
`microframe SOF is a 1 ms frame).
`In particular, the hub can keep its frame timer synchronized even ifit
`misses zeroth microframe SOFs (as long as the microframe timer stays synchronized).
`
`So in summary, the hub can synchronize its 125 its microfiame timer after receiving SOFs of two
`consecutive microframes. It synchronizes its 1 ms frame timer when it receives a zeroth microframe SOF
`(and the microframe timer is synchronized). The 125 its microframe timer loses synchronization after three
`SOFs for consecutive microframes have been missed. This also causes the 1 ms frame timer to lose
`
`synchronization at the same time.
`
`The 'IT must only generate full-speed SOFs downstream when its 1 ms frame timer is synchronized.
`
`Correct internal operation of the TT is dependent on both timers. The 'IT must accurately know when
`microframes occur to enforce its microframe pipeline abortifree rules.
`It knows this based on a
`synchronized microframe timer (for generally incrementing the microframe number) and a synchronized
`frame timer (to know when the zeroth microframe occurs).
`
`Since loss of microframe timer synchronization immediately causes loss of frame timer synchronization, the
`TT stops normal operation once the microframe tim er loses synchronization.
`In an error free environment,
`microframe timer synchronization can be restored afier receiving the two SOFs for the next two consecutive
`microfram es (e.g., synchronization is restored at least 250 ps after synchronization loss). As long as SOFs
`are not missed, fi'ame timer synchronization will be restored in less than 1 ms after microframe
`synchronization. Note that frame timer synchronization can be restored in a hi gh-speed operating case in
`much less time {0250-1250 ms) than the 2-3 ms required in full-speed operation. Once the frame timer is
`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
`|PR2018—001 10
`
`

`

`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).
`
`Must abort any buffered periodic startnsplit transactions in the periodic pipeline.
`
`Must ignore any high-speed periodic start-splits.
`
`Must stop issuing full-speed SOFs on downstream facing full-speed ports (and low-speed keep-alives
`on low-speed ports).
`
`Must not start issuing subsequent periodic full-llow-speed transactions on downstream facing full—flow-
`speed ports.
`
`Must respond to hi gh-speed start-split bulkz'control transactions.
`
`Buffered bulkfcontrol results must respond to high-speed complete-split transactions.
`
`8.
`
`Pending bulkicontrol transactions must not be issued to filll-i’low-speed downstream facing ports. The
`TT buffers used to hold bulkfcontrol transactions must be preserved until the microframe timer is re-
`synchronized. (Or until a Clear_TT_Buffer request is received for the transaction).
`
`Note that in any case a TT must not issue transactions of any speed on downstream facing ports when its
`upstream facing port is suspended.
`
`A TT only restores normal operation on downstream facing full-flow-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 microframe timer synchronization requirements on start-splits.
`
`For suspend sequencing of a hub, a hub will first lose microframefframe 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-flow-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 (afier high-speed transactions
`continue). Then in less than 1 ms (assuming no errors), the flame timer will be synchronized and the TT
`can start normal operation (including SOstkeep-alives on downstream facing full—flow-speed ports).
`
`Microtrames
`
`Yo
`
`