Design failed on board from time to time

[Altera_Forum]

Hi all, 

 I have my design finished and tested on board. But sometimes it works and sometimes it doesn't.   My design is a TV data stream scrambling module. It has 7 sub-modules running in parallel to scramble the data. The connection and function of the 7 are all the same.   And I've found the potential error always happens to the data scrambled by the 6th and the 7th module(I have scrambled 20M data, and all the errors happens to those two).   I suspect there could be some timing problems which are not detected by the TimeQuest. I have to use a pretty high frequency(160Mhz) to do the scrambling, and for one part I have to use both the rising edge and the falling edge to implement the algorithm.   I've got some setup slacks only 0.2XX. I'm wondering could that be a too small slack that might have caused the failure?

[Altera_Forum]

you cannot use dual edges of a clock inside the FPGA. DO you have any logic generated clocks? Could you post the code for the module?

[Altera_Forum]

Also - did you specify timing specs or did you just look at the FMAx calculation?

[Altera_Forum]

Why I cannot both edges of the clock in FPGA? 

Could you expain that?   By the way, my clock is generated from a PLL.

[Altera_Forum]

You can use both edges in design inside fpga. I am sure Tricky means you cannot per process(register) and that is true obviosly in current technology. 

 Have you checked your reset operation. Does your failure/success occur per build or per power cycle or per some other change.   Remember timing tool will not check first set of registers for setup/hold or removal/recovery unless it has info on those paths(registered reset for example).

[Altera_Forum]

kaz, I have observed my failure happened just when it's data should be scrambled by the 5th and 6th module(and their occurence in different trials are nondeterministic). So I suspect there could me some timing problem there. 

 And I just tuned my sdc file a little bit. I used to set_clock_uncertainty from hiclk to hiclk 0.35 to get rid of some setup violation. And after I have changed 0.35 to 1.24, I've found my error pattern changed. Now I got my errors occur more often and they are not restricted to 5th and 6th module scrambled data anymore.   Do you think I should've avoided using set_clock_uncertainty?

[Altera_Forum]

I wouldn't recommend reading too much into results if timing is violated. 

 One way to test your design is (assuming all your 7 modules are instants of same) is to pass same input to all 7 and check their outputs). If they are different then I will blame something other than functionality of logic. I could blame timing or other differences from various inputs.

[Altera_Forum]

Why shouldn't I worry about the existing timing violations? 

 Because I kinda suspect that setup violation from hiclk to hiclk(the clock domain of the 7 scrambling module) is the reason that caused the failure on board.   Because I used set_clock_uncertainty to hide that violation before, so it actually fails on board. And after the 2nd time I gave a even more relaxed set_clock_uncertainty(from 0.35 of the first time to 1.25), the tool generated a even worse results and yields more failure on board.   SO how could i fix this setup violation?   Thanks a lot!

[Altera_Forum]

Using both edges of same clock in FPGA is problematic and leads to timing paths which cannot or very difficult to define. 

Therefore, for my opinion, if you really must use both edges, better practice is to create 2 different posedge clocks with 180 degrees shift between them, using PLL.

[Altera_Forum]

I am not saying don't worry about existing violations... 

I am saying concluding from results is misleading if violations do occur.   Your clock uncertainty from .3 to 1.2 is not relaxing but more constraining. I do believe using both edges is problematic but I assume tool will detect timing errors across. However I believe you may pass timing yet sample the data wrongly across edge to edhe transfer. Thus a functional simulation may fail. You may not noticed that unless you use same input pattern.

[Altera_Forum]

--- Quote Start ---  Using both edges of same clock in FPGA is problematic and leads to timing paths which cannot or very difficult to define. Therefore, for my opinion, if you really must use both edges, better practice is to create 2 different posedge clocks with 180 degrees shift between them, using PLL.  --- Quote End ---    This makes no sense whatsoever. It is perfectly acceptable to use both edges of a clock in FPGAs and it is not necessary to use two separate clocks of opposite phases (if this were true, DDR wouldn't work). If properly constrained, TimeQuest will time all paths properly.  Some suggestions:  - Check your Uncontrained Paths report in TimeQuest. If all your paths are not constrained, then this could be the cause of your failure.  - Check your Ignored Constraints report in TimeQuest. If for some reason any of your constraints are being ignored, you could have failures that you think are being timed properly.  - Run the Design Assistant. If you have any Critical or High Violations, this could be the cause of your failure.