cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
apogeedbkxilinx
Adventurer
Adventurer
10,744 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
apogeedbkxilinx
Adventurer
Adventurer
17,527 Views
Registered: ‎04-02-2010

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.

View solution in original post

0 Kudos
10 Replies
venkata
Moderator
Moderator
10,733 Views
Registered: ‎02-16-2010
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
apogeedbkxilinx
Adventurer
Adventurer
10,724 Views
Registered: ‎04-02-2010

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

0 Kudos
apogeedbkxilinx
Adventurer
Adventurer
10,709 Views
Registered: ‎04-02-2010

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
venkata
Moderator
Moderator
10,699 Views
Registered: ‎02-16-2010
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
apogeedbkxilinx
Adventurer
Adventurer
10,689 Views
Registered: ‎04-02-2010

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
venkata
Moderator
Moderator
10,674 Views
Registered: ‎02-16-2010
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
apogeedbkxilinx
Adventurer
Adventurer
10,668 Views
Registered: ‎04-02-2010

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
venkata
Moderator
Moderator
10,644 Views
Registered: ‎02-16-2010
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
venkata
Moderator
Moderator
10,581 Views
Registered: ‎02-16-2010
Could you find the way to get your design working?
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
apogeedbkxilinx
Adventurer
Adventurer
17,528 Views
Registered: ‎04-02-2010

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.

View solution in original post

0 Kudos