Xilinx Ten Giga Sub System IP生成詳細步驟

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。客戶端接口協(xié)議為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配置接口支持什么協(xié)議，在去除了這組接口后，IP核會將配置寄存器全部作為一組vector呈現(xiàn)在IP核端口上。

2. KCU105模塊兩個XG口的Transeiver綁定的x0y9和x0y10，所以選擇其中之一即可（根據(jù)板子的具體情況去選擇）。

3. Shared Logic在Core和example中的區(qū)別就是GTHCHANNLE3在Core外面還是Core里邊。如果不是做級聯(lián)只用1個Core，那么就放在core里。

IP核仿真

這個IP核的仿真網(wǎng)表文件（axi_10g_ethernet_0_sim_netlist.v）是壞的，不能用來進行仿真，仿真現(xiàn)象是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這個整數(shù)，那么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為低時數(shù)據(jù)必須保持到tready為高時發(fā)出，DA的第一個字節(jié)必須在數(shù)據(jù)通道0上，tlast表示傳輸?shù)淖詈笠黄?，有效字?jié)靠tkeep來標識。

1.2.TX In band FCS padding

Core可以配置成in-band FCSpassing，意思是在包的尾部跟CRC，32個比特。當Core沒有配置成這個模式時，如果client發(fā)了小于46Byte的payload，Core能自動padding，將包長度padding成符合以太網(wǎng)最小包長的包。如果配置了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加上。根據(jù)IEEE802.3規(guī)定，Strat必須在第0條數(shù)據(jù)通路上。分不連續(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ù)為高保持數(shù)據(jù)傳輸最大效率化。

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為高表明接收數(shù)據(jù)有效，keep指示8條通路中有效的通路，這里要注意的是data是從最低為開始assign數(shù)據(jù)的，所以，最后一片數(shù)據(jù)的keep[0]一定為高。tx_usr為高持續(xù)一個時鐘周期，表明收到的數(shù)據(jù)幀有效。

2.2. good frame or bad frame

傳輸?shù)淖詈笠黄瑪?shù)據(jù)至少得有一個Byte有效，keep不能為0；

傳輸?shù)膶嶋H幀幀長比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出現(xiàn)在stream接口上，同TX

2.6. 帶Vlan Tag

Vlan Tag使能，接收端會出現(xiàn)Vlan域，最大包長變成1522B

2.7. 超長幀傳輸

設置MTU（Max TransmitUnit）的值必須大于1518，jumbo 幀功能需要打開；

編輯：hfy