针对voilated时序进行代码级的分析及修改

至于IP核内部时序违逆，就不要管了！这已经说明：时序已经跑出它能跑的范围了，内部违逆没办法处理。

主实验：

导入工程rgmii_image，并将环境配置成：
1.在Analysis&Synthesis Settings中，Optimization Technique改为Balanced，More Settings中的Synthesis Seed改为8；
2.在Fitter Settings中，Desired worst case slack改为 2 ps，Seed改为 4；
3.在Report Timing中，From clock填入sclk，选中Setup分析类型，报告路径1000条。
（注意：一般都是建立时间出现voilated。因为+^T相对来说比较小，而减去的T1却是巨头）

现有的计算机程序并不存在 量子玄学问题，只要我们按照环境配置方法，就会得到这165条违逆路径，而且布局布线是一致的！

针对最差路径启动Chip Planner，可以发现它的“战线”拉得比较长。用到的LE比较多，中间的判断逻辑可能比较复杂！
然后，我们就需要通过对最差路径进行代码级的修改。右击最差路径，单击Locate，选择其下的Locate in Design File，就会直接定位到对应的代码行。
从跳转到的代码行中可以发现：该判断语句中受多条比较逻辑（比较器）路径影响。
精髓：一定要避免在判断中加入多条线！！！

在该问题中，我们需要一条线一条线的分析。而在总体的程序设计上，一定要避免以上情况
解决方法：除了“打断”路径，还是“打断”路径！！！ 在always、assign、逻辑、case等不同场景（“打断”就有 不同表现形式），都有典型电路来调整。不过，插入的位置具有一定的概率，可能变短，也有可能变长。
又因为最差路径设计的寄存器是pixel_cnt[9]，于是锁定到 pixel_cnt的判断逻辑！
如果我们可以在该判断中插入一级寄存器的话，这是可行的！
在该行代码的下方又可以注意到：同时还存在着 pixel_cn<= 'd9 的信号。于是可以知道这是一个比较器（比较pixel_cn 与 'd9之间的大小）。
这样的话，我们就面临着如何去拉低信号的问题。通过浏览本文件可以发现，存在着pixel_pkg_flag== 1’b0来使 pixel_cnt清零。
进入Report Timing…查看，最差路径变成其他的了（就好像是打地鼠），只剩下31条违逆路径（但不要高兴得太早！）
我们可以通过Report Path…来查看之前路径的情况，但也有可能这段路径被优化掉了，因为毕竟我们加了寄存器了。

使用同样的方法查看 “9 到 10” 的路径信息
再按照原来的步骤来“打地鼠”，不过可以放心：成功的道路尽管是曲折的，但迟早是可以优化好的！

我们发现，又是原来的代码行😓 再次提醒：尽可能避免在判断中加入多条线！！！
尽管pixel_cnt已经不报错了，
但结果出乎意料。。。（出现了315条违逆，比第一次还多！！！）


自己走的路跪着也要走完，不能再往回走了！
（到底是否往前走，完全取决于：我们修改的代码是否产生了对原有错误的改进！）

用到的case语句，用来作固定的寄存器输出（按照地址输出寄存器）。其实，我们可以在RAM中实现该功能，但也有些时候避免不了用case语句来做。

在代码段中发现的问题：if else语句中叠加了case语句，比较庞大。
还有就是像case中再加case的情况，因为case本身就是连接多个查找表，由上图的Chip Planner图可以看出来！这些路径使得延时非常大。
单个大case段，也很容易出现时序违逆。（可以将大case拆分成多个小case，再通过选择器组合到一起）

解决方案：将else if中的“多线程逻辑”换成 单比特信号。
详细实现：我们先来尝试一下，将其中的一处替换掉。先不考虑功能，只关注是否有效。若有效，之后再来优化逻辑以实现功能。
不减反增。。。（出现了366条违逆）
我们进一步将所有的else if中的逻辑全部取消，只留下大case段作为else！
这一步也就意味着：功能与之前又不一样了！
经过大修改后，变好了不少，违逆路径只剩下了31条。
但还是有违逆，而且不符合最初的功能（暂时不考虑，反正也只涉及到一个大if-else）。
紧接着，我们要将大case拆分成2个小case。当然不一定会变得更好，这只是我们预期的。只因为综合器会把内部的一些东西优化，可能会变得更差！最终还得看综合器的结果！
注意：第125行的cnt_base应改为cnt_base1，否则会报出20个errors！
“Can’t resolve multiple constant drivers for net at .v报错"原因如下：

https://blog.csdn.net/weixin_30588827/article/details/95067885

另外，还要将case(cnt_base1)的default中的d2赋值为pixel_data；将case(cnt_base)的default中的d赋值为0；不然也会有违逆。

最后，终于得到了我们想要的结果：无违逆

额外实验一：

在完成工程的优化之后，我们再来尝试一下“在选中小case时不给它延时一拍”（即：把 选择小case 做成 组合逻辑）的情况：
因为担心可能会冲击到LHS侧的tx_en、tx_data的时序，所以一开始就将这两个声明成寄存器类型。但在不延拍的情况下，选择过程就只相当于“线与逻辑”，没有了寄存器的功能！结果效果很差，显示的1000条路径全是违逆！
所以，不加上tx_en、tx_data这一级寄存器（就是上面的这种“线与”情况），就会直接冲击到 tx_data的时序。

额外实验二：

但如果只将tx_en变回“线与逻辑”，而不改变tx_data。可以发现：电路时序反而变好了！

额外实验三：

再来尝试一下：不拆开大case，只打拍。（因为最开始未拆分前，tx_en和tx_data都是用assign组合逻辑赋值，根本就没有“打拍”的概念！）结果发现：比最开始未拆分前的那次结果（31violated，-0.278）还要差！！！

结尾顺便提一句

重定时 其实和 讲到的”插入寄存器“ 本质上是同一个概念！区别就在于：重定时是移动寄存器的位置，而插入寄存器却是新增一个寄存器使 两级寄存器路径延时 减少。