cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
kef2189
Observer
Observer
6,511 Views
Registered: ‎02-18-2010

RXRESET Missing

Jump to solution

Hi,

 

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.

 

 

 

0 Kudos
1 Solution

Accepted Solutions
kef2189
Observer
Observer
5,451 Views
Registered: ‎02-18-2010

I may have the issue mentioned here with the clock correction. 

 

http://forums.xilinx.com/t5/Connectivity/Aurora-Core-on-ML605-evaluation-boards/td-p/102238

 

I will give this a try.

 

 

View solution in original post

14 Replies
luisb
Xilinx Employee
Xilinx Employee
6,496 Views
Registered: ‎04-06-2010
Are you using a certain protocol or core?
0 Kudos
kef2189
Observer
Observer
6,484 Views
Registered: ‎02-18-2010

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?

 

 

0 Kudos
kef2189
Observer
Observer
6,469 Views
Registered: ‎02-18-2010

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. 

0 Kudos
kef2189
Observer
Observer
6,464 Views
Registered: ‎02-18-2010

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.

0 Kudos
kef2189
Observer
Observer
6,453 Views
Registered: ‎02-18-2010

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?

 

 

0 Kudos
kef2189
Observer
Observer
6,447 Views
Registered: ‎02-18-2010

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?

 

 

0 Kudos
kef2189
Observer
Observer
6,444 Views
Registered: ‎02-18-2010

Interestingly, swapping boards seems to have an impact on the bit error rate. 

0 Kudos
mcgett
Xilinx Employee
Xilinx Employee
6,440 Views
Registered: ‎01-03-2008

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.

------Have you tried typing your question into Google? If not you should before posting.
Too many results? Try adding site:www.xilinx.com
0 Kudos
kef2189
Observer
Observer
6,438 Views
Registered: ‎02-18-2010

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.

 

 

0 Kudos
kef2189
Observer
Observer
5,452 Views
Registered: ‎02-18-2010

I may have the issue mentioned here with the clock correction. 

 

http://forums.xilinx.com/t5/Connectivity/Aurora-Core-on-ML605-evaluation-boards/td-p/102238

 

I will give this a try.

 

 

View solution in original post

kef2189
Observer
Observer
4,612 Views
Registered: ‎02-18-2010

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. 

 

 

0 Kudos
kef2189
Observer
Observer
4,607 Views
Registered: ‎02-18-2010

After 500 billion sucessful transfers, I think the problem is solved.

0 Kudos
mcgett
Xilinx Employee
Xilinx Employee
4,594 Views
Registered: ‎01-03-2008

> 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?

------Have you tried typing your question into Google? If not you should before posting.
Too many results? Try adding site:www.xilinx.com
0 Kudos
kef2189
Observer
Observer
4,587 Views
Registered: ‎02-18-2010

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.

0 Kudos