cancel
Showing results for 
Search instead for 
Did you mean: 
Observer
Observer
5,052 Views
Registered: ‎12-03-2014

Pulse width problem with gtwizard 3.5 CPLL railing module

Jump to solution

Hi,

 

I recently updated my gtwizard IP from vivado 2014.4 (gtwizard v3.4) to vivado 2015.2 (gtwizard v3.5) and get a timing violation error for pulse width of reference clock at the input of BUFR in CPLL railing module.

 

This timing violation appear in the example design generated from the attached file.

 

Can Xilinx fix this?

 

Thanks and regards.

 

M. SAVOYAT

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Observer
Observer
8,811 Views
Registered: ‎12-03-2014

Re: Pulse width problem with gtwizard 3.5 CPLL railing module

Jump to solution

As I directly use the xci file in my design, I can't set USE_BUFG parameter nor modifying the connection the the IBUFDS_GTE2.
Saving BUFG is very important. Why not using BUFH in all case?

 

I fixed this by replacing the BUFR by a BUFH with a tcl script (at implementation):

set oldBUFR [get_cells */gtwizard_inst/U0/gtwizard_adc_i/cpll_railing0_i/use_bufr_cpll.refclk_buf]
set newBUFH [create_cell -reference BUFH */gtwizard_inst/U0/gtwizard_adc_i/cpll_railing0_i/use_bufh_cpll.refclk_buf]
connect_net -net [get_nets -of_objects [get_pins $oldBUFR/I]] -objects [get_pins $newBUFH/I]
connect_net -net [get_nets -of_objects [get_pins $oldBUFR/O]] -objects [get_pins $newBUFH/O]
remove_cell $oldBUFR

View solution in original post

3 Replies
Highlighted
Community Manager
Community Manager
4,930 Views
Registered: ‎07-23-2012

Re: Pulse width problem with gtwizard 3.5 CPLL railing module

Jump to solution

The pulse width violation is valid because GTREFCLK (625 MHz) is driving a BUFR whose maximum allowable frequency is 540 MHz as per table 35 of DS183.

 

To workaround this issue, you need to set USE_BUFG paramter to 1 in gtwizard_adc.v file; this will replace BUFR in design with BUFG whose max allowable frequency is 710 MHz.

-----------------------------------------------------------------------------------------------
Please mark the post as "Accept as solution" if the information provided answers your query/resolves your issue.

Give Kudos to a post which you think is helpful.
0 Kudos
Highlighted
Moderator
Moderator
4,927 Views
Registered: ‎02-16-2010

Re: Pulse width problem with gtwizard 3.5 CPLL railing module

Jump to solution
BUFR is used to save on the BUFG count in the design. Please follow the workaround mentioned by Sai for your use case.

One more method is to connect the ODIV2 output of IBUFDS_GTE2 to CPLL railing logic instead of "O" output. In this method, the BUFR can be kept the same way.
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
Highlighted
Observer
Observer
8,812 Views
Registered: ‎12-03-2014

Re: Pulse width problem with gtwizard 3.5 CPLL railing module

Jump to solution

As I directly use the xci file in my design, I can't set USE_BUFG parameter nor modifying the connection the the IBUFDS_GTE2.
Saving BUFG is very important. Why not using BUFH in all case?

 

I fixed this by replacing the BUFR by a BUFH with a tcl script (at implementation):

set oldBUFR [get_cells */gtwizard_inst/U0/gtwizard_adc_i/cpll_railing0_i/use_bufr_cpll.refclk_buf]
set newBUFH [create_cell -reference BUFH */gtwizard_inst/U0/gtwizard_adc_i/cpll_railing0_i/use_bufh_cpll.refclk_buf]
connect_net -net [get_nets -of_objects [get_pins $oldBUFR/I]] -objects [get_pins $newBUFH/I]
connect_net -net [get_nets -of_objects [get_pins $oldBUFR/O]] -objects [get_pins $newBUFH/O]
remove_cell $oldBUFR

View solution in original post