It is possible to rename the generated clocks that are automatically created by the tool.
The renaming process consists in calling the create_generated_clock
command with a limited number of parameters:
create_generated_clock -name new_name [-source master_pin] [-master_clock master_clk] source_objectThe arguments that must be specified are the new generated clock name and the source
object of the generated clock. The source object of the generated clock is the object
where the auto-derived clock is created (CMB output pin, GT output pin for UltraScale, and so on). The -source and
-master parameters must be used only when more than one clock
propagates through the source pin in order to remove any ambiguity.
Important: If any of the
-edges/-edge_shift/-divide_by/-multiply_by/-combinational/-duty_cycle/-invert
options is passed to the create_generated_clock command, the generated
clock is not renamed. Instead a new generated clock is created with the specified
characteristics.Important: When a module (IP/BD/DFx/...) is synthesized
Out-Of-Context, the module is inferred as a black-box when the top level is synthesized
and the module internal pins and clock names are not anymore accessible. In that
scenario, the top level XDC constraints used for synthesis cannot refer to a clock name
or rename an auto-derived clock that is generated inside the module. With OOC synthesis,
the top-level timing constraints must point to the OOC clocks through the module ports
that propagate those clocks. This can be done using some queries such as
‘get_clocks -of_objects [get_pins
<OOC_MODULE_OUTPUT_CLOCK_PORT>]. The XDC constraints used for
implementation do not have this limitation since the entire design is rebuilt before the
XDC constraints are applied.