由于以太網測試使用的開發板是淘寶購買的某款開發板，開發人員在電路設計時沒有考慮到將以太網芯片的接收時鐘、發送時鐘通過FPGA的專用時鐘管腳接入到到全局時鐘網絡；其實這對時序裕量有影響，按照官方的說法，經過全局時鐘網絡的信號其延時最小，驅動能力大；而且只有專用時鐘管腳引入的信號才能接入到PLL；

這個千兆網芯片使用的是RGMII接口，收發時鐘達到了125MHz，但是卻沒有經過專用時鐘管腳進入全局時鐘網絡，為了保證能在125MHz時序下，電路能夠穩定的跑通，我在時序裕量上做出了一些的努力。

參考該塊開發板給出的例程

開發板所帶例程的部分

這一部分是在生成IP數據包的首部，并且計算首部的校驗和；

但是綜合之后，可以從時序報告看到下圖

可以看到"ip_header"與"check_buffer"之間的有很多標紅警告，這造成時序分析報告里面e_rxc(接收時鐘)的max_frequency遠遠小于我們想要的125MHz；

為此，我修改了make狀態，在計算check_buffer的過程中加入了多個寄存器，起到緩沖作用；如下圖

原來10個16進制的1周期加法計算可能會造成大的延時，現在將10個16進制的加法計算拆分成3周期的加法計算，從時序報告看緩解了這部分的slack不足。

其實這里使用的是使用面積換取時間的方法，參考的例程里面由于需要在1個周期內計算過多的數據量造成太大的延時，所以這部分的時序不會太高，而我們在這個過程插入寄存器，分級計算，每個階段的時序提高了，整體部分的時序也達到了設計要求；

這種做法是很多人推崇的FPGA設計中的流水線設計一個實例，其原理就相當于將一堆復雜的操作分割成幾個簡單的操作，增加了電路面積但是由于每個部分的操作相對簡單，所以運行頻率可以得到相對的提升。

其實我這里發現有進一步的改進方案，可以在以太網芯片發送8個前導碼的同時，組成IP數據包頭并計算checksum，這樣的話checksum的計算是1周期還是3周期都不會影響發送流程的整體過程，修改的結果如下圖：

第二個改進的地方如下圖，例程中發送以太幀首部信息采用了下圖這種方法；

這種寫法看著很有C語言循環寫法的風格，感覺并不好，而且這個部分的時序報告也不太好；我起初想到的修改方法是類似如下的方法：

這個修改的方法的意圖是這樣的，在SEND_HEADER狀態下，txd每次都發送ip_header的高八位，同時ip_header向左移動8位，在發送完ip_header后，狀態機會跳出SEND_HEADER狀態。

但是，可能ip_header寬度過大，每次做移位操作造成較大延時，這么修改仍有部分時序標紅，于是我又做出了如下修改：

通過狀態機和計數器的配合，解決了發送端口應該在什么時候發送什么信息，避免做判斷和移位操作。

通過以上兩個措施，解決了一部分的時序裕量不足的問題，但一波未平一波又起；在這個過程中在很多地方用了cnt寄存器作為計數器，于是時序報告中又產生了cnt寄存器與txd等信號的時序裕量不足的報告。

分析這個現象產生的原因，我們不難發現，在狀態跳轉，比如從發送MAC地址的狀態跳轉到發送IP首部信息的狀態，就是使用計數器技術到某一數值作為跳轉條件；而每次在狀態機使用計數器和閾值作比較，由于cnt寄存器的寬度較大，在比較的過程中也有延時，在高速時鐘下這點延時也會造成一定的影響。

又又又為了解決這個問題，采用了如下圖的解決方案：

用wire類型的flagxx信號代替原來的"cnt >= xxx"，看似沒什么變化，但是原來的比較方案中，當電路運行到判斷條件時，會進行多bit的比較，在時鐘頻率較高時，也會對時序電路有所影響；而使用flag單bit信號做判斷之后，對時序電路的影響較小，時序電路的max_frequency可以有所提高。

由于接收時鐘沒有經專用時鐘管腳引進；全局時鐘信號驅動下，其他的物理輸入輸出信號延遲較小；而此處接收時鐘被當做一個普通IO信號引入，可能會造成其他的物理輸入輸出信號相對時鐘信號有較大延遲；又因為時鐘信號在時序電路中是驅動其他信號工作，所以這個時鐘信號（從普通IO口引入）的扇出一定很大，這也會造成一定的意料之外的延時。而這部分問題，我還沒有找到一個很好的解決方法，可能時鐘信號沒有從專用時鐘管腳引入就是一個錯誤，而我沒找到解決它的好辦法。

總結：

1. 將計算量較大，較多，較復雜的地方分級處理，中間插入寄存器，這樣可以提高時序裕量。
2. 使用狀態機代替循環和移位等操作。
3. 避免多比特信號的判斷比較，用單比特信號代替多比特信號的比較。
4. FPGA的隨路時鐘要通過專用時鐘管腳引入。