影响成败的小细节

一、前端的小细节

       1、在做设计时，要写好设计文档。文档内容要条理清晰、简繁适中、图表齐全，同时做好历史记录、修订记录。

       2、在设计芯片架构时，要考虑到出故障后，如何恢复芯片，让其能重新工作。

       3、仿真时，对于做deglitch的逻辑，要验证零界点，即当deglitch 计数刚好到达阈值时，被deglitch的信号无效了，看看此后相关信号的行为。

       4、当需要修改系统时钟时，一定要检查整个设计里的counter、deglitch、分频、IP的接口信号脉宽、超时机制、中断脉宽等等，凡是跟时序有关的地方都要仔细地思考，

             以防止改了时钟，导致相关的时序、timer计时长度 跟设计不一致。（此坑已踩过，以后要小心！！！）

       5、当设计上有拿不准的地方，一定要把问题抛出来 ，让大家集思广益！！！

       6、在完成初版的RTL design后要及时地做CDC检查，并在项目中间定期跑一边CDC。

       7、某一个设计模块，在不同项目间使用时，不能直接copy之前的设计到新的设计里，一定要检查两个项目有什么区别。同事的项目直接copy以前项目里的一个滤波器设计用到新的设计

             里，结果芯片回来测试，发现新项目里滤波器的输入是有符号的，之前的项目里是没有符号的。（此坑已踩过，以后要小心！！！）

       8、在设计里一定要增加一个可以复位所有功能的后门，如果碰到异常卡死、状态机不能回到idle的情况，这个后门还可以救活。 同事已踩此坑，芯片在老化测试碰到问题，分析可能是某个信号异常，状态机不能回到idle，没有任何方法可以救活，除非掉电。。。。。。多么痛苦。

 

 

二、后端的小细节

       1、在release code 之前，要先跟layout 确认，询问layout的状态。如果layout未准备好，可等一段时间再release code 给PR。在等待的这段时间里，

             还可以继续验证RTL，以防有遗漏的issue。

       2、在提供sdc文件给PR时，要仔细检测那些额外增加的时序约束路径，要用PT报出这些时序路径是否存在。

            比如 set_max_delay 20 -from [get_pins u_dut/u_xxx_reg/QN] -to [get_pins u_dut/u_yyy_inv/B]

            这里额外增加了从pin u_dut/u_xxx_reg/QN 到 pin u_dut/u_yyy_inv/B 的最大延时不超过20ns的约束，但是这条路径又可能不存在，因为有时综合后，

            寄存器u_xxx_reg的QN端没有使用，只用了Q端。

       3、在PR后，一定要检查spare gate是否还在，同事已踩此坑，芯片回来后有问题，eco要用到spare gate，发现spare gate都在PR阶段被优化掉了。

       4、在PR后，一定要检查送到数字部分的时钟的驱动能力够不够，已踩此坑，芯片回来后有寄存器异常，分析功能没问题，但就是在工作中赋值出问题，后来发现送到数字的时钟走线比较远，而且驱动buffer也很弱。通过做FIB，换个大驱动能力的buffer，问题就解决了。     

    

 

 

 

 

 

 

未完。。。。。。