2014年9月24日 星期三

USB Power Delivery Protocol Layer

USB Power delivery定義了Protocol layer,利用Protocol制定的message來溝通。
下面為他們所制定的message格式。


每段message都會有16bits的header用來表示message的類別,如果是data message
,後面會有0~7個Data Objects,而control message被包含在16bits的header裡。


這16bits header的格式如下
Number of Data Objects:它讓接受端知道header後面會有幾個data objects。
MessageID:讓接受端知道,目前是第幾段message,在一開機時,應該為0。
Port Role:表示目前發出message的是0(Sink) or 1(Source)。
Specification Revision:表示發送端支援00(PD reversion 1.0) or
                                         01(PD reversion 2.0)。
Message Type:message分為control與data兩種,而data meesage會在header後面
                           跟隨data object。而conrol message沒有data object。

Control Message:當Number of data objects為0,表示這段message為Control
                                    message。Control message用來做兩端的溝通。


Data message:用來傳送資料。


   有下面四種種類的data object
 Power Data Object (PDO) :
Source端用來送出自已的供電能力,另外當Source端送出PDO,但Sink端發出Reject message來表示Source的供電能力不符合Sink端的需求,Source端可以要求Sink送出
PDO來表示Sink端需要的電力為何。

 Request Data Object (RDO) :
當Source端發送PDO後,例如是12/1.5A,Sink端可以發送RDO來表示自已只需要0.5A。


 BIST Data Object (BDO) :
用來做physical layter test,算是debug mode。

 Vendor Defined Data Object (VDO) :
用來傳VDM,可以知道另一端的Product ID、Cable ID。在確認ID後,如果device支援alternate mode,在Type-C port可以用MUX開關,讓原的USB訊號,改傳PCIE、DisplayPort訊號。如果device為audio裝置,可以從USB訊號PIN傳類比的耳
機訊號。是一個讓USB port延伸更多功能的方式。

Reference
1. Universal Serial Bus  Power Delivery Specification_Revision  2 .0,   V0. 90

15 則留言:

Raymond 提到...

Dear Kevin,
1. cc pin normal的狀態是什麼? 在header封包交握前有沒有一個啟始的狀態或訊號, 來確認開始之後的溝通?
2. 當1個host電力不夠時, device能夠接受1個以上host供電, 能大概說明一下交握的過程嗎?
thanks

KevinZheng USB&DSP&Firmware 提到...

Hi Raymond
你是有要design TypeC PD的產品嗎?問的問題都很深入。
1.供電端的CC pin是pullup, 受電端的CC pin是pulldown。當兩端連結後,供電端偵測到CC pin的電壓被下拉,供電端才會輸出5V。

2.我沒有看到有定義兩個PORT的溝通,我想應該是靠MCU或CPU來獲取兩個PORT的訊息,再來做控制。

Raymond 提到...

HI Kevin,
1. 最近開始在study PD的東西, 公司是做電源設計的, 有聽聞詢問度很高想必未來幾年很火.
2. 您是否有資料可以參考, 關於溝通決定那種電壓profile, 軔體的flowchart?
thanks

KevinZheng USB&DSP&Firmware 提到...

Good morning Raymond.
實際上,在這個blog上的資料都是從USB協會網站上得到的。關於USB PD protocol ,你可以在下面的網站下載。http://www.usb.org/developers/powerdelivery/

leo 提到...

Dear Kevin,
請問 Start of Packet Sequence (SOP)
是做啥的?
我目前知道他是由4個k-ode組成,可是不知道他是在幹嘛用的

KevinZheng USB&DSP&Firmware 提到...

Hi, LEO. 您可以參考PD spec. 2.4 SOP* Communication with Cable Plugs。由於USB PD的功用很廣,所以產生了很多種不同功能的CABLE,其中有些Cable會需要在裡面放一顆PD的IC,用來與Device溝通,讓device知道它是接到什麼樣的cable。所以當Provide與consumer兩端在溝通時,再加上cable上的PD chip,是要怎麼區分命令是要下給誰呢,就要靠SOP編碼。請參考5.6.1.2 Start of Packet Sequences, SOP是指兩端device溝通,SOP'是指Device與Cable。編碼會被放在Figure 5-3 USB Power Delivery Packet Format的封包裡。

Paul 提到...

Dear Kevin:
您有提到PD溝通時需要在cable上加PD chip(SOP),
而我在一些IC廠資料中發現有些建議線路在Cable內放了一顆chip IC有些則放兩顆,
請問您知道原因嗎? 是否PD spec內有定義呢?
因為目前查不到相關資料, 再麻煩解惑:)

KevinZheng USB&DSP&Firmware 提到...

Hi Paul
如果Cable內有一顆PD IC,會用SOP'來溝通,如果有第二顆PD IC,就會用SOP''來
跟它溝通。在PD SPEC有定義"Cable Plug",它也算是一個device,Cable兩端的
cable plug可能是不一樣的。所以如果你要讓DFP知道Cable的兩端,各是那一種
cable plug,那就要在兩端各加一顆PD IC (E-marked IC)。

Paul 提到...

Dear Kevin,
請問PD溝通一定要使用有e-mark的cable嗎?
因為我在Type C規範Table 3-1中看到USB 2.0/3A Cable寫e-mark option且support BMC.
是否表示PD只調整VBUS電流不超過3A的情況下是可以使用passive cable呢?

KevinZheng USB&DSP&Firmware 提到...

Hi Paul
如你所說的,不超過3A,是可以使用passive cable。
超過3A,才一定要使用E-marked cable。

vincent 提到...

Dear Kevin,

目前已了解PD的建立是透過control message 跟 data message,
但不太了解VDM的溝通順序,請問是cable接上且source端供電(ex:20v,3A)後才開始做不同模式(ex: dicovery 或enter mode)的溝通嗎?

KevinZheng USB&DSP&Firmware 提到...

Hi Vincent

請參考type-C spec 1.1, 5.1.4.3,這有個docking連接的例子。
是先有VBUS 5V,再做PD電源溝通(20/3A),最後才進到Aletrate
mode(VDM溝通)。

Unknown 提到...

Dear Kevin

想請教你是否有讀過Communications Engine PD Compliance MOI v1.0?

我對於PHY LAYER的以下這項測試方法百思不解
BMC-PHY-RX-BUSIDL: BMC Bus Idle Detection Test
裡面分為2部份
1.
The Protocol Tester send BIST Test Data message, and then immediately continue sending data zeros for 195us,然後看UUT有沒有回應GOODCRC,有的話即為FAIL
2.
Send BIST Test Data message, then continue sending noise for 195+237+6.6us=438.6us, then open receiver. We are expecting the UUT to ignore the noise, and respond with a GoodCRC.

我疑問是BIST後跟著195us的0->UUT不可回覆GOODCRC
BIST後跟著一堆NOISE-> UUT卻要忽略掉NOISE然後回覆GOODCRC??

這樣到底是什麼邏輯? 不太懂這項測試的目的...
請指教....

KevinZheng USB&DSP&Firmware 提到...

Hi Kent

我沒讀過Communications Engine PD Compliance MOI v1.0,不過
我剛去下載了這份文件。

TDA.2.1.2.1: BMC-PHY-RX-BUSIDL BMC Bus Idle Detection Test
我的理解是,這個測試是用確認UUT能不能正確判斷CC bus是不是在idle
的狀態。UUT要在idle時,才能回傳goodCRC。

在第1個部份,由於Tester送出Bist test message後,又送出一串data
給UUT,所以CC bus不是在idle的狀態,UUT不應該回傳goodCRC。

在第2個部分,Tester送出Bist test message後,在CC bus上送出
438.6us的noise,但我們期望UUT能不被noise影響,UUT還是能判斷出CC
line是在idle的狀態,UUT能回傳GoodCRC給Tester。



Unknown 提到...

請問,還能夠詢問些問題嗎。