06-19-2019 05:52 AM
I'm developing for the Amazon AWS F1 cloud platform, which uses Virtex US+ FPGAs. I have a Clockig Wizard in my design which leads to the following error:
ERROR: [Place 30-718] Sub-optimal placement for an MMCM-BUFGCE-MMCM cascade pair.If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint
in the .xdc file to demote this message to a WARNING. However, the use of this override is highly discouraged. These examples can be used directly in the .xdc file to override this clock ru
< set_property CLOCK_DEDICATED_ROUTE ANY_CMT_COLUMN [get_nets WRAPPER_INST/SH/kernel_clks_i/clkwiz_sys_clk/inst/CLK_CORE_DRP_I/clk_inst/clk_out2] >
The complete message is attached. Of course I tried the suggested "set_property CLOCK_DEDICATED_ROUTE ..." command, but that leads to timing violations quite fast. I have attached a screenshot of the failing path.
The FPGA on Amazon is split into to reconfigurable regions, the SH (Shell), which I have no access to, and the CL (Custom Logic), where the developer design is placed. The SH has a MMCM, and I can only place my MMCM in the CL. I cannot configure the MMCM in the Shell.
Also, I don't see that I can follow the best practice "Resolution: The MMCM-BUFGCE-MMCM cascade pair can use the dedicated path between them if they are placed in vertically adjacent clock regions and in the same column (LEFT/RIGHT) of the device", because this is in a region where I have no access.
Does anyone have a suggestion how this might be resolved? I already tried using a PLL instead of MMCM, disabling buffers and so on, but it did not help.
06-19-2019 06:37 PM
The placement error doesn't seem to necessarily lead to the timing failure.
Looking at the failing path, you would see this is from FF to BUFGCE. The FF is driving the clock buffer's clock enable pin.
The MMCM's CLKOUT0 is connected in parallel to two clock buffers. One of the two clock buffers drives the source FF, and the other clock buffer is the destination BUFGCE. The clock paths are unbalanced causing large negative clock path skew.
You may want to consider moving the clock gating to the load elements.
07-03-2019 02:51 AM
Thanks for your response! I was wondering why CLKOUT0 would drive another BUFGCE at all. Turnes out the "Safe Startup" option was enabled, which causes another BUFGCE to be inserted. I disabled this option and now timing is no longer a problem. Hopefully I don't need the "Safe Startup" option, otherwise I might resort to another solution.
Just wondering, would it be useful to run phys_opt_design -clock_opt? According to UG904, this...
"Inserts global buffers to create useful skew between critical path start and endpoints. To improve setup timing, buffers are inserted to delay the destination clock."
...so it should be able to fix this single failing path?