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

Timing driven compilation - appears to not balance setup-hold window

Altera_Forum
Honored Contributor II
1,455 Views

I have a problem meeting timing in a cyclone V design with a source synchronous DDR 500Mbps (250MHz clk) input bus. The inputs are constrained with set_input_delay, set_false_path and the clock is setup as recommended in the various guides for DDR constraining including the command "quartus_sta --ssc <revision name>", an433 (https://www.altera.com/en_us/pdfs/literature/an/an433.pdf) and the excellent timequest user guide (http://www.alterawiki.com/uploads/3/3f/timequest_user_guide.pdf) by RYSC. The timing relations looks ok - the right edges are in play when looking at timing analyzer waveforms, except for the balancing of setup-hold margins: Some are slightly negative, but the other margin is positive, so delay adjustments can tighten this up. 

 

I do a multi corner compilation with these special options 

set_global_assignment -name TIMEQUEST_MULTICORNER_ANALYSIS ON set_global_assignment -name OPTIMIZATION_MODE "HIGH PERFORMANCE EFFORT" set_global_assignment -name ROUTER_TIMING_OPTIMIZATION_LEVEL MAXIMUM set_global_assignment -name OPTIMIZE_HOLD_TIMING "ALL PATHS" set_global_assignment -name OPTIMIZE_MULTI_CORNER_TIMING ON set_global_assignment -name FITTER_EFFORT "STANDARD FIT" set_global_assignment -name PHYSICAL_SYNTHESIS_EFFORT EXTRA 

 

The result indicates as mentioned, that the different inputs have different su-ho margins. Some inputs would benefit from adding delay in the data path to improve hold time slack at the expense of setup slack, others would benefit from less data delay to improve setup slack at the expense of hold slack. 

If I use the "locate in resource property editor" command to see the properties of the different bus inputs, I can see, that they are all assigned the same delay in the D1 and D3 delay blocks. Delays added in the data paths is 606ps(D1) 3998ps(D3). There is both room for increasing the delay and for reducing the delay here. 

 

This is what surprises me: why does the timing driven complation not adjust these delays individually to better center the su-ho window?  

Am I missing an important compile option or do I have to manually adjust these delays to balance su-ho margins? 

 

Thanks
0 Kudos
2 Replies
Altera_Forum
Honored Contributor II
740 Views

When multi corner compile is on, the slacks are adjusted according to all timing models - slow fast, high, low temperature. So looking at only the result for one models timing, this may not appear optimized because other models may have contradicting requirements. In multi corner mode, a global compromise is taken.

0 Kudos
Altera_Forum
Honored Contributor II
740 Views

 

--- Quote Start ---  

When multi corner compile is on, the slacks are adjusted according to all timing models - slow fast, high, low temperature. So looking at only the result for one models timing, this may not appear optimized because other models may have contradicting requirements. In multi corner mode, a global compromise is taken. 

--- Quote End ---  

 

 

as far as I am aware the timing tool does not target balanced slack. It targets a timing pass for all corners. You can try slow clock and see. 

 

TQ however advises on balanced slack at io since corners are less predictable.
0 Kudos
Reply