使用synplify时，
GSR GSR_INST (.GSR(w_rst_n));
这句话不能用？
点灯工程，去掉这句就能闪灯了,啥也没改，使用这句话就不闪灯了。
板上有几个灯，我用了经过pll的时钟，还有直接管脚进来的参考时钟，也用了fpga内部产生的复位，也用了管脚复位，都不行
目前做的实验，只要去掉使能gsr的，闪灯都没问题，不管复位信号用外部管脚进来的，还是内部逻辑产生的，时钟用外部管脚进来的，还是使用pll产生的
w_rst_n用’1’替换试一下，是可以闪灯了，看起来w_Rstn似乎可能一直是0，但如果是0，去掉使能gsr也应该不会闪灯啊，可实际情况是去掉了gsr，功能齐全的工程也能运行起来，之前是运行不起来的。
还有为什么一样的代码，那为啥用lse编译就能运行正常？
结题：
去掉那句指定gsr的语句，也能正确找到全局复位线，nco也能正常工作，粗略看了数字板，工作正常
w_Rstn 是在逻辑内部产生的吗 ？
你截张这里的图看看
最有可能的情况是：w_Rstn被一直复位着。如果列化GSR 时，输入的信号是来自管脚，而且管脚是高的话，不会出现这样的问题。
如果是完全一样的代码用lse综合可以正常运行，而用synplify综合却有问题，那有可能是别的原因。
好多年前我遇到过一次，内部产生的复位信号，导致整个逻辑都被复位住，最后原因是产生复位信号的逻辑也被复位住了。虽然代码里面产生复位信号的逻辑没有写复位信号，但底层看，发现复位逻辑相关的寄存器的GSR 是被打开了，也就是说自己被自己一直复位着，最终导致复位信号一直处于复位状态。明天你可以查一下，w_Rstn是不是GSR 是enable 的。
估计不同的综合工具对GSR 的使用上不一样，尤其是没有指定复位信号的寄存器
去掉GSR那一句后，软件自动分配一个复位信号为GSR,是没问题的。大多数设计都是软件自动分配，客户不需要指定。
去掉那句指定gsr的语句，也能正确找到全局复位线，nco也能正常工作，粗略看了数字板，工作正常，这样作为最终版测试应该没问题吧