DCM_CLKGEN重置自己后恢复默认值怎么办？

d，
电源有什么用？
IO信号是否存在过冲/过冲？
无论是电源是否超出规格，或者信号完整性如此糟糕以至于注入的电流流入/流出衬底会导致存储器单元翻转其状态。
如果它是信号完整性，较慢的时钟不会阻止它发生。
如果它是电源欠压，那么较慢的时钟应该减少电流，并且它不应该快速断开。
我看到间歇性负载与电路板电源产生共振，导致崩溃。
大多数电路板都有一个20到40 KHz的电极（如果你遵循我们的指导原则），所以在相同的频率下进行任何负载变化就像在正确的频率上推动一个孩子一样，容纳电源电压的极端变化（并且可怕
孩子）。
即使具有100的MHz时钟速率，也可能存在状态机和其他复杂性，从而产生这种低频负载变化。
Austin Lesea主要工程师Xilinx San Jose



以下为原文

d,
 
What are the power supplies doing?
 
Is there overshoot/undrershoot on the IO signals?
 
It is either the power supply is falling out of specification, or the signal integrity is so bad that injected currents into/out of the substrate is causing the memory cells to flip their state.
 
If it is signal integrity, a slower clock will not prevent it from happening.  If it is  brown-out of the power supplies, then a slower clock should reduce current, and it should not break as quickly.
 
I have seen intermittent loads resonate with the board power supplies, causing a crash.
 
Most boards have a pole at 20 to 40 KHz (if you follow our guidelines), so having any load change with the same frequency is like pushing a child on a swing at exactly the right frequency, casing extreme variations in supply voltage (and terrifying the child).
 
Even with 100's of MHz clock rates, there may be state machines, and other complexities which create this low frequency load change.
Austin Lesea
Principal Engineer
Xilinx San Jose

你好奥斯汀，
感谢您的快速回复。
根据你的说法，这可能是一个电源问题。
当我在180Mhz达到这个条件时，我没有遇到频率较低（例如100MHz）的问题。
如果这是问题，并假设我根本无法改变董事会，你有什么建议可以防止这种情况发生吗？
我的想法是：
- 在不同的时间“开启”FPGA（现在它们是成对的，因此每一对或多或少地在同一时刻开启，可能在几个周期内差异）。
- 使用不同的时钟相位？
所有FPGA均由同一时钟驱动，该时钟通过PLL原语然后馈入DCM_CLKGEN。
对于一半的FPGA，我可以尝试使用180度相位。
还有什么想法吗？
非常感谢oyu为你提供帮助，这真的很有用！
大卫



以下为原文

Hello Austin,
 
Thanks for your quick reply.
It could make sense, according to what you say, that it would be a power supply issue. I haven't had this problem with lower frequencies (say 100MHz) while I'm hitting this condition at 180Mhz.
If this was the issue, and assuming I can't change the board at all, do you have any suggestions to prevent this from happening? My thoughts would be:
 
- Turning the FPGAs "on" at different times (right now they are paired so each pair turns on at the same instant more or less, probably within a couple of cycles difference).
- Using different clock phases? All the FPGAs are driven from the same clock, that clock goes through a PLL primitive and then is fed into the DCM_CLKGEN. I could try to use 180 degrees phase for half the FPGAs.
 
Any more ideas?
 
Thank oyu very much again for you help, it's really useful!
 
David

d，
270相移是IO与结构的“魔术”空值（结构时钟为0度，输出时钟为270度）。
这值得一试。
更快的时钟也可能更好，我们已经看到时钟加倍，但使用时钟启用/禁用来折衷以更快时钟运行的区域也可能有所帮助。
最后，必须消除任何低频功率变化。
Austin Lesea主要工程师Xilinx San Jose



以下为原文

d,
 
270 phase shift is a 'magic' null for IO vs. fabric (fabric clocked at 0 degrees, outputs clocked at 270 degrees).  That is worth a try.
 
Faster clock may also be better, we have seen doubling the clock, but using clock enable/disable to trade off areas running at the faster clock may also be helpful.

Finally, removing any low frequency power variation is a must.
 
 
Austin Lesea
Principal Engineer
Xilinx San Jose

我可能有点生疏，但我没有得到“低频”位。
我的设计必须是时钟：70MHz，包含顶级逻辑和UART接口以及可变时钟（100-200MHz），占设计的80％。
另外值得一提的是，我使用了大约60％的FPGA资源，所以它非常繁忙。
70mhz时钟域并不是一直运行，有些任务是每几十毫秒完成的，但它们不是那么密集，因为它代表了非常少量的逻辑。
经过一些测试（我现在无法查看电源，因为我没有适当的仪器）我知道这确实发生了一段时间后（相反“一旦我解除复位信号就会发生），所以我
不知道为什么DCM会在几秒钟后以最高速度平稳运行时自动重置为什么。此外我相信电路会在此期间产生有效的结果，因为我会在时钟疯狂之前得到明智的响应。
这只发生在其中一个FPGA上，但是我必须使用相同的电路板并且两个都是相同的（相同的FPGA），所以你可能对电源问题做得很好。
我没有使用I / O引脚（差不多）。
再次感谢您的帮助！



以下为原文

I may be a bit rusty but I don't get the "low frequency" bit.
My design has to clocks: 70MHz that contains toplevel logic and UART intefaces and a variable clock (100-200MHz) that represents 80% of the design. Also worth mentioning that I'm using around 60% of the FPGA resources, so it's quite busy. The 70mhz clock domain is not running all the time, some tasks are done every dozens of milliseconds but they are not that intensive, since it represents a very small amount of logic.
 
After some tests (I cannot look at power source right now since I don't have proper instrumentation) I'm learning that this does happen after some time (as opposed as "It happens as soon as I deasssert reset signal), so I don't really get why the DCM would reset itself while everything is running smooth at top speed after some seconds. Also I'm confident the circuit produces valid results during this period, since I get sensible responses before the clock goes crazy.
 
This only happens to one of the FPGAs, but I have to identical boards and happens to both of them (same FPGA) so you might be well right about the power supply thing. I'm not using I/O pins (almost).
 
Thanks for your help again!