Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16556 Discussions

Hold violation on source synchronous clocks

Altera_Forum
Honored Contributor II
1,608 Views

Timing is failing with Hold time negative slack of (-0.098) when going from a 20MHz to a 100MHz clock domain (both clocks are synchronous and generated from the same PLL). This is a cyclone V design which is using upwards of 80% resource usage.  

 

I have not added any multicycle path exceptions here. 

 

timing will occasionally pass or fail at different paths with similar hold violations. 

 

Please see the screenshot and worst case path report attached.  

 

What do you suggest for resolving this?
0 Kudos
5 Replies
Altera_Forum
Honored Contributor II
512 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
512 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
512 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
512 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
512 Views

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?
0 Kudos
Reply