Xilinx RocketIO problems

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I am trying to establish a communication between two RocketIO driven
Virtex2P FPGAs. I am currently simulating the design running into the
following problem: When I set the RocketIO Transmitters (Xilinx
GT_CUSTOM) into parallel loopback mode everything is fine (received data
= sent data). Whenever I set it into serial loopback mode (or try to
communicate with another RocketIO receiver) I seem to receive strange
data (which doesn't seem to be connected to sent data in any way). I am
completely running out of ideas what I might do wrong, even though I am
just a starter with RocketIO. An yes, I did read the RocketIO Users
Guide, but I didn't find it very helpful for my problem.

tnx alot


Re: Xilinx RocketIO problems
Quoted text here. Click to load it

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.

Re: Xilinx RocketIO problems

Quoted text here. Click to load it

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.


Re: Xilinx RocketIO problems
Quoted text here. Click to load it

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.

Re: Xilinx RocketIO problems ->solved
Quoted text here. Click to load it
Quoted text here. Click to load it

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


Re: Xilinx RocketIO problems
Quoted text here. Click to load it

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,


Site Timeline