08-20-2020 01:19 PM - edited 08-20-2020 03:45 PM
According to Xilinx's own GTX docs, https://www.xilinx.com/support/documentation/user_guides/ug476_7Series_Transceivers.pdf#60, 32b wide 10G pcs/pma should be able to run with a 156.25MHz external ref clock (first row of table 2-17, "typical" refclk is only 156 not 312).
How does one do this? The IP cores in Vivado do not have this option. You get 10G either 32b with a presumed 312.5 external refclk, or 64b with the presumed 156MHz reference. These are your only options. Clearly a clock multiply x2 will need to happen *somewhere* before the data-path for coreclk to be 312.5. But how?
Looking at figure 3-16 from the 10G PCS guide, I did try exporting the IP to an example project and modifying the 'shared code' section by putting in a 2x PLL between the IBUFDS_GTE and BUFG/GT_COMMON blocks. It did not error (unless I tried to put a BUFG between IBUFDS and PLL--so don't do that) but seems like a hack? Is there a better way?
I did look at the 64b example project too and noticed that the GT_COMMON block has it's QPLL settings off by a factor of two in one divisor compared to the 32b example. Could I use this to get the right gt0_qpllclk_i ? But then won't gt0_qpllrefclk_i be half the needed speed still since it's is passed through? Does the core even USE that clock vs the core and tx and rx clocks?
To add: I do not feel comfortable mucking with anything actually inside the core. I saw a bunch of confusing GTX documentation about gearboxing and mucking about with the R/TX_INT_DATAWIDTH = 0 vs 1 and TXUSRCLK2 being 1x or 2x USRCLK, and having to pause data every so many count cycles, but was hoping to not have to dive into that. Seems like that would have to be supported by the IP authors and not the user, it is so low level, you wouldn't be stamping out copies of the "core" logic anymore in Vivado. You'd be remaking the IP with all the 32/33 clock counting, K codes, etc.
08-25-2020 01:28 AM
GT can have the multiple configurations. While IP core may not have all the choices. As you can see in the IP core GUI, there're some predefined clock frequencies. If you want to use the different clock frequency, you have to modify the IP core by yourself.
First, generate a GT example with the clock you want. Compare the generated GT and the GT in the IP core. Replace it manually. And finally do functional simulation to verify your modification.
08-26-2020 11:39 PM - edited 08-26-2020 11:45 PM
@guozhenp, it looks like IBUFDS => MMCM x2 => QPLL used as usual will compile and sim (but haven't tried in real life yet). However is there a "cleaner" way? Because I'm using power for a 2x MMCM multiply but the QPLL is dividing by 2.
For instance if refclk is half speed, and I manually adjust the QPLL to not divide by 2 after the x33 multiply for gt0_qpllclk_i, will this work? I see a potential problem that gt0_qpllrefclk_i is now half what the original ref design expected. But is that signal even actually used by gt_wiz_wrapper_GT for anything? or is the qpllclk and the CPLL multiplications of it used for everything? Will txoutclk be 156.25 because it's refclk based? Or will it be the proper 312.5 because it's divided down by 33 from the internal 10.3125 GHz bit clock? Can the 7 series even do that? There's so many internal core mux settings get txoutclk but the doc doesn't say which way the ref design core uses.
Is txoutclk used for ANYTHING or just an output? I could put the MMCM x2 on it then to generate txuserclk and coreclk if it is 156.25, rather than the IBUFDS. Or if I'm lucky it's already 312.5.
08-26-2020 11:48 PM
You can't use IBUFDS => MMCM x2 => QPLL
QPLL will multiple the reference clock frequency and its noisy as well so it requires a high quality clock. Clock generated from MMCM is not good enough to GT/QPLL.
Changing QPLL attributes is a good way. You can go ahead to do the modification and do simulation to verify it. If the Ethernet IP can link up and the line rate is expected in simulation, I think the attributes change is OK.
08-27-2020 12:02 AM - edited 08-27-2020 12:03 AM
Thanks for the fast reply.
If the core is using qpll_refclk that won't be affected by my *M/N QPLL changes so will stay half the "expected" rate? Does qpll_refclk get used for anything? If it is sent to txusrclkout will that be half normal also? can that be PLL'd x2 for txusrclk?
Fig 3-1 shows the gt0_qpllrefclk_i entering gt_wiz_wrapper_G but it's not clear if it or gt0_qpllclk_i are used for the various txoutclk/rxclock that come out?
Is there anything else inside the core trying to use that txusrclkout that may be half-speed? Or is that kinda the purpose of looping txusrclkout out of the core and right back in again? (Never understood why core made you add a bufg yourself outside)
Also, I'll probably still have to do IBUFDS => PLL x2 => core clock to get 312.5 since txusrclk is too fast at 322.26 (or 161.13 if I'm unlucky)?
08-28-2020 07:20 PM
So I did a quick simulation. While the datasheet shows gt0_qpllrefclk_i going from the GT*E2_COMMON to gt_wiz_wrapper_GT, it apparently (?) is not used for anything. I tried forcing it to 1'bX and nothing breaks in sim that I can find.
This means that if the refclk coming in is half-speed, gt0_qpllrefclk_i out will also be half-speed, but it should not matter. As long as the QPLL clock divider setting is adjusted appropriately to make the qpllclock be 5.27GHz. I'm guessing TXCLKOUT and RXCLKOUT are each being divided by 16 from this 5.27GHz DDR bit-clock in the PMA and I'm guessing core's TXOUTCLKSEL is b'010?
Now I still need to double refclk to create the MII side 312.5MHz coreclock, but I'm guessing that is OK to use a PLL for?