Forum Discussion
Occasional ContributorUsing PCIe HIP core clock out to drive IOPLL reference clock -- advise on set_false_path syntax
Hi FvM
So it seems when the base/parent clock for the 100MHz domain was the external crystal Quartus was treating it as an unrelated clock hence no timing failures and status/control bits between the clock domains have synchroniser depth of 2 -- when PCIe core clock out was substituted for the external crystal -- Quartus started treating both clocks as related even though decoupled using an IOPLL instance -- the following design constraints appear to correct the situation
set_false_path -from [get_clocks {u0|pcie_hip|coreclkout}] -to [get_clocks {u0|iopll_1|*}] set_false_path -from [get_clocks {u0|iopll_1|*}] -to [get_clocks {u0|pcie_hip|coreclkout}]Thanks
Steve
Occasional ContributorHi FvM
Yes agreed which is why I am out of my depth here -- there are no data paths between the 125MHz and 100MHz domains -- previously the 100MHz domain had its own dedicated crystal as shown below:
In the external crystal configuration the project makes timing comfortably however the extra crystal has been removed from the design and using the PCIe core clock out as its substitute causes build timing to collapse...
I note that PCIe core clock out appears to be spread spectrum for Arria 10 devices when measured on external pin which is great for EMC but perhaps is causing the fitter/timing-analyser difficulties?
If solution is not to set a false path how do I tell Quartus to be relaxed about using core clock out as reference clock to the IOPLL instance?
Regards
Steve
Super Contributorspread spectrum period variation should be low enough not to affect timing closure. How does it appear in .sdc description?
Can you show where you see timing failures, what kind of violation, which clocks involved?
- Steve-Mowbray-ENL
Hi FvM
Ok so I found a data path between the two domains -- there is an Avalon-MM register with control bits that are passed to a component in the 100MHz domain -- confusingly the end point for these control bits has synchroniser depth of 2 and I am still unsure as to why timing would be good when the 100MHz domain was referenced to the external clock device and bad when referenced to an internal IOPLL driven by PCIe core clock out...
Anyways I am testing the following design constraint:
set_false_path -to {system_top:u0|psu_drv:u1|duty_cycle_ctrl_in}Will report back when build has completed
Regards
Steve
- Steve-Mowbray-ENL
Hi FvM
So it seems when the base/parent clock for the 100MHz domain was the external crystal Quartus was treating it as an unrelated clock hence no timing failures and status/control bits between the clock domains have synchroniser depth of 2 -- when PCIe core clock out was substituted for the external crystal -- Quartus started treating both clocks as related even though decoupled using an IOPLL instance -- the following design constraints appear to correct the situation
set_false_path -from [get_clocks {u0|pcie_hip|coreclkout}] -to [get_clocks {u0|iopll_1|*}] set_false_path -from [get_clocks {u0|iopll_1|*}] -to [get_clocks {u0|pcie_hip|coreclkout}]Thanks
Steve
