UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor davee
Visitor
3,104 Views
Registered: ‎06-07-2017

Aurora 64B/66B Clock Compensation

Jump to solution

Hi,

I have a general question about Clock Compensation (CC) with Aurora 64B/66B cores.

I am using an Ultrascale XCVU125 GTH Aurora Core to communicate with a legacy design

Virtex-7 XC7VX1140 GTH Aurora Core. The original Virtex-7 core had been designed with CC

disabled to improve throughput, as it was communicating with another Virtex-7 device and they both shared

the same reference clock (thus CC not necessary). This works fine.

The new Ultrascale device Aurora core has CC enabled by default in the generated IP, so is different to the Virtex-7.

Can a core with CC disabled communicate with a core that has CC enabled (still sharing the same reference clock)?

Or do both cores need to either have CC enabled or CC disabled?

Thanks.

0 Kudos
1 Solution

Accepted Solutions
Visitor davee
Visitor
4,534 Views
Registered: ‎06-07-2017

Re: Aurora 64B/66B Clock Compensation

Jump to solution

I believe I have now answered my question, so here is an explanation that may be useful to others.

 

If CC is disabled in Virtex-7, but enabled in Ultrascale, the devices will not be able to communicate. CC either needs to be disabled in both Virtex-7/Ultrascale Aurora cores, or enabled in both Virtex-7/Ultrascale cores. With CC disabled in my legacy Virtex-7 design, CC characters are not transmitted to the Ultrascale core. There is a watchdog timer inside the Aurora cores which is looking for CC characters, and if these are not seen then the Aurora link is reset. This meant that my Ultrascale Aurora core was being continually reset and therefore would not communicate correctly. I have now disabled CC in the Ultrascale core as well, and the devices are now able to communicate.

 

As mentioned above by Austin, CC is enabled by default in the Aurora cores, and the user should not override it. This is good advice and should be followed. However as I was dealing with a legacy design it was necessary for me to do this.

0 Kudos
5 Replies
Scholar austin
Scholar
3,091 Views
Registered: ‎02-27-2008

Re: Aurora 64B/66B Clock Compensation

Jump to solution

d,

 

Given this option is set by the software automatically (comparing 7 series with US clocking users guides), and the user should not override it, I would say "yes" it would work.  7 series set it properly for a 7 series device, US set it properly for that device (to provide a working design in either/both).

 

As it relates to hold timing, it applies to exactly that device family, and how the core uses it for that family.  As it also relates perhaps to a recovered clock, it only matters that the recovered data is timed properly by the recovered clock.

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Visitor davee
Visitor
3,062 Views
Registered: ‎06-07-2017

Re: Aurora 64B/66B Clock Compensation

Jump to solution

Thanks for your reply Austin.

 

Just to help my understanding; Xilinx recommend that Clock Compensation should always be enabled in both Virtex-7

and Ultrascale Aurora cores?

 

However if CC is disabled in Virtex-7, but enabled in Ultrascale, the two devices should still be able to communicate

without error?

 

Thanks

D.

0 Kudos
Moderator
Moderator
2,959 Views
Registered: ‎02-16-2010

Re: Aurora 64B/66B Clock Compensation

Jump to solution
CC with Aurora core is used for dual purpose. Both clock compensation and to ensure far end GT-Rx is properly reset when valid data is present at the FPGA inputs. This is the reason for the IP recommendation to keep the CC logic and enabling it by default.
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
Visitor davee
Visitor
2,873 Views
Registered: ‎06-07-2017

Re: Aurora 64B/66B Clock Compensation

Jump to solution

Thanks venkata.

 

However I would still like to understand, if CC is disabled in Virtex-7, but enabled in Ultrascale, should the two devices be able to communicate without error (assuming they are using the same reference clock)?

0 Kudos
Visitor davee
Visitor
4,535 Views
Registered: ‎06-07-2017

Re: Aurora 64B/66B Clock Compensation

Jump to solution

I believe I have now answered my question, so here is an explanation that may be useful to others.

 

If CC is disabled in Virtex-7, but enabled in Ultrascale, the devices will not be able to communicate. CC either needs to be disabled in both Virtex-7/Ultrascale Aurora cores, or enabled in both Virtex-7/Ultrascale cores. With CC disabled in my legacy Virtex-7 design, CC characters are not transmitted to the Ultrascale core. There is a watchdog timer inside the Aurora cores which is looking for CC characters, and if these are not seen then the Aurora link is reset. This meant that my Ultrascale Aurora core was being continually reset and therefore would not communicate correctly. I have now disabled CC in the Ultrascale core as well, and the devices are now able to communicate.

 

As mentioned above by Austin, CC is enabled by default in the Aurora cores, and the user should not override it. This is good advice and should be followed. However as I was dealing with a legacy design it was necessary for me to do this.

0 Kudos