ADS54J66: Deterministic Disparity Errors While Receiving ILA Sequence with VC707 / Xilinx JESD Core

David,

What exactly do you mean by ++/-- disparity? If you set your firmware to ignore ILA errors, do you get valid data?

Regards,

Jim

Hi Jim,

the decoded octets are fine (ILA and data), so there is no need to ignore inconsistent ILA data (the receiver does this anyway). The problem is the running disparity of the encoded 10b data. According to the protocol, running disparity should be +-1 at most, so the transmitter changes the 8b10b disparity every octet, respecting symmetric symbols. If we capture the payload data received from the DAC after the Rx PHY (including ILA) and feed it to our HDL design as a "correctly" encoded 10b stream, we do not see any errors. But in the actual setup, there are disparity errors reported by the Rx for every second octet. As the link seems to be perfectly stable otherwise, I think we can rule out any accumulating DC imbalance. So I was wondering whether the DAC transmitters for some reason or in certain conditions allow for running disparity to be as high as +-2. The only way to find out on our side would be to probe the lanes directly, which we cannot do right now, so maybe one of the chip designers has an explanation for this. Our current. work-around is to ignore disparity errors (not ILA errors) on the receiving side altogether, which does not seem like a good permanent solution.

Thank you and best regards
David

David,

The only way we can think of that would cause this is if the polarity of a lane was swapped. Have you checked for this? Otherwise, we have never come across this issue from any other customer or during factory test. You may want to double check your firmware again.

Regards,

Jim

Hi Jim,

yes, we have checked the polarity of the lanes. These two users report very similar issues:

As you can see from their screenshots, the disparity errors also occur in every other byte. Unfortunately, there a no solutions given in these threads. What is striking, however, is that all three cases seem to be based on the same clocking configuration and FPGA IP cores.

Best regards,
David

David,

Can you try a different LMF setting or different clocking configuration and see if you still have the issue?

Regards,

Jim

Jim,

the issue seems to be connected to the way / order the JESD mode and K are written to the registers 0, 1, and 6 in the digital JESD bank.

Unfortunately, the datasheet gives inconsistent advice about several registers (e.g. the JESD_MODE_EN bit set in the suggested start-up sequence neither matches the register map nor the "example register writes") and the configuration file you sent us does not contain the first step at all:

0x690000 0x80 // set CTRL K, JESD MODE EN
0x690006 0x1F // set K to 32

For example, this seems to work at 10 GBps (no more disparity errors):
- select digital JESD bank (broadcast mode enabled)
- write 0x40 to register 0    // enable JESD mode
- write 0x01 to register 1    // JESD mode
- write 0x80 to register 0    // custom K
- write 0x1f to register 6    // K = 32

While this produces disparity errors in every second byte:
- write 0xc0 to register 0    // custom K and enable JESD mode
- write 0x01 to register 1    // same
- write 0x1f to register 6    // same

Do you have a definitive recommendation about the order the registers in the 6900 bank should be written to?

When decreasing the line rate to 5 GBps by dividing the input clock to 250 MHz, we observe that the chip inserts /K/ characters at the end of the first ILA multiframe (K=32) so sync is re-asserted by the FPGA and ILA is never completed.

Best regards,
David

David,

We are working on getting the next version of this data sheet released. The only order required is toggle the IL Reset in page 0x6800 address 0x00 after all other registers in this page have been written as these writes only take effect after this reset is toggled from high to low.

I do not see how the chip could insert /K/ characters at the end of ILA unless SYNC was sent low or bit 7 of address 0x01 in page 0x6900 is set to "1". 

Regards,

Jim