1.4.3.5. Using Entity-Based SDC-on-RTL Constraints

Quartus® Prime Pro Edition User Guide: Design Compilation

Download PDF

ID 683236

Date 7/08/2024

Version

Public

Visible to Intel only — GUID: fwb1690915432133

Ixiasoft

View Details

1.4.3.5. Using Entity-Based SDC-on-RTL Constraints

A typical design includes a combination of third-party IPs and RTL, so the primary goal of entity-based SDC-on-RTL is to ensure seamless integration of IPs by empowering IP owners to encapsulate their IP's SDC constraints.

Given that timing constraints specified in an SDC file are generally applied globally throughout a design rather than to specific entities, proper encapsulation of IP SDCs becomes crucial. This encapsulation allows utilizing the IPs without encountering unexpected SDC leaks. To achieve this, the entity binding prepends the RTL path name of the IPs, effectively preventing any SDC leaks and averting the potential impact on design paths that might coincidentally match the name.

In addition, the introduction of entity based SDC-on-RTL constraints offer IP authors the ability to define specific constraints at the module boundaries. These constraints are optimized for post-synthesis timing analysis within the context IP instantiation in the design hierarchy. Even when IP authors lack precise knowledge about where their IPs are instantiated in the design hierarchy during its implementation, the constraints remain effective. This approach allows IP authors to implement their SDC constraints without requiring detailed information about the eventual placement of the IP within the hierarchy.

The flow supports reading entity-based SDC-on-RTL in designs and IP cores during the Analysis & Elaboration stage, where the entity-based SDC-on-RTL constraints are read and saved in a low-level entity database. These constraints are eventually processed in the SDC read-in order and applied to the hierarchical netlist objects during compilation.

The Quartus® Prime runtime generates IP SDCs along with the IP instantiation and specifies a project assignment to associate IP SDCs with the IP design entity name.

QSF Assignment Syntax

set_instance_assignment -name RTL_SDC_FILE <sdc_file_name> -entity <entity_name> [-no_sdc_promotion]

Where:

Argument	Description
`RTL_SDC_FILE`	Specifies the SDC-on-RTL file name.
`-entity`	Indicates that it is an entity-based assignment. The SDC file is applied to each instance of the design entity. The instance hierarchy path is implicitly applied to the `pattern` argument search for `dni::get_*` (`get_cells`, `get_pins`, `get_ports`, and `get_nets`) commands.
`[-no_sdc_promotion]`	An optional argument that works only with the `-entity` flag. For the entity-based constraints, the `[-no_sdc_promotion]` argument removes the default behavior of the instance hierarchy path being the default implicit with the netlist search commands, This allows you to control which individual command to apply the instance hierarchy path in the netlist object search. Use the `get_entity_current_instance` Tcl command to obtain the current instance hierarchy path of the entity. For example: set_false_path -from [get_pins [get_entity_current_instance]\|ff_src\|clk] \ -to [get_pins [get_entity_current_instance]\|ff_dst\|d]]

Entity-based SDC-on-RTL Constraints Example

Furthermore, these entity-based SDC-on-RTL constraints provide flexibility. You can enhance or override them by introducing additional SDC constraints during the implementation stages. The following example shows how to establish logical constraints for post-synthesis timing analysis using entity-based SDC constraints on a design that includes two instances of IOPLLs:

Figure 50. Example Design with Two Instances of IOPLLs

In this simple design example, observe iopll_1 and iopll_2 entities. There are additional hierarchies inside these entities. The following image depicts the hierarchy for iopll_1:

Figure 51. Hierarchy Inside the iopll_1 Block

Apply the initial SDC-on-RTL constraints file to the entire design using the RTL_SDC_FILE argument.
```
set_global_assignment -name RTL_SDC_FILE test.sdc
```

Define a specific SDC-on-RTL constraint file using the RTL_SDC_FILE complemented by the arguments -entity and -library to target each IOPLL entity.

set_global_assignment -name RTL_SDC_FILE clock_generator.sdc  -entity "iopll_1" -library "iopll_1"
set_global_assignment -name RTL_SDC_FILE clock_generator.sdc  -entity "iopll_2" -library "iopll_2"

Define the constraints that rule over the IOPLL module.
Note: During the initial stages of designing when the RTL netlist is generated, the internal connections of the PLL might not be fully known. Consequently, apply these constraints at the module boundaries, specifically at the IOPLL ports using the get_ports (or get_pins <port_name> ) Tcl command when addressing the module inputs and outputs. Along with other constraints, they facilitate the creation and propagation of output clocks generated from the incoming reference clock. The actual connections in the RTL netlist between the clock source and the target are not required to exist initially to apply early timing constraints. However, the Timing Analyzer will issue a warning about the missing connectivity and continue to operate.
```
# clock_generator.sdc
# get the name of the current instance to generate a name
set current_entity_instance [get_entity_current_instance]
 
# Note: Do not specify the -master_clock if you want STA to 
#       use the source to determine the master clock name.
create_generated_clock -divide_by 1 -source [get_ports refclk] [get_ports outclk_0] -name ${current_entity_instance}_outclk_0
create_generated_clock -divide_by 2 -source [get_ports refclk] [get_ports outclk_1] -name ${current_entity_instance}_outclk_1
```
The clocks are shown here in the Timing Analyzer report, as shown in the following:

Figure 52. Post-Synthesis Clock Reports

It is advantageous to leverage SDC-on-RTL scoping capabilities to generate timing constraints that target RTL nodes, which can be applied during the early stages of timing analysis. Even so, the constraints defined through entity-based SDC-on-RTL files can be adjusted, replaced or supplemented, during the implementation stage, where physical constraints come into play, this allows you to target internal nodes as needed for accurate timing modeling.

Tcl Commands

The SDC commands set model closely relates to the industry-standard SDCs. In particular, the dni::get_ports command can query hierarchical ports on an unflattened design netlist. This behavior differs from the existing Timing Analyzer get_ports command that can query top-level ports in the post-synthesis design.

When used in the context of entity-based SDC-on-RTL file, the dni::get_ports command, for example, [dni::get_ports refclk] searches for a port in the context of the current instance of the instantiated RTL. To avoid the implicit prefix of the current instance in the dni::get_ports command, use the -no_sdc_promotion option along with the dni::get_entity_current_instance command in the SDC file where the entity’s instance hierarchy path is required.

Select Your Language

Using Intel.com Search

Quick Links

Recent Searches

Advanced Search

Only search in

Quartus® Prime Pro Edition User Guide: Design Compilation

1.4.3.5. Using Entity-Based SDC-on-RTL Constraints

Entity-based SDC-on-RTL Constraints Example

Tcl Commands