Rocket IO testing

[rob d]

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

 

[Austin Lesea]

Rob,

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.

http://www.xilinx.com/bvdocs/appnotes/xapp661.pdf

Austin

rob d wrote:

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

 

[Hal Murray]

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.

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 suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[rob d]

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.

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