cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
11223344
Observer
Observer
407 Views
Registered: ‎04-17-2018

pulse_width_clock check_timing warning for GigE IP in Artix 7

Jump to solution

I have the same issue that was described in:

https://forums.xilinx.com/t5/Timing-Analysis/quot-Register-Latch-pins-need-pulse-width-check-quot-on-GTP-in/td-p/630383

but no solution seems to have been provided for that old post.

I find that the same issue is present in a GigE IP example design with Vivado 2018.3 and an Artix-7 part. Check Timing does not report any missing clock, but it does report 2 pulse_width_clock warnings:

        Register/Latch pins need pulse width check (2)

        core_wrapper_i/inst/pcs_pma_block_i/transceiver_inst/gtwizard_inst/inst/gtwizard_i/gt0_GTWIZARD_i/gtpe2_i/PLL0CLK

        core_wrapper_i/inst/pcs_pma_block_i/transceiver_inst/gtwizard_inst/inst/gtwizard_i/gt0_GTWIZARD_i/gtpe2_i/PLL1CLK

This is regarding a transceiver internal path between the GTPE2_COMMON cell and the GTPE2_CHANNEL cell.

Can you please confirm that this is not an issue? Just an erroneous warning? Is there a way to get rid of it?

0 Kudos
1 Solution

Accepted Solutions
hongh
Moderator
Moderator
248 Views
Registered: ‎11-04-2010

It's device related information and for 7-series device it can be safely ignored.

For ultrascale/Utrascle+ device, the RX/TXoutclk of the GT_CHANNEL can be derived by the reference clock. (The intermediate clock pin will also be assigned a derived clock)

For 7 series, the RX/TXoutclk of the GT_CHANNEL has to be created directly on its clock output pin(Here define in IP), instead of being derived from the reference clock. So the input clock pin of GT_CHANNEL primitive having no clock created and it won't affect the behavior of the GT_CHANNEL.

 

 

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

View solution in original post

5 Replies
hongh
Moderator
Moderator
387 Views
Registered: ‎11-04-2010

Please refer to the below discussion:

https://forums.xilinx.com/t5/Timing-Analysis/quot-Register-Latch-pins-need-pulse-width-check-quot-on-GTP-in/m-p/973911#M16745

If you still have question, please attach your xci file.

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
11223344
Observer
Observer
329 Views
Registered: ‎04-17-2018

Hello,

I don't find this post helpful.

This issue has to do with internal IP constraints and I am not ready to modify the IP constraints without the full support of a Xilinx expert.

I am attaching the IP xci as you requested. I generated this IP with 2018.3, and when I open the associated example design and run implementation I get the same check timing pulse_width_clock warnings.

Thank you for your help.

0 Kudos
11223344
Observer
Observer
326 Views
Registered: ‎04-17-2018
 
0 Kudos
hongh
Moderator
Moderator
249 Views
Registered: ‎11-04-2010

It's device related information and for 7-series device it can be safely ignored.

For ultrascale/Utrascle+ device, the RX/TXoutclk of the GT_CHANNEL can be derived by the reference clock. (The intermediate clock pin will also be assigned a derived clock)

For 7 series, the RX/TXoutclk of the GT_CHANNEL has to be created directly on its clock output pin(Here define in IP), instead of being derived from the reference clock. So the input clock pin of GT_CHANNEL primitive having no clock created and it won't affect the behavior of the GT_CHANNEL.

 

 

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

View solution in original post

11223344
Observer
Observer
173 Views
Registered: ‎04-17-2018

Thank you for this information!

0 Kudos