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: 
Adventurer
Adventurer
9,778 Views
Registered: ‎04-02-2010

Aurora channel down. IBERT clean

Jump to solution

Part: Kintex Ultrascale 115 ES2

Tool: Vivado 2015.2.1

IP: Aurora 64/66 v10.0

 

I have a board with about 100 single lane Aurora interfaces running at 10.3125Gb line rate.  About a dozen  have problems with the channel_up signal not staying up.  The channel up goes high for a while but does not stay up.  The other 80 or so don't have any problems.  Running IBERT on the problematic lanes using matching dirver and equalization setting has not shown any data errors with any of the PRBS patterns.

 

1. Has anyone seen anything similar?

2. How did you solve the problem?

3. Are there possibly other settings I should look into in IBERT beside txdiffctrl, precursor, postcursor, and DFE to more closely match Aurora 64/66?

 

I appreciate any help.

Tags (2)
1 Solution

Accepted Solutions
Highlighted
Adventurer
Adventurer
16,561 Views
Registered: ‎04-02-2010

Re: Aurora channel down. IBERT clean

Jump to solution

Thank you for checking in on this.  For the time being we have given up trying to get the core to work at our target line rate of 10.3125Gb/sec.  I suspect there is something not quite proper with the IP, but this is nearly impossible to prove.

We are currently running at 7.8Gb/sec which has shown itself to be reliable.  This is sufficient for a short-term benchmark.  I may be investigating more in the future when time permits and/or the core is upgraded again.

0 Kudos
10 Replies
Moderator
Moderator
9,767 Views
Registered: ‎02-16-2010

Re: Aurora channel down. IBERT clean

Jump to solution
Could you test only the problematic lanes with Aurora design?

Whether the failing lanes are any different from the other lanes?
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
Adventurer
Adventurer
9,758 Views
Registered: ‎04-02-2010

Re: Aurora channel down. IBERT clean

Jump to solution

Thanks for the suggestions. I'm looking into issues along these lines.

0 Kudos
Adventurer
Adventurer
9,743 Views
Registered: ‎04-02-2010

Re: Aurora channel down. IBERT clean

Jump to solution

I'm start to get better results on a problematic connection by applying the power on reset sequence from the Aurora 64/66 product guide (screen cap attached).  From these waveforms, there seems to be a requirement for "BoardA" and "BoardB" to synchronize their reset logic.  In particular BoardA releases pma_init, then boardB releases pma_init, then boardA releases reset_pb, then boardB releases pma_init.  Is this the intention?  I had thought that Aurora was self synchronizing without external control, but I may have been mistaken.

Thanks for any insights you can give.

Tags (2)
powerOnReset.PNG
0 Kudos
Moderator
Moderator
9,733 Views
Registered: ‎02-16-2010

Re: Aurora channel down. IBERT clean

Jump to solution
There is no sequencing required between the two boards. Your understanding is correct. Aurora Duplex core will self synchronize itself.
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
Adventurer
Adventurer
9,723 Views
Registered: ‎04-02-2010

Re: Aurora channel down. IBERT clean

Jump to solution

Thanks for the reply.  Further tests are showing that setting the RXCDRHOLD control to 1 is improving the behavior. 

 

With RXCDRHOLD set to 0 the channel stays up for hours before I see RXCDRLOCK deassert or the channel go down.

With RXCDRHOLD set to 1, I have yet to see any issues.

 

What are the drawbacks of setting RXCDRHOLD to 1?  In my application both sides of the Aurora channel are running off the same oscillator.

 

Thanks

0 Kudos
Moderator
Moderator
9,708 Views
Registered: ‎02-16-2010

Re: Aurora channel down. IBERT clean

Jump to solution
When RXCDRHOLD is set to "1", CDR will stop adapting to locking with incoming data.
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
Adventurer
Adventurer
9,702 Views
Registered: ‎04-02-2010

Re: Aurora channel down. IBERT clean

Jump to solution

Thanks for the reply.  This is what I understood from the user guide.

I was interested in more detailed/practical information if anyone has anything to share.  For example, does this mean there will tend to be problems across voltage/temperature variation?  Or is that not an issue?  Or other practical ramifications of making the CDR "stop adapting".

Tags (3)
0 Kudos
Moderator
Moderator
9,678 Views
Registered: ‎02-16-2010

Re: Aurora channel down. IBERT clean

Jump to solution
Aurora 64B66B enables DFE by default. If the channel attenuation is low, then you can try using LPM for your design.
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
Moderator
Moderator
9,615 Views
Registered: ‎02-16-2010

Re: Aurora channel down. IBERT clean

Jump to solution
Could you find the way to get your design working?
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
Highlighted
Adventurer
Adventurer
16,562 Views
Registered: ‎04-02-2010

Re: Aurora channel down. IBERT clean

Jump to solution

Thank you for checking in on this.  For the time being we have given up trying to get the core to work at our target line rate of 10.3125Gb/sec.  I suspect there is something not quite proper with the IP, but this is nearly impossible to prove.

We are currently running at 7.8Gb/sec which has shown itself to be reliable.  This is sufficient for a short-term benchmark.  I may be investigating more in the future when time permits and/or the core is upgraded again.

0 Kudos