请问关于watchdog 对复位信号的控制
RESETn信号是外部的复位信号，
wdt_out是看门狗输出的控制复位的信号，
sys_rst_n是内部的复位信号。
目前在顶层模块里，设计人员使用
assign sys_rst_n = RESETn & wdt_out ;生成了内部的复位信号，
但是我们用PT做STA时watchdog模块一直存在recovery/removal time的错误，
后来想起来，RTL设计里好像不允许在出现门控复位这种情况
请问大家这么产生复位信号是否合适?如果错误的话应当怎么处理?
我感觉你这个很可能是由于wdt_out信号产生的时钟边沿和sys_rst_n信号使用的时钟边沿一样或相位相差不大引起的，请确认下
sys_rst_n在内部作为一个异步复位信号，watchdog模块，复位信号也是sys_rst_n，这样对于这个模块计算起来是否时钟相位上就会出现错误?
话说，我想起来，时钟分频电路部分，用于watchdog的那个时钟信号也会出现recovery和removal的错误，这个模块的复位信号也是sys_rst_n
我下面有几个问题，请解答下：
1、wdt_out信号，是怎么产生的?由哪个时钟触发?上升沿还是下降沿触发?
2、sys_rst_n信号，在哪里使用?其寄存器由哪些时钟触发?上升沿还是下降沿触发?这些时钟和产生wdt_out信号的时钟有什么关系?
另外，可以的话，粘贴出来timing report最好
我没有参与这个项目的设计，所以不是太熟悉timing_report目前没办法贴出来，因为存报告的服务器还被锁着，一会儿我看看能不能拿出来。
设计里，所有的触发器都是时钟上升沿触发
wdt_out应该是watchdog模块在计数器溢出的情况下置为有效的，由一个叫做clk_25mhz的时钟信号上升沿触发；
sys_rst_n是整个设计的异步复位信号，内部有几个时钟，其中clk_25mhz就是产生wdt_out的时钟
可以看得出来，设计本身就存在这个问题的，recovery/removal violations是必然的
建议将产生wdt_out的寄存器使用下降沿触发
谢谢您的解答，我再和设计人员讨论一下。
感謝 未來有機會碰到的東西
你们的胆子还是相当大哦
居然组合逻辑搞定，
好歹还是要异步复位，同步释放撒，
watch dog , 外部复位源，内部复位控制，这3个服务源是SOC中经常的复位源，
尤其是一个模块受3个源的控制，再怎么在模块端看见的应该是异步复位，同步释放
正解！