DC **** 第七课

第七课

Reducing large datapath delay

例如：y <= a * b + c * d + e - f; 由于两个寄存器之间组合电路太多可能满足不了时序，这个时候一个比较好的解决方法就是pipeline（流水线），在组合电路中间插入寄存器。那么原来需要1个cycle完成的事情，现在可以用3个cycle去完成。
代价：流水线级数越大，面积越大，初始化延迟越高。并且时钟频率取决于最慢的一级。

• 约束命令（需要licence支持）
  针对流水线寄存器作优化的选项：

set_optimize_registers true  //需要在compile_ultra之前给出

重新分布的寄存器名字会从 XYZ_reg[#]变成clockname_r_REG_S#
而-retime是针对非流水线的寄存器所做的优化，两个命令可以并行使用。

• RTL代码推荐写法
  将寄存器集中放在输入或者输出，并依靠命令进行调整，而非人工在每一级中间插入寄存器。
  这种做法如果忘记使用命令可能会遗留严重的后果。
  另外如果需要保证寄存器输出，可以输入以下命令进行限制：

set_dont_retime [get_cell U_pipeline/P3_reg*] true

Multi-core optimization

当综合较大的电路例如SoC时，可以通过命令申请多核并发综合。（需要licence支持）
licence越多，可以申请的核就越多。

report_host_options //查看当前系统有多少个核
set_host_options -max_cores 4  //申请四个核
compile_ultra

constraint report after compile

report_constraint -all_violators
report_timing  //报告每个组中时序最差的路径
group_path -critical -weight -from ... -to ...  //可以将时序最差的路径的权重调高
compile_ultra -incremental //进行增量编译

settime的违规需要手动解决。
增量编译在逻辑优化和GTECH库之间循环，不会再回到原理图优化。
如果有无法接受的时序violation或者DRC violation，则需要从前端开始重新编写代码或者重新设置约束。

Appendix 1:Better coding style

RTL代码除了仿真通过以外还需要注意其它很多问题。

• allow resource sharing
  
  DC在优化中不一定会从左图调整为右图，需要手动修改代码。(compile_ultra可以做到）
• 写算式时不写括号可以允许DC重新排序，让时序更好（但是看起来会更乱）
  
• 使用for循环时注意循环内的逻辑不要太复杂。

Appendix 3:Design for test

通过一定的方法测试芯片是否在生产过程中发生了错误。
DFT不是为了验证芯片的功能，而是验证芯片是否出错，如果出错，则需要定位出错的部位。

• ATPG：Automated Test Pattern Generation（自动测试向量生成器）
  生成激励以及相应的输出的过程叫做ATPG，若实际输出与应有输出不同，说明出现问题。

• Stuck-At Fault(SAF)
  SAF是用来表示芯片潜在物理缺陷的逻辑模型。

如下图，无论B输入什么信号，输出都会被短接至地，因此被称为SA0。
Q：封装后只能看到管脚（ABCDZ）的情况下，如何测试SA0的问题？
A：输入中施加适当的电平，测试管脚B的功能，如在此例中可以令A=1,C=D=0，就可以使Z=B，从而进行验证。
关键：要使错误传递到输出。 非门/与非门的其它输入需接1，或门/或非门的其它输入需接0。

**D(discrepancy)算法就是DFT的雏形，以正常和错误输出的差异为基础检查电路。

Q：以上的办法适用于组合电路，时序电路中要如何调节输入电平？
A：在寄存器前面加MUX，需要测试时将寄存器串联成扫描链，逐级输入激励，并配合ATPG验证结果。

DC的-scan选项就可以在寄存器之前插入MUX，但是在插入之前需要先评估是否会影响时序，增大的面积是否能接受。