滄小海基於xilinx srio核的學習筆記之第五章 Rapidio協議詳述
5.1 概述
第一二章內容是概念性的,一是理解互連的含義,二是對rapidio有個大致的認識。第三、四章闡述xilinx的srio核相關內容,瞭解核結構、如何配置該核以及相應的測試程式的解析,本章就在前四章內容的基礎上深入的闡述rapidio的各種協議。描述方式採用是按功能進行分類,對每一類的協議進行詳細的描述並結合具體的時序。
5.2 事務型別介紹
在RapidIO體系結構中定義了6種基本的I/O操作,也就是6種不同的事務型別(FT),每個大的事務型別有包括若干個小的事務型別(TT),如下表所示給出了這6種基本的I/O操作及用來執行相應操作的事務和對操作的描述,其中“N”應該是節點的意思吧。
操作 | 使用的事務 | 描述 |
請求類事務 | NREAD、ATOMIC_inc、dec、set、clr | 從目標器件中讀資料 |
寫 | NWRITE | 往目標器件中寫資料 |
有響應寫 | NWRITE_R、RESPONSE | 往目標器件中寫資料,寫完後等待目標的響應 |
流寫 | SWRITE | 面向大資料量DMA傳輸優化寫資料 |
Atomic | ATOMIC、RESPONSE | 原子操作,讀-修改-寫,事務不能被打斷 |
維護 | MAINTENANCE | 以RapidIO專用暫存器為目標的事務 |
對上表的分析我們也可以看出,這六個事務(FT)其實囊括了四大類功能,即讀、寫、Atomic和維護。為什麼要將這四大類功能分為不同的事務而不直接分為四大類呢?這是因為事務的分類是按照協議的格式分的。如下圖,每一條是一個協議型別,每一種協議就是一種格式,而一種格式可適用於多項功能。這種分類方式更有利於我們的程式設計和可擴充套件性。例如我們是功能分類,那我們肯定是分為四類,每一類可能都需要對同一個協議進行描述,所以必然造成程式碼的重複性。如果按照協議分類,只要我們做好每種協議的介面即可
但我們在理解各種協議時卻可以按照功能分類來理解,如下表。
操作 | 使用的事務 |
寫 | NWRITE、NWRITE_R、SWRITE |
讀 | NREAD、RESPONSE |
Atomic | ATOMIC_inc(增加)、dec(減少)、set(置位)、clr(清零)、test(測試)、swap(交換) |
維護 | MAINTENANCE |
寫很好理解,就是A給B發資料,只不過rapidio比較厲害,支援不同的資料傳送模式,具體的在下文闡述。讀也是,A發出個讀請求,B將資料反饋給A。Atomic呢?我們也稱之為原子操作。原子本意是“不能被進一步分割的最小粒子”,而原子操作(atomic operation)意為“不可被中斷的一個或一系列操作”。這就是原子操作的特點,它類似與中斷,是不可被打斷的,如果把一個事務可看作是一個程式,它要麼完整的被執行,要麼完全不執行。這種特性就叫原子性。所以我們在用原子操作時候就要有這樣的功能。維護操作是用來訪問暫存器的,一般是用來訪問 RapidIO能力暫存器(CARs,Capability Registers)、命令和狀態奇存器( CSRs,Command and Status Register) ,本地定義的暫存器(Locally-Refined Registers)以及資料結構(Data Structures)。
下面呢,我們就對各個事務分別做詳細描述。
5.2.1 請求事務格式(FT=2)
請求類事務包括讀請求和原子操作。這一類事務的執行不包括有效資料的傳遞,也可以將這種事務型別理解成是一個指令,對於NREAD型別事務,通過該指令請求得到另一個器件上某記憶體區域中的內容,記憶體請求的資料長度在1到256位元組之間,返回的資料要進行對齊限制(通過Rdsize、Wdptr實現),資料超過8位元組就應以雙字的方式對齊,資料長度應該是8位元組的整數倍。對於原子操作,允許請求的資料長度為單位元組、雙位元組和四位元組,不允許8、3、5、7位元組。具體事務如下表。
序號 | TT | 型別 | 備註 |
1 | 0X4 | NREAD | 讀操作, |
2 | 0XC | ATOMIC_inc | 增加資料 |
3 | 0XD | ATOMIC_dec | 刪減資料 |
4 | 0XE | ATOMIC_set | 置位 |
5 | 0XF | ATOMIC_clr | 清零 |
欄位 | 含義 |
Ftype | 事務型別,就是確定這包資料大致是幹嘛的 |
Ttype | 事務型別(Transaction Type),與Ftype共同唯一的確定包的格式 |
Rdsize | 此欄位根據包的型別來決定讀事務資料的大小,這個欄位配合wdptr(word pointer)欄位一起使用,並不是簡單的表示資料長度 |
Src TID | 包的事務ID(Transaction ID)號。RapidIO器件在兩個端點器件間同時處理最多允許有256個事務。可以理解為兩個端點間傳輸包的編號吧 |
Extended Address | 擴充套件地址,這是一個可選欄位,指定50-bit實體地址的高16-bit或者66-bit實體地址的高32-bit,注意,是擴充套件高位。 |
Address | 29-bit的實體地址,由於RapidIO傳輸以一個雙字(double-word)為基本單元,大多數嵌入式系統是32位的,所以一個字(word)佔用4個位元組,一個雙字(double-word)佔用8個位元組,所以29-bit的實體地址指向的一個儲存單元實際上是佔用8個位元組的,這樣用29-bit的實體地址實際可以訪問4G(2^32)的記憶體空間 |
Wdptr | 字指標(Word pointer),配合Wrsize/Rdsize欄位來指明資料的大小以及對齊方式,詳細的說明請檢視RapidIO_Rev_2.2_Specification第33頁 |
Xamsbs | 擴充套件地址最高位(Extended address most significant bits),把實體地址進一步擴充套件2位,由於29-bit的地址已經可以訪問4G記憶體空間,在最高位擴充套件2位以後就可以訪問16G的記憶體空間 |
本節最重要的內容是如何確定請求地址及請求的資料長度。
正如《RapidIO嵌入式互連》所說,Wrsize/Rdsize、Extended Address、Wdptr、Address並不是如字面意思那樣簡單。當初rapidio的設計為了節省位寬,將通常需要48bit表示匯流排事務的典型設計(32bit地址,8bit位元組通道,8bit事務大小)用36位元實現。首先,請求地址為什麼是29bit呢,因為rapidio是雙字對齊,注意是雙字不是雙位元組,也就是64bit對齊。Address是一個位寬為29bit的實體地址,由於29bit指定的是雙字(64bit),所以支援定址範圍達4G,Xamsbs是兩bit資料,作為定址空間的最高位,將定址範圍擴大到了16G。但有個問題,由於定址最小單元是64bit資料,那麼,如果一個地址存放8bit,我們只需要取出20個位元組,該如何操作呢?而且若地址不能對齊,即便資料是8的整數倍,也會出現如下圖的情形。
一個傳送端期望通過互聯架構將其資料包傳送到另外接收端中,因為流的開始和結束並不對齊到一個雙字邊界,傳送端會將這個流拆分成3次交易如圖所示,第一次交易送出頭三個位元組(在位元組lane5、6、7),第二次交易送出所有餘下的資料完整的64bit資料,第三次交易送出最後5個位元組在位元組lanes0、1、2、3、4。
這就需要其他資料來進行輔助定位,而且說到現在,我們還沒說如何確定請求資料長度呢。所以,下面就靠Wrsize/Rdsize、Wdptr了。它們所表示的含義已經在上文表格中描述了,下面就說一下怎麼用。
首先要思考一個問題,我們要用“Wrsize/Rdsize、Wdptr”做什麼?兩件事,1是確定資料長度,2是非邊界對齊時讀的或寫的位置,也就是如圖1-2的第一次和第三次讀資料。Rapidio的巧妙設計實現了這兩個功能的同時實現。
這個就是rapidio做了規定,規定“Wrsize/Rdsize、Wdptr”以什麼樣的組合表示什麼樣的情況,如下表所示。所以在設計時就需要以查詢表的方式來實現。
5.2.2 寫事務包格式(FT=5)
寫型別格式包包括NWRITE(節點寫)、NWRITE_R(帶響應的節點寫)、ATOMIC_swap、compare-and-swap、test-and-swap這幾種型別。這一類事務包括有效資料,對於有效資料等於或小於一個雙字的資料組合方式由Wrsize、Wdptr生成的查詢表來確定,對於整數倍的雙字資料,wrsize欄位指定多個雙字事務的資料有效負載的最大大小。對於NWRITE,是不需要響應的寫事務,故srcID是任意值。NWRITE_R是需要接收方響應的兩種操作,這兩種操作對於請求放指示TT的不同,請求方可以用這兩種事務往目標方指定的地址寫入資料。對於原子操作的test-and-swap模式和swap,只允許1個雙字的資料載荷。而compare-and-swap模式允許兩個雙字的有效資料載荷。
它們的協議如下所示。
各個欄位的含義與5.2.1一致,只不過多了資料段。
5.2.3 流寫事務包格式(FT=6)
事務型別6只有一種事務,就是流寫(swrite streaming write)。這可以看做NWRITE的一種特殊形式,它沒有表示資料長度的欄位(即Wrsize、Wdptr),所以只能通過包內的資料長度來判斷,資料欄位的長度可以在8到256之間,且必須雙字對齊,長度是雙字的整數倍。這種模式一般用來遷移DMA類操作的大量資料,傳輸效率很高。
3.2.4 維護事務格式(FT=8)
型別維護資料包格式用於訪問RapidIO功能和狀態暫存器(CAR和CSR)以及資料結構。與其它事務不同,型別8資料包格式既用作維護操作的請求格式又用作響應格式。型別8資料包不包含地址,僅包含寫請求和讀響應的資料有效載荷。所有配置暫存器讀取訪問均以字(4位元組)和可選的雙字(8位元組)或指定的多個雙字數量(不超過64個位元組)進行wrsize欄位指定。
維護埠寫操作是寫操作,不能保證傳遞,也沒有相關的響應。此維護操作對於從不包含端點的裝置(例如交換機)傳送訊息(例如錯誤指示符或狀態資訊)很有用。資料有效載荷通常放置在目標端點的佇列中,並且通常會向本地處理器生成中斷。對已滿的佇列的埠寫請求或忙於處理另一個請求可能會被丟棄
表4-7提供了特定於型別8資料包的欄位的定義和編碼。表4-2中描述了非特定於型別8資料包的欄位。
第8類事務維護事務用於訪問RapidIO能力暫存器(CARs,Capability Registers)、命令和狀態奇存器(CSRs,Command and Status Register),本地定義的暫存器(Locally-Refined Registers)以及資料結構(Data Structures)。與其他的請求格式不同,維護操作的請求和響應包格式都是第8類包格式。第8類包不含地址欄位,只含寫請求和讀響應的資料載荷。
第8類事務維護事務用於訪問RapidIO能力暫存器(CARs,Capability Registers)、命令和狀態奇存器(CSRs,Command and Status Register),本地定義的暫存器(Locally-Refined Registers)以及資料結構(Data Structures)。與其他的請求格式不同,維護操作的請求和響應包格式都是第8類包格式。第8類包不含地址欄位,只含寫請求和讀響應的資料載荷。
3.2.5 門鈴事務格式(FT=10)
型別10資料包格式是(DOORBELL)門鈴事務格式,這型別事務沒有載荷有效資料,結構非常簡單,用於簡單的訊息傳遞和中斷。
3.2.6 訊息事務格式(FT=11)
對訊息事務的理解,首先要明白其應用場景。
如下圖所示是訊息事務格式,這與之前的有較大的不同,下面首先對比較陌生的幾個欄位進行闡述。
欄位 | 值 | 含義 | |
Ftype | 4‘b1011 | Ftype=11表示這是一個MESSAGE事務 | |
Msglen | 包的個數 | 訊息長度(Message Length):指的是組成該訊息的包的總數。值為0時表明該包是一個單包訊息,值為15(4’b1111)時,表明這是一個由16個包組成的訊息。 | |
Ssize | 4’b0000~4’b1000 | 保留(Reserved) | 標準訊息包資料大小(Stardard message packet data size)。該欄位告訴訊息接收者一個單獨訊息操作除訊息中最後一個包外組成訊息的所有包的資料載荷大小。這樣可以防止傳送者過度延長最後一個包的資料欄位並允許接收者正確的將包放入本地儲存器 |
4’b1001 | 8位元組(byte) | ||
4’b1010 | 16位元組(byte) | ||
4’b1011 | 32位元組(byte) | ||
4’b1100 | 64位元組(byte) | ||
4’b1101 | 128位元組(byte) | ||
4’b1110 | 256位元組(byte) | ||
4’b1111 | 保留(Reserved) | ||
Letter | 2bit信件。該欄位用來識別信箱(MailBox)中的一個槽(SLOT)。該欄位允許傳送方同時傳送最多4個訊息到接收方的同一個信箱中 | ||
Mbox | 信箱的哪個格子 | 2bit信箱(MailBox)。該欄位用來指定目標處理部件中的接收信箱 | |
Msgseg | 哪個信箱 | 4bit訊息段(Message Segment)。該欄位用來表明該包是組成訊息的包中的第幾個包。值為0表明該包是訊息的第一個包。值為15(4’b1111)表明該包是訊息的第16個包。 | |
Xmbox | 對於單包資料訊息事務,該欄位用來指明目標信箱的高四位。該欄位與Msgseg佔用相同的欄位。 Xmbox欄位和mbox欄位組合使用的定義如下: xmbox || mbox : mailbox number 0000 00:mailbox0 0000 01:mailbox1 0000 10:mailbox2 0000 11:mailbox3 0001 00:mailbox4 1111 11:mailbox63 |
3.2.7 響應型別包格式(FT=13)
當一個RapidIO端點完成由另一個RapidIO端點發起的請求時,該端點就會傳送一個響應事務。響應事務包總是以與請求事務包相同的方式被髮送和路由。從廣義上說,第12、13、14 和15類格式(Ftype=12表示的就是第12類格式)是響應類事務的格式。通常,第12和14類是保留的,第15類由具體應用定義,第13類才是主要的響應類事務。第13類包格式返回狀態,資料(如果需要)和請求者的事務ID。帶有“ERROR”狀態或沒有預期的資料裁荷的響應的RESPONSE包沒有資料載荷。響應包使用第13類格式來響應除維護和無響應寫之外的所有請求包。維護響應包響應維護請求。一個典型的響應包的格式如下圖所示
邏輯層各個欄位的含義如下表所示
欄位 | 值 | 含義 |
Ftype | 4’b1101 | 格式型別(Format Type),與Ttype唯一的確定包的格式,對於一個有效的響應包來說,此欄位的值固定為4’b1101, |
Ttype | 4’b0000 | 不攜帶資料的響應 |
4’b0001~4’b0111 | 保留 | |
4’b1000 | 攜帶資料的響應 | |
4’b1001~4’b1111 | 保留 | |
Status | 4’b0000 | DONE狀態:表示請求事務得到了正確的響應 |
4’b0001~4’b0110 | 保留 | |
4’b0111 | ERROR狀態:表示請求事務出現了不可恢復的錯誤 未能得到正確的響應 | |
4’b1000~4’b1011 | 保留 | |
4’b1100~4’b1111 | 使用者自定義響應 | |
Target TID | —— | 目標事務ID(Transaction ID)號 |
Data Payload | —— | 響應包攜帶的資料,如果是不攜帶資料的響應,那麼這個欄位就不存在 |
相關文章
- Java學習筆記之基於TCP協議的socketJava筆記TCP協議
- Raft協議學習筆記Raft協議筆記
- Raft 協議學習筆記Raft協議筆記
- IP協議學習筆記協議筆記
- 學習筆記 - DNS協議筆記DNS協議
- OAuth 2.0 協議學習筆記OAuth協議筆記
- HTTP 協議 學習筆記一HTTP協議筆記
- TCP/IP學習筆記之協議和郵件TCP筆記協議
- Internet安全協議 學習筆記協議筆記
- CAN匯流排協議 學習筆記協議筆記
- 計算機網路學習筆記(10) TCP/IP協議棧 之TELNET協議計算機網路筆記TCP協議
- http協議學習系列(協議詳解篇)HTTP協議
- 《HTTPS權威指南》-協議學習筆記HTTP協議筆記
- swift學習筆記4——擴充套件、協議Swift筆記套件協議
- Object C學習筆記15-協議(protocol)Object筆記協議Protocol
- ble學習筆記九----------ble協議棧之OSAL的執行機理筆記協議
- 華為帳號服務學習筆記(二):OAuth2.0協議詳解筆記OAuth協議
- 《圖解HTTP》學習筆記(二):簡單的HTTP協議圖解HTTP筆記協議
- 基於docker 初學 MongoDb 學習筆記DockerMongoDB筆記
- 華為帳號服務學習筆記(五):OpenID Connect協議詳解筆記協議
- ZooKeeper一致性協議ZAB學習筆記協議筆記
- 隨記(四):簡述HSTS協議協議
- Xilinx約束學習筆記(二)—— 定義時鐘筆記
- PBR(基於物理的渲染)學習筆記2筆記
- ELK學習筆記之基於kakfa (confluent)搭建ELK筆記
- 基於深度學習的醫學影像配準學習筆記2深度學習筆記
- 網路協議之:基於UDP的高速資料傳輸協議UDT協議UDP
- gevent 學習筆記 —— 協程筆記
- deep learning深度學習之學習筆記基於吳恩達coursera課程深度學習筆記吳恩達
- SpringMVC 學習筆記(五) 基於RESTful的CRUDSpringMVC筆記REST
- hive學習筆記之九:基礎UDFHive筆記
- hive學習筆記之六:HiveQL基礎Hive筆記
- CISSP學習筆記之安全管理基礎筆記
- Python學習之迭代器協議Python協議
- 網路協議之:socket協議詳解之Datagram Socket協議
- 學習筆記-Verilog實現IIC匯流排協議筆記協議
- HTTP協議簡述HTTP協議
- 簡述HTTP協議HTTP協議