Visible to Intel only — GUID: mpf1656551164775
Ixiasoft
Visible to Intel only — GUID: mpf1656551164775
Ixiasoft
2.3.2.1.4. Creating Constraints in SDC-on-RTL SDC Files
SDC 2.1 Compliance
SDC-on-RTL SDCs is an industry-standard to provide constraints targeting your RTL. Target nodes are from the elaborated netlist and aligned closely with your RTL. You can target hierarchical nodes and propagate constraints into the compilation flow through various compilation stages.
The Intel® Quartus® Prime software preserves the order of constraints in SDC-on-RTL SDC files. The order in which you list constraints in the SDC file defines the order in which they are loaded in the Intel® Quartus® Prime software.
SDC-on-RTL constraints are designed to support only SDC 2.1-compliant commands. Object accessors, such as get_keepers, get_registers, or get_nodes, are notably absent. The following is the list of supported SDC commands, and you can find more information about them in the TCL Commands and Packages Summary section of the Intel® Quartus® Prime Pro Edition User Guide: Scripting:
- create_clock
- create_generated_clock
- set_input_delay
- set_output_delay
- set_false_path
- set_max_delay
- set_min_delay
- set_multicycle_path
- set_clock_groups
- set_clock_latency
- set_clock_uncertainty
- set_data_delay
- set_net_delay
- set_max_skew
Identifying Timing Paths
For defining timing paths, use SDC standard accessors, such as get_pins, instead of the Intel® Quartus® Prime software-specific commands, such as get_keepers or get_registers. Intel® recommends using explicit get_<pins|ports|nets> commands when targeting objects. Using bare names can result in unintended targets, and DNI might issue a warning.
set_false_path -from [get_keepers { reg_A }] -to [get_keepers { reg_B }]
set_false_path -from [get_pins { reg_A|clk }] -to [get_pins { reg_B|d }]
Status | Exception Command | From Flag | From | To Flag | To | Setup Slack |
---|---|---|---|---|---|---|
Complete | set_false_path | -from | [get_pins{tf_sync[0] |ff_src|clk}] |
-to | [get_pins{tf_sync[0] |ff_dst|d}] |
3.603 |
Invalid | set_false_path | -from | [get_pins{tf_sync[2] |ff_src|q}] |
-to | [get_pins{tf_sync[2] |ff_dst|d}] |
Invalid |
Invalid | set_false_path | -from | [get_pins{tf_sync[3] |ff_src|d}] |
-to | [get_pins{tf_sync[3] |ff_dst|d}] |
Invalid |
Debugging SDC-on-RTL Constraints
There are several ways to debug SDC-on-RTL constraints. For example, you can isolate the exact locations where constraints are used in your design and analyze them in the flow. You can also use compilation reports that report the constraints (see Post-Elaboration Constraints Compilation Report). However, when debugging the constraints, consider the following:
Errors with reading SDC-on-RTL constraints issue an error message with a command stack showing the line number of the offending command. For example:
When handling the constraints, ensure the following:
- Targets and basic syntax are correct (node finding or target acquisition). You can use the RTL Analyzer to find the nodes on the elaborated netlist.
- Constraints make sense with respect to the timing graph (constraint behavior). You can review this in the Timing Analyzer.
Examine the SDC-on-RTL constraints conveyed to the Timing Analyzer (import_sdc loads only the SDC-on-RTL commands) from the design netlist. The import_sdc command loads a version of the SDC-on-RTL constraints after propagating through various stages of the compile flow. After this step, the experience is the same as a typical Timing Analyzer session.