紫光同创PGL22G开发平台试用连载(3)---以太网测试工程二

yuancwei 提交于 周五, 09/11/2020
紫光同创PGL22G开发平台试用连载-(3)以太网测试工程二

续前一篇博文,经过多次对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输入约束如下:

3-1

编译结果发现setup时序裕量充足,而hold时序特别差。通过Timing Analyzer查看的结果如下:

3-2

查看详细的时序路径报告可以发现,输入RGMII Clock的路径延迟比数据大2.106ns,这是导致时序不满足的主要原因。这种情况下需要手动对输入数据添加延迟。延迟的实现使用GTP_IODELAY原语来实现,每个延迟单位的值是25ps,按照添加约1ns延迟计算(这样hold时序余量就有0.2ns左右),GTP_IODELAY的延迟单位DELAY_STEP取值40,重新编译一下。

但是再次编译的结果与预期的不一致,说明GTP_IODELAY的实际延迟值与理论有差异,在布局布线不同时也应该是有差异的,需要多次尝试找到合适的参数值。

3-3

最终将GTP_IODELAY的延迟参数DELAY_STEP设置为127(已经是可以设置的最大值了),得到的结果是setup最小值0.934ns、hold最小值0.052ns。由此发现setup时序结果远好于hold,如果器件或工具能在hold上做一下改进应该会更好。

GTP_IODELAY #

(

.DELAY_STEP ( 7'd127 ),

.DELAY_DEPTH ( 7 )

)

3-4

另外RGMII接口实际是双沿采样,时序报告工具只给出了时钟上升沿的时序结果,下降沿的结果并未给出。根据之前与紫光同创技术支持人员的沟通结果,应该是时序实际上是有检查的,只是没有报告,只要没有时序报错就无问题。

总的来说,用于以太网测试的工程搭建起来了,功能仿真和时序都ok,下一步就是正式的上板测试了。

相关文章

Digi-Key