Symptom
A create_clock constraint applied in a Synplify Pro .fdc file to a clock pin inside a PCIe or SERDES IP passes the synthesis constraint check, but has no effect afterwards. The post-synthesis log reports:

WARNING - No pin matched '<hierarchical_path>/LINK0_CKUSRO'.
WARNING - Can't resolve object '<hierarchical_path>/LINK0_CKUSRO' in constraint 'create_clock ...'.
WARNING - create_clock/create_generated_clock is being ignored due to errors

The clock keeps its default frequency (for example 250 MHz on PCIe Gen1 x1). The same constraint in .pdc works.

Cause
After synthesis, Radiant merges the PCS elements of the hard IP block, which relocates and renames the instance your constraint names. The constraint is validated before that merge, so it passes the check but cannot be resolved afterwards and is dropped. This is a tool limitation, not a syntax or design error.

Affected version
Radiant 2022.1.

Resolution
Update to Radiant 2023.1 or later, where constraint object names are updated after the PCS merge. No constraint changes are required.

Workaround for Radiant 2022.1
Apply the clock constraint as a design/physical constraint (.ldc or .pdc) rather than in the .fdc. Select the clock object from the post-synthesis netlist in the Constraint Editor or Timing Analyzer instead of typing the pre-synthesis hierarchical path.