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

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

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

編譯結(jié)果發(fā)現(xiàn)setup時序裕量充足，而hold時序特別差。通過Timing Analyzer查看的結(jié)果如下：

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

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

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

GTP_IODELAY #

(

.DELAY_STEP ( 7'd127 ),

.DELAY_DEPTH ( 7 )

)

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

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