Quartus® Prime Pro Edition User Guide: Timing Analyzer

ID 683243
Date 11/26/2024
Public
Document Table of Contents

2.3.7. Using Fitter Overconstraints

Fitter overconstraints are timing constraints that you adjust to overcome modeling inaccuracies, mis-correlation, or other deficiencies in logic optimization.
You can overconstrain setup and hold paths in the Fitter to enable more aggressive timing optimization of specific paths.

One typically writes overconstraints that apply only during the Fitter, with a conditional statement that checks the name of the executable that is reading the .sdc file. The following example shows a conditional statement that applies an overconstraint during the Fitter.

Note: Fitter overconstraints generally require Fitter targets. For this reason, you use conventional SDCs (non SDC-on-RTL) for specification. SDC-on-RTL constraints do not support targeting specific Compiler stages.
# Example Fitter overconstraint targeting specific nodes
if { $::TimingAnalyzerInfo(nameofexecutable) eq "quartus_fit"} {
  set_max_delay -from ${my_src_regs} -to ${my_dst_regs} 1ns
}

One typically applies overconstraints because a particular path (or set of paths) requires more than the default optimization effort from the Fitter. Therefore, overconstraints typically specify particular node or register names in the path or paths that require extra optimization.

Other Overconstraint Combinations

You can apply timing constraints to specific stages of the Compiler, in addition to the Fitter as described above. The following table shows different combinations of compile stages and the conditional expression that applies those constraints during the stage or stages.

Table 13.  Overconstraint Combinations
Compile Stages Tcl Condition Notes
Fitter if { $::TimingAnalyzerInfo(nameofexecutable) eq "quartus_fit" } Applies constraints during entire Fitter stage. Use for fitter overconstraints with devices that do not support Hyperflex® architecture.
Signoff timing if { $::TimingAnalyzerInfo(nameofexecutable) eq "quartus_sta" } Applies constraints during timing analysis. This condition is uncommon. Typically you apply timing analysis constraints during the entire compile flow. If you apply overconstraints with an expression conditioned on the name of an executable, ensure that is the only applicable executable where the constraints should apply. For example, to apply during signoff timing and power analysis, check the executable name against quartus_sta and quartus_pow.
Plan, Place, and Route if { ! [is_post_route] } Applies constraints during the Plan, Place, and Route stages in devices that support the Hyperflex® architecture. Use for fitter overconstraints .
Retime (HyperRetimer), Finalize, Signoff timing if { [is_post_route] } Applies constraints after the Route stage completes in devices that support the Hyperflex® architecture. This combination of stages is uncommon. Typically you apply timing analysis constraints during the entire compile flow.
Retime (HyperRetimer) and Finalize if { [is_post_route] && $::TimingAnalyzerInfo(nameofexecutable) eq "quartus_fit" } Applies constraints during Retiming and Finalize stages in devices that support the Hyperflex® architecture. This combination of stages is uncommon.

Overconstraints for Hyperflex® Architecture Designs

For devices that support the Hyperflex® architecture, such as Stratix® 10 and Agilex™ FPGA portfolio devices, timing constraints that apply to particular node or register names prevent the Hyper-Retimer from optimizing paths containing those nodes or registers.

Because the Hyper-Retimer is component of the Fitter, an overconstraint that conditionally applies during the Fitter is counter-productive during the Hyper-Retimer portion of the Fitter. The overconstraint actually prevents the optimization instead of focusing the optimization effectively.

When designing for the Hyperflex® architecture, use the is_post_route Tcl function form of conditional statement to apply the overconstraint during placement and routing but not during the Hyper-Retimer. is_post_route allows you to apply overconstraints and adjust slack for stages of the Fitter, such as Plan, Place, and Route. is_post_route also allows post-route retiming via the Hyper-Retimer without affecting sign-off timing analysis.

# Example Fitter overconstraint targeting specific nodes (allows for post-route retiming)
if { ! [is_post_route]} {
  set_max_delay -from ${my_src_regs} -to ${my_dst_regs} 1ns
}

Overconstraints for Designs that Target All Other Device Families

You can assign Fitter overconstraints that check the name of the current executable, (either quartus_fit or quartus_sta) to apply different constraints for Fitter optimization and sign-off timing analysis.

set fit_flow 0
if { $::TimingAnalyzerInfo(nameofexecutable) == "quartus_fit" } {
   set fit_flow 1
}
if {$fit_flow} {
  # Example Fitter overconstraint targeting specific nodes (restricts retiming)
  set_max_delay -from ${my_src_regs} -to ${my_dst_regs} 1ns
}