--- Quote Start ---
Your paths easily meet setup, so I don't think that's the problem. I would also check hold, especially in the fast corner. There may be a logical issue, i.e. if you have 3 registers on slow_clk and slow_data path, I hope slow_clk is supposed to transition long after slow_data_path has settled, as their sources are asynchronous and you can guarantee what cycle they get a value. As buzmeg says, I would not have a signal like filt_resync be used as a clock. It's not meant to be a clock, and should probably be an enable or something. And it doesn't hurt your power or anything, since your base signal is already on a global.
--- Quote End ---
Hello buzmeg and Rysc ! Yes I totaly agree that using slow_clk as an enable signal is the best solution, and the first thing to do is to avoid gated clocks in FPGA designs, in general. The problem in my case is that the code was automatically generated by a Quartus IP (FIR filter, coefficients loading). The other solution (the one I choose) was to ensure that slow_data doesn't change on slow_clock edge. This is what I have implemented and it works fine. My question was more to understand why Timequest did not manage this problem, despite the fact that I tell him that there was a gated clock. So to conclude we can say that Timequest is unable to manage gated clocks ?
Cheers,
Jérôme
Honored Contributor
