08-27-2018 04:51 PM
I'm pretty new to working with FPGAs, so apologies if I seem clueless about anything. Been reading through various datasheets and userguides and some other forum posts, but not sure what to do at this point.
I have a Zynq UltraScale xczu3eg-sfvc784-1-e, and am working with Vivado 2018.1. Right now I have just a single custom IP block in the PL fabric, so there's really not much in there. I have a clock signal that is coming in on pin AG14 of bank 24. Per UG1075, this is an IO_L#P pin (and not IO_L#P_GC, which I think may be part of the problem). When I get to the implementation stage, it errors out with:
ERROR: [Place 30-675] Sub-optimal placement for a global clock-capable IO pin and BUFG 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 rule. < set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets clk_osc_drv_0_IBUF_inst/O] > clk_osc_drv_0_IBUF_inst/IBUFCTRL_INST (IBUFCTRL.O) is locked to IOB_X0Y2 clk_osc_drv_0_IBUF_BUFG_inst (BUFGCE.I) is provisionally placed by clockplacer on BUFGCE_HDIO_X0Y4 The above error could possibly be related to other connected instances. Following is a list of all the related clock rules and their respective instances. Clock Rule: rule_bufgce_bufg_conflict Status: PASS Rule Description: Only one of the 2 available sites (BUFGCE or BUFGCE_DIV/BUFGCTRL) in a pair can be used at the same time clk_osc_drv_0_IBUF_BUFG_inst (BUFGCE.O) is provisionally placed by clockplacer on BUFGCE_HDIO_X0Y4
I'm trying to fix this without including the CLOCK_DEDICATED_ROUTE FALSE in my constraints, since it is strongly recommended not to use that.
When I do put the CLOCK_DEDICATED_ROUTE FALSE in my constraints so I can open an implemented design, I see that as the warning says AG14 and the IBUFCTRL is down in the X0Y0 clock region, and the output of that is routed all the way up to clk_osc_drv_0_IBUF_BUFG_inst in the X0Y2 clock region. It looks like maybe 98% of the logic of my custom IP is in the X0Y2 clock region, with just a few pieces that slip down into X0Y1.
I did come across AR #66659 (https://www.xilinx.com/support/answers/66659.html). I tried to go through it, but in step 3 it says to do a set_property CLOCK_REGION on the BUFG instance name. I add this into my constraints file, but when I do a build it just prints out a warning that the name I passed to get_cells doesn't exist, and then I hit the error about sub-optimal placement. I only seem to be able to do a successful get_cells on that name when I have the CLOCK_DEDICATED_ROUTE FALSE workaround in, and after the implementation has completed (during the implementation itself it still printed a warning that get_cells on the BUFG instance name did not find a cell that existed). After implementation completes, I can run the get_cells command from the tcl console and it seems to find the instance just fine.
So I'm kind of at a little bit of a loss of what to do or try next.
1. If we had used a pin that was IO_L#P_GC instead of just IO_L#P, would that potentially resolve this issue?
2. Assuming I can't change the hardware at this point (perhaps in a future board spin), should I still be able to work around this? Is there some way to force things to be in the same clock domain?
3. Am I missing anything obvious?
Because I saw it asked for in a different post about a sub-optimal placement issue, I tried to attach the *opt.dcp file from my build, but I just get an error "The attachment's zynq_ultra_bd_wrapper_opt.dcp content type (application/octet-stream) does not match its file extension and has been removed."
08-28-2018 06:12 PM
Using a GC should resolve this issue. How about only adding the workaround below?
set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets clk_osc_drv_0_IBUF_inst/O]
08-29-2018 05:08 PM - edited 08-29-2018 05:10 PM
Yes, adding that constraint changes it from an error to a warning and allows the implementation to complete. I was just trying to avoid using that as it specifically says "However, the use of this override is highly discouraged."
When it is included, I get:
WARNING: [DRC PLCK-58] Clock Placer Checks: Sub-optimal placement for a global clock-capable IO pin and BUFG pair. Resolution: A dedicated routing path between the two can be used if: (a) The global clock-capable IO (GCIO) is placed on a GCIO capable site (b) The BUFG is placed in the same bank of the device as the GCIO pin.
Both the above conditions must be met at the same time, else it may lead to longer and less predictable clock insertion delays. This is normally an ERROR but the CLOCK_DEDICATED_ROUTE constraint is set to FALSE allowing your design to continue. The use of this override is highly discouraged as it may lead to very poor timing results. It is recommended that this error condition be corrected in the design.
Okay, so I don't know why it never crossed my mind *at all* until now, but I realized I could just claim in my constraints that the clock was on a GCIO pin instead of the actual pin it will be on, and that verified that it implements without any errors or warnings.
We will probably have a future pass of hardware where we can fix which pin we use. But for knowledge's sake, is there any way to get rid of this error/warning when not using a GCIO pin (other than using the CLOCK_DEDICATED_ROUTE FALSE constraint)?
Maybe I was misinterpreting what I was reading. In UG572 it says "External global user clocks must be brought into the UltraScale device on differential clock pin pairs called global clock (GC) inputs." Is any external clock coming into the device a "global" user clock? My thinking was that the clock comes in on the pin we currently have it come in on, which lands it in the X0Y0 clock region, and then if the logic needing it is also in the X0Y0 clock region, everything is fine. But the logic seems to always get placed in the X0Y2 clock region, even though there appears to be no logic being utilized in X0Y0. But... is any external clock considered a "global user clock" regardless of if it needs to cross clock regions? That would then mean that we definitely need to use a GCIO pin. Otherwise, if there is such a thing as an external "non-global" user clock not requiring a GCIO pin, is there a way to force the logic to be implemented in the X0Y0 clock region where the clock comes in?