续前一篇博文，经过多次对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，下一步就是正式的上板测试了。
