- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page