Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Timing constraints: Are they constraining designs or designers? Tom Spyrou TAU 2015 3/2015."— Presentation transcript:

1 Timing constraints: Are they constraining designs or designers? Tom Spyrou TAU /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  Late SDC changes needed for paths that suddenly pop up and need to be fixed These are scary because someone has to sign in blood that the path is always false 2

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 3

4 CDC Transfer Constraining 4 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 DQ > DQ > Clock tree AClock tree B DQ > DQ > DQ > DQ > DQ > DQ > DQ > DQ > in_wr_ptr_gray DQ > DQ > DQ > DQ > DQ > altera_std_synchronizer_bundle din_s1

5 CDC Transfer Constraining 5 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} –Cuts all setup & hold analysis on transfers between clocks A and 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 DQ > DQ > Clock tree A Clock tree B DQ > DQ > DQ > DQ > DQ > DQ > DQ > DQ > DQ > DQ > DQ > DQ > DQ > altera_std_synchronizer_bundle din_s1 in_wr_ptr_gray

6 Why failures started happening? 6 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 DQ > Clock tree B DQ > DQ > DQ > DQ > DQ > DQ > DQ > DQ > DQ > altera_std_synchronizer_bundle DQ > Clock tree A DQ > DQ > DQ > DQ > din_s1 in_wr_ptr_gray

7 Desired Situation 7 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 DQ > DQ > Clock tree AClock tree B DQ > DQ > DQ > DQ > DQ > DQ > DQ > DQ > DQ > DQ > DQ > DQ > DQ > altera_std_synchronizer_bundle din_s1 in_wr_ptr_gray

8 CDC Transfer Constraining - The New Way 8 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 9 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 10 set_max_skew [-fall_from_clock ] [-fall_to_clock ] [-from ] [-from_clock ] [-get_skew_value_from_clock_period ] [-rise_from_clock ] [-rise_to_clock ] [-skew_value_multiplier ] [-through ] [-to ] [-to_clock ] [ ] set_net_delay -from [-max] [-min] [-from ] [-to ]

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


Download ppt "Timing constraints: Are they constraining designs or designers? Tom Spyrou TAU 2015 3/2015."

Similar presentations


Ads by Google