cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
hans.ingelberts
Visitor
Visitor
1,000 Views
Registered: ‎06-03-2018

Aurora 8B10B user clock frequency incorrectly reported from Vivado 2018.2 and forward

Hello,

My design (originally created in Vivado 2017.4) uses an Aurora 8B10B IP block.

I have been using and working on this design for about a year and the Aurora IP functions as expected.

Due to some video IP license restrictions I had to upgrade my design to the newer (2018-2019) tool versions.

Also the Aurora 8B10B was upgraded to a newer version and now I get a wrongly reported user_clk_out frequency (double) and this results in frequency restriction violations in other IP blocks and impeded synthesis.

I tested different tool versions and found that the user_clk_out frequency was still reported correctly in version 2018.1 (Aurora Version 11.1 (Rev. 4)) and not anymore from 2018.2 (Version 11.1 (Rev. 5)) and forward.

These are my Aurora configurations:

Knipsel.PNG

A line rate of 3.125 Gbps and line width of 4 bytes should result in a user clock of 78.125MHz and this is also reported like that in Vivado 2018.1.

But in Vivado 2018.2 I get the double frequency clock of 156.25MHz. This is the frequency for a 2 byte line width but I get the frequency regardless of the line width, both 2 byte and 4 byte line width report 156.25 MHz.

In the Aurora Version 11.1 (Rev. 5) there was a Bug Fix: Fixed display only issue showing improper clock frequencies for tx_out_clk and sync_clk in IPI flow for GTP devices.

It seems that at least for my case this now results in an improper clock frequency reported for user_clk_out.

I did a sanity check and made small test design with an Aurora 8B10B and measured the user clock and indeed it was 78.125 MHz while Vivado reports 156.25MHz

 

1. It seems to me this is a proper bug that should be fixed. If not, what could I be doing wrong?

2. What work-around could I use? Can I somehow overrule that wrongly reported frequency? Or (less preferred), can I force validation/synthesis in spite of the clock frequency violations?

 

Thanks for looking into this!

 

0 Kudos
2 Replies
guozhenp
Xilinx Employee
Xilinx Employee
939 Views
Registered: ‎05-01-2013

If you see the clock is still 78M in simulation or on board, please go ahead to use the IP core.

The double clock frequency may be just a tool display issue.

0 Kudos
jlipsher
Visitor
Visitor
734 Views
Registered: ‎12-09-2010

It's really hard to imagine that this exact bug still exists in Vivado revision 2019.1!  But that's what I'm currently seeing.  Is this really so far down on the priority stack that it can't get fixed after 6 years??

0 Kudos