Visible to Intel only — GUID: row1706912461580
Ixiasoft
1.2.1. Timing Path and Clock Analysis
1.2.2. Clock Setup Analysis
1.2.3. Clock Hold Analysis
1.2.4. Recovery and Removal Analysis
1.2.5. Multicycle Path Analysis
1.2.6. Metastability Analysis
1.2.7. Timing Pessimism
1.2.8. Clock-As-Data Analysis
1.2.9. Multicorner Timing Analysis
1.2.10. Time Borrowing
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.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.1. Report Fmax Summary
2.5.2. Report Timing
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
Visible to Intel only — GUID: row1706912461580
Ixiasoft
2.3.5.1.1. Targeting Constraints to Module Inputs and Outputs
SDC-on-RTL allows you to define constraints at module boundaries, even if some internal connections within the modules or IP remain partially unknown. It is best to apply SDC-on-RTL constraints at the module boundaries, specifically at the input and output boundaries of each module.
When targeting your timing constraints to the inputs and outputs of a module, you can target the following different element types, depending on your circumstances:
inst_port—these elements are retrieved in collections due to applying the get_pins filter. They target inputs and outputs of modules in a manner similar to addressing pins on registers and LUTs.
# inside get_pins {clk_in} clk_dic.rtlsdc
Note: Use get_pins for constraints that expect pins as targets.
Figure 61. Targeting the Instance Port
port— these elements reside within the module and are primarily for use in targeting ports in entity-bound constraints. You can employ the get_ports filter for this purpose.
# Inside get_ports {clk_in} clk_dic.rtlsdc
Note: Use get_ports for constraints that expect ports as targets.
Figure 62. Targeting the Port