IC前端设计bug小结。

bug  review会

近几天公司内部开了个IC设计前端的bug review会议，总结了经常出现的问题，很有意思，特记录一下。

1. 在验证的时候，不仅仅只从RTL角度考虑test case，也应该结合应用场景考虑test case。

      一方面，应用场景提出的要求可以帮助设计者检查自己的设计是否符合能够满足实际需求；

      另一方面，也有助于功能验证的完备性。

2. 同步设计中不允许在sdc约束中加入multicycle或者false path，如果综合出现timing violation则

   可以通过修改设计插入register解决。设置了multicycle或者false path之后，STA工具就不会检查

  这部分同步设计了。如果需要在前仿中加入对multicycle的仿真，可以通过加delay的方式模拟后仿。

3.  在涉及到RAM的设计中，一定要注意在某个时钟周期内部，是否可能会存在同时读/写RAM而造成

     冲突的问题。

4. 在有明显的周期性的处理过程(如多媒体中以帧为单位的处理），在当前周期处理完成或者下个周期开始处理

    之前要有自己回复成原始状态的功能。不能依赖于reset信号回复原始状态。即系统 soft reset是当系统出现问题

    时恢复用的，在正常功能中不应该存在复位行为。

5. 在多媒体的验证中，不能仅仅为了方便验证单帧case。多帧的case也要占到一定的比例。

6. 中断报告的时机。考虑以下场景，假设A要通过fifo向C发数据，只有A真正的将数据全部写入FIFO之后，才能报

    中断给C。这是中断报告的基本原则。以AXI总线写为例，不能仅仅发出最后一笔AXI_WR的command就报中断，准确来说应该等到

    全部BRESP回来再报中断。

    

7. 设计AXI_master写时，要等到一个burst全部数据都准备好（缓存在一个FIFO中）之后才能发出burst write command，这样子数据

   在下一个周期开始发送。这种设计不会由于自身的设计问题拖累AXI BUS的性能。

8. 设计AXI_master读时，要等到有足够的空间能接受全部读的数据（或者随着时间推移，总是保证有足够空间保存数据，而不至于RREADY

   拉低）时，才能发出AXI read burst command。这种设计不会由于自身的设计问题而拖累AXI BUS的性能。

9. 当做UVM验证时，最好不要单纯做黑盒测试。为了测试的完备性，应考虑至少做到灰盒测试。

10. 写sdc文件时，一定要保证每一条约束都是有明确目的的，一定要在完全清楚该约束的含义及可能导致的后果的前提下，才能写该约束。因为

     sdc设置问题而导致的芯片bug会很严重，且难于验证出来。

11. 一般来说，软件给硬件分配的空间是地址对齐的。但是由于硬件多以32bit为基准操作，所以硬件多是以word对齐的。这样在驱动端就会导致软硬件

     对齐方式的不一致。直接后果是：驱动为了匹配二者，从而徒劳的做一次数据搬运，而且可能会占用一个静态数组，导致该空间被永久占用。

that is all。