IP核描述
10 Giga Ethernet Sub System , 參考文檔PG157:
https://www.xilinx.com/support/documentation/ip_documentation/axi_10g_et...
IP核提供一個MAC模塊和一個PCS/PMA模塊,PCS/PMA模塊支持10GBASE-R/10GBASE-KR。客戶端接口協議為AXI4 Stream,有32bits和64bits兩種位寬,對于10GBASE-R,32bits位寬接口有著低延遲和低資源消耗的優(yōu)勢。AXI4-lite為可選接口,用于配置IP核內部寄存器。IP核支持DIC機制,支持Vlan和jumbo幀,支持客戶定制Preamble。支持BASE-R上的1588時鐘機制(onestep & two step)。
IP核總體框架如下圖所示:
IP核生成
按如下步驟生成IP核:
在生成IP核過程中有如下幾個注意點:
1. MAC option模塊中去除了AXI4-lite選項。此接口是連接至CPU接口的配置接口,這里去除是因為不知道CPU配置接口支持什么協議,在去除了這組接口后,IP核會將配置寄存器全部作為一組vector呈現在IP核端口上。
2. KCU105模塊兩個XG口的Transeiver綁定的x0y9和x0y10,所以選擇其中之一即可(根據板子的具體情況去選擇)。
3. Shared Logic在Core和example中的區(qū)別就是GTHCHANNLE3在Core外面還是Core里邊。如果不是做級聯只用1個Core,那么就放在core里。
IP核仿真
這個IP核的仿真網表文件(axi_10g_ethernet_0_sim_netlist.v)是壞的,不能用來進行仿真,仿真現象是Core接口上很多輸出是高阻。如果要仿真,則必須使用如下文件:
Sync目錄下的axi_10g_ethernet_0.v;
bd_0文件夾中的內容。
Example設計中提供了一套驗證環(huán)境,驗證頂層文件為: axi_10g_ethernet_0_demo_tb.v。
這里需要注意的是:
時間單位是1ps,精度也是1ps,serdes上是按66bits塊串行打碼流,那么比特周期就是6400/66,由于除不盡,就用了98這個整數,那么ref_clk就不能是6400了,所以這里的ref_clk是66*98.。如果不按這種處理,IP核在仿真時就不能link上,從RxGMII接口上看就是一直有l(wèi)ink fault,碼流是壞的。
仿真平臺框圖如下圖所示:
Bench支持兩種模式:
1. DEMO模式,這種模式下必須開啟address swap功能,激勵是從rx串行端口灌進去的,在PktGen模塊中通過Axi4-Stream環(huán)回。
2. BIST模式,激勵從Xgmii TX端口灌進去,在串行端口環(huán)回。
接口解析
以64bits位寬為例
1. client Tx Interface
1.1. TX Normal
信號在tready為高時才能傳輸,當tready為低時數據必須保持到tready為高時發(fā)出,DA的第一個字節(jié)必須在數據通道0上,tlast表示傳輸的最后一片,有效字節(jié)靠tkeep來標識。
1.2.TX In band FCS padding
Core可以配置成in-band FCSpassing,意思是在包的尾部跟CRC,32個比特。當Core沒有配置成這個模式時,如果client發(fā)了小于46Byte的payload,Core能自動padding,將包長度padding成符合以太網最小包長的包。如果配置了in-band FCS padding,則client需要保證最小包長,如果沒有提供符合要求長度的包,則core在FCS后padding,并表示這是個無效包。
1.3. TX Abording Transmissio
假如要終止一次傳輸該怎么做?
在client interface處終止一個包的傳輸操作稱為underrun,這種情況發(fā)生時由于在整包傳輸完成前發(fā)送端口處FIFO空了,有兩種情況:
a. 在txvalid有效的情況下將tx_tuser置起。斷包必須要有DA,SA,L/T域。
b. 包尾處tx_tlast沒有置起。
1.4. Back to Back
1.5. 自定義Preamble
就是在DA前將8字節(jié)Preamble加上。根據IEEE802.3規(guī)定,Strat必須在第0條數據通路上。分不連續(xù)傳輸和連續(xù)傳輸兩種,分別如下圖所示。
1.6. Vlan Tag Frame
提供Vlan Tag傳輸功能,客戶端需提供8100tag標志。傳輸時序如圖所示。
Vlan Tagged
Q in Q Vlan Tagged
1.7.Jumbo 幀傳輸
設計默認disable此功能,在此功能被關閉時若client傳輸超長幀,超長幀將被truncated,error code被插入顯示此幀錯誤。
1.8. IPG 更改
你可以通過配置選擇各種長度的IPG。通過ifg_delay_value來延遲XGMII column,Core產生反壓來延遲下一幀的傳送。
1.9. DIC機制
發(fā)送端支持DIC機制,有FCS和無FCS兩種情況下均支持。Tx_valid必須持續(xù)為高保持數據傳輸最大效率化。
1.10. Link Fault
Core收到local/remotefault或者link interrupt時,在寄存器FaultInhibit被關閉的情況下,Core不會發(fā)送任何幀,Core中的RS層會被使能,當RS層收到LocalFault或者link interrupt ordered set,Core將發(fā)送Remote Ordered Sets.當收到Remote Fault 序列時,Core將發(fā)送IDLE。
2. RX Client Interface
2.1.Normal Reception
rx_axis_tvalid為高表明接收數據有效,keep指示8條通路中有效的通路,這里要注意的是data是從最低為開始assign數據的,所以,最后一片數據的keep[0]一定為高。tx_usr為高持續(xù)一個時鐘周期,表明收到的數據幀有效。
2.2. good frame or bad frame
傳輸的最后一片數據至少得有一個Byte有效,keep不能為0;
傳輸的實際幀幀長比length域顯示的大,則在FCS –PASS功能沒有打開的情況下,多出來的會被當做padding而被移除;
Lenth域小于46,收到實際報文不滿64,如果lengthcheck沒有關閉的情況下,這個幀被標記為壞幀.
2.3. Frame reception with errors
接收錯誤報文(runt或者不正確crc)
錯誤幀產生因素:
1. FCS ERROR
2. 小于64Byte 的幀
3. 在jumbo幀功能沒有使能的情況下收到jumbo幀
4. 設置了MTU,收到的幀比設置的MTU大并且jumbo幀功能沒有使能
5. 長度/類型字段是長度,其中長度值小于46。在這種情況下,需要padding。如果沒有padding,這時這個幀就是錯誤幀。
6. 長度/類型字段是長度,其中長度值是46或更大,但是真實的接收幀的長度不匹配或超過長度/類型字段中的值
7. 在沒有禁用控制幀長度檢查功能時,收到的控制幀長度小于最小幀長度;
8. XGMII code中有ERROR
9. 有效pause幀,因為其已經被MAC邏輯使用;
2.4. Reception with FCS passing
如果FCS check failed ,則last為高時user信號為低;
2.5. Reception with Preamble
就是preamble出現在stream接口上,同TX
2.6. 帶Vlan Tag
Vlan Tag使能,接收端會出現Vlan域,最大包長變成1522B
2.7. 超長幀傳輸
設置MTU(Max TransmitUnit)的值必須大于1518,jumbo 幀功能需要打開;
編輯:hfy
-
寄存器
+關注
關注
31文章
5325瀏覽量
120054 -
cpu
+關注
關注
68文章
10829瀏覽量
211196 -
Xilinx
+關注
關注
71文章
2164瀏覽量
121044
發(fā)布評論請先 登錄
相關推薦
評論