LMH1218: Alignment Jitter in SL12G and LMH1218 not locking to any rate.

Thank you for the quick reply Nasser,

Please see my replies below.

1). First of all, at 3G-SDI, device should be able to lock without register initialization. I suggest if we can try first to understand why at 3G there is no lock. So please just power up the device and make sure signal is present. Device should be able to lock under this condition.

I agree that we concentrate on getting the 3G locking. We are still having problems with the 12G but  we have now got the LMH1218 locking in 3G.

We had tried the test you suggested previously and yes, with no register initialization at all the device would lock in 3G but it would not lock with the minimum register settings for initialization.

We had to change the way we were Reading/Writing to/from registers. Previously we were just writing a register data byte and a mask byte. What we do now is to read the register, mask the bits we don't want to change e.g. Reserved Bits, write back the modified data byte and mask.

For example, we are setting a value in register 0x80.

0x80 0x40 0xF0.

What we do now is to read register 0x80, mask the bits we don't want to change e.g. Reserved Bits, write back the modified data byte (0x40) and mask 0xF0. The device is locked and the eye pattern amplitude changes accordingly.

However, we can change the value to e.g. 0x44 and we get a different eye pattern amplitude even though it is masked with 0xF0 which should not allow the bottom 4 bits to change?

Is it necessary to write the mask to the device?

Thanks in advance,

John

Hi John,

LMH1218 or other SDI devices uses Read/Modify/Write. To explain this further, please note the followings example for Read/Modify/Write steps"

Read:

a). Read lmh1218 register that you are planning to change. For example you read register 0x80 and the value is 0xA5 (note this is just an example to make Read/Modify/Write operation more clear).

Modify:

a). Your micro-controller, FPGA, or ASIC - in it's local memory - preserve bits that you do not want to change. For example, here we want to preserve lower nibble (reserve bits which is equal to 0x5).

b). Micro-controller/FPGA/ASIC in it's local memory changes the upper nibble (0xA) ONLY - bits that you want to change - and let's say you change this value to 0xB.

c). Micro-controller/FPGA/ASIC in it's local memory does  logical binary operation to create new 8 bits together (for example you logical OR 0xB0 with 0x05) and the result is 0xB5. 

Write:

a). Finally, Micro-controller/FPGA/ASIC does a write operation and writes back 0xB5 back into lmh1218 register.

Given these steps, we preserved bits that we did not want to change(i.e lower nibble) and just changed higher nibble that we wanted to change and wrote back the final value

As you can see, in your example you should write back 0x40 because reserved lower nibble has 0x0 value. Hope this make it clear.

Regards,,nasser 

Thank you for the excellent support Nasser,

There was a problem where we were not carrying out the Read, Modify, Write process correctly. We now have the devices locking in 3G and 12G with good eye patterns.

However, in 12G we are still having a problem with Alignment Jitter (please see below.) Our trace length from the output of the LMH1218 to the coax connector is only approx 10mm and so we set the CTLE register 0x03 to 0x00 for minimum boost setting on initialization. We also tried setting 0x13 to 0x02 to bypass stage 3 & 4 of the CTLE but this didn't seem to have any effect.

We have checked the layout considerations and have clearance around the devices and traces. Do you have any other suggestions that we could try to reduce the Alignment Jitter in 12G?

Thank you in advance,

John.

Hello Nasser,

Thanks again for your support. I think we are nearly there.

We are using 1M Belden 4694 with 12G BNCs and colour bars for alignment jitter tests.

We tried adjusting the output PLL bandwidth on the source device but found it made matters far worse. The default for this device is 0.13 Mhz and that yields the best results.

The Phabrix QX allows the alignment jitter monitor to be triggered on a single line and with the filter set to 10Khz we can see that is not flat. The alignment jitter figure is representing the peak to peak measurement of this and so it is high.

We found that this is not a fixed frequency causing this effect. It changes with video content. With live video we see additional undulations appearing in this display representing the alignment jitter?

At 59.94P the effect is less and the Alignment jitter is actually then within specification.  Please see below...

59.94P

50P

I think this could perhaps be to do with our source video rather than the LMH1218 but please let me know your thoughts so that we can be sure to eliminate it.

Thank you,

John

Hi John,

Alignment jitter is a band pass filter measuring jitter from 100KHz up to the one tenth of the data rate. Based on how clean or how jittery is the source video transmit clock/content and if the jitter is within the loop bandwidth of the LMH1218, this has wide impact on the overall alignment jitter measurement result. There are video sources with 0.12UI, 0.22UI or even 0.28UI of AJ. In summary, this is related to the video source FPGA/ASIC implementations. SMPTE specifies color bar with 1m  cable however there is no golden unit and FPGA/ASIC implementations are different from one vendor to another and this has wide impact on this measurement.

Regards,nasser