SerDes interface参考设计_程序优化（8）

8    程序优化

在测试中，对timing的报告进行分析，发现制约传输速率的因素并非IO接口的速率，在LVDS接口中，IO可以跑到800Mhz，而是内部的逻辑时序跑不上去了，而制约速度的来源主要为两个地方，分别为接受部分的r_check模块、S2p_10bit模块。

在没有进行优化前，timing的报告如下：

S2p_10bit模块：对时钟进行恢复，并将串行数据转换为并行10bit数据，其内部有一个4bit的count用于时钟恢复与数据串行转并行的数据个数计数，因为逻辑比较复杂，在timing report中，该count是制约时钟的主要因素。

R_check模块：将数据进行对齐的功能，其工作的时钟rclk由S2p_10bit的采样时钟10分频得到，在相对低的时钟域内，但是其内部有一个非常大的对比检测逻辑，对10bit的数据依次检测并对其，内部有10个else if，数据路径很长，也是制约速率的重要因素。

8.1   逻辑优化1：

S2p_10bit模块：将恢复的数据长度由10bit变为5bit，并在后级将两个5bit的数据进行拼接，这样可以的降低count的位数，由4bit变成3bit，同时降低的逻辑的复杂程度。

R_check模块：comma码的关键在于其独一无二的7bit数据1111100，因此在程序设计是，comma检测可以由检测10bit的commaK28.5（0101111100）缩短为检测7bit的局部comma （1111100），这样可以在很大程度上降低逻辑的复杂程序。

以下是对逻辑进行优化后的timing report：

在优化后对逻辑进行了通信的测试，以下是测试的环境:

测试5：采用LVDS的IO标准进行数据传输，发送端发送8位的累加值，传输后经过在接受端对数据进行恢复并判断，测试平台为HR03的evb板，数据线为普通的杜邦线，线长约15cm。

系统时钟	测试时间	错误数据个数
250M	1h	0
260M	1h	1个/s

在作出以上处理后，对发送模块的程序作了相应的时序约束，在时序约束为160MHz，测试结果最为理想，其约束结果如下：

在此约束条件下，系统测试结果如下：

系统时钟	测试时间	错误数据个数
270M	1h	0
280M	1h	0
290M	1h	10个/s

由此可以证明，发送模块也是影响通信速率的重要因素，应该对发送模块的部分程序也做相应的处理！

在Ｍ7上做相同的处理的timing对比结果如下图：