10-18-2011 01:19 PM
I have a system with two high speed serdes chips communicating - an XUPv5 and aTI chip. If the TI chip is powered on, followed by an XUPv5 reset, things work fine. However, if the TI chip is reset, the XUPv5 serdes freezes and stops receiving data.
I assume this is because it lost sychronization and doesn't attempt to recover.
What external action in my hardware should I take to get the SERDES on the XUPv5 to resynchronize?
RXRESET seems like a good candidate, but my verilog wrapper doesn't export this signal.
I also tried toggling the "RX_LOSS_OF_SYNC_FSM" flag, to no effect.
10-24-2011 06:57 PM - edited 10-24-2011 07:04 PM
10-21-2011 07:36 AM
No, just the raw GTP IP. We have the GTP tile and a couple of clock generation modules.
Because our interface is so simple, I am now suspicious that we are having clock compensation issues between the boards. I don't really know how to deal with that though. I wish that we could use aurora, but unfortunately, we are using a TI on the other board. It is connected to an FPGA though. Is there a sample design that looks at this sort of scenario.
I did manage to find the RXRESET line - it was buried under a couple levels of verilog. Still not sure on how to reset though.
Also, is it possible/advisable to use aurora on one lane of a GTP while using the raw serdes interface on the other?
10-24-2011 08:43 AM
I switched to trying to get an aurora based-link between two XUPV5 boards working, just to make sure that that could be done.
The goal in this experiment is to show 1) the aurora can reset itself correctly on loss of connection 2) no errors occur in the aurora channel.
I managed to get a 2gbps aurora sort of working by clocking it with the 200Mhz on board clock. The good news is that the channel comes up and data seems to flow between the boards. I don't get a deadlock or dropped data, so I think I am picking up the correct number of data across the link.
However, I am getting soft errors at the rate of a couple hundred per second, but only on one of the FPGAs. The other board reports 0 soft errors.
When I was bringing the board up, I also remarked that one board appeared to be generating spurious receptions (i.e. board a is not transmitting, but board b is receiving something.
What can cause these sorts of errors?
Is the 200 Mhz clock a losing proposition?
I think I will try swapping boards next just to see what is going on.
10-24-2011 08:54 AM
I suppose I should also list the chief pitfall that I encountered:
The RESET signal to the aurora test module is active low. It should properly be labelled RESET_N. This is remarked upon elsewhere in the forums, but Xilinx, you should really fix this.
10-24-2011 01:52 PM
A potential problem is that I am using the XUPV5 200Mhz clock and routing it through the FPGA. This probably contributes to the errors that I am seeing. Could this be the case?
Which clocks should I use to produce a 2Gbps transceiver?
10-24-2011 04:40 PM
Okay, I switched to using the clock (150Mhz) tied to the GTP clock fabric. This dramatically cut down on errors. However, there are still errors.
Is it realistic to expect that aurora will be error free?
10-24-2011 06:17 PM
It is realistic to expect a near zero bit error rate, but you must have a properly designed system this includes:
1) Using a low jitter LVDS or LVPECL clock in to the REFCLK inputs of the MGT
2) Both sides of the link should have less than 100ppm of difference between clock sources
3) The transmission channel between the TX and RX must be low loss
4) The TX output swing and pre-emphasis should be optimized for the transmission channel
5) The RX input equalization should be optimized for the transmission channel
Routing the clock through the fabric violates point 1 and there is insufficient information in your prior posts to comment on points 2-5.
10-24-2011 06:46 PM
Ah. This response is helpful.
1) Initially I was not using the REFCLK input. However, I have switched to using the LVDS clock listed in the manual (the 150Mhz clock on y3/y4). This clock is not 200MHz (a problem for a different day), so I had to regenerate the aurora design. I assume that this is tied to the REFCLK, because I no longer need to instantiate a BUFG on the clock.
2) I would assume this is the case, since I am using two XUPV5. I imagine the performance difference that I am seeing when I swap boards is related to clock differential.
3) I am using the copper SATA cable that comes with the XUPV5. I assume that this is sufficient. I am planning on migrating to SMA as soon as the parts come in, but I'd still like to get things working over sata.
4) & 5) I read a little about this in the RocketIO manual. Should I run the ibert to get parameter, or can I hand tune? Or is there a spec sheet (or a knowledgeable person) that would tell me what the right parameters are? I would assume that the XUPV5 has enough deployment that someone has figured it out.
10-24-2011 06:57 PM - edited 10-24-2011 07:04 PM
10-24-2011 07:33 PM
Okay! Now the number of errors has been reduced dramatically - indeed the only errors appear to occur at start up. I would imagine that clock compensation might need to run at least once before attempting to send data.
10-25-2011 08:16 AM
> I may have the issue mentioned here with the clock correction.
For future readers of this thread, could you please confirm that you were using an older revision of the Aurora core that had a bug in the example design that prevented clock correction sequences from transmitting and that upgrading to a new revision fixed the problem?
If this is correct which version did you use originally and then upgraded to?
10-25-2011 10:43 AM
I did not upgrade, I just applied the fix that was suggested, namely inverting the reset to the clock compensation module.
I'm using Xilinx 12.3 and aurora core aurora_8b10b_v5_2 for the Virtex 5. This bug occurs in the reference design provided by Xilinx, in the example_design.v file.
I may upgrade though. I will post those results when I do.