这个端午节真郁闷，一直在加班，直到加班到今晚九点多，服务器文件系统挂了，才能无奈的休息回。而这不意味这几天焦头烂额的生活已经结束，也许意味着服务器好了后会过的更焦头烂额！！

不过也只能怪自己，当初任务没做细，有些事一直在拖，搞得到紧要关头手忙脚乱。在这里随便扯扯教训，算是对做H264硬解码一个子模块的教训，也权充这周的日志。

  1. 万事不能拖，当解决的时候就必须解决。之前其实曾经有空整这东西，但是由于各种原因（包括自己的，以及各种对外部因素的依赖），一直没彻底搞定，自己也知道自己做的模块肯定会有问题，但却一直不想去改。这又是我执行力不够的体现，还是那就话，加强自己的执行力，任何事，想到了就去做。
  2. 不能报侥幸心理。之前解码中有个解出来的参数mb_skip_run，我想当然的以为他不应该超过一行的宏块数，虽然当时怀疑过自己的想法，但却报侥幸心理，觉得大部分视频的mb_skip_run都不会超过这个值，应该问题不大，的确，前面跑了很多视频，都没有出问题，可是昨天测了个视频，跑错了，一trace，发现问题就出在mb_skip_run上这点想当然。于是改，谁知，要不改状态机，得用到除法，而在Verilog中，用除法风险太高了，肯定出来的结果时序要求不符合，DC过不了，主频就惨了。最后只好大改，改状态机，还好，毕竟是自己写的，对状态机挺熟，花了一下午终于改好了，并且做了一些回归测试。还有，之前也怀疑过一个Frame会有几个Slice，但是由于没跑到这样的视频，所以也以为这样的视频很少，不做也罢，谁知，到最后还是得加。
  3. 思路得清晰，关键处要有文档，之前有个8x8块，我为了省面积，愣是想用4x4块的寄存器数（可以省700+寄存器）来完成8x8的残差计算和扫描，当时想通过4x4的想通过掩码把4x4打散成8x8块，当时就意识到逻辑会比较复杂，当时总觉得肯定可以，于是硬着头皮写了个逻辑，但自己都没有把握。由于之前没跑到8x8的视频，也不知道对否，就一直放在那。直到今天，跑了8x8的视频，才知道有问题，于是重新看了下代码，发现由于逻辑太复杂（需要先打散，之后扫描，扫描又分zigzag和field）以及没有文档，自己都看不懂自己当时是怎么写出那逻辑的。后来仔细想了想，想直接通过掩码，不用寄存器暂存8x8的块不现实（因为只打散的话，可以通过掩码做到，但是还要扫描，掩码就没辙了），于是只好加了用来暂存8x8的寄存器，并且残差输出的状态机也要改，又是一下午的时间才改完并且初步做了回归测试。
  4. …
    马上就到端午节了，贴张粽子的图吧，望梅止渴下：

粽子