同學們在學網絡課程的時候都知道，除巨幀外，常見的以太網幀的長度範圍是64字節到1518字節，並且因為最初總線型半雙工的組網原因，人們制定了CSMA/CD協議，規定了以太網中最短幀為64字節。然而，互聯網的發展日新月異，今天的網絡早已不是當初的半雙工模式，CSMA/CD協議也早已不再使用，那麼現在網絡是否允許小於64字節的以太網幀或者報文傳輸呢？本文搭建硬件環境進行了驗證。
回顧
電磁波在雙絞線上傳輸的速度為0.7倍光速，在1km電纜的傳播時延約為5us。傳統的網絡信道比較差，需要有重傳機制保障可靠性。於是，在節點A向節點B發送數據進行通信的時候，要保證以太網的重傳，必須保證A收到碰撞信號的時候，數據包沒有傳完，要實現這一要求，A和B之間的距離很關鍵，也就是說信號在A和B之間傳輸的來回時間必須控制在一定範圍之內。IEEE定義了這個標準，一個碰撞域內，最遠的兩臺機器之間的round-trip time 要小於512bit 時間。(來回時間小於512位時，所謂位時就是傳輸一個比特需要的時間）。因此，傳統以太網有如下特點：
1、最大覆蓋距離（兩個站點最遠的距離）：2500m；
2、爭用期（即一個信號最遠來回的傳播時間）：51.2us；過來這個時間還未監聽到衝突，則說明無衝突；
3、最小幀長：64字節；因為傳統以太網速率是10Mbps，爭用期是51.2us；即在這個時間內，幀的數據不能發完，否則將不能監聽到衝突了（CSMA/CD協議是邊發邊聽、不發不聽；因為如果幀發完，則不在監聽，這個時候即使來了有衝突的信號，不在監聽，也不知道已經衝突了），這樣的話CSMA/CD協議可靠性也就大大折扣了；即：B/10M >= 51.2us;即512bit，64個字節；
4、幀間最小間隔：9.6us；相當於發送96bit；即在CSDM/CD協議下，一個站點在監測到信道空閒後，需要等待9.6us才能發送數據；（主要目的是留給剛剛接收數據的站點清理接收緩存，做好接下一陣的準備----------流量控制其實也是）
上述所說的以太網幀是針對以太網Ⅱ型幀進行的描述。幀格式如下：
那麼，現在互聯網中發送長度小於64字節的報文時如何傳送呢？比如ARP報文。有效長度如下：
ARP報文：4字節+4字節+6字節+4字節+6字節+4字節=28字節，遠不夠64字節。
事實上，在傳送ARP報文時，需要進行填充。
arp程序代碼裡，會增加一個填充程序，填充字段 18字節， 這樣以太網數據部分=ARP28字節+填充18字節=46字節。這樣，Dmac 6字節+S mac 6字節+ type 2字節+ARP 46字節+FCS4字節=64字節。
從而保證了互聯網上可以有效的傳輸小於64字節的報文。上述內容來源於網絡，如有侵權，請聯繫我刪除。網上有很多很多討論為什麼以太網幀最短幀為64字節的文章，大家可以自行百度。
我們關注的問題是，如果不填充，而是強行傳送小於64字節的報文呢？我們搭建了一個上板實驗進行了驗證。
實驗環境
開發板：Zedboard。
網絡：雙絞線接Zedboard四端口擴展板1口和3口並形成迴環。
EDA工具：Vivado2018.2、ModelSim10.5。
真實硬件驗證環境如下圖（請忽略圖中紙箱子等雜物）：
迴環結構
實驗目的：為了驗證，在實際鏈路中短於64字節的mac數據幀能否通過雙絞線在phy層之間傳輸，以及mac核對於長度不符合要求的數據幀的處理情況。
事實上，在上圖中，最短幀能否通過MAC1對應的RJ45網口發出來的前提是能否順利的通過PHY芯片，FPGA芯片、PHY芯片以及RJ45接口的關係圖如下：
PHY與FPGA之間的接口為RGMII接口。在FPGA內部構建的長度小於64字節的以太網幀，通過FPGA芯片與PHY芯片之間的RGMII接口首先發給PHY芯片，如果能夠順利的通過PHY芯片，才能從RJ45接口（MAC1）通過雙絞線發送給MAC2的RJ45接口，進而再經過MAC2對應的RJ45接口、PHY芯片，最後送回到FPGA芯片內部。如下圖所示，左側MAC1採用自己寫的超短幀產生和接收模塊，右側MAC2採用Opencores上的開源MAC核。
數據流
- Step1：通過data_gen模塊循環發送定長數據32’h12_34_56_78，通過8位數據端口傳給ephy_source模塊。
- Step2：ephy_source模塊根據接收的數據，以及長度進行mac幀封裝，並填寫固定目的mac地址：48’h01_01_01_01_01_01以及源mac地址:48’h08_08_08_08_08_08之後依次按單字節發送數據域內數據，並進行crc計算。
- Step3：通過rgmii接口模塊進行8位gmii接口數據到4位rgmii接口數據的轉換後接到phy層。
- Step4：經雙絞線傳輸後來到另一端的phy層，並依次經過phy層、rgmii轉換送入mac處理。
- Step5：mac接收的數據，在去掉前導碼、crc校驗後，以32位寬的形式將數據部分發送給用戶側，這裡直接將數據通過迴環發送到mac2的用戶發送數據端口，再次通過mac2的組幀、crc計算、8位gmii到4位rgmii的轉換之後通過phy2的tx發送回phy1的接收端口。
超短幀長度設置為40字節。從MAC1發出，經過PHY1芯片，經過雙絞線和MAC2的PHY2芯片，可以在MAC2的RGMII接口處收到。
仿真及上板結果如下：
可以看到在數據幀長度不符合標準的時候，是沒有辦法通過MAC2的mac核的，但是能夠到達接收端的rgmii_rx部分。
經檢查，發現開源IP核接收數據文件mac_rx_ctrl.v中對接收到的數據幀進行了長度判斷，把不滿足64字節的數據幀給過濾掉了。
通過寄存器可以配置LTU MTU大小，默認的LTU=64bytes MTU=1530bytes。
為了能接收到長度為40直接的數據幀，我們進行了如下修改：
LTU限制改為34， payload=34-4=30，由於接收控制的最小幀長信號是在寄存器組裡配置，所以對需要在reg_init中更改。
修改完之後，在MAC2處即能接收到40字節的以太網幀了。
數據流可以在MAC2處迴環了。但從MAC2的發送口收到的數據幀長度被自動填充到64字節了。如下圖中的打紅叉處。
經檢查，發現開源代碼的發送模塊部分會自動的填充補零。相關模塊代碼如下：
修改成支持傳輸40字節的超短幀，如下圖：
修改過之後，超短幀數據即可形成迴環。
上板抓取超短幀
MAC1超短幀發送端
ephy_send側的發送數據，對應抓取數據幀位置如下圖。
注意：這裡沒有抓發送側的rgmii_txd是因為他是oddr型的驅動，沒有辦法驅動寄存器，所以沒法打拍抓信號，更不能直接抓，所以抓了轉換前的8位數據。
MAC2超短幀接收端
值得注意的是，這裡的rgmii_rx是buf型的驅動，所以是可以抓的信號，並且還未進行4到8的轉換，所以這裡只有上升沿採到的高半字節偶數，而低半字節需要下降沿採樣。抓取位置對應於下圖中的箭頭處。
結論
通過以上實驗可知，超短幀是可以經過雙絞線傳輸的，PHY芯片不會對其進行過濾。但筆者沒有對商用的交換機進行測試，也許會出現文中提到的MAC那樣，硬件芯片會自動補零到64字節了。歡迎留言討論。
注：以上實驗由李家俊同學設計並上板調試完成。
全文完。
閱讀更多 網絡交換FPGA 的文章
