Hello, In my design I keep getting hold time violation warnings. "From Node" and "To Node" in the TimeQuest indicate the same signal.

A few things: 1) for a hold analysis, you should be looking at the fast timing model. 2) Your report_timing command is looking at all paths latched by clk[0]. Is this what you intend to look at? I would want to see you scroll down in that data path tab to try to figure out why the from and to nodes are the same. I would also want to see your .sdc, and your clock and clock summary reports. It's hard to diagnose with what you have here.

One way to resolve Hold issues, is to phase shift your clock. If the design uses a PLL, then you can phase shift the clock by a few degrees and see if the hold violations are resolved. I had a similar kind of issue with Hold violations in my Qsys design. I then shifted the generated clocks by 90 and re-compiled and the hold violations were gone, did see a better slack margin as well as Fmax of the design also went up.

Thank you @sstrell​ ,

1. Sure, I get this warnings for fast as well as for slow models.
2. Yes, clk[0] is my system clock. See attached scrolled down of the data arrival and the data required paths, the .sdc file and the clock report.

Thank you!

This is the scrolled down of the data arrival and the data required paths.

And this is the .sdc file

This is the .sdc file

Thank you @Abe​ , I just have tried to change the phase by 90 deg., got a different result, but the hold warnings still here... I'll try different phases.

I don't really expect to see hold violations, there is a problem here and I can't figure out what could it be.

Thank you.

Assuming the 100 MHz clock is driving the "upstream" and "downstream" devices this FPGA is connected to, you should have a separate virtual clock constraint and reference it in you set_input[output]_delay constraints and use derive_clock_uncertainty to get the most accurate uncertainties on I/O:

create_clock -name clock_in_vir -period 10

create_clock -name clock_out_vir -period 10

set_input_delay -clock clock_in_vir ...

set_output_delay -clock clock_out_vir ...

Aside from that, looking at the timing reports, these failures seem to be feedback loops in your design. I'm not sure why you have such loops, but it might be useful to look back at your code to try to understand them. You can cross-probe from the timing reports by right-clicking a failing timing path and select Locate Path. It might be helpful to see these paths in the Technology Map Viewer to understand what they're connected through and what they're doing.

Thank you @sstrell​ , I'm updating the .sdc file.

I checked the paths with the Technology Map and the failures really caused by feedback loops. But these loops are in different Altera's IPs code - FIFO, EPCS controller so it is not clear what they are doing exactly...

I'll try to understand better what happens.

Thank you for your help.

Hi ACoga,

Have you try to add delay in the path?

Thanks.