Visible to Intel only — GUID: fwb1690915432133
Ixiasoft
Visible to Intel only — GUID: fwb1690915432133
Ixiasoft
1.16.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]] |
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.