ATPG 的TOP的仿真注意事项

先整理 edt_dofile,看里面的层次结构是否正确，edt 以及 scanchain的名字，以及edt clk update channel in out 对应pad GPIO等的关系要表述正确

后面用testproc实现， 目前初步try的话 tie信号的时候要保证 tdr可控哦！！！

整理CCD 也可以去各个block owner下查看

Tunit有一个IO_TEST mode tdr， 把这个配起来进入test mode,所有的IO pinmux就会按照test mode下设置的IO direction去配置OEN

我配起来了 ，但是我的atpg 的io lib没有link起来导致配起来也没啥作用。所以找一下对应的lib

DE3.0的时候 还是tie的一些信号，在GLS环境中我们要force这些信号，还有一些 tb中的power pin也要force上。

跑仿真的时候 scan mode要通过 proc 读进去，尤其是和top有关的 比如app 的scanmode 就是和fuse的一些reg的初始化有关，如果scan mode一直是tie 1 的 那么就一开始没有走function 的mode 导致一些fuse 的reg 没有初始化一直是x态的原因。

在 DC 仿真的时候， atspd mode要一直为0， dump.do文件里 误操作tie成了1 ，导致时钟有一截是x态，

   这是因为在occ中， 虽然GPIO_04的capture为x，但是atspd 为1，scanmode是1，那么 就导致了与门传递了capture的x态，所以scan_clk_sel 为x ，所以由于sel是x 导致 clk_4_scan_mode 是x，又由于scanmode为1，导致了clkout是x，进而到了reg上 clk是x 导致了Q是x。所以在DC的时候atspd要是0，那么与门就是0，sel就是0 ，走的是scanclk，就不会有x态了。

chain ser的debug：检查的是每一条chain是否有问题。

     仿真的log中看到的是GPIO_13有x态，对应的是top的edt的chanel_out[2] ，可以看到每条chain的尾部到edt内是有x的，然后压缩后是channle_out是有x的 到pad上当然也有了x，反过来再看 虽然channel_in是有x的但是 解压缩后的edt_scan_in是没有x的，所以到达每条chain的头部是没有x的。因此debug的结论就是chain出了问题，atpg后会有scancell的report记录了一下每条chain上的cell的顺序（是倒着的）。可以查看chain的头部，发现他的Q端没有被复位导致连载了下一个cell的SI端传递了X，如下图所示，所以当reg27 的R端有一个复位后就不会有x态的传递了。

复位是在这里给的。因为是tie的所以没有复位的过程，因此读入proc后应该就是可以的了。