cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Visitor
Visitor
671 Views
Registered: ‎01-15-2019

GTP TXOUTCLK min period check

Jump to solution

I have a question about a specific timing check on a design I'm trying to close out. 

I have an Artix-7 design with a GTP configured with a 3 GHz line rate with a 500MHz reference clock.  4 channels are enabled and clocking is as common as possible, single PLL, RXOUTCLK=TXOUTCLK.  TXOUTCLK from GT0 feeds a MMCM that generates the parallel clock which is commonly distributed to each of the 4 channels (single quad).  A MMCM is configured to generate a 187.5MHz output clock which is correct for a 16 bit byte with 3GHz transfer rate.  TX buffer is bypassed.


There is custom logic as well as a number of different Xilinx IPs in the design as well, and a couple of different clock domains.  The GTP portion of the design is very heavily based on the example design generated by Vivado with minor reset additions and connection of the DRP interfaces.

Timing is clean except for a single min period check on the TXOUTCLK pin of the GTP channel.  The check requires 2.424 ns, and I have a create_clock constraint generating a clock with a period of 2.0 ns on that pin.  That makes sense as the TXOUTCLK is selecting the PLL reference clock which is 500MHz.  The 500MHz create_clock constraint is in the gt_wizard.xdc file generated in the IP output products:


# User Clock Constraints
create_clock -period 2.0 [get_pins -filter {REF_PIN_NAME=~*TXOUTCLK} -of_objects [get_cells -hierarchical -filter {NAME =~ *gt0_gtwizard_0_i*gtpe2_i*}]]

 

I see that the data sheet specifies a Fmax of 412.5MHz on this pin, which makes sense for a max line rate of 6.6GHz/16=412.5MHz if using TXOUTCLK directly as TXUSRCLK.  I'm not doing that - advanced clocking is enabled and TXOUTCLK only is used to feed the MMCM, which generates the slower 187.5MHz clock which feeds back into TXUSRCLK.


My question(s) are whether or not the min period check is valid and required, and whether or not it can be ignored since I'm not using TXOUTCLK as TXUSRCLK.  If it is valid, how is it possible to use a single PLL with a GT ref clock > 412.5MHz? 


Part: xc7a50tfgg484-3
Vivado 2018.3

Thanks!

Mike

0 Kudos
Reply
1 Solution

Accepted Solutions
Moderator
Moderator
629 Views
Registered: ‎07-30-2007

I see.  Is there a special reason to choose the refclk output?  If you just open the example design it should normally set the TXOUTCLKSEL to 010 which is the TXOUTCLKPMA that will already be the right frequency to generate the TXUSRCLK.  This is the normal flow.  You could also choose the 100 setting which will give you the refclk/2 to drive the MMCM which is at a frequency that wouldn't cause pulse width problems.  I was assuming you had a special need to have the 500 MHz clock for some other use.  Refer to the diagram on page 108 of UG482.

BTW you can use the output of the IBUFDS_GTE* to the MMCM and drive the TXUSRCLK that way but you shouldn't do that unless you have a special need to have the 500 Mhz refclk.

 




----------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution
----------------------------------------------------------------------------


View solution in original post

5 Replies
Moderator
Moderator
664 Views
Registered: ‎07-30-2007

The txoutclk is not expected to be higher than the TXUSRCLK rate.  The period check is likely a real problem.  You should be able to output the refclk directly from the IBUFDS_GTE2 O port  through a BUFG which will avoid this.  Not sure all parts can output the O port to a BUFG so if you run into problems you can use the ODIV2 port and send the output to a PLL to multiply it up to the frequency you are looking for.




----------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution
----------------------------------------------------------------------------


0 Kudos
Reply
Visitor
Visitor
639 Views
Registered: ‎01-15-2019

Thanks for the reply, but I don't understand how this will help.  Are you suggesting to use the output of the IBUFDS_GTE2 as the input to the MMCM instead of TXOUTCLK?

Thanks,

Mike

0 Kudos
Reply
Moderator
Moderator
630 Views
Registered: ‎07-30-2007

I see.  Is there a special reason to choose the refclk output?  If you just open the example design it should normally set the TXOUTCLKSEL to 010 which is the TXOUTCLKPMA that will already be the right frequency to generate the TXUSRCLK.  This is the normal flow.  You could also choose the 100 setting which will give you the refclk/2 to drive the MMCM which is at a frequency that wouldn't cause pulse width problems.  I was assuming you had a special need to have the 500 MHz clock for some other use.  Refer to the diagram on page 108 of UG482.

BTW you can use the output of the IBUFDS_GTE* to the MMCM and drive the TXUSRCLK that way but you shouldn't do that unless you have a special need to have the 500 Mhz refclk.

 




----------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution
----------------------------------------------------------------------------


View solution in original post

Visitor
Visitor
599 Views
Registered: ‎01-15-2019

Thanks again Roy.

Because I have the TX buffer bypassed, the output products (and example design) are selecting 011 on the TXOUTCLKSEL.  The .xci file has the string "USE_TXPLLREFCLK" as the corresponding value.  For fun, I enabled the TX buffer and sure enough it works as you said, the default value is the TXOUTCLKPMA 010, and the string in the xci is set to "AUTO".  I want to bypass the TX buffer, so I will use the 100 setting and update the dividers on the MMCM accordingly.  Is there a string value that I can update in the xci to cause 100 to be automatically selected in the future if the project needs to be regenerated or updated?  

With "Enable TX Buffer" deslected in the wizard, I can't choose any options -  the "Use TXPLLREFCLK" is checked but greyed out.

 

Thanks,

Mike

0 Kudos
Reply
Moderator
Moderator
595 Views
Registered: ‎07-30-2007

No, I'm afraid that can't be adjusted in the wizard.




----------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution
----------------------------------------------------------------------------