tessent工具做DFT，完全把function时钟复用为DFT时钟，岂不是更好？

IC菜鸟无敌

DFT设计中，对于DFT时钟，可以在顶层新增DFT的clock，也可以把已有的function clock进行复用。
用tessent工具做DFT，有add_clocks这个命令，在扫描链插入阶段，如果直接使用add_clocks命令把现有的clock直接复用为DFT的clock，会不会更好？不用在顶层新增DFT clock的端口，这样既减少了顶层pin的数量，又减少了后端做CTS的复杂度，岂不美哉？
如果不使用add_clocks复用时钟，那么需要在顶层添加dft_clk，然后通过MUX选择来控制时序逻辑。但这样做需要在顶层新增dft_clk，增加pin的数量。而且新增了dft的时钟端口和选择逻辑，增加了CTS的复杂度？既然如此为什么不使用add_clocks命令来复用时钟？
还有一个问题，请教各位大神，occ测试的时候，高速时钟是内部PLL产生的，但DFT测试的时候，处于DFT模式，内部PLL还会正常产生时钟信号来使用吗？（我们公司的SOC芯片的PLL模块、serdes这些都是自己做的，我们是做模数混合芯片的）。DFT模式下，内部PLL输出的时钟会不会受其他数字部分的影响？进而影响到occ部分的高速测试？

kk2009

除非整个芯片的clock只有 1个，否则clock 上的mux是避免不了的。
关于PLL的clock这块，就需要设计上去保证即使在DFT模式下，也能产生，而且需要避免受DFT的影响，简单就是在DFT的情况下，这些寄存器不串入scan，同时保证这些clock不反转，reset不动

ic_expert

我们芯片port很少，只有一个时钟，shift，capture clock全部复用这一个，不需要增加dft_clk。
AC测试时，PLL的时钟一直在动，scan_en=0时，切换2个快速时钟。

janlesion

只是单纯从功能上说应该是可以，但实际在整个流程中,芯片制造出来后一般直接做scan测试，而这个时候它们并不会测试你的模拟模块，也就是根本无法确认是否有时钟，而且当有问题时，他们也就无法来控制时钟来分析问题，至少不如由外面输入时钟方便，测试的前提条件就是激励要准确，如果给了一个不可靠的时钟，就无法做后续的测试，

tttank

pll产生的高速时钟倒是可以用来做at-speed测试的capture时钟

zhx_sm

整个芯片只有一个时钟，DFT的scan时钟怎么设计比较好呢