How to deal with unavoidable setup time violation in CoolRunner II cpld?

Just want to add that I have a local oversampling clock, and the bus could switch at anytime, say 0.1ns before the clock edge. and the cpld requires setup time of 1.8ns.

You can't get rid of metastability, but you can reduce it to spectacularly low likelihoods.

The classic way of doing this is to route the signals through extra flip-flops. 1-2 are usually enough for most applications.

Violating the setup time on the first FF gives you a certain chance of it entering a metastable state. It won't stay in it forever - it just takes longer to switch. The metastable state must last longer than the clock period to affect the second FF, which is very unlikely.

The critical setup time windows which could cause a problem are in the sub-femtosecond range - somewhere within your setup time window. I think Xilinx have a appnote somewhere about the details.

Kind regards,

Iwo

If the setup time on the FF is not met, then it could possibly enter the metastable state. If it does, it will recover rather quickly...I can't remember the exact figure...but you can't be certain of any output. It could go either way. Even if it doesn't go metastable, once you break the setup time, you cannot know for certain what the output will be. Therefore, you would never be able to 100% trust your bus analyzer. I am basing this on how I understand you post.

You mention in the second one that you are using a 'local oversampling clock'. Is this just some integer multiple of the bus speed? If it is, then you can try to figure out a way to do data recovery on the oversampled data. Then you can shove data into the CPLD asynchronously, oversample it X times, recover the data, push it into the local clock domain, and analyze it.

Setup violations are unavoidable in synchronizers. I would use two flop synchronizers in a separate entity/module and just assume that it works. The alternative is to use false path constraints for STA.

Make sure the fast clock period is less than the input pulse widths, and use the slow clock only as in input.

-- Mike Treseler

The problem with violating set-up time is not the ambiguity of the output. If the input switches withing that window, then a 0 as an answer is every bit as good as a 1. Who cares? The real problem is the increased output delay,if the input changes during that sub-femtosecond critial part of the set-up time window. Then the output may fall back at an undefined time after its last clock. But modern flip-flops are very fast. A metastable delay of more than 3 ns is extremely rare. The Xilinx app note is XAPP094 (I think) You can also google: Metastability, Xilinx, Alfke... Peter Alfke

Thank you for the suggestion. yes the local clock is a integer multiple of the norminal bus speed. If the consequence of the timing violation is a misinterpretation of 0 or 1 then it's not a problem , since it will be treated as bit width variation. My original concern was that the output going into metable state and oscillate for prolonged time. Now I read Peter's XAPP094 I no longer worry about this, since my clock period is 20ns, way longer than the already unlikely 3ns...

Thank you all for the kind suggestions and help, I added two flip- flops synchronizers in front of my other logic to make it more solid... That APP NOTE was about Virtex II FPGA, I suppose flip-flops in CoolRunner are the same, or even better than that, right?