PCI-Express協(xié)議傳輸層讀書筆記_第1頁
PCI-Express協(xié)議傳輸層讀書筆記_第2頁
PCI-Express協(xié)議傳輸層讀書筆記_第3頁
PCI-Express協(xié)議傳輸層讀書筆記_第4頁
PCI-Express協(xié)議傳輸層讀書筆記_第5頁
已閱讀5頁,還剩18頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、PCIE TLP層學(xué)習(xí)摘要 北京炎強通信技術(shù)有限公司處理層協(xié)議(transaction Layer specification) 整理:捷馬聯(lián)系我:giema 2011-12-02目錄1TLP概況21.1四種空間:21.2 三種處理類型:21.3 兩種屬性:31.4 主要包格式:31.5 TLP通用包頭42TLP打包地址和路由導(dǎo)向方式72.1 Address尋址72.2 ID尋址方式82.3 處理層描述符(transaction Descriptor):103i/o,memory,configuration,message request、completetion詳解。113.1 Memory

2、 Request Package113.2 I/O Request 包123.3 Configuration Request包133.4 Message 包:133.5 Completion Rules(應(yīng)答機制)154請求和應(yīng)答處理機制164.1 Request Handling Rules174.2 Completion Handling185 .virtual channel(vc)Mechanism虛擬通道機制。195.1 TC/VC映射205.2 Flow Control216Data Integrity數(shù)據(jù)完整性22 1TLP概況 處理層(transaction Layer spe

3、cification)是請求和響應(yīng)信息形成的基礎(chǔ)。包括四種地址空間,三種處理類型,從下圖可以看出在transaction Layer 中形成的包的基本概括。1.1四種空間:1.2 三種處理類型: i/o口和memory的讀寫包(TLPS:transaction Layers packages), 配置寄存器的讀寫設(shè)置包 信息包,描述通信狀態(tài)。作為事件的信號告知用戶。對memory的讀寫包分為讀請求包和響應(yīng)包、寫請求包(不需要存儲器的響應(yīng)包)。而i/o類型的讀寫請求都需要返回I/O口的響應(yīng)包,configuration包對配置寄存器的讀寫請求也有響應(yīng)包。這些請求包還可以按屬性來分類。1.3 兩種

4、屬性: Non Posted:即請求需要返回completion的響應(yīng)包; Posted:即不需要completion返回響應(yīng)包。例如上面的存儲器寫入請求包和Message包都隸屬于posted包。1.4 主要包格式: 每種類型的包都有一定格式的包頭(Tlp Header),根據(jù)不同的包的特性,還包括有效數(shù)據(jù)負荷(Data Payload)和tlp開銷塊(Tlp Digest)。包頭中的數(shù)據(jù)用于對包的管理和控制。有效數(shù)據(jù)負荷域存放有效數(shù)據(jù)信息。具有數(shù)據(jù)的TLP傳遞是有一定規(guī)則的:以DW為長度單位,發(fā)送端數(shù)據(jù)承載量不得超過“Device Control Register”中的“Max_Paylo

5、ad_Size”數(shù)值,接收端中,所接收到的數(shù)據(jù)量也不能超過接收端“Device Control Register”中的“Max_Payload_Size”數(shù)值。TLp Digest域是32位的ECRC校驗。具體的包結(jié)構(gòu)圖如下:由此圖可看出數(shù)據(jù)從低字節(jié)的高位先發(fā)送,從左到右。以下詳細介紹TLPS的每個成分。1.5 TLP通用包頭R為保留信息位,應(yīng)設(shè)為0,路由器switch對此位不做修改,接收器應(yīng)該忽略此位。 Fmt1:0:Format of TLP (see Table 2-2) bits 6:5 of byte0 Type4:0:Type of TLP bits 4:0 of byte 0 T

6、C2:0: Traffic Class bits 6:4 of byte1,關(guān)于TC的作用將在下文說明。 Attr1:0: Attributes bits 5:4 of byte 2,詳細介紹見下文 TD:1b indicates presence of TLP digest in the form of a single DW at the end of the TLP標(biāo)志TLPDigest域的有無。 EP: indicates the TLP is poisoned bit 6 of byte 2有效數(shù)據(jù)中毒(出錯)機制。 Length9:0:Length of data payload

7、in DW.Fmt開銷位說明TLP Header的長度和TLP是否包含數(shù)據(jù),見下圖。 Fmt1:0=00b,代表3DW的包頭,沒有數(shù)據(jù)。 Fmt1:0=01b,代表4DW的包頭,沒有數(shù)據(jù)。 Fmt1:0=10b,代表3DW的包頭,有數(shù)據(jù)。 Fmt1:0=11b,代表4DW的包頭,有數(shù)據(jù)。Fmt 0 表示包頭格式是3長字還是4長字。Fmt1 表示包頭是否包含數(shù)據(jù)。Fmt和Type開銷組合定義了包(TLP)的類型如下。上圖定義了各種類型的包,圖中的r2:0用于定義Message包的隱含尋址方式,在下文中更為詳細。Length域定義了有效負荷的DW長度如下。在不包含data payload塊的包中L

8、ength的值應(yīng)被設(shè)置為保留值R,并被接收端忽略。余下的各個開銷位將在后文提到。2TLP打包地址和路由導(dǎo)向方式主要有三種TLP尋址方式: 地址路由(address)、 ID識別路由、 間接路由(implicit)。下面主要解釋address和ID尋址方式,間接尋址將在后面提及。2.1 Address尋址主要用于memory和i/o request請求包,u memory讀寫請求包支持64位地址和32位地址,u i/o讀寫請求只支持32位地址u 64位地址尋址的TLP Header有4DW(16字節(jié)),u 32位地址尋址的TLP Header有3DW長。上圖就是64位地址的4DW的包頭和32位地

9、址的3DW的包頭。對于memory讀寫request包,AT(address Type field)有如下的編碼。2.2 ID尋址方式主要用在configuration 請求包、部分message包、響應(yīng)包中。ID包括Bus number、Divce number、function number為TLP定位目標(biāo)接收器。ID尋址的TLP包頭長度也有4DW和3DW兩種,ID在TLP中位置見下圖。第七個Byte(Byte7)是第一個DW數(shù)據(jù)負荷和最后一個DW數(shù)據(jù)負荷使能位(Byte Enables),Byte Enables在于memory,i/o,configuration 請求包中有效,如圖。對

10、于last DW BE和1st DW BE中的每一個位,為0表示相應(yīng)的數(shù)據(jù)字節(jié)不被讀或?qū)懀瑸?表示相應(yīng)的數(shù)據(jù)字節(jié)有效。每個使能位相對應(yīng)的字節(jié)如下。2.3 處理層描述符(transaction Descriptor):對于兩種路由方式來說是通用的。用于請求器件和應(yīng)答器件間轉(zhuǎn)送處理層信息,包括三部分,Transaciton ID、Attributes、Traffic class(TC)。如下圖。其中Transaction ID包括: Requester ID、Tag,如圖。Tag7:0是由產(chǎn)生請求包的器件生成的,如果請求器件需要應(yīng)答,則每個Tag7:0和Function Number是獨一無二的。

11、Transaction ID是一個全局標(biāo)識符用于響應(yīng)包尋址請求器件。TC的規(guī)定如下,描述服務(wù)的層次和用于映射虛擬通道:處理層描述符在請求包中第二個DW:。中圖中看出,描述字符放在第二個DW的前三個字節(jié)中。3i/o,memory,configuration,message request、completetion詳解。memory、i/o、configuration request包頭除了基本的域之外還包括:Transaction ID即requester ID、Tag、Last DW BE、1st DW BE,放在第二個DW中。以下分別介紹這三種不同的請求包。3.1 Memory Reques

12、t Package采用直接地址尋址,有64bit地址和32bit地址兩種,其中讀請求包的Length域不應(yīng)大于Max_Read_Request_Size寄存器設(shè)置的值。請求器件不會示例一個所訪問的memory空間超過4KB的read request包。以下是兩種不同地址長度的memory request 包。 64位地址的包格式 32 位地址的包格式3.2 I/O Request 包I/O request 包只有32位地址尋址。有如下限制: TC2:0 must be 000b Attr1:0 must be 00b AT1:0 must be 00b Length9:0 must be 00

13、 0000 0001b Last DW BE3:0 must be 0000b格式如下:可見每次只傳送一個DW數(shù)據(jù)。3.3 Configuration Request包configuration request包采用ID尋址方式,包頭(Tlp Header長度是3DW)。有如下規(guī)定: TC2:0 must be 000b Attr1:0 must be 00b AT1:0 must be 00b 9:0 must be 00 0000 0001b Last DW BE3:0 must be 0000b包格式:3.4 Message 包:Message包分為:􀂉 INTx In

14、terrupt Signaling INTx中斷信息包􀂉 Power Management 電源管理機能。􀂉 Error Signaling錯誤信息包􀂉 Locked Transaction Support 鎖住交易的支持􀂉 Slot Power Limit Support插槽電源限制的支持􀂉 Vendor-Defined Messages制造商自行定義信息所有的Message包都用Msg編碼,即不包括數(shù)據(jù)負荷的Message包,除了Vendor_Defined Messages和Set_Slot_Pow

15、er_Limit Message包,Message包有以下限制: The Message Code field must be fully decoded (Message aliasing is not permitted). Except as noted, the Attr1:0 field is reserved.保留Attr域。 AT1:0 must be 00b. Except as noted, bytes 8 through 15 are reserved.保留包頭部分的bytes8到byte15. Message Requests are posted and do not

16、require Completion.Message包不需要返回響應(yīng)包。 Message Requests follow the same ordering rules as Memory Write Requests.尋址方式:隱含尋址,由Type域中的r2:0決定,即Type域的最后三位。具體尋址映射如下:r2:0是010時,尋址方式就是ID尋址。3.5 Completion Rules(應(yīng)答機制)completion包用ID尋址方式,尋址使用的ID就是request提供的requester ID。除了那些正常的域以外,還包括: Completer ID15:0 Identifies th

17、e Completer described in detail below Completion Status2:0 Indicates the status for a Completion BCM Byte Count Modified Byte Count11:0 The remaining byte count for Request Tag7:0 in combination with the Requester ID field, corresponds to the Transaction ID Lower Address6:0 lower byte address for st

18、arting byte of Completioncompl.Status位有如下含義:4請求和應(yīng)答處理機制處理機制就是對接收到的經(jīng)Data Link Layer進行數(shù)據(jù)完整性驗證的Tlp進行處理。無效的包將被拋棄,保留字(reserved)將被忽略。以下是處理流程:對所有的包分request handling和completion handling,按不同的規(guī)范處理。4.1 Request Handling Rules如果請求是一個不支持的請求包,并且需要響應(yīng),則Completion Status=UR,即不支持的請求。如果請求包是一個Message 包則按Message包處理規(guī)則處理,否則

19、對這個request進行處理。如果請求違反器件編程定義則給出ca響應(yīng),即響應(yīng)器件放棄該請求,否則做出正確應(yīng)答。4.2 Completion Handling如果接收到一個completion包的Transaction ID和requester的Transaction ID不一致則這個應(yīng)答包是非預(yù)期包。合法的應(yīng)答包將按Compl.Status域處理并提取有效數(shù)據(jù)負荷。5 .virtual channel(vc)Mechanism虛擬通道機制。虛擬信道(virtual channel)在總線中提供用TC域來區(qū)分的虛擬信息通路,即某一傳輸通路,有不同的流程控制機制(Flow Control)。當(dāng)某流

20、程控制出現(xiàn)擁塞時,其他通路依然暢通。VC有自己的獨立流控制,是實現(xiàn)Qos的秘訣。VC通道是解決擁塞的基礎(chǔ)。在Switch內(nèi)部,VC通道機制如下:5.1 TC/VC映射每個TLP包并不包含具體的VC信息,VC是由TC映射得到的。每個器件的TC/VC映射是不同的,TC0/VC0是固定的。具體TC、VC映射如下:一個或多個TC映射到一個VC,同一個TC不能映射到不同的VC上,連接雙方的映射機制一致。除了TC0外,其他的可以軟件設(shè)置。鏈路兩端的映射方案要一致,如圖是一種映射方案。具體的虛擬通道是由VC ID決定和識別的。5.2 Flow Control每個虛擬通道有獨立的流程控制的緩沖空間。在收發(fā)雙方,流程控制信息是用數(shù)據(jù)鏈路包(DLLP)打包發(fā)送的,其中的“VC ID“就是用來載送虛擬通道的識別??偟膩碚f,流程控制是由數(shù)據(jù)交易層(Transaction Layer)搭配了數(shù)據(jù)鏈路層(Data Link Layer)來處理的,只是,處理層通常是針對接收到的TLP打包,生成TC,再

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論