Most of the signals relate to NIOS. The design based on a single 100MHz clock. There is an additional clock 12.5MHz generated in pll in QSYS and connected only to epcs flash controller. I've seen similar connection of the epcs flash controller in some examples.
I get no setup time violations and functionally everything works fine. But I can't get rid of hold time violation warnings. See the attached TimeQuest Report. Please help.
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. 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 ,
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.
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.
Thank you very much @KhaiY_Intel , great explanations. I'll try to overconstrain, but it looks that I have a problem with some settings. The warnings don't look real - all of them from and to the same node...