原文地址 https://www.cnblogs.com/coryxie/p/3956491.html
本文爲CoryXie原創譯文，轉載及有任何問題請聯繫cory.xie#gmail.com。
附錄A 符號編碼
表A-1顯示了對於數據字符字節到符號的編碼。 表 A-2顯示了對於特殊符號的編碼。 RD- 和 RD+是指以per-Lane爲基準的符號序列的Running Disparity。
附錄B 符號加擾（Symbol Scrambling）
B.1 數據加擾（Data Scrambling）
下面的子函數使用LFSR來對"inbyte" 中包含的8-bit值進行編碼和解碼。這僅僅時作爲例子展示。有許多方法來獲得恰當的輸出。這個例子展示瞭如何在一個操作中讓LFSR 步進（advance）8次，以及如何在一個操作中對數據XOR。有許多其他可能的實現，但是他們必須要能產生與這裏相同的輸出。下面的算法使用"C"編程語言傳統，其中"<<"以及">>"代表左移和右移操作，">"是大於比較操作，而"^"是異或操作，"&"是"與"操作。
復位（reset）之後的最先128個 LFSR步進的初始16-bit LFSR值如下：
復位（reset）之後，0值使用LFSR連續8-bit值編碼，產生下面的連續8-bit值：
附錄C 電源管理
本附錄提供了USB 3.0的系統級概述電源管理特性和能力。包括下面的主題：
- 如何計算端到端的低功耗狀態鏈路退出延時
- 討論一個設備發起的鏈路電源管理策略
- 一個延遲容忍消息（Latency Tolerance Messaging）的設備實現示例
- 超高速設備與高速設備接口在系統功耗方面的考慮
C.1超高速環境下電源管理概述
超高速體系架構被設計爲以平臺的功耗有效性作爲首要目標。增強功耗有效性的關鍵點包括：
- 去除對設備的連續輪詢方式
C.1.1鏈路電源管理
當鏈路雙方處於空閒狀態時，鏈路電源管理功能可以使鏈路進入低功耗狀態。一對鏈路雙方處於空閒狀態的時間越長，鏈路從U0 (鏈路處於活動(active)狀態) 逐步進入到 U1 (鏈路處於 待機(standby)狀態並可快速退出), 再進入到 U2 (鏈路處於待機(standby)狀態且能稍慢退出), 以及最後進入到U3 (鏈路處於掛起(suspend)狀態) 這一過程中節省的功耗越多。
在被軟件配置之後，U1 和 U2鏈路狀態會通過硬件自動控制而進入或者退出。硬件自動從U1轉換到U2鏈路狀態使得響應時間更快。從而，這也在進入節能狀態時轉換到更好的節能模式 ，並且在退出節能狀態時對操作狀態的影響更小。但是U3 鏈路狀態只會在軟件的控制下才能進入，典型的是在一段軟件不活動超時期之後才進入，並且要麼通過軟件（主機發起退出）或者硬件（遠程喚醒）退出。U3 鏈路狀態直接與設備的掛起狀態掛鉤（參考附錄C.1.4）。
C.1.1.1 鏈路狀態總結
表 C-1 提供了對超高速鏈路狀態和特性的總結。
表 C-1. 鏈路狀態和特性總結
鏈路狀態 | 描述 | 特性 | 狀態轉換髮起者 | 設備時鐘生成（On/Off） | 典型的退出延時範圍 |
U0 | 鏈路活動 | 鏈路處於可操作狀態 | N/A | On | N/A |
U1 | 鏈路空閒-快速退出 | Rx和Tx電路被設置爲靜止狀態（quiesced） | 硬件 | On或者Off | μs |
U2 | 鏈路空閒-稍慢退出 | 時鐘生成電路可能也會被附加地被設置爲靜止狀態（quiesced） | 硬件 | On或者Off | μs – ms |
U3 | 鏈路掛起 | 接口（例如物理層）電源可能會被切除 | 進入：只能是軟件 退出：可能是硬件或者軟件 | Off | ms |
注意:
- 在系統測試條件下，可能人爲通過軟件發起U1和U2狀態轉換。
- 從功耗有效性角度看，在U2狀態期間，設備有必要關閉它們的時鐘生成電路（例如，它們的PLL）。
C.1.1.2 U0 – 鏈路活動狀態
U0 是完全可操作的, 鏈路活動狀態。處於U0狀態時，任何類型的數據包都可以在鏈路上通信。
C.1.1.3 U1 – 鏈路空閒並且可快速退出
U1 是一種節能狀態，具有能夠從該狀態快速回到U0狀態的特性。注意到當從U1->U0轉換過程中的主要延時是由獲得鏈路夥伴雙方的符號鎖（symbol lock）所需要的時間引起。
C.1.1.3.1 進入U1狀態
鏈路夥伴的每一方都可以請求將鏈路轉換到U1鏈路狀態。 所有的下游端口（集線器或者根端口）通過一個不活動計時器機制來跟蹤鏈路的不活動。當一個端口的不活動計時器過期的時候，如果其被使能了，就會請求轉換到U1狀態。基於設備特定的策略，上游口也可能發起進入U1狀態。
當一個端口發起進入U1的請求時,它的鏈路對方可以接受也可以拒絕該請求。鏈路層級的U0->U1轉換過程包含一個端口發送一個LGO_U1鏈路命令，並且其鏈路對方用LAU（接受該請求）命令或者LXU（拒絕該請求）命令做出迴應。
拒絕進入U1狀態請求的最典型原因可能是因爲請求者的鏈路對方還有一些活動，短期內就需要進行包傳輸。如果沒有使能其接受U1轉換請求，下游口也可能拒絕轉換到U1。上游口拒絕轉換到U1的請求，只會簡單地復位並且重啓請求者一方的不活動計時器。
系統軟件配置並且接着使能每一個設備來發起進入U1的請求。設置硬件的自動鏈路狀態管理主要的編程參數包括：
U1DevExitLat – 被設備用於報告它們的最大的U1到U0的退出延時（參考第9章的細節）。
PORT_U1_TIMEOUT – 設置下游端口的U1不活動計時器初值。當設置在0x01-0xFE 之間的值時，也會使能下游端口發送轉換進入U1的請求給其鏈路對方（參考第10章的細節）。
U1_Enable – 使能上游端口發起轉換到U1狀態的請求（參考第9章的細節）。
U1_Enable 特性控制該特定的上游端口是否可能發起進入U1的請求。不論是否上游端口是否被使能了發起進入U1請求，它都要響應其鏈路對方發起的進入U1的請求，要麼接受要麼拒絕該轉換請求。下表展示了在下游端口超時和上游端口使用U1_Enable來配置平臺以達到鏈路電源管理的任意組合之間的關係。例如，如果U1_Enable被使能，並且PORT_U1_TIMEOUT 被設置爲 FFH，那麼只有上游端口可以發起轉換到U1的請求。
關於進入U1過程的特定細節，參看本規範的第7章。
C.1.1.3.2 退出U1狀態
有兩種方式可以退出U1狀態。鏈路可以返回到活動的U0狀態，或者進入更深的節能狀態（U2）。
從U1轉換到U0
鏈路夥伴任意一方都可以啓動從U1到U0的轉換。這個過渡通常都是在需要傳送一個數據包時被啓動，例如從主機端收到IN消息，或者一個來自設備的ERDY消息。轉換過程首先由一個低頻週期信號（LFPS）握手所啓動，接着是鏈路恢復和訓練序列。參考第6和第7章。
從U1轉換到U2
這將把鏈路轉換到一個更低的功耗狀態,並且是被第二個不活動定時器所觸發（U2不活動定時器）。當鏈路進入U1的時候就啓動了U2不活動定時器了。如果當鏈路處於U1期間，U2不活動定時器超時，那麼鏈路夥伴雙方都默默地從U1轉換到U2，沒有更多的總線活動。後面的章節會討論這一點的更多細節。
C.1.1.4 U2 – 鏈路空閒伴隨緩慢退出(Link Idle with Slow Exit)
U2DevExitLat – 用於設備報告他們的最大U2到U0退出時延的參數（參考第9章）。
PORT_U2_TIMEOUT – 設置一個下游口的U2不活動定時器的值。當被指定了在0x01-0xFE範圍內的值時，也就使能了下游端口啓動向其鏈路夥伴發起U2進入轉換請求（參考第10章）。
U2_Enable – 使能一個上游端口啓動請求轉換進入U2（參考第9章）。
U2_Enable特性控制一個上游口是否可以啓動從U0進入U2。不論上游口是否被使能了進入U2的啓動功能，它仍然要響應來自其鏈路夥伴的U2進入請求，要麼接受，要麼拒絕該轉換請求。
正如前面所提到的，U2典型地是從U1直接進入的。U2不活動定時器在進入U1時就啓動，並且當U2不活動定時器超時時，鏈路夥伴雙方都摸摸地從U1轉換到U2。
退出U2只能導致鏈路狀態轉換到U0。鏈路夥伴雙方都可以啓動退出U2，這是在當有包需要傳輸時啓動的。退出過程與U1àU0的類似，包含一個低頻週期信號（LFPS）握手，接着是鏈路恢復和訓練序列。
C.1.1.5 U3 – 鏈路掛起狀態（Link Suspend）
U3狀態是一個深節能狀態，除了需要用來完成下面功能的部分，設備電源的部分可能被移除：
⎯ 喚醒（Wakeup）信號的傳送 (用於具有遠程喚醒功能的設備)
在U3期間，VBUS仍然有效。設備的任何電源軌跡（power rail）關斷都是實現特定的，並且超出了本規範的範圍。
U3的進入只可能被主機啓動（詳情請參考第10章）。軟件典型地會實現一個不活動超時值，目的是在一段很長時間的不活動之後，將一個功能設置到掛起狀態。
當一個下游端口啓動U3進入請求時，其鏈路夥伴不允許拒絕。下游端口發送一個LGO_U3鏈路命令，而其鏈路夥伴用一個LAU鏈路命令響應（詳情請參考第7章）。
唯一合法的源自U3的狀態轉換是U3àU0，並且鏈路夥伴的雙方都可以啓動該轉換。
如果退出是由設備發起的，發起該喚醒的設備中的特定功能（function）應該接着在由LFPS觸發的到U0的轉換之後，發送一個Function Wake設備通知包給主機。
對於主機發起的U3退出，LFPS握手過程允許設備有最多20ms來完成，允許設備有足夠的時間來打開一個被關閉的電源軌跡（power rail），如果實現了點話（詳情請參考第6章）。
與U3相關的軟件接口包括一組端口控制和功能控制。端口控制，例如在一個集線器下游端口上啓動U3，在附錄C.1.2.3節描述。功能控制，例如使能一個功能（設備）的遠程喚醒，在附錄C.1.4.1描述。
在鏈路電源管理中，集線器了扮演幾個關鍵角色。他們完成下面的功能：
• 在上游端口和他們的下游端口之間，協調上游鏈路電源管理狀態
• 處理包的延後（packet deferral），在這裏，集線器告訴主機，包被髮送到了一個當前不處於U0的下游端口
當設備在一個集線器的下游端口上發起一個從低功耗狀態回到U0的轉換時，集線器立即開始將其上游端口轉換到U0，與其下游端口的轉換同時進行。
對於向下遊發送的包，集線器必須首先接收該包，判斷該包的目的端口是哪個，而且只發起對那個特定下游端口的到U0的轉換。
USB 3.0集線器使用一種單播（unicast）包傳輸模型，這就在每個部署有集線器的平臺上，增強了平臺的電源有效性。
包推後是在支持深度鏈路電源管理時使得可以有效利用總線的一種機制。包推後通過使集線器代表處於低功耗狀態的設備發出（對主機的）響應來達到該目標。這使得主機可以在設備被帶回活躍狀態的同時向前推進。
當設備收到具有deferred 字段被設置的IN或者OUT頭包時，它就準備該傳輸，發送一個ERDY給主機，並保持鏈路處於U0，直到傳輸發生。
這一特性用於請求鏈路狀態從任何當前U-狀態改變到下一個U-狀態。在正常操作環境中，這個特性純粹用於請求U0àU3以及U3àU0的轉換。但是，它也可以用於測試目的，用來請求其他的狀態轉換。
這個標誌用於標示一次從U3àU0的轉換完成。特別地，一次主機發起的喚醒會導致這個標誌在下游端口上被設置。
一旦C_PORT_LINK_STATE標誌被設置，一個端口狀態改變事件會被髮送給系統軟件，指示該下游端口和其鏈路夥伴已經完成轉換到U0狀態。
注意到在遠程喚醒事件時C_PORT_LINK_STATE沒有被設置。如前面所討論的，在Remote Wakeup時，相關的功能（function）發送一個Function Wake設備通知包給主機。
這個特性是用來使能和禁止下游端口上的U1進入的。它也用來指定U1不活動超時值。
這個特性是用來使能和禁止下游端口上的U2進入的。它也用來指定U2不活動超時值。
其他集線器端口控制也可以影響鏈路電源管理行爲，例如，PORT_RESET特性，但是不在這裏討論（詳情請參考第10章）。
C.1.3.1 有包等待標誌（Packets Pending Flag）
如果鏈路在有等時傳輸被調度時還處於低功耗狀態，從源端到目的端轉換到U0所需的時延可能會使得該傳輸延遲超出其所指定的等時傳輸服務時段。
爲了保證能夠滿足等時服務協定，定義了一個超高速機制(Ping)，用來將主機和等時端點之間的路徑帶回到U0，作爲對等時端點服務的一個常規步驟。
• 設備通過發送PING_RESPONSE 包來響應PING包。
設備電源管理重要是由軟件控制，包括各種硬件機制來支持它。設備電源管理包括一些功能層級的機制，以及一些設備和集線器層級的機制。
C.1.4.1 功能掛起（Function Suspend）
一個功能（function）可以獨立於其他功能，被使用FUNCTION_SUSPEND特性置於功能掛起狀態。FUNCTION_SUSPEND特性也被用來使能功能遠程喚醒（詳情請參考第9章）。
設備掛起是設備範圍內的狀態，它是隨着設備的上游端口進入或者退出U3狀態而進入或者退出該狀態。設備可能被轉換到設備掛起狀態，無論其內部功能的功能掛起狀態如何。
設備可能實現一個可開關的電源軌跡（power rail），並在掛起狀態將設備大部分的電源移除。有些設備狀態信息必須在掛起過程中要被持續保存（詳情請參見第9章）。
C.1.4.3 主機發起的掛起（Host Initiated Suspend）
• 發送一個SetPortFeature(PORT_LINK_STATE, U3) 請求給其鏈路夥伴即是該目標設備的端口。
• 下游端口通過發送一個LGO_U3 鏈路命令發起進入U3。
• 設備發送一個LAU 鏈路命令（接受吧，這是不可協商的）。
• 鏈路夥伴雙方都將它們的發射器轉換到電氣空閒狀態，即進入U3狀態（詳情請參見第7章）。
掛起USB鏈路層級（Suspending the USB Link Hierarchy）
C.1.4.4 主機發起的從掛起的喚醒（Host Initiated Wake from Suspend）
對於單個設備，一組設備，或者整個鏈路層級，主機發起的從掛起狀態的喚醒過程，也是使用相同的重複過程來完成的，一次一條鏈路。圖C-1 顯示了主機發起的喚醒序列。
C.1.4.5 設備發起的從掛起狀態的喚醒（Device Initiated Wake from Suspend）
設備發起的從掛起狀態的喚醒（U3àU0）依照下面概述的順序：
2. 該LFPS 信號向上傳導，直到它遇到根集線器，或者不處於U3狀態的集線器。這個集線器被稱爲控制集線器（Controlling Hub）。
3. 接着，該控制集線器（Controlling Hub）就在接收到該喚醒信號的下游端口上反射（reflects）LFPS 喚醒信號。
4. 在到遠程喚醒設備直接路徑上的每個集線器，都在其接收到遠程喚醒信號的下游端口上傳導該喚醒信號。隨着該喚醒信號向下傳導，每條鏈路都完成其LFPS 握手，並轉換到U0狀態（詳情請參考第6和第7章）。
延遲忍耐消息【Latency Tolerance Message (LTM)】特性允許平臺在功耗和性能之間做出動態權衡。這與設備協同而使之成爲可能，並且沒有引起附加的代價。
C.1.5.1 系統退出時延以及BELT 【System Exit Latency and BELT】
圖C-2顯示了設備在LTM上下文中可能經受的總共時延。該時延是參數t1, t2, t3, 和 t4的綜合：
t1: 當轉換是由設備發起時，將到主機的所有鏈路轉換到U0所需要的時間
t3: 主機處理該ERDY 並傳送一個對於該請求的響應所需的時間
U1SEL 以及 U2SEL被主機軟件計算並編程。對於t1計算的例子在C.2節提供。針對LTM的目的，t2 和 t4應該由主機軟件按照下面來計算：
⎯ 如果在設備和主機之間的直接路徑中沒有集線器，則t2 爲0。
⎯如果在設備和主機之間的直接路徑中由多於1個集線器，則t2 大致爲【2.1 μs + 250 ns * (number of hubs – 1)】。
• 對於t4, 集線器轉發一個包可能最多延遲大約250 ns。T4的值大致爲250 ns 乘以在設備和主機主機直接路徑上集線器的個數。
本節提供如何計算從設備到主機之間延展的端到端的退出時延（也即，從非U0狀態轉換到U0狀態所用的時間）的例子。對於設備發起的和主機發起的退出都給出了例子。
圖C-3描繪了一個超高速層級圖，並且列出了在後面將會描述的相關參數。
在這個例子中，一個外圍設備 (Dev1) 以及一個主機控制器根端口 (RP1)時鏈路夥伴，通過一個鏈路通信 (Link1)。
主機通過傳送LFPS發起轉換。在這一時間點，鏈路夥伴雙方的U1àU0轉換同步進行。
退出時延由兩個設備退出時延中最大者決定：Dev1:U1DEL和 RP1:U1DEL
在本例中，假定至少鏈路雙方之一（例如，RP1）被使能了U2。主機通過傳送LFPS發起轉換。在這一時間點，鏈路夥伴雙方的U1àU0轉換同步進行。
退出時延由兩個設備退出時延中最大者決定：Dev1:U2DEL和 RP1:U2DEL
• U1端到端退出時延是 Dev1:U1DEL 和 RP1:U1DEL中的大者。
• U2端到端退出時延是 Dev1:U2DEL 和 RP1:U2DEL中的大者。
在本例中,一個外圍設備(Dev2)通過鏈路(Link3)連接到一個集線器的下游端口(DP2)，而集線器則通過鏈路(Link2)連接到主機控制器的根端口(RP2)。
本例着重顯示在將Link2 和 Link3兩者都從U1轉換到U0時所引起的端到端時延。爲了這個示例的目的，假設所有的鏈路夥伴都被使能了U1，並且Link2 和 Link3兩者都處於U1狀態。
圖C-6顯示了按時間順序的一系列事件。在圖後是對此多跳鏈路狀態轉換的每個階段的更詳細的描述。
Max(RP2:U1DEL, Hub1:U1DEL) + HSD + HUB1:HHDL + Max(Hub1:U1DEL, Dev2_UP:U1DEL)
本例着重顯示在將Link2 和 Link3兩者都從U2轉換到U0時所引起的端到端時延。爲了這個示例的目的，假設所有的鏈路夥伴都被使能了U2，並且Link2 和 Link3兩者都處於U2狀態。
Max(RP2:U2DEL, Hub1:U2DEL) + HSD + Hub1:HHDL + Max(Hub1:U2DEL, Dev2_UP:U2DEL)
本例着重顯示在將Link2 和 Link3兩者都從U1轉換到U0時所引起的端到端時延。爲了這個示例的目的，假設所有的鏈路夥伴都被使能了U1，並且Link2 和 Link3兩者都處於U1狀態。
圖C-7顯示了按時間順序的一系列事件。在圖後是對此多跳鏈路狀態轉換的每個階段的更詳細的描述。
3.端到端時延最後的組件由Hub1_UP:U1DEL 和 RP2:U1DEL的大者決定，這代表Link2的退出時延(Link2_EL)。
端到端退出時延 = Max(Link3_EL, (Link2_EL + tHubPort2PortU1ExitLat))
本例着重顯示在將Link2 和 Link3兩者都從U2轉換到U0時所引起的端到端時延。爲了這個示例的目的，假設所有的鏈路夥伴都被使能了U2，並且Link2 和 Link3兩者都處於U2狀態。
3.端到端時延最後的組件由Hub1_UP:U2DEL 和 RP2:U2DEL的大者決定，這代表Link2的退出時延(Link2_EL)。
端到端退出時延= Max(Link3_EL, Link2_EL + tHubPort2PortU2EL)
有效利用鏈路電源管理所得到的功耗節省可以對系統功耗產生極大影響。例如，不用使用鏈路電源管理，筆記本電腦電池的平均壽命可能會被降低多大15%。設備和下游端口都可以發起進入U1 和 U2。
• 下游端口具有不活動定時器用來發起進入U1和U2。下游端口不活動超時使用系統軟件編程。
• 設備可能具有更多信息可用來更嚴苛地（aggressively）決定進入U1或者U2。
設備通過比等待不活動定時器更嚴苛地發起進入U1 或 U2可以節省更多功耗。例如，等時設備可以在每隔服務時段期間一旦完成等時傳輸之後就發起進入U1來充分增加在U1狀態的時間。
設備可以使用下面的信息來幫助決定什麼時候根據端點的空閒情形來發起U1或者U2：
⎯ 有包等待標誌（Packets Pending flag）, 用於bulk端點
⎯ 突發結束標誌（End of Burst flag）, 用於interrupt端點
⎯ 最後的包標誌（Last Packet flag）, 用於isochronous端點
• 協議層端點流控條件, 例如, 一個已經發送了NRDY的端點
如果能夠判定其鏈路在超過U2設備到主機退出時延（加上一段適當的防護帶）的一段時間週期內都不被需要，設別應該發起進入U2。設備在其他所有情形下都應該發起進入U1。
下面的子小節提供一些建議，以供判定何時端點空閒，或者根據端點類型，判定是否在一段已知的週期內需要使用鏈路。空閒情形也可以依據其他實現特定的方式來判定。
• 要麼已經發送了一個NRDY，或者在上一個從主機接收到的ACK 包中的有包等待標誌（Packets Pending flag）被設置爲0。
在設備發送一個於批量端點相關的ERDY後，鏈路應該被保持在U0，直到主機發送一個請求來響應該ERDY（或者直到tERDYTimeout發生，請參考8.13節）。
C.3.2.5 需要時間戳包（Timestamp Packets）的設備
C.4 延遲忍耐消息【Latency Tolerance Message (LTM)】實現示例
在接下來的子小節中，首先給出對BELT的描述以及其與整體系統退出時延的關係。接着，描述一個設備狀態機實現的示例。
本節描述一個典型的設備實現的示例。這裏假設設備實現支持U1和U2，同時也包括LTM。
在本例中，定義了兩個設備延遲忍耐狀態(LT-states) ：
• LT-idle 狀態: 設備處於空閒並且可以忍耐系統更大的時延（這是默認狀態）。
• LT-active 狀態: 設備已經決定需要執行與主機的數據傳輸並且想要喜用有一個更短的時延。
本實現示例所描述的設備被設計得可以容許在LT-active時U1SEL的最差情形值，以及在LT-idle時U2SEL的最差情形值。
• 設計需要在LT-active時最小LTM BELT 爲 125。
對於U2SEL小於其最差情形值的系統實現，設備報告一個大於1 ms的BELT值。
對於U1SEL小於其最差情形值的系統實現，設備報告一個大於125 μs的BELT值。
C.4.1.3.1 從 LT-idle 轉換到 LT-active
當設備判定有bulk 或者 interrupt數據傳輸需要發生時，設備從LT-idle轉換到LT-active。下面給出一些例子：
在有些情形下，從LT-idle轉換到LT-active並不一定合適，即使設備需要向主機做傳輸。例如：
• 主機發送一個GetStatus 請求給設備。由於是控制傳輸而不是批量或者中斷傳輸，設備保持在LT-idle狀態。
當設備從LT-idle轉換到LT-active，設備發送一個LTM TP，其中BELT至少爲tBELTmin。
C.4.1.3.2 從 LT-active 轉換到 LT-idle
當設備判定它處於空閒時，就從LT-active 轉換到LT-idle。本例所用到的空閒檢測基於U2的進入。當設備處於LT-active時，當其鏈路剛剛要進入U2時，設備就轉換到 LT-idle。
2. 設備發送一個LTM，其BELT值至少爲tBELTdefault.
處於in LT-active 的設備應該執行下面的動作來準備從U1轉換到U2：
3. 設備發送一個LTM，其BELT值至少爲tBELTdefault.
C.5 超高速（SuperSpeed）和高速（High Speed）電源管理比較
有些設備在高速（480 Mbps）下可能已經能工作得很好，但是如果使用超高速接口來實現則可以很大的降低系統功耗。除了設備電源管理之外，在選擇新設備設計的接口時，系統電源管理也應該考慮在內。
當設備正在活躍地傳輸數據時，系統組件也在傳輸這些數據。對於有些系統，系統組件的功耗遠大於一個USB設備對於系統功耗的貢獻。
圖C-9展示了一個例子設備，當被活躍地使用時，具有平均20 MBps的數據傳輸速率。圖中顯示了當設備在超高速和高速模式下工作時的系統功耗。
當沒有數據傳輸時，系統功耗是PIDLE。PIDLE 在超高速和高速時被估計爲大致相同。爲了說明的目的，鏈路功耗考慮在此被忽略。
附錄D 示例數據包
