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

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

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

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

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

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

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

GTP_IODELAY #

(

.DELAY_STEP ( 7'd127 ),

.DELAY_DEPTH ( 7 )

)

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

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