Timing errors in the first few nanoseconds due to clock edges...how does this translate to real life?
The post route timing simulator has brought up an interesting question.
If a clock signal is being fed into an FPGA, it is inevitable that eventually on startup a clock edge will arrive before some of the signals inside the FPGA are prepared for this. Thus the simulator gives a timing warning.
Of course, I can fix this in the simulator by delaying the clock start, but in real life the clock is generally running from time 0.
I realize the GSR resets things if used, and I use my own externally generated reset to get things going, but the question is:
Does a timing violation in the beginning necessarily screw everything up from that point on due to metastability or will this generally resolve itself before GSR?
Does my eventual hard reset force the clearing of any metastability issues?
If my forcing of the latches to a known state clears these issues, then no problem. But if metastability can somehow result in a hardware latch up which cannot be resolved by a forced reset then it's a big problem!
I recall that metastability in xilinx devices tends to decay extremely quickly. The length of the Power-on GSR (which on all xilinx FPGA's I've used is an automatic and mandatory part of the startup process) is pretty darn long in the big scheme of things, for several reasons, most likely including this very one. (AIUI GSR is fully asynchronous so the entire time the signal is high
latches are being reset (the reset does not just happen on posedge of
the GSR signal)). But I'm not Xilinx engineer, and indeed have never even spent too much time considering metastability in an FPGA design at all, much less your specific concern. Just some food for thought, until somebody more knowledgable comes along.