--- Quote Start ---
launch clock = clk_ff
latch clock = inst|the_pll_main|the_pll|altpll_component|pll|clk[0]
So they are different clock domains. This doesn't necessarily mean there's a problem, but often is. So looking at the first failing path:
The launch edge time is 41.666ns and the latch edge time is 44.440ns, which means you have less than 3ns to meet the setup timing.
But the strange numbers are probably the biggest clue that something is wrong. I don't know the frequencies of these two clocks, but assume they are not related. For example, if the clocks were both 10ns, you would generally see a launch at time 0ns and a latch at time 10ns, for a 10ns setup requirement. But if the latch clock had a period of 9ns, then TimeQuest would find the point in time where they have the most restrictive setup requirement, which would be a launch at time 80ns and a latch at time 81ns, for a 1ns setup requirement.
So my guess is these domains should not be in the same group in your set_clock_groups command.
Now, I don't have the design, but I believe your earlier statement said that the clk_ff is the input clock pin to this PLL. So why aren't they related? If the PLL is creating a timing requirement that is not easily related to the main clock, that can happen. For example, if you have a 10ns input clock, but the output clock is 3/2 of that frequency(66.66ns), then even though they originate from the same source, they can't be related in such a way for you to do synchronous transfers between them.
So the final part is, does the design work if you don't do timing analysis between these domains, as there is obviously a path that exists. From the looks of it, I believe this is going to be all right, but to be perfectly honest I don't know for sure(I don't have much experience with Nios). It looks like they are register to register paths with no combinatorial logic in between, and is probably doing some sort of handshaking mechanism(i.e. transfer the data over, then hand-shake to say it is okay, which is a slow interface and has many clock cycles to meet timing).
Anyway, hope that helps.
--- Quote End ---
Thanks for taking the time. Every bit helps. I really didn't expect it would take longer to specify timing that to design the project.
clk_ff is indeed an external 24mhz clock which ONLY goes to a pll to produce clk0 (15/4=90mhz nios core) and clk1 (90mhz sdram). There are no explicit paths to/from clk_ff other than the one pll input. In SOPC clk_ff is only assigned to the pll, everything else uses clk_core, clk_sdram or clk_event (a different pll domain). Who knows what Quartus is doing behind the scenes here. I don't have the full license so I probably can't easily find out. My 2nd external clk input (50mhz) is treated in an almost identical way (but simpler ratios 1/1 and 1/5) and it does not show violations in the summary.
In kwalt's example which I followed, he also shows the pll input being grouped with the pll outputs, but his pll ratios were simpler.
I'll try having 3 clk groups instead of 2.
Honored Contributor
