Rocket IO testing

Has anyone given any thought to rocket IO testing. I have to write some test firmware and can't find any advice of the XILINX site.

Lets assume that all my links go between FPGA's but that I don't want to have to control the transmitter and receiver as each FPGA is coupled to a different processor across a subrack.

My best option seems to be to free run the transmitter with a clock correction packet, followed by a byte sync(Comma) followed by a 1024 byte packet( each byte from an LFSR) with CRC enabled. Each receiver can then throw away the data and check that it's getting the correct number of packets/second and that none of the many error flags (in particular the CRC of course) are getting set.

In the long term it would be nice if I could control the transmitter at the same time so that I could force CRC errors and watch for them being received or turn off 8B10B for a while and plot BER against edge transitions so that getting a BER for the application becomes easier.

Any suggestions or url's greatly appreciated.

Rob D

Reply to
rob d
Loading thread data ...


We have a BERT core that provides for bit error rate testing, both generation of anything you want (8b10b, 2^n-1 patterns, XAUI stress, etc.) as well as registering the errors at the other end. When used with Chipscope Pro(tm), you save a few hundreds of thousands of dollars, and you can actually see what is going on, and really characterize your backplane.

Please work with your local FAE to get the BERT designs (covered by an app note), as well as to get the characterization report which will also be useful to you.

We have been able to walk into a "problem" situation, put the BERT core in place, cable the JTAG to a laptop, run Chipscope, and find and fix the problems in less than an afternoon.

formatting link

Aust> Has anyone given any thought to rocket IO testing. I have to write

Reply to
Austin Lesea

Are you trying to check the connectors and wires on the backplane? The wires and solder joints on the board? Or do you want to burn-in test the whole design?

If you are sending LFSR data, you might just as well check it bit-for-bit (byte-for-byte) at the receive end. You can do that on the other side of a recv fifo and such. If you copy/reuse that part of the logic from your real/main design, then you are testing that part of the design as well as that part of the on chip hardware.

The catch is getting the LFSR generators in sync. That's easy if you feed the received data (good or bad) into the receive LFSR rather than feeding the LFSR output back to itself. This is often used for scramblers - called self-synchronizing. Works great.

(The catch is that you get a multiple bit error for each error on the wire. The error pattern matches the 1s in the polynomial used in the LFSR.)

The mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
 Click to see the full signature
Reply to
Hal Murray

I was going to throw away the data because of the hastle in re-synchronizing but your suggestion makes instant sense. Many thanks.

Reply to
rob d

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.