01-12-2010 02:55 AM
Aurora core of Virtex-4 and Virtex-5 are generated with following features.
1) Two 2-byte lane Streaming mode
2) Full Duplex
3) 8B/10B coding
4) Reference clock - 125 MHz.
5) Version 3.0
Scenario when it fails is :
1) Two channel partners are Virtex-4 Aurora v3.0 and Virtex-5 v3.0 are connected in full duplex streaming mode.
2) Both are working fine in the normal operation when both channels are up
3) In between when we reload the Virtex-4 Aurora v3.0 fpga then channel goes down and comes up ( Virtex-5 is not reloaded)
a) Virtex-5 aurora starts requesting for data from Virtex-4 aurora by putting x"00& quot; on the 'TXD' and asserting 'TX_SRC_RD Y_N'
b) We are able to see the data transmitte d by the Virtex-4 Aurora on 'RXD' of Virtex-5 aurora. But 'RX_SRC_RD Y_N' of Virtex-5 aurora is not asserted.
c) Virtex-5 user interface is able to validate the data and keeps sending the requests for more data on 'TXD'.
4) When one channel partner goes down and comes-up, what is the status of other Aurora core?
5) Is it a initializa tion issue?
Is anybody facing the similar problem? Pls. do help.
02-04-2010 09:45 AM
Have you received any response to your post, or even solved the problem? We are experiencing a similar problem with occasional loss of data and we cannot figure out how to fix it.
02-04-2010 08:16 PM
02-04-2010 09:10 PM
I don't think either one of us is talking about occasional bits but rather complete words (16 bits in my case since I use a single lane). Naika is also claiming that the data indeed arrives but the RX_SRC_RDY_N signal doesn't indicate it.
As far as I have understood the behavior of the Aurora core, single bit errors due to signal integrity problems would be indicated by either the HARD_ERROR or SOFT_ERROR signal, something which does not happen in my design.
I have also done a test where I have set up a ML507 board with the same design I'm using on my custom board and I see the same error there, when communication between two different Aurora blocks on different transceiver blocks.
However, as you mentioned it; How would one go about in order to "characterize" and "optimize" the transceiver settings? This is not something that can be changed in the Aurora Wizard in Coregen, can it?
02-05-2010 04:01 AM
Its sure that its not at all related to signal intigrety...
We are able to see the data on the logic analyzer on the RX_D but there is no RX_SRC_RDY_N asserted..
definitely there is some problem in the decoding of the control charatcers or the statemachine..
Pls. do help if you any special means for characterization / optimization???
02-12-2010 01:59 AM
Which version of ISE are you using?
Are you using and flow control?
We are using ISE 11.3.
On our custom board we are using a 125MHz reference. On the ML507 there is a 150MHz. Same error.
We have tried using both framing and streaming. Same error.
We have tried different transfer rates. Same error.
The value of RX_SRC_RDY_N is dependent on a few other signals (depending on what kind of interface you are using). Have you been able to determine which signal that fails? Is it possible that the timing analyzer fails to verify the timing of some of these signals so that something goes wrong as the two different clock sources drift?
We have tried opening a webcase but the responses have left us somewhat unsatisfied...
02-12-2010 02:44 AM
I'm using 125 Mhz ref. clock on both the boards. It is streaming mode with no flow control...
02-14-2010 11:00 PM
Issue seems to be an initialization (to be precise Virtex-4 FX Aurora 8B10B design).
In board-to-board setup, one aurora 8B10B design in one board undergoing power cycle (reset or FPGA is configured again), other board's Aurora 8B10B design will get reinitialized due to following sequence : no data on serial lines --> loss of CDR / excessive soft error --> hard error on Aurora --> Re-initialize the channel.
Virtex-4 FX Aurora 8B10B has longer initialization than Virtex-5 Aurora 8B10B due to reset sequence imposed by Virtex-4 MGT (GT11_INIT_TX/RX).
To confirm this, you can try either of the following:
1. Force the Virtex-5 Aurora 8B10B to longer by some glue logic
2. Observe reconfiguring Virtex-5 Aurora 8B10B after establishing link in board-to-board setup. I hope this scenario should work.
Hope this helps-Killi
02-16-2010 06:42 AM
Just thought I would share my experiences with you over this issue, I have been suffering with exact same problem, V4 to V5, RX_SRC_RDY_N occassionally not detecting data after initialiation when the V4 is reconfigured, though channel_up and lane_up indicate that the link is good.
Xilinx recommended to upgrade to V5.1 core for the V5 but has had no effect, nor compiling the core with XST. Not so easy to upgrade the V4 to the latest as the 125MHz clock is no longer available as an option in coregen 11.4, so for the moment stuck at V3.0.
02-16-2010 06:53 AM
Your shared experience is very much appreciated. As I hope has been clear from my previous posts, we are having the issue between two Virtex5 FPGAs (one SX and FX) but we see the same problem on the ML507 board. On the ML507 board we are using two separate transceivers through the SMA connectors and the SATA connectors with a loopback cable and the same issue is evident.
We have tried to ask Xilinx whether and upgrade to 11.4 (and core 5.1) would be helpful but received no response to that. If it would help I would presume that there was a known bug in the older cores but that's unheard of.
The fact that 125MHz isn't an option in 11.4 is news to me. Is there a know reason for that? It would be good to know this and replace the 125MHz reference oscillators for the next generation of our PCB.
02-16-2010 08:08 PM
Virtex-5 Aurora 8B10B has to be upgraded to Aurora 8B10B v5.1 core
Virtex-4 Aurora 8B10B has to be updated to Aurora 8B10B for Virtex-4 FX FPGA v3.1
May i know the line rate that Aurora design is running at. So that i can give my comments on 125MHz option.
02-16-2010 08:18 PM
Value of 3 in PLL_DIVSEL_FB (refer UG198) is removed due to poor performance of this divider setting in hardware. This restricts some of the REFCLK options. I can provide more details if i know the line rate/device/speed grade for more details.
Hope this helps
02-16-2010 11:17 PM
Currently we are using 1.25Gbps but we hope to increase this in future designs. The connection will be between FX70-2 and SX95-2.
I'd presume that the removal of the 125MHz option is unrealted to our problem as we can see it with both 125MHz and 150MHz ref clocks and independent of line rate.
03-02-2010 04:07 AM
I tried Aurora v5.1 in V5 .. did not help..
I could not try Aurora v3.1 in V4 because there is no option of 125MHz.
Line rate is 2.5 gbps...
03-02-2010 05:02 AM
This may be of some use, I have found this xilinx Answer Record, which may account for the problem of no RX_SRC_RDY_N.
In the process of implementing the last option, needs a bit of debugging.
03-02-2010 07:00 AM
This is a very interesting Answer Record which I have not previously seen. It talks strictly about the GTP transceiver. Do you think the same applies for the GTX? This is also a problem unrelated to Aurora and I would presume that the Aurora core handles these issues but I might be wrong.
Are you implementing these options in your Aurora core or are you using the transceivers with other protocols?
03-02-2010 08:11 AM
my implementation is with the aurora core, if other impelmentations use the same basic decode state machine then one can assume that the same problem will occur. My take on it is that it is the decode state machine doesn't always get it right at after a channel has gone down and back up again, and miss aligns the data, so nothing is valid. In the process of asserting PMA_INIT after I have counted 6 * DO_CC cylces, as these are roughly every 40us, not working as planned yet needs a little bit more debug
03-02-2010 09:05 PM
AR# 25385 is applicable only for Virtex-5 GTP.
Problem symptom is no CHANNEL_UP in case Aurora core.
Since we are discussing interoperability between Virtex-4 and Virtex-5 GTX in this thread, this AR is not applicable imho.
03-30-2010 06:13 AM
If this issue is not fixed so far, here is the wokaround:
DO_CC is colliding with data which causes drop of the data @ RX.
DO_CC is enable signal for Clock Correction sequence transmission.
As per Aurora 8B10B protocol, CC is highest priority of all other data.
Fix is available in TX_STREAM module of the V4FX Aurora 8B10B v3.1
I suggest to generate the V4FX Aurora 8B10B v3.1 core with different line rate and do the diff between V3.0 core and V3.1 core
This should resolve the issue.
Since REFCLK (125MHz) was not able to generate from V4FX Aurora 8B10B v3.1 core, leave the MGT wrapper settings as it or take cautios approach by reading UG076 for any modifications. CLOCK_MODULE parameters will be dealt carefully as REFCLK is different.
Hope this helps.
Report to the forum what you observe