Hold violation on source synchronous clocks

Hi there,

Probably the best way is to resolve this by setting a multi cycle path but you need to take care of it with clock enables or some other functional technique.

Another thing, did you try the Timing Optimization Advisor that the Quartus tool provides to optimize for hold timings?

Thanks,

Victor

Thanks Victor.

I am using Clock enables, but I was reading Rysc's TimeQuest user guide and it seemed to suggest that when you open the window, you're generally relaxing the setup relationship but the hold relationship stays at zero, so I was a confused as to whether or not clock enables provide immunity from hold violations due to excessive clock skew for example.

Also, when using clock enables, are you supposed to keep the clock enable asserted for the duration of the new data valid window?

thanks,

Peter

Is the path fully inside a DSP block? If so, the router can't add delay and the clock skew may be too large. If that's the case, please try to have all the DSP registers use the same clock domain and then transfer between domains in the fabric.

If the path is in the fabric, you could overconstrain it. Add to your .sdc:

if {$::quartus(nameofexecutable) != "quartus_sta"} {

set_min_delay -from [get_clocks REGCLK] -to [get_clocks SCLK] 0.2

}

This constraint will be seen by the fitter so it tries to add more delay, but in timing sign-off you'll have the correct 0ns analysis.

I suggest to try the routing optimizations for hold timings if you have sync registers between the clock domains.

In my previous post I meant to use clock enable in the 100MHz domain synced to the negative edge of the 20MHz, thus you'll have 2/20MHz delay. However, this is a functional change and I don't know if it would have some impact on your design.

Thanks,

Victor

Thanks for your response and for your excellent user guide.

The path is not inside a DSP block. The thing is, I'm not sure if I need to over constrain it. The DSP block is running at the slower 20MHz clock and then the result is valid once every 50 clocks of the 20MHz clock. and then the result needs to be clocked into the faster system clock at 100 MHz. So I'm using the data valid as a clock enable but I'm trying to figure out if that means that it's safe to relax both the setup and hold constraints?

Also, do I need to extend the data valid (clock enable) to be asserted for the entire width of the expanded window?