Forum Discussion
Hi Farabi
Rather than experimenting with cludge fixes I am focussing on the Platform Designer automatic generated:
(*altera_attribute = "-name SDC_STATEMENT \"if { [get_collection_size [get_pins -compatibility_mode -nowarn ~ALTERA_CLKUSR~~ibuf|o]] > 0 } { create_clock -name ~ALTERA_CLKUSR~ -period 8 [get_pins -compatibility_mode -nowarn ~ALTERA_CLKUSR~~ibuf|o] }\"" *)associated with the transceiver reset sequencer instance in the design -- doesn't seem to be an obvious IP parameter to tell the instance that CLKUSR is at 100MHz rather than 125MHz...
Transceiver PHY Reset Controller (parameters)Regards, Steve
Hi Steve,
Please refer to the following explanation of the Warning that you see.
Based on the explanation, we would infer that Quartus detected transceivers in your design.
- If transceivers are used in your design, then you need NOT do a pin assignment in the .qsf. However, it is must to provide a clock of 100-125 MHz at its input. No need to constraint it in the .sdc.
- If you are not using transceivers, not using HMC, and not using this pin as a user-supplied configuration clock, instead want to use it as a GPIO, then you need to assign the logic port to the device CLKUSR pin location and constraint the pin in .sdc.
We hope this information helps.
Regards,
Aqid
- Steve-Mowbray-ENL5 days ago
Occasional Contributor
Hi Aqid
Thanks -- all understood -- my purpose is to identify why timing analyser reports CLKUSR at 125MHz when our design requires 100MHz -- and if there is a method to indicate to Quartus/Platform-Designer what CLKUSR frequency actually is or failing that if the incorrect CLKUSR frequency reported is in fact unimportant and can be ignored (our project does seem to mostly run as expected but there are some quirks which could be related to transceiver operation)
Regards, Steve