Quartus® Prime Pro Edition User Guide: Timing Analyzer

Download PDF
ID 683243
Date 11/26/2024
Public
Document Table of Contents
Document Table of Contents x
Answers to Top FAQs 1. Timing Analysis Introduction 2. Using the Quartus® Prime Timing Analyzer 3. Troubleshooting Common Timing Issues A. Quartus® Prime Pro Edition User Guides
1. Timing Analysis Introduction x
1.1. Timing Analysis Basic Concepts 1.2. Timing Analysis Overview Document Revision History
1.1. Timing Analysis Basic Concepts x
1.1.1. Timing Path and Clock Analysis 1.1.2. Clock Setup Analysis 1.1.3. Clock Hold Analysis 1.1.4. Recovery and Removal Analysis 1.1.5. Multicycle Path Analysis 1.1.6. Metastability Analysis 1.1.7. Timing Pessimism 1.1.8. Clock-As-Data Analysis 1.1.9. Multicorner Timing Analysis 1.1.10. Time Borrowing
1.1.1. Timing Path and Clock Analysis x
1.1.1.1. The Timing Netlist 1.1.1.2. Timing Paths 1.1.1.3. Data and Clock Arrival Times 1.1.1.4. Launch and Latch Edges
1.1.5. Multicycle Path Analysis x
1.1.5.1. Multicycle Clock Hold 1.1.5.2. Multicycle Clock Setup
1.1.10. Time Borrowing x
1.1.10.1. Time Borrowing Limitations 1.1.10.2. Time Borrowing with Latches 1.1.10.3. Enabling Time Borrowing Optimization
2. Using the Quartus® Prime Timing Analyzer x
2.1. Using Timing Constraints throughout the Design Flow 2.2. Timing Analysis Flow 2.3. Applying Timing Constraints 2.4. Timing Constraint Descriptions 2.5. Timing Report Descriptions 2.6. Scripting Timing Analysis 2.7. Using the Quartus® Prime Timing Analyzer Document Revision History 2.8. Quartus® Prime Pro Edition User Guide: Timing Analyzer Archive
2.2. Timing Analysis Flow x
2.2.1. Step 1: Specify General Timing Analyzer Settings 2.2.2. Step 2: Specify Timing Constraints 2.2.3. Step 3: Run the Timing Analyzer 2.2.4. Step 4: Analyze Timing Reports
2.2.2. Step 2: Specify Timing Constraints x
2.2.2.1. Specifying SDC-on-RTL Timing Constraints 2.2.2.2. Specifying Conventional SDC Timing Constraints 2.2.2.3. Specifying Synthesis-Only SDC Timing Constraints
2.2.3. Step 3: Run the Timing Analyzer x
2.2.3.1. Running Post-Synthesis Early Timing Analysis 2.2.3.2. Running Post-Fit Timing Analysis
2.2.3.2. Running Post-Fit Timing Analysis x
2.2.3.2.1. Setting the Operating Conditions for Timing Analysis 2.2.3.2.2. Promoting Critical Warnings to Errors
2.2.4. Step 4: Analyze Timing Reports x
2.2.4.1. Cross-Probing with Design Assistant 2.2.4.2. Launching Design Assistant from Timing Analyzer 2.2.4.3. Locating Timing Paths in Other Tools 2.2.4.4. Correlating Constraints to the Timing Report
2.2.4.1. Cross-Probing with Design Assistant x
2.2.4.1.1. Cross-Probing from Design Assistant to Timing Analyzer
2.3. Applying Timing Constraints x
2.3.1. Recommended Initial Conventional SDC Constraints 2.3.2. Example Circuit and Conventional SDC File 2.3.3. SDC File Precedence 2.3.4. Iteratively Modifying Constraints 2.3.5. Applying Entity-Bound Timing Constraints 2.3.6. Constraining Design Partition Ports 2.3.7. Using Fitter Overconstraints
2.3.1. Recommended Initial Conventional SDC Constraints x
2.3.1.1. Create Clock (create_clock) 2.3.1.2. Derive PLL Clocks (derive_pll_clocks) 2.3.1.3. Derive Clock Uncertainty (derive_clock_uncertainty) 2.3.1.4. Set Clock Groups (set_clock_groups)
2.3.5. Applying Entity-Bound Timing Constraints x
2.3.5.1. Using Entity-Based SDC-on-RTL Constraints 2.3.5.2. Using Entity-Bound SDC Files
2.3.5.1. Using Entity-Based SDC-on-RTL Constraints x
2.3.5.1.1. Targeting Constraints to Module Inputs and Outputs 2.3.5.1.2. Entity Based SDC-on-RTL Constraint Scope 2.3.5.1.3. Automatic Scope Example for SDC-on-RTL 2.3.5.1.4. Manual Scope Example for SDC-on-RTL
2.3.5.2. Using Entity-Bound SDC Files x
2.3.5.2.1. Entity-Bound SDC Constraint Scope 2.3.5.2.2. Automatic Scope Entity-bound Constraint Example 2.3.5.2.3. Manual Scope Entity-bound Constraint Example 2.3.5.2.4. Exporting a Design Partition with Entity-bound Constraints 2.3.5.2.5. Importing a Design Partition with Entity-bound Constraints
2.3.6. Constraining Design Partition Ports x
2.3.6.1. Timing Analysis of Imported Compilation Results
2.4. Timing Constraint Descriptions x
2.4.1. Clock Constraints 2.4.2. I/O Constraints 2.4.3. Delay and Skew Constraints 2.4.4. Timing Exception Constraints 2.4.5. Delay Annotation
2.4.1. Clock Constraints x
2.4.1.1. Creating Base Clocks 2.4.1.2. Creating Virtual Clocks 2.4.1.3. Creating Generated Clocks (create_generated_clock) 2.4.1.4. Deriving PLL Clocks 2.4.1.5. Creating Clock Groups (set_clock_groups) 2.4.1.6. Accounting for Clock Effect Characteristics 2.4.1.7. Constraining CDC Paths
2.4.1.1. Creating Base Clocks x
2.4.1.1.1. Automatic Clock Detection and Constraint Creation
2.4.1.2. Creating Virtual Clocks x
2.4.1.2.1. Specifying I/O Interface Uncertainty 2.4.1.2.2. I/O Interface Clock Uncertainty Example
2.4.1.3. Creating Generated Clocks (create_generated_clock) x
2.4.1.3.1. Clock Divider Example (-divide_by) 2.4.1.3.2. Clock Multiplexer Example
2.4.1.5. Creating Clock Groups (set_clock_groups) x
2.4.1.5.1. Exclusive Clock Groups (-logically_exclusive or -physically_exclusive) 2.4.1.5.2. Asynchronous Clock Groups (-asynchronous) 2.4.1.5.3. set_clock_groups Constraint Tips
2.4.1.6. Accounting for Clock Effect Characteristics x
2.4.1.6.1. Set Clock Latency (set_clock_latency) 2.4.1.6.2. Clock Uncertainty
2.4.2. I/O Constraints x
2.4.2.1. Deprecation of the blackbox Argument 2.4.2.2. Input Constraints (set_input_delay) 2.4.2.3. Output Constraints (set_output_delay)
2.4.3. Delay and Skew Constraints x
2.4.3.1. Advanced I/O Timing and Board Trace Model Delay 2.4.3.2. Maximum Skew (set_max_skew) 2.4.3.3. Net Delay (set_net_delay) 2.4.3.4. Data Delay (set_data_delay)
2.4.4. Timing Exception Constraints x
2.4.4.1. Timing Exception Precedence 2.4.4.2. False Paths (set_false_path) 2.4.4.3. Minimum and Maximum Delays 2.4.4.4. Multicycle Paths 2.4.4.5. Multicycle Exception Examples 2.4.4.6. Creating Efficient Timing Exceptions
2.4.4.4. Multicycle Paths x
2.4.4.4.1. Common Multicycle Applications 2.4.4.4.2. Relaxing Setup with Multicycle (set_multicyle_path) 2.4.4.4.3. Accounting for a Phase Shift (-phase)
2.4.4.5. Multicycle Exception Examples x
2.4.4.5.1. Default Multicycle Analysis 2.4.4.5.2. End Multicycle Setup = 2 and End Multicycle Hold = 0 2.4.4.5.3. End Multicycle Setup = 2 and End Multicycle Hold = 1 2.4.4.5.4. Same Frequency Clocks with Destination Clock Offset 2.4.4.5.5. Destination Clock Frequency is a Multiple of the Source Clock Frequency 2.4.4.5.6. Destination Clock Frequency is a Multiple of the Source Clock Frequency with an Offset 2.4.4.5.7. Source Clock Frequency is a Multiple of the Destination Clock Frequency 2.4.4.5.8. Source Clock Frequency is a Multiple of the Destination Clock Frequency with an Offset
2.5. Timing Report Descriptions x
2.5.1. Report Fmax Summary 2.5.2. Report Timing Setup Slack Breakdown On the Extra Info Tab 2.5.3. Report Timing By Source Files 2.5.4. Report Data Delay 2.5.5. Report Net Delay 2.5.6. Report Clocks and Clock Network 2.5.7. Report Clock Transfers 2.5.8. Report Metastability 2.5.9. Report CDC Viewer 2.5.10. Report Asynchronous CDC 2.5.11. Report Logic Depth 2.5.12. Report Neighbor Paths 2.5.13. Report Register Spread 2.5.14. Report Route Net of Interest 2.5.15. Report Retiming Restrictions 2.5.16. Report Register Statistics 2.5.17. Report Pipelining Information 2.5.18. Report Time Borrowing Data 2.5.19. Report Exceptions and Exceptions Reachability 2.5.20. Report Bottlenecks 2.5.21. Check Timing 2.5.22. Report SDC
2.5.13. Report Register Spread x
2.5.13.1. Registers with High Timing Path Endpoint Tension 2.5.13.2. Registers with High Immediate Fan-Out Tension
2.5.20. Report Bottlenecks x
2.5.20.1. Specifying Custom Bottleneck Criteria
2.6. Scripting Timing Analysis x
2.6.1. The quartus_sta Executable 2.6.2. The quartus_staw Executable 2.6.3. Collection Commands
2.6.3. Collection Commands x
2.6.3.1. Wildcard Characters 2.6.3.2. Adding and Removing Collection Items 2.6.3.3. Query of Collections 2.6.3.4. Using the get_pins Command
3. Troubleshooting Common Timing Issues x
3.1. Troubleshooting Asynchronous Clock Domain Crossing (CDC) Timing Issues 3.2. Troubleshooting Reset Domain Crossing (RDC) Timing Issues 3.3. Troubleshooting Common Timing Issues Revision History
3.1. Troubleshooting Asynchronous Clock Domain Crossing (CDC) Timing Issues x
3.1.1. CDC Timing Overview 3.1.2. Identifying CDC Timing Issues Using Design Assistant 3.1.3. Identifying CDC Timing Issues Using Timing Reports 3.1.4. Debug CDC Example 1—Incorrect SDC Definition 3.1.5. Debug CDC Example 2—Additional Logic in the Crossing 3.1.6. Debug CDC Example 3—CDC Depending on Two Simultaneous Clock Domains
3.1.3. Identifying CDC Timing Issues Using Timing Reports x
3.1.3.1. Using Report Clock Transfers to Identify CDC Issues 3.1.3.2. Using Report Asynchronous CDC to Identify CDC Issues 3.1.3.3. Identifying Synchronizer CDC Issues
3.1.3.3. Identifying Synchronizer CDC Issues x
3.1.3.3.1. Reviewing Reports about Synchronizers 3.1.3.3.2. Constraining Synchronizers in CDCs
3.1.4. Debug CDC Example 1—Incorrect SDC Definition x
3.1.4.1. Resolve Violation: 1-Bit Asynchronous Transfer Not Synchronized 3.1.4.2. Resolve Violation: CDC Bus Constructed with Unsynchronized Registers 3.1.4.3. Resolve Violation: Intra-Clock False Path Synchronizer 3.1.4.4. Example 1 CDC Debug Summary
3.1.5. Debug CDC Example 2—Additional Logic in the Crossing x
3.1.5.1. Resolve Violation: Combinational Logic Before Synchronizer Chain
3.1.6. Debug CDC Example 3—CDC Depending on Two Simultaneous Clock Domains x
3.1.6.1. Resolve Violation: Multiple Clock Domains Driving a Synchronizer Chain
3.2. Troubleshooting Reset Domain Crossing (RDC) Timing Issues x
3.2.1. RDC Timing Overview 3.2.2. Debug RDC Example—Asynchronous Reset Is Not Synchronized
3.2.2. Debug RDC Example—Asynchronous Reset Is Not Synchronized x
3.2.2.1. Resolve Violation: Asynchronous Reset Is Not Synchronized
Answers to Top FAQs
1. Timing Analysis Introduction
2. Using the Quartus® Prime Timing Analyzer
3. Troubleshooting Common Timing Issues
A. Quartus® Prime Pro Edition User Guides

2.5.2. Report Timing

The Timing Analyzer's Reports > Timing Slack > Report Timing… command allows you to specify settings to report the timing of any path or clock domain in the design. The equivalent scripting command is report_timing.

Figure 150. Report Timing Report

You can specify diverse options to customize the reporting. You can specify the Clocks and Targets that the report displays, the Analysis Type to run, whether to display Extra Info in the report, and the Output options for the report. For example, you can increase the number of paths to report, add a Target filter, and add a From Clock.

Figure 151. Report Timing Dialog Box (Top Section)
Figure 152. Report Timing Dialog Box (Bottom Section)
Table 24.  Report Timing Settings
Option Description
Clocks From Clock and To Clock filter paths in the report to show only the launching or latching clocks you specify.
Targets Specifies the target node for From Clock and To Clock to report paths with only those endpoints. Specify an I/O or register name or I/O port for this option. The field also supports wildcard characters. For example, to report only paths within a specific hierarchy:
report_timing -from *|egress:egress_inst|* \
     -to *|egress:egress_inst|* -(other options)
When the From, To, or Through boxes are empty, the Timing Analyzer assumes all possible targets in the device. The Through option limits the report to paths that pass through combinatorial logic, or a particular pin on a cell.
Analysis type The Analysis type options are Setup, Hold, Recovery, or Removal. The Timing Analyzer reports the results for the type of analysis you select.
Paths Specifies the number of paths to display by endpoint and slack level. The default value for Report number of paths is 10, otherwise, the report can be very long. Enable Pairs only to list only one path for each pair of source and destination. Limit further with Maximum number of paths per endpoints. You can also filter paths by entering a value in the Maximum slack limit field.
Extra Info Provides additional data that is relevant for diagnosing timing failure root cause, such as setup slack breakdown, and unexpected routing detours caused by congestion and hold time fix-up. Specify whether to include None, Basic, or All extra information in the report. The Extra Info tab data can help you identify potential, unnecessary routing detours, as well as placement or circuit issues that restrict the path fMAX performance. Refer to Setup Slack Breakdown On the Extra Info Tab.
  • All—report includes Extra Info tab that reports extra information for source timing endpoints that pass through the unregistered output of a RAM or DSP block, or for destination timing endpoints that pass through the unregistered input of a DSP block. The Data Path tab includes Estimated Delay Added for Hold and Route Stage Congestion Impact data.
  • Basic—report includes the Extra Info tab but no extra information on the Data Path tab.
  • None—report includes no Extra Info tab or other extra information on the Data Path tab.
Output Specify the path types the analysis includes in output for Detail level:
  • Summary—level includes basic summary reports. Review the Clock Skew column in the Summary report. If the skew is less than +/-150ps, the clock tree is well balanced between source and destination.
  • Path only—displays all the detailed information, except the Data Path tab displays the clock tree as one line item.
  • Path and Clock—displays the same as Path only with respect to the clock.
  • Full path—when higher clock skew is present, enable the Full path option. This option breaks the clock tree into greater detail, showing every cell, including the input buffer, PLL, global buffer (called CLKCTRL_), and any logic. Review this data to determine the cause of clock skew in your design. Use the Full path option for I/O analysis because only the source clock or destination clock is inside the FPGA, and therefore the delay is a critical factor to meet timing.
Show routing Shows routing data in the report.
Split the report by operating conditions For the operating condition timing corners, subdivides the data by each operating condition.
Report panel name Specifies the name of the report panel. You can optionally enable File name to write the information to a file. If you append .htm or .html as a suffix, the Timing Analyzer produces the report as HTML. If you enable File name, you can Overwrite or Append the file with latest data.
Tcl command Displays the Tcl syntax that corresponds with the GUI options you select. You can copy the command from the Console into a Tcl file.
Figure 153. Extra Info Tab

Setup Slack Breakdown On the Extra Info Tab

The Extra Info tab contains other timing metrics to help you diagnose timing closure issues, including Setup Slack Breakdown for the path.

The slack of a path specifies the margin by which the path meets its timing requirement. The setup slack breakdown is a numeric value that the Timing Analyzer calculates from the following timing requirements and path element delays:

Figure 154.  Setup Slack Breakdown Calculations

A path can fail timing requirements for many varied reasons. For example, the clock relationship can be impossibly tight, or there can be excessive routing delays that alone cause failure for the timing path. Calculating the intrinsic margin of a timing path, and then comparing that margin to other delays of the path, can help identify the specific reasons why a path fails its timing requirement.

The Extra Info tab can help you identify potential significant or unexpected routing detours caused by congestion and hold time fix-up. The Extra Info tab can also report extra information for source timing endpoints that pass through the unregistered output of a RAM or DSP block, or for destination timing endpoints that pass through the unregistered input of a DSP block.

You can review the Extra Info data and Locate Path or Locate Chip Area in Chip Planner, Technology Map Viewer, or Resource Property Viewer to determine whether to make changes to improve placement and routing.

Some delay elements are more sensitive to a path’s placement and routing than others. Intrinsic delays that are part of Setup Slack Breakdown are less sensitive to placement and routing, and are inherent in the RTL and timing requirements. Non-intrinsic delays are the other delays that are sensitive to placement and routing.

Table 25.  Extra Info Tab Data
Extra Info Data Description
Intrinsic Margin

Reports the intrinsic and non-intrinsic timing elements that comprise the timing path slack value. Intrinsic margin is a numeric value that the Timing Analyzer calculates from the timing requirements and path element delays. The Timing Analyzer also derives the slack of the path from the same requirements and delays, but with a different calculation. Intrinsic delays are less sensitive to placement and routing, and are inherent in the RTL and timing requirements. Non-intrinsic delays are the other delays that are sensitive to placement and routing.

From Node Info Specifies the node Type, any Retiming Restriction, and any Power-Up "Don't Care" attributes for the From Node. Consider removing the retiming restriction to allow retiming and improve performance for timing closure.
To Node Info Specifies the node Type, any Retiming Restriction, and any Power-Up "Don't Care" attributes for the To Node. Consider removing the retiming restriction to allow retiming and improve performance for timing closure.
Max Fanout

Reports the maximum fan-out of register and combinational nodes in the path.

Route Stage Congestion Impact Reports whether routing has a Low, Medium, or High impact on congestion. A Low value suggests timing issues are not congestion related. A High value suggests competition for scarce routing resources plays a role in poor timing.
Estimated Delay Added for Hold Reports the estimated amount of delay added on to the fastest delay route to satisfy hold. This value can help you determine whether delays are routing congestion or Hold related.
Sufficient Setup Margin for Hold Reports whether the setup margin is suitable for the hold timing. Yes, indicates that the setup margin is sufficient. No indicates that the setup margin is insufficient for hold timing.
Source/Destination Bounding Box Reports the lower-left and upper-right coordinates for the boundary box enclosing the source and destination registers.

In an ideal case, the Source/Destination Bounding Box, Cell Bounding Box, and Interconnect Bounding Box values are roughly the same, and the relative areas are approximately 1.0. If the cell bounding box size grows relative to the Source/Destination Bounding Box, that can indicate a potential unnecessary routing detour on the path.

Source/Destination Area Covered Reports the total area covered in terms of LABs.
Source/Destination Relative Area Reports the area for the source and destination, relative to the Source/Destination Bounding Box. The value is always 1.0, which equals the same size.
Cell Bounding Box Reports the lower-left and upper-right coordinates for the boundary box enclosing the source and destination registers, and any cells in the path.
Cell Area Covered Reports the area for the cell, relative to the Source/Destination Bounding Box. A value of 1.0 equals the same size. A value greater than 1.0 can indicate a path has a cell outside of the space between the registers in the path.

The following describe the interpretation of timing conditions indicated by the Setup Slack Breakdown:

  • When the Setup Slack Breakdown is less than 0—the path has such a tight timing relationship, a significant difference in microparameters, or such significant clock source uncertainty, that the path fails before the addition of any delay. Review the SDC constraints to verify that the timing relationship is correct. An incorrect relationship can exist between unrelated clocks that lack the proper timing cut. Ensure that parameterizable hard blocks (such as 20K RAM and DSP blocks) are fully registered. Investigate clock sources to verify that the clocks use global signals for routing.
  • When the clock skew exceeds the Setup Slack Breakdown —address the clock transfer to meet timing on the path. You may need to create clock region assignments. You might also need to redesign cross-clock transfers to switch from synchronous to asynchronous implementation, such as with a FIFO or other handshake.
  • When the cell delay is greater than its intrinsic margin—reduce the cell delay, as the path would fail timing even if the clocks are perfect and use no routing wires. Rewrite RTL to reduce the logic depth, restructure logic to allow the Compiler to use faster LUT inputs, or unblock retiming optimizations. The Compiler can automatically retime registers to reduce logic depth, but only in ways that maintain functionality and that the device architecture supports. To unblock the Hyper-Retimer, remove asynchronous resets and initial conditions.
  • When the interconnect delay is greater than its intrinsic margin—the path would fail timing even if the clocks are perfect, and there is no logic. This occurs if registers are too far apart, or a timing path detours around a congested chip area. Review the fan-in and fan-out of registers that are far apart. Apply Logic Lock regions so the Fitter places the registers closer together. Use Logic Lock regions only after determining why placement is initially poor.
Related Information
Level Two Title