Using both edges of a clock

There is something odd with that clock.

In first place, the input pad of the clock has a fanout of 32. This is already odd, because a global external clock has normally a single fanaout, to the clock control block.

In second place, according to that report it would seem that the clock is routed globally to the source register, but not globally to the destination one. You can get additional routing details with the parameter "-show_routing" on the timing report.

Check the clock paths with the post-fit technology viewer as well.

--- Quote Start ---

There is something odd with that clock.

In first place, the input pad of the clock has a fanout of 32. This is already odd, because a global external clock has normally a single fanaout, to the clock control block.

In second place, according to that report it would seem that the clock is routed globally to the source register, but not globally to the destination one. You can get additional routing details with the parameter "-show_routing" on the timing report.

Check the clock paths with the post-fit technology viewer as well.

--- Quote End ---

Hi vjAlter,

You are right. The post-fit technology viewer shows that the clk for the destination register is connected to the output of the IO_IBUf, not the output of the CLKCTRL. Following that clue I found that I actually didn't explicity define the clk_7m as a global clock, only defined it as a clock in timequest. The compiler automatically prompted it as global signal but it looks like the compiler only prompted part of the network (is this possible?). I will set it as a global clock explicity and give it a try.

Thanks again!

Hua

I don't think an explicit global assigment is the solution to the root of the problem. Quartus normally won't promote a clock just to some registers.

You should investigate what is causing this. Check Quartus compiler warnings, fix all those unconstrained clocks, run the assistant for correct synchronous design, etc.

--- Quote Start ---

I don't think an explicit global assigment is the solution to the root of the problem. Quartus normally won't promote a clock just to some registers.

You should investigate what is causing this. Check Quartus compiler warnings, fix all those unconstrained clocks, run the assistant for correct synchronous design, etc.

--- Quote End ---

Just did a compile with all the clocks set to global explicitly and the timing violation was gone. But it may take a few compilation to find out if this problem is indeed gone.

Thanks again.

As I know the main reason of hold violations is that data arrives faster than clock. In FPGAs it is rare due to the built-in delays of the logic blocks and routing resources.

However, excessive delay on the clock line can cause hold violations. Some synthesis tools may correct this situation, and some might not. I am not sure about Quartus II native syntheser.