續前一篇博文，經過多次對PANGO工具的參數進行修改的嘗試，在資源占用率為（LUT-70.02%，Register-36.34%，DRM18K-15.63%，I/O-15.42%）的情況下，整個設計采用125MHz頻率的結果無法達到。而相同的工程下，系統采用100MHz、局部125MHz的結果是可以的。好了，這對于我的以太網測試工程是足夠的，時鐘系統就按照這個來。這里還是需要強調的是，PGL22G芯片肯定是可以在125MHz或更高的時鐘頻率下工作的，我這里是采用了之前的一些現有設計，沒有進行優化的結果。

在開始測試前，還有一個重要的問題就是RGMII接口時序的約束（特別是接收）。提供的以太網測試例程里面的RGMII是沒有約束的（但是測試好像沒有問題）。測試第一步在提供的例程上修改，對接收數據的以太網幀的CRC進行監控，然后在外部使用發包設備進行大流量數據包的發送，測試結果發現接收數據包果然是有CRC錯誤計數。

根據PHY芯片datasheet說明及開發板的硬件配置，RGMII源同步接收信號在輸入到FPGA時，數據相對于時鐘的setup和hold時間均為1.0ns，因此RGMII輸入約束如下：

編譯結果發現setup時序裕量充足，而hold時序特別差。通過Timing Analyzer查看的結果如下：

查看詳細的時序路徑報告可以發現，輸入RGMII Clock的路徑延遲比數據大2.106ns，這是導致時序不滿足的主要原因。這種情況下需要手動對輸入數據添加延遲。延遲的實現使用GTP_IODELAY原語來實現，每個延遲單位的值是25ps，按照添加約1ns延遲計算（這樣hold時序余量就有0.2ns左右），GTP_IODELAY的延遲單位DELAY_STEP取值40，重新編譯一下。

但是再次編譯的結果與預期的不一致，說明GTP_IODELAY的實際延遲值與理論有差異，在布局布線不同時也應該是有差異的，需要多次嘗試找到合適的參數值。

最終將GTP_IODELAY的延遲參數DELAY_STEP設置為127（已經是可以設置的最大值了），得到的結果是setup最小值0.934ns、hold最小值0.052ns。由此發現setup時序結果遠好于hold，如果器件或工具能在hold上做一下改進應該會更好。

GTP_IODELAY #

(

.DELAY_STEP ( 7'd127 ),

.DELAY_DEPTH ( 7 )

)

另外RGMII接口實際是雙沿采樣，時序報告工具只給出了時鐘上升沿的時序結果，下降沿的結果并未給出。根據之前與紫光同創技術支持人員的溝通結果，應該是時序實際上是有檢查的，只是沒有報告，只要沒有時序報錯就無問題。

總的來說，用于以太網測試的工程搭建起來了，功能仿真和時序都ok，下一步就是正式的上板測試了。