系統概述

<圖三>是將我們的設計實現在FPGA裡的系統概圖，系統匯流排採用Avalon System Bus。其上除了TOE本體外、還有系統主記憶體、Nios 處理器、系統DMA、還有LAN91C111這塊PHY/MAC晶片的控制器。TOE的本體將會在後面”主要功能與區塊”章節詳細描述。

在這個系統裡面，Nios處理器所扮演的角色是系統的主控制器，負責MAC←→TOE←→Main memory三者的資料搬移。接收時，在MAC接收到訊框後透過韌體將之送至TCP/IP Offload Engine的資料緩衝區，並在處理完畢送至主記憶體。傳送時則相反，將欲傳送的資料送至TOE內部資料緩衝區，並在附加完標頭後搬移到MAC並控制MAC將準備好的資料傳送出去。
　

會使用Nios處理器的動機，其實是因為我們的系統需要的周邊，PCI interface與SDRAM，在Altera的PCI development board上都有提供，雖然在這次比賽沒有辦法完成到最後的目標(利用SDRAM作為Data buffer以支援更多連線；利用PCI Interface與上層作業系統作溝通)，但為了將來本系統發展的擴充性，選擇了這塊發展版進而選擇了Altera的發展環境。

所需效能評估

1. 在Rx-Tx這個測試項目中，當封包大小為60 Byte時，TOE每秒鐘處理的封包數目為封包大小1514 Byte的12倍，會造成這樣的結果是因為TOE從接收到傳送會經過3次資料複製，第一次是由MAC buffer複製到TOE RxBuffer，第二次是由TOE RxBuffer複製到TOE TxBuffer，最後一次是由TOE TxBuffer 複製到MAC。

2. 在Rx這個測試項目中，當封包大小為60 Byte時，TOE每秒鐘處理的封包數目為封包大小1514 Byte的8.7倍，而在Rx-Tx這個測試項目中兩者相差為12倍，這是因為減少一次TOE RxBuffer複製到TOE TxBuffer的時間。

3. 在Rx-Tx這個測試項目中，當封包大小為60 Byte時，TOE每秒鐘處理的封包數目為12000，也就是所接收的封包數目大約為6000。而同樣的封包大小，在Rx這個測試項目中，TOE每秒鐘接收的封包數目為10664。會造成這個結果是因為cpu同時要處理Rx封包與Tx 封包的資料複製。

4. 在Rx-Tx這個測試項目中，當封包大小為60 Byte時，TOE每秒鐘處理的封包數目為12000，也就是所接收的封包數目大約為6000，如果扣除資料複製的時間，也就是假設封包為1514 Byte，則每秒鐘所能接收的資料量為：6000*1514/1000000=9.084MByte。

5. 在Rx這個測試項目中，當封包大小為60 Byte時，TOE每秒鐘處理的封包數目為10664，如果扣除資料複製的時間，也就是假設封包為1514 Byte，則每秒鐘所能接收的資料量為：10664X1514/1000000=16.145MByte。

6. 由以上的分析可知TOE的效能瓶頸在於資料的複製，如果減少資料的複製次數和增加資料複製的速度，本TOE是有能力處理100Mbps的網路速度。要處理1Gbps則需要提升處理器時脈到達：1Gbps/16.145MByte=7.8，40Mhz*7.8=312MHz。

TOE硬體系統設計概念

如<圖四>：首先，我們將堆疊分成兩大模組：接收(Rx module)和傳送(Tx module)模組，它們都是ASIC並掛在同一個系統匯流排上，所以它們可以被同一顆Embedded CPU所控制，並擁有一塊共享的記憶體。除了TCP在作full-duplex mode之下需要跟輸入模組做溝通(例如Sliding Window 大小受ACK reply的影響)外，兩大模組可以完全的獨立運作，這樣設計的好處是傳送跟接收兩個動作可以平行處理，只要在模組需要抓取資料或將完成的資料送到記憶體時利用適當韌體操作便可。
　

<圖五>表示模組與buffer的連接關係，因為在處理完一層的協定後要將處理過的資料丟到下一層去，為避免過多的memory to memory搬移，每一個通訊協定的處理模組應該要能讀寫一塊共享的記憶體(Shared memory)。如此，當一個協定的模組處理完時，只需要告知下一個模組一個位於共享記憶體的指標，那麼處理流程就可以以最小的記憶體搬移數量來得到資料，當然實際上無法找到大於3個Access port的記憶體可以使用，所以這些模組與buffer連接時，應該要經過仲裁器(arbiter)來判斷誰要先讀寫buffer，至於此仲裁機制對於不同的應用或是不同數量的連線數是否有所相關，是一個可以深入探討的問題。
　

本作品三大功能的實現(TCP、UDP、Ping)，是參考Behrouz A. Forouzan, Sophia Chung Fegan 所著TCP/IP Protocol Suite一書，並根據TCP/IP stack的軟體模組來做設計，利用硬體電路來完成每一個軟體模組的邏輯功能(使用multi-cycle based, Finite State Machine分階段性的去實現單一模組的功能)，再將邏輯電路連接到Shared memory以做溝通(<圖五>)，整個TCP/IP stack 可以被劃分成數個模組如<圖六>所示，以期望達到平行處理的可能性，如同前面所提，這樣的設計可以在處理傳送封包時，仍有能力接收封包。另外，當一個封包正在處理TCP協定時，可以接受另一個封包佔用IP處理模組來執行IP層的協定工作。而每個協定模組會跑如<圖七>的狀態機：
　

簡單的說，這些子模組是利用multi-cycle的邏輯電路來實作軟體模組的行為，負責接收的模組群依序分析存在資料緩衝區中訊框的標頭欄位，對此筆資料作處理，傳送的模組群則依據使用者(驅動程式，系統韌體)所下的命令替準備要傳送的資料區段加上網路標頭。

資料緩衝區設計

如<圖十>所示，資料緩衝區中，因為亂序完成的關係，所空出的空間並不連續，最好的管理機制，就是將這些空的區塊，用linked list連接起來，除了搬移整筆封包資料的機制(例如： 將訊框從MAC搬移到TOE，或是從TOE搬到主記憶體)需要支援linked list外，封包標頭的處理並不需要，因為一個Slot的大小被設定為遠遠大於所有協定標頭的長度總合，所以封包標頭處理時不會跨Slot。

<圖十>中我們可以看到為了支援這種機制需要兩塊空間，我們將這兩塊空間放置在CCI中，所以CCI的記憶體分配如<圖十一>所示。第一塊我們稱為Status bits，在這塊空間裡共有128bit的資料位元，每一個bit都代表資料緩衝區中一個slot的狀態，1為被佔用，0為空閒。第二塊我們稱為linking ptrs (linking pointers)，這個區塊的主要目的是紀錄被佔用的data slot互相連結的狀況。本區塊中共有128個單位，每個單位有32個Bits，一個單位對應到一個Slot。如圖所示，最高位元的2bit代表這個Slot的狀態，2’b00代表這個Slot是一筆未被分割的資料的一部分，2’b10代表這個slot是linked list 的一個node，2’b11代表這個slot是linked list的最後一個node；接下來有兩個7bit的欄位，分別代表這個slot中有效資料的開始和結束的偏移量；最後9bit為指向下一個data slot的指標。

要特別注意的是，這種Linked list機制是靠Nios處理器來管理的，在硬體處理標頭時不會動用到Linked list的機制，因為一個Slot的大小。當有資料要送進TOE時，Nios處理器會查閱TOE中的Status bits來尋找空閒的Slot，若有必要則啟動linked list機制將資料存進TOE中。在資料要移出TOE時則會確認是否有linked list的存在，將處理完畢的資料重新串連並送至目的地。

處理流程

圖片說明：<圖十二>以及後面的<圖十三>分別代表傳送以及接收的流程圖，在圖片中被圓形圈起來的部份(流程的開頭與最底部)的部份就是Nios CPU用軟體所負責處理的，方塊部分則是硬體的協定處理模組所負責。流程旁邊用虛線與粗體箭頭連接的方塊，則是硬體處理模組溝通佇列中單一條目的資料結構，我們可以看到TCP_Tx模組傳給IP_Tx模組時，需要如下圖所示的兩個資訊，資料指標以及封包種類。

 請回顧”功能說明”的資料緩衝區設計<圖十>及<圖十一>，接收端和傳送端的資料緩衝區在CCI(連線控制資訊, Control Connection Information)有兩塊欄位用來記錄資料緩衝區的狀況：Status bits 和Linking pointers，Status bit以0與1來紀錄Slot空閒與否，Linking pointers則是紀錄每個slot間互相連接的狀況。將資料搬進TOE時，CPU除了控制資料搬移的DMA engine外，還需要去更改這些記錄資料緩衝區狀況的資料結構，以便正確控制處理模組的操作。

<圖十二>為傳送封包的流程圖。
1. 當要傳送的封包在主記憶體裡，cpu會去檢查slot status table裡的status bits看看是否有足夠的空間 ，這時有三種情況發生：
a. 足夠的連續空間：
將要使用的空間相對應的status bit 設定為1。
將被要求的Slot相對應的Linking_ptrs 的status bit 設定為00。
b. 足夠的不連續空間:
將要使用的空間相對映的status bit 設定為1。
相對應的Linking_ptrs中的每個欄位都要設定。
c. 沒有足夠的空間：cpu不斷的去檢查，直到有足夠的空間為止

2. CPU呼叫DMA將資料從主記憶體搬到Tx_data_buffer。

3. 在Tx_data_req加入一個條目，告知tcp/ip offload engine 有資料要傳送。
4. 在tcp/ip offload engine裡面每個模組都有相對應的table，資料處理的程序為：上層模組將資料處理完，就將指向資料所在位址的指標加入下層模組的table。因此每個模組只要去查看其table，就知道要處理哪些資料。

5. tcp/ip offload engine 最後一層arp_tx處理完之後，發出中斷訊號，CPU呼叫DMA將資料從Tx_data_buffer搬到MAC buffer，完成封包傳送的動作。

接收封包

1. 當要傳送的封包在主記憶體裡，cpu會去檢查slot status table裡的status bits看看是否有足夠的空間 ，這時有三種情況發生：
a. 足夠的連續空間：將要使用的空間相對映的status bit 設定為1，相對應的Linking_ptrs 的status bit 設定為00
b. 足夠的不連續空間: 將要使用的空間相對映的status bit 設定為1，相對應的Linking_ptrs中的每個欄位都要設定
c. 沒有足夠的空間：cpu不斷的去檢查，直到有足夠的空間為止

2. CPU呼叫DMA將資料從MAC buffer搬到Rx_data_buffer

3. 在frame_table加入一個條目，告知TCP/IP offload engine 有接收到資料

4. 在TCP/IP offload engine裡面每個模組都有相對應的table，資料處理的程序為：上層模組將資料處理完，就將指向資料所在位址的指標加入下層模組的table。因此每個模組只要去查看其table，就知道要處理哪些資料。

5. TCP/IP offload engine 最後一層Tcp_rx和udp_rx處理完之後，發出中斷訊號，cpu呼叫dma將資料從Rx_data_buffer搬到主記憶體，完成封包接收的動作。

圖十三為整個系統的架構圖。其中包含了幾個主要元件：
1. Nios cpu,
2. DMA engine,
3. 由Altera sync SRAM 建構成的Main memory(將來考慮使用開發板上的DDR SDRAM配合SDRAM controller作為main memory)
4. Tri-state bridge for Lan91c111 PHY/MAC
5. Custom ASIC TCP/IP Offload Engine

以上元件的連接是由SOPC builder來建立系統，使彼此之間透過Avalon system bus 傳遞資料。我們自行設計的TOE(TCP/IP Offload Engine)，總共有5條對外通道，分別是：
1. 接收端CCI系統存取通道、
2. 傳送端CCI系統存取通道、
3. 接收端資料緩衝區系統存取通道、
4. 傳送端資料緩衝區系統存取通道、
5. Register File存取

這些通道是透過sopc builder內的interface to user logic來與avalon system bus 連接，為slave裝置，並透過適當的位址解碼機制，使Nios能透過這個介面來存取TOE的5個通道。

整個系統是由Nios cpu控制，cpu執行放置在main memory裡的程式，這個程式會初始化lan91c111和TOE，接著就等待裝置的interrupt，然後去執行相對應的ISR(Interrupt Service Routing)。本系統有以下幾種ISR:
·Lan91c111 PHY/MAC ISR:
當處理完的封包放在MAC buffer，會發出interrupt，cpu會做以下事情:
1. 檢查slot status table中的status bits來尋找rx_buffer中是否有足夠的空間來放置封包
2. 呼叫DMA將封包從MAC buffer搬到rx_buffer
3. 在Rx_frame中加入一個條目

·LTOE ISR:
cpu檢查TOE_status_reg看是TOE的哪一種interrupt
1. 接收封包的interrupt:cpu呼叫dma將處理完成的封包搬到main memory
2. 傳輸封包的interrupt: cpu呼叫dma將處理完成的封包搬到MAC buffer

·L DMA ISR:
cpu會去檢查slot status table中的status bits來尋找Tx_buffer中是 否有足夠的空間來放置封包
1. 呼叫DMA將封包從Rx_buffer搬到Tx_buffer
2. 在Tx_frame中加入一個條目

我們的作品有以下的特點：
1. 如果只單純用nios的cpu來處理TCP/IP網路協定，將無法達到100Mbps的速率，但是如果用nios cpu加上TOE這樣的的架構來處理TCP/IP網路協定，就能達到100Mbps的速率。
2. 我們的架構是將每個協定模組化，每個模組都根據各自的表格來做動作，因此可以很容易的加入新的協定，架構上具有很大的彈性。
3. 傳送和接收的模組是分開的，可以平行處理訊框。
4. 支援最多同時8條UDP連線。
5. 硬體ARP table。
6. 硬體UDP連線管理機制。
7. 處理模組在處理訊框時，只互相傳遞訊框所在地指標，減少記憶體的資料搬移。
8. 因為網路功能被硬體實作，在有網路需求的嵌入式系統應用時，可以大大的減低網路動作所佔的Host CPU資源。
9. 資料緩衝區的設計是分成一塊一塊的Slot來管理，簡化資料連結與管理的機制，並且可以簡單的藉由更改設計中的參數，來改變Slot大小的配置以符合不同需求。
10. 我們的系統的目標是用在網路儲存設備上，所以目前設計的參數設定是對儲存網路應用的最佳化。
11. 若只計算MAC接收完畢到存於目的主記憶體上的時間。本系統可以處理100Mbps網路速度的封包。