Random results on FPGA

[Altera_Forum]

Hello, 

 I'm using altera devices for about 10 years with quartus or quartus + synplify pro. I'm currently struggling for about a month !!! on this issue: Using the same netlist from synplify pro, the same timing constraints, and doing the place and route with quartus, I can get total different results on FPGA (stratix III): fully working, or failing on first HW accesses. The IP in the FPGA uses a lot of clock gating and I think that Quartus is not doing a good timing analysis (timequest reports no timing violations and the design is fully constrained), leading to such random results.  Did you ever face such problem at your place ?  Metastability report in timequest reports no problem.  Resets are ok.  Cooling the FPGA does not change anything.  I never faced such situation before.   I need help !  Alex

[Altera_Forum]

that was the root cause of the issue. 

  adding this uncertainty of 500 ps in my sdc solves the unpredictable results.  set_clock_uncertainty -add -from [get_clocks *] -to [get_clocks *] -setup 0.5 set_clock_uncertainty -add -from [get_clocks *] -to [get_clocks *] -hold 0.5   "Clock uncertainty" is the interval of confidence around the ideal clock value, such that the measured value is always within the stated interval. Common sources of clock uncertainty include clock jitter, duty cycle distortion, and phase shift error. Due to these sources, clock uncertainty must be factored in to guard against deep submicron effects that are not explicitly reflected in the timing models.  PLL phase error, PLL jitter, I/O buffer, clock network noise, core noise, On chip variation (die process, temperature), crosstalk between nets.   Wich is specially true for my complex design with more thqn 100 clocks and plenty of clock gating.

[Altera_Forum]

Good, but using clock uncertainty to solve the problem, still seems to mean Quartus II fitting process does not smart enough. 

It might still be good for you to file a service request for Altera to look into what they can do better

[Altera_Forum]

--- Quote Start ---  Good, but using clock uncertainty to solve the problem, still seems to mean Quartus II fitting process does not smart enough. It might still be good for you to file a service request for Altera to look into what they can do better  --- Quote End ---    Quartus is doing a proper job.  clock uncertainty cannot be predicted and is design/fpga yield dependant.  I'm currently in contact with them to get the excel sheet to calculate the real clock uncertainty, as they do it for hardcopy devices.

[Altera_Forum]

Well, again, there is another root cause of the problem ...

[Altera_Forum]

I found it this time. 

Problem was due to the internal clock definiton of the cpu clock domain. Doing that was cutting io, reset and other clock domains connection timing analysis. By removing those clock definition, I could see plainty of big timing violations (like 10 ns). Now it is stable. So when it was working it was by luck due to the place and route positioning.

[Altera_Forum]

Yes, so it has to be always be careful with the SDC constraint, it is among the biggest challenge to debug when it gives random result. Well, great work to find out the root cause

[Altera_Forum]

yeah, for some reason one clock that i define in a particular clock domains amongst otthers clock in the same domain, is breaking the timing path. 

Will look furter into that one Today.

[Altera_Forum]

--- Quote Start ---  yeah, for some reason one clock that i define in a particular clock domains amongst otthers clock in the same domain, is breaking the timing path. Will look furter into that one Today.  --- Quote End ---    Anymore on your exciting progress.

[Altera_Forum]

Yes. 

Got it this time ;-) I changed my clock constraint, I removed all gated clock definition because using create_generated_clock or create_clock of those internal clock was cutting the timing analysis for those clocks that needs to be clocked balanced. Adding them in hte same clock group was not helping.  I now just define the source clock node and quartus is able, by itself, to properly figure out the clock routing and properly balance the gated clocks.  I really think it is the end of story now ;-)

[Altera_Forum]

I can confirm that the root cause of the problem is found. 

I'm very happy now ;-)

[Altera_Forum]

rtl compiler from cadence behaves the same

[Altera_Forum]

Glad to hear that :)