01-30-2018 02:03 PM
I am looking at sharing reference clocks between multiple QUADs, the same clock after IBUFDS_GTE4 to drive a lot of generic logic.
Don't know if this is a good idea or not.
I read from UG576, there are rules in limiting number of transceivers in using the reference clock.
01-30-2018 02:11 PM
01-30-2018 02:11 PM
01-30-2018 02:22 PM
It seems gt_refclk_out is after BUFG_GT, is it possible to bring out refclk to be used by other QUAD, without changing 10G/25G subsystem core structure in a block design?
01-30-2018 02:28 PM
01-30-2018 02:54 PM
01-31-2018 07:26 AM
I have a design passed implementation.
It has QUADs taking reference clock from 10G.gt_refclk_out (which is output of BUFG_GT), also the clock is used by generic logic.
Is there any risk/increased jitter on my GT Quads to use this clock as reference input?
01-31-2018 08:05 AM
01-31-2018 08:35 AM
02-23-2019 07:15 AM
Can this solution be setup using the Buf_Util blocks in the Vivado IPI, or does it require Verilog/VHDL instantiation? I have Util-buffers configured as IBUF-GTE feeding BUFG_GT, but no clock is getting to the logic.
04-15-2019 09:09 AM - edited 04-15-2019 09:09 AM
I think you are near the solution, simply don't put all other signals of the ds_buf to ground.
Take a look at this post:
Based on that simply put some constant block IP to give the right settings
07-15-2019 10:56 AM
Can we drive the gt_ref_clk from IBUFDS_GTE4 to BUF_GT and then we can share ' O' ref_clk to other logic blocks?
beacuse i finding some issues like this...
[DRC REQP-1929] IBUFDS_GTE4_O_may_only_drive_GTxE4: The IBUFDS_GTE4 n10g_interface_inst/IBUFDS_GTE4_inst O pin may only be connected to the GTREFCLK pin of a GTHE4_COMMON, GTHE4_CHANNEL, GTYE4_COMMON, or GTYE4_CHANNEL component. The IBUFDS_GTE4 O pin cannot drive n10g_interface_inst/xgbaser_gt_wrapper_inst/bufhce_156_25_inst, and n10g_interface_inst/xgbaser_gt_wrapper_inst/i_ten_gig_eth_pcs_pma_ip_common_wrapper/ten_gig_eth_pcs_pma_ip_gt_gtye4_common_wrapper_i/common_inst/gtye4_common_gen.GTYE4_COMMON_PRIM_INST.
07-16-2019 02:11 AM
Hi @likith ,
you are replying to an old thread with a new topic. It would be better to open a new thread to get an answer.
If you look at ug576, page 25, you can see that the 'O' output in the IBUFDS_GTE4 can only drive *COMMON or *CHANNEL primitives. So the DRC message is correct if you try to connect it to a BUFG_GT.
Only the 'ODIV2 ' output has routings to BUFG_GT and can therefor drive fabric logic. With REFCLK_HROW_CK_SEL you can select what you will see at the output.