DS32EL0124/421 Error rate / Link losses

Hi Harry,

Remote Sense allows the DS32EL0124 or DS32ELX0124 deserializer to send a signal upstream to the DS32EL0421 or DS32ELX0421 serializer to indicate that the device is not locked. If the serializer detects this signal then the data present on the LVDS inputs is ignored and a training pattern is instead transmitted out. If the deserializer is able to achieve lock it will stop sending the signal, at which point the serializer will resume sending the data that is latched in from the LVDS inputs.

Note, the Remote Sense feature is not capable of distinguishing errors from actual data. Remote Sense is only use to ensure that training pattern is sent out from the serializer to the deserializer for the purposes of lane alignment and lock.

Also, you can operate the chipset with 5-LVDS lanes of data and Remote Sense activated. If the DC Balance feature is activate then the 5th LVDS lane is used signal data transmission or idle character transmission.


If you are having trouble with EMC, I would consider the following:

- using common mode chokes on the high speed differential traces
- use shielding with low impedance ground connections for any high speed cable interfaces
- if vias are implemented on the high speed traces, be sure to also place return (GND) vias near the differential vias


Mike Wolfe
DPS APPS / SVA

Dear Mike,
thank you so much for your detailled answering about the remote sense feature.

So, the main aspect of the remote-sense feature is to take care about achieving a lock and re-locking if a lost of lock is detected. I think this is clear for now. It's good to know that the training doesn't have to be done manually.

Ok, so the fifth lane would be available, as long as we don't activate the DC Balance feature. In our application, both sides can't be galvanically isolated - are there any other reasons why we should enable the DC Balance? Is it used to keep the DC value on the signal in a defined range, don't letting it drift away over time depending on the transmitted data?

Thank you for your tips regarding EMC:
- on our prototyping board we already have the following CMC in the highspeed trace: Würth 744230900.
- In a sample design, we've seen a serial coupling capacitor in the high-speed trace. Would it be better than the CMC, which is recommended?
- Shielding is always a crucial tasks - we are aware about it, although it is quite difficulty sometimes.
- Vias: We don't have any vias on the high-speed traces, neither on the 5 LVDS lanes nor on the CML highspeed trace except the pins of the RJ45 connector.
- What about the performance of the gigabit link over a CAT cable with RJ45 connectors? We know, that coax SMA would be better, but we are stucked on RJ45 atm. (The datasheet doesn't say anything about it)


While performing tests with our prototyping board, it is crucial for us to get some information about the reliability of the link on different cable types. So we plan to do a bit error rate test. Are there some features in the DS32 chips or do we have to detect and count the errors manually after reception in the FPGA? (We thought that we could observe errors in deserializer's registers 2B&2D, but they are stucked to zero, even when we plug out the cable and the lock is lost...)

Thank you for your hints!

Best regards,
Harry

Hi Harry,

DC balancing is important for any AC coupled interconnect. As you noted, you do not want the data to drift too far one way or the other.

For cable reach, depending on your system conditions you may be able to achieve up to 20m with 24AWG CAT-6 cable. If you plan to utilize additional wire pairs within the cable you may reduce the maximum cable reach. If cable distance is critical for you application you could consider adding a DS30EA101 for additional reach or margin. The DS30EA101 is an adaptive cable equalizer rate up to 3.125 Gbps.

MIke Wolfe
DPS APPS / SVA

Dear Mike, thanks again.

Yes, we thought to utilize the four pairs of the cat cable as follows:

• 1-2: First lane of highspeed downlink-channel 2.5Gbps (with DS32's)
• 3-6: 5V supply / GND for peripheral supply
• 4-5: Low-speed LVDS 120Mbps uplink-channel (with SN65LV1224/1024)
• 7-8: Second lane of highspeed downlink-channel 2.5Gbps (with DS32's)

Do you see any problems with utilizing the cable this way? What about Xtalk when driving at this speed? If we manage to reach 10m, this would be sufficient.

Can you please explain some details about the bit error detection, which I noted in my last post - or please let me know if I didn't have made myself clear about that and I'll try to describe my question more in detail.

Thank you and kind regards - Harry

Hi Harry,

The cable wiring seems OK. Pair 3-6 always interacts more with pair 1-2 and pair 4-5 due to the standard wiring of the connector. CAT-6 cable will give you better isolation for the various pairs for the length of the cable, compared to CAT-5, but in the end you will have cross-talk at the connectors.

Keep in mind that LVDS signaling requires a common ground, so you should take care to ensure that power and GND are established before sending data over the LVDS connection. This is typically implemented as a First to Make, Last to Break ground connection or circuitry. For the DS32EL0421/DS32EL0124 links, the interconnect can be AC coupled.

For the data rates of the DS32EL0421/DS32EL0124 links, you mentioned 2.5 Gbps. Is that your application payload or the line rate? If it is your application payload and then you use the DC balancing circuit your line rate becomes 3.125 Gbps.

For the bit error detection, the DS32EL0421/DS32EL0124 are capable of performing an internal bit error selft test (BIST). This only checks for errors between the DS32EL0421 output and the DS32EL0124 input. It does not take into account the parallel LVDS data integrity of either device. Note that the BIST operation disrupts the normal operation of the devices. When in BIST mode, the DS32EL0421 ignores any data present on the parallel LVDS inputs and instead generates its own PRBS sequence. I can send you instructions for operating this test mode, but the best way to measure link performance and reliability is to generate and check for errors within the FPGAs.


Mike Wolfe
DPS APPS / SVA

Hi,

some more information about our current setup and the future plans:

We use a combination of SN65LV1224B / SN65LV1023A in our current configuration running at 576Mbps (self-built cameras <-> framegrabber). The cable runs for around 6m through the machine (passing by power supplies, servo and stepper motors, causing a lot of distortions. But atm we are able to handle these distortions with good grounding and shielding. For the future we need a faster connection because of higher resolution cameras and higher frame rate. The CAT5 cable used is flexible and specialized for the cable chain, so the plan would be to use the same cable for the new setup. We are evaluating a similar CAT6 cable in the meanwhile, but it has the drawback that is about 2mm thicker, which causes problems in the cable chain.

I mentioned the 2.5Gbps, because we plan to use the channel aggregation approach, described in application note AN-1887. Using the DC-balancing this should give us a total data payload of 5Gbps, spread on two lanes, isn't it?

ad BIST:
Ok, so the normal approach would be to measure the bit errors with a test setup on both FPGA sides? This is what I've done lately: I started a burst of data on transmitter side (a simple 16bit counter), spread it on the 5 LVDS lanes to the transmitter and checked the counter values and counted the number of errors on the receiver side. Then I tested with various cable length, transmission speeds and (most challenging) various equalizer/pre-emphasis settings. With some combination of settings and cable length, the DS32 chips weren't even able to establish a link (LOCK signal was blinking), but with the correct setting the error counter stayed at zero. So, is this a approach you would prefer to test channel reliability or would you prefer other methods? I didn't have time to test the channel aggregation setup yet, but I plan to test it soon. So maybe you can send me the documentation about the internal BIST, it would be interesting any way.

In the past, we had sometimes observed random lock losts with the SN65LV1224B / SN65LV1023A setup on the receiver side. We think this is due to bad jitter values on the transmitter side, we are working on that. But, for the future setup, we wonder if there would be a mechanism in the DS32s chips, which monitors such problems like bit errors or lost locks and similar during the "normal operation" with not using a special BIST mode? Like a "problem counter", which could be read out every now and then to qualify a link reliability? (I hope I made myself clear...)

Thank you very much for the support,
regards, Harry