04-26-2017 01:23 PM
We are bringing a clock in on CC input. Due to a shortage of BUFRs, the clock comes into a BUFIO and a BUFG. Can we clock in the input side of a DDR with the BUFIO and the output side with the BUFG version? Is this a safe clock crossing? Or must we use a BUFR/BUFMR when using the BUFIO?
04-27-2017 06:24 AM
Table 1-1 of UG472 : https://www.xilinx.com/support/documentation/user_guides/ug472_7Series_Clocking.pdf
has a good list of what the CCIO Used to Directly Drive
MRCCs that are located in the same clock region and on the same left/right side of the device drive:
• Four BUFIOs
• Four BUFRs
• Two BUFMRs
• One CMT (one MMCM and one PLL)
• CMTs above and below (using limited CMT backbone resources)(1).
MRCCs within the same half top/bottom drive:
• 16 BUFGs
MRCCs within the same horizontally adjacent clock regions drive:
The CC can drive the BUFG in the same half and the output of the BUFG can drive IDDR.
05-04-2017 09:44 AM
Sorry, but you missed the point of my question. If I clock the DDR with the BUFIO, and the downstream logic with the BUFG, is this considered a clock boundary crossing? Can I safely move across these domains? Will the tools time this path?
05-05-2017 10:59 AM
Depending on whether you are using an IDDR or an ISERDES the answer is "it is not recommended" or "it is illegal".
First, looking at the ISERDES. For the ISERDES, the CLK and CLKDIV must be "in phase". The user guide gives a set of legal clocking schemes that keeps the two clocks "in phase" - the BUFIO/BUFG combination you describe is not one of them - hence this is illegal.
For the IDDR (which is more what you are asking) the answer is "it is not recommended". The reason the BUFR exists in the first place is to have a "shorter" insertion time so that the BUFIO -> BUFR clock crossing can be accomplished. The insertion time of a BUFG is significantly longer than that of a BUFR due to a couple of reasons:
- the BUFR is located in the IOB column, right beside the BUFIO and adjacent to the CC pin; the BUFG is located in the center of the FPGA
- the BUFR only fans out to the resources in one clock region, whereas the BUFG can fan out to the entire FPGA
- this means a much larger clock tree, and hence a longer clock insertion time
So the net result of this is that the BUFG clock will drastically lag the BUFIO clock. While structurally legal and the tools are able to understand the structure, there will be significant hold time problems crossing synchronously between these two domains. If you code this, the tools will attempt to fix the hold violations in the route phase, but due to PVT variations, there is an upper limit in terms of frequency where this will work (the minimum delays required at fast PVT will result in delays at slow PVT that are too long to make it in one clock period - even including the positive clock skew).
Furthermore, these routes will chew up routing resources in order to create the required delays, potentially impacting the rest of the routing.
All this being said, I am wondering how you can be running out of BUFRs, while not running out of BUFIOs and/or clock capable pins at the same time. In most systems, systems use an equal number of BUFIOs and BUFRs - there are very few applications where a BUFR can be used alone (and none where a BUFIO can be used alone). Furthermore there is one BUFIO and one BUFR per CC... So why are you running out of BUFRs? It is worth looking at the larger problem in case you are using more BUFRs than you should be...
05-16-2018 11:02 AM
I have question related to discussion. Suppose the circuit is something like in the image below but instead of marked BUFR there is BUFG. Clock comes to IDDR through BUFIO and to FF through BUFG. Does tool consider IDDR->FF path as clock domain crossing? I have timing differences in destination clock path more that 2.5 ns between cases of BUFG and BUFR (with period of 8 ns) and tool doesn't complains about it (or I doesn't see it, but timings pass, cdc and drc reports are clear). Example is from RGMII interface with 8 ns clock period, double data rate; data windows something like in the post https://forums.xilinx.com/t5/Timing-Analysis/Input-clock-IDDR/td-p/735891 . It is seemed BUFG case is wrong (as @avrumw explained) and actually BUFG case doesn't work correctly in hardware. Vivado 2015.1 was used for implementation. Is there a way to make tool to complain about it or is it a correct tool behavior or is it something in my design that masks the problem in this case?
05-16-2018 03:20 PM
05-17-2018 12:20 AM - edited 05-17-2018 12:21 AM