LX16EVK01 Channel Link III Ser/Des evaluation kit

From a customer:

We got the LX16EVK01 Channel Link III Ser/Des evaluation kit.

This is what we did:

1. Populated the voltage regulators on both boards.
2. Installed a 10 MHz oscillator (ASFLMB-10.000MHZ-LC-T) at location Y1 on the serializer board.
3. Set I/O voltage option jumper for VDIO = +3.3VDC on both boards.
4. Adjusted the output voltages of the on-board regulators from 0 to the required voltage using the on-board trimpots.
5. Connected the USB cable between the serializer and the deserializer boards.
6. Installed +5VDC power supplies to each board.
7. Set the serializer DIP switch to the following:
   1. PDB = HIGH
   2. M_S = HIGH
   3. RESO = LOW
   4. Set the deserializer to the following:
      1. RESO = LOW
      2. M_S = LOW
      3. BISTEN = HIGH
      4. PDB = HIGH
      5. Wired GPIO(0) & GPIO(1) to ground on the deserializer to select the external PCLK on the serializer.
      6. Powered up the boards
      7. Observed that the LOCK and PASS LEDs light up on the deserializer board.
      8. Observed with a scope that the PASS output from the deserializer chip is toggling ½ cycle HIGH AND ½ cycle LOW (50 NS HIGH / 50 NS LOW).  This is described in the DS92LX1621(2) datasheet page 34 as indicating two or more bits in a row have failed.  The PASS flag indicator on the bi-directional control channel on GPIO(0) of the serializer indicates there are no errors on this channel.  It is always HIGH.

Why is PASS toggling constantly?

I can make BISTEN LOW and send data from the serializer to the deserializer.  I have only tried applying data asynchronously with respect to the PCLK.  In this case the PASS output will stay high unless I apply asynchronous data around 5 MHz.  This makes sense there would be errors in this case since the data is coming in close to the PCLK rate and asynchronously.  I can imagine there might be some metastability which would cause data errors in the transmission.  In our intended application we will always apply data synchronously to the serializer.

We have not yet tried I2C communication with the serializer or deserializer chips.