Presentation is loading. Please wait.

Presentation is loading. Please wait.

Timing constraints: Are they constraining designs or designers?

Similar presentations


Presentation on theme: "Timing constraints: Are they constraining designs or designers?"— Presentation transcript:

1 Timing constraints: Are they constraining designs or designers?
Tom Spyrou TAU 2015 3/2015

2 How do designers make timing constraints?
Focus first on flat or block level constraints Designers create clock, input and output arrival times based on a system or block level specification Usually simple to create and don’t change too much Easy to verify and modify Multi-cycle paths Also created by hand from system or block specification If one is missed and the path doesn’t show up in a timing report as critical it may never be fixed. Some over-constraining. Late SDC changes needed for paths that suddenly pop up and need to be fixed Not too scary to add these in late since the path is visible and the clocking easy to analyze False Paths Some are set pro-actively Many are set by the user when an unwanted path shows up as critical The complete set of false paths is never specified Tools to do so fail from the complexity of the problem or from the size of the set of exceptions and their affect on STA runtime and memory These are scary because someone has to sign in blood that the path is always false

3 New additions to syntax for common complex cases
Use cases for path segmentation Study them and look for possibilities For example before –through many multi-cycle paths were constrained with path segmentation Big step forward to have –through Clock Domain Crossings Propose new set_max_skew command

4 CDC Transfer Constraining
Example: FIFO Write -> Read domains Stack Pointer transfer Gray coded transfers ensure 1 bit transitions Need to control datapath delay to be low skew and low delay for clock domain crossing (CDC) paths in_wr_ptr_gray altera_std_synchronizer_bundle D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > din_s1 Clock tree A Clock tree B

5 CDC Transfer Constraining
Many users set_false_path on this transfer set_false_path -to [get_pins {*altera_std_synchronizer:*/d}] Cuts all setup & hold analysis on transfers between clocks A and B Some users used Clock Groups to cut whole domain transfers set_clock_groups -asynchronous -group {A} -group {B} Can’t selectively constrain some paths while leaving others “don’t care” Placement constraints and the assumption of low clock skew allowed this work One example of many creative ways people use SDC Began to fail in newer technologies with higher skew and local clocks routed through LABs in_wr_ptr_gray altera_std_synchronizer_bundle D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > din_s1 Clock tree A Clock tree B

6 Why failures started happening?
Improvements in timing driven P&R take greater liberty in placement and routing of logic elements Routing delay and skew are of no concern to the Fitter because of the false path constraint Higher Fmax demands for clock domains drive tighter timing requirement Increased clock skew on highly utilized designs in_wr_ptr_gray altera_std_synchronizer_bundle D Q > Clock tree A D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > din_s1 Clock tree B

7 altera_std_synchronizer_bundle
Desired Situation Constrain both skew and total wire delay to keep this transfer short, low-skew, and functionally correct for the needs of the interface & system Constrain both clock and data skew together in_wr_ptr_gray altera_std_synchronizer_bundle D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > din_s1 Clock tree A Clock tree B

8 CDC Transfer Constraining - The New Way
The new way: Constrain datapath delay and total bus skew with knowledge of the clocks involved Important changes in Quartus II 15.0 New constraint set_max_skew added New constraint set_net_delay added Lower precedence than set_false_path but higher than everything else Smart options for set_max_skew, set_net_delay Simple case is simple, but command is flexible

9 SDC Precedence insertion
Now in Quartus15.0 Highest precedence set_false_path (unchanged) set_net_delay (raised) set_max_skew (raised) set_clock_groups (lowered) …… Lowest precedence

10 New Exceptions set_max_skew [-fall_from_clock <names>]
[-fall_to_clock <names>] [-from <names>] [-from_clock <names>] [-get_skew_value_from_clock_period <src_clock_period|dst_clock_period|min_clock_period>] [-rise_from_clock <names>] [-rise_to_clock <names>] [-skew_value_multiplier <multiplier>] [-through <names>] [-to <names>] [-to_clock <names>] [<skew>] set_net_delay -from <names> [-max] [-min] <delay>

11 Using New Options for set_max_skew on CDC Busses
set_max_skew -from in_wr_ptr_gray*/q -to din_s1*/d \ -get_skew_value_from_clock_period min_clock_period in_wr_ptr_gray altera_std_synchronizer_bundle D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > D Q > din_s1 Clock tree A Clock tree B


Download ppt "Timing constraints: Are they constraining designs or designers?"

Similar presentations


Ads by Google