Forum Discussion

Steve-Mowbray-ENL's avatar
Steve-Mowbray-ENL
Icon for Occasional Contributor rankOccasional Contributor
3 months ago
Solved

Using PCIe HIP core clock out to drive IOPLL reference clock -- advise on set_false_path syntax

Hi Need advise on suitable set_false_path design constraint construction for the following scenario where PCIE HIP core clock out is used as the reference for an IOPLL instance: Impact of doi...
  • Steve-Mowbray-ENL's avatar
    Steve-Mowbray-ENL
    3 months ago

    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

Steve-Mowbray-ENL's avatar
Steve-Mowbray-ENL
Icon for Occasional Contributor rankOccasional Contributor
3 months ago

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's avatar
Steve-Mowbray-ENL
Icon for Occasional Contributor rankOccasional Contributor
3 months ago

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