Xilinx RocketIO problems

Are you trying to implement your own protocol? If you are just transferring data between the devices, why not use the Aurora protocol? It is simple and already debugged, and works quite well.

[RocketIO]

As a matter of fact, I have to write a conduit for a special application protocol already established. I do have the source code for that protocol and I basically followed each step which is done, but had no success. It seems so strange, that the parallel loopback works, but the serial does not. As a matter of fact this is my first high speed protocol experience and as far as I understand the synchronization (apart from bit alignment) is done by the RocketIO controller. I still find no explanation why the bits are changed in that drastic matter (input doesn't seem to match output in any way) I also had a look at the Aurora protocol, but I am not sure if that is really going to help me (even though I'm still looking through it). At this point pretty much every idea is welcome.

John

I have 2 guesses as to what is likely wrong.

1) You didn't wait long enough for the MGT PLL and CDR to be fully functional and if you run it another 10K+ words things might be OK. 2) Your special application protocol is not properly aligned as you either haven't set the 8B10B comma alignment sequences to the values defined in your protocol (along with the correct initialization control) or if you have a scrambled protocol you haven't implemented an aligner in the fabric.

When you start something new and foreign, IMHO, it is best to start from a known working solution that is close to what you are attempting to do. Then you can verify that your setup is correct, understand how it works, tweak it, and eventually build your own unique version. In this case starting with the Aurora 8B10B example designs for Virtex-II Pro would be a very good first step.

Ed McGettigan

-- Xilinx Inc.

Howdy John,

At the risk of pointing out the obvious, it's pretty much gotta be one of the following:

1. MGT power (LDO fed, right?)
2. MGT ref clock (tried renting a differential scope probe? Coming from an XO [not a PLL]? Low jitter?)
3. chip-to-chip problem (board-level signal integrity through traces, connectors, ac-coupling, etc)
4. Protocol (anything in the digital domain - like byte alignment that others have hinted at, or not crossing clock domains correctly)

One item to be aware of: the analog loopback (looping TX data to RX data) is exactly that - analog. While I wouldn't call it useless, it is VERY sensitive because you end up with a great big stub hanging off due to the trace to your other FPGA. If you happened to have connected power to a spare MGT, you might try looping back there.

Good luck,

Marc

[...]

I double-checked on every bit regarding the alignment and finally found my (dumb) mistake. One signal for the Phase-alignment was not connected correctly. You can imagine how I felt when finding that out. Once connected the simulation does what I expect it to. Right now the "correct" data is being received after about 50 to 60 clock cycles in the ISE Simulator. (I am aware that this might take a lot longer when being deployed).

tnx to all who helped

John