Timequest question using gated clocks

[Altera_Forum]

Hello, I'm working on a design under Quartus II v12.1, and I have one question about Timequest. 

 I want to use a slow gated clock, which is generated from a synchronized design (cf. image in attachement). The problem is that when the data (slow_dat) is moving at the same time than the clock (slow_clock), the output is garbage.  I though that there was possible to tell to timequest to constraint the design so that the fitter will let enough time between sclk_b and sdat_b to be sure the setup time of the output register will be respected. So I entered something like this in timequest/.sdc file : # Main clock create_clock -name {clk16384} -period 61.035 -waveform { 0.000 30.517 } [get_ports {clk16384}] # Gated clock created from a register (which name is FILT_resync_in2) create_generated_clock [get_registers {resyncsig:FILT_resync_in2|DOUT}]   -name sclk_b   -source [get_ports {clk16384}]   -master_clock [get_clocks {clk16384}] # Generate clock uncertainties from the design derive_clock_uncertainty   It seems that there is still garbage on the output port. I would like to know what is wrong in my approach.  Thanks, Jérôme  Nota : I have solved this problem by insuring that the data will not move on the clock rising edge, but I would like to understand why timequest didn't work as expected.

[Altera_Forum]

run: 

report_timing -setup -npaths 10 -detail full_path -to_clock sclk_b -panel_name "s: -> clk(sclk_b)"  First, Data Required Clock Path trace all the way back to the same source as the Data Required? That's usually the biggest mistake, when there's something wrong with the generated_clock assignment. Also, is slow_clk asynchronous to clk16384? If so, that first register will go metastable now and then, and you don't pipeline it to allow that metastability to settle before using it as a clock, so that could be a problem. (Most of the time this will work, and the metastability will only occur every once in a while, so you're failure rate might help determine if that's an issue)

[Altera_Forum]

Thanks for your quick answer ! Yes 'slow_clk' is asynchronous to clk16384, but in fact there are 3 registers on slow_clk and slow_dat paths to insure metastability is not propagated. So we can consider that the signals are synchronous to clk16384. 

 Your command 'report_timing' is very interesting. I also tried the command :  report_timing -setup -npaths 10 -detail full_path -from_clock clk16384 -to_clock clkcoef -panel_name "s: clk(clk16384) -> clk(clkcoef)"  (note that in my design the gated clock name is 'clkcoef' instead of 'sclk_b').  It seems that the timing is ok, but it is difficult to understand because the output signal is in fact a fir IP from Quartus, and some sources are encrypted, such as the 'shift_in:in_coef' block.

[Altera_Forum]

As far as I can see, Quartus just sucks whenever you generate a clock from logic aka divided clock (which seems to be what you are doing from the picture). To close timing at even relatively modest speeds on the Arria V series, I had to switch over to using clock enables for everything. 

 This sucks if your design only has a couple of high speed transitions and most of the logic is working at a much slower speed since the maximum frequency clock spine has to be routed to everything and costs power. However, Quartus/TimeQuest always seems to wind up with a massive uncertainty that it can't deal with when it routes a divided clock through a clock buffer.  I suspect that you could tweak this by hand to force it to work, but I suspect it is a fool's errand. I have learned over many years that fighting a broken tool is generally more work than adjusting the design to live within the limitations of the tool.

[Altera_Forum]

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. 

 As for Quartus sucking, I've actually found it pretty good. The problem tends to be pretty difficult though. For example, I put a 10ns hold requirement on a 20ns clock, and it couldn't meet timing. That's because it needed to meet across all timing models, and so a 10ns delay in the fast corner can be longer than 20ns in the slow. I ended up changing the clock to 40ns(it was just an experiment), and the router successfully added ~20ns of delay in the slow corner, which met the 10ns requirement in the fast corner. It basically routed once around the chip to do this. When you have lots of paths crossing domains with clock skew, and if the setup requirement is tight, this can blow up. If the setup requirement isn't tight, it can add a lot of routing, which wastes valuable resources and power.   I do agree the on-die variation in the timing models sucks, although everything I hear is that it's real. But it absolutely kills timing between domains, and makes the fitter look bad. In the end, going with an enable is usually much better, as you're fighting something FPGAs aren't designed for. (I have seen designs that required gated clocks, and implement more than 30 in a single design, but it's not fun).

[Altera_Forum]

--- 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