• State
  • Locked Locked
  • Replies 16 replies
  • Subscribers 33 subscribers
  • Views 1659 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Issue with lock at low frequency for DS92lv1021 and DS92LV1212

Dexter
Intellectual 450 points
Other Parts Discussed in Thread: DS90LV001

I am using ds92lv1021, ds92lv1212 sedes for module communication. What i have observed that during initialization ( SYNC transmission) lock with serializer donot take place for frequency range 16 Mhz to 25 Mhz. Then un reliable lock occurs between 25 Mhz to 35 Mhz. After this permanent lock is received with frequency of 40 to 60 mhz. Why this is happening?? as SERDES should not operate above 40 MHz.

  • 0
    TI__Expert 3175 points
    Gaurav,Can you provide more details on the problem you mentioned?
    What is connected from the serializer to the de-serializer? cable or pcb, and how long?
    I suggest to review your schematic diagram to make sure they are connected correctly.
    Also suggest the following debugging to find what is the problem:
    1. Check the serializer DS90LV1021 is sending out signals at D0+- with a differential probe
    2. Check the deserialier DS90LV1212 input RIN+- with a differential probe, ensure the signal level is healthy
    3. Check the RCLK waveformThe DS92LV1021/1210 supports 16-40MHz clock rate.
    regards,TK Chin
  • 0 in reply to T.K. Chin
    Intellectual 450 points
    Serializer and deserializer are communicating over Cat5e cable through RJ45 connector. Tx+ Tx- connected to Pin 1 and 2 and Rx+ and Rx- are connected to pin 3 and 6 of RJ 45.
    I checked the signals on DO+ and RIN+- using single ended prob and signal levels are Ok.

    As i said serdes are locking properly (stable) after 40 Mhz(even though SERDES woring range is 16Mhz to 40 Mhz). Below this serdes get locked but get only for limited duration. The duration of Lock gets smaller with smaller Tclk frequency. During LOCK period correct RCLK is received.

    SERDES(DS92lv1021, DS92lv1212) is placed on the PCB. This PCB is getting Power, clock and other signals from FPGA Evaluation Kit (SP601, spartan-6) through FMC connector. CLock is also derived from the FPGA. Clock and all other signals are fed to SERDES through Voltage Translator (2.5 V to 3.3 V).
  • 0 in reply to Dexter
    TI__Expert 3175 points

    Hi Gaurav,

    If possible, please me the schematic on the serializer and de-serlizer.

    On CAT5 cable, how long is the cable you used?

    Since this is bi-directional links, there is crosstalk consideration for adjacent pair in the CAT5 cable you use. Pair 1-2 and pair 3-6 is of crosstalk concern.  If possible, use two pairs that are further apart in the connector, one pair at 1-2, one pair at 7-8.

    regards,

    TK Chin

  • 0 in reply to T.K. Chin
    Intellectual 450 points

    Hello,

    I have attached the schematic. I have tried with cable length from .5 meter to 5 meter with same result. In frequency range of 40-60 Mhz errorless communication take place  with cable length upto 1 meter above this data gets  corrupted. In the schematic, I have not mounted DS90LV001 buffer. So Serialiser and deserialiser are operating on different RJ45 connector.

    lvds_comm-sch(2).pdf

  • 0 in reply to Dexter
    TI__Expert 3175 points

    Gaurav,

    In the schematic, please remove the 100ohm at the serializer side (R1).

    For LVDS, need a 100ohm at the receiver side only, so keep R3.

    Suggest to remove the external bis R2, R4 to check if they cause any problem.

    regards,

    TK Chin

  • 0 in reply to T.K. Chin
    Intellectual 450 points

    I have tried with that too with same result.

  • 0 in reply to Dexter
    TI__Expert 3175 points
    It is hard debug remotely. Please send us some scope shots on the Serializer output, and at de-serializer inputs. We will review to see if we can find anything.
    Regards,TK Chin
  • 0 in reply to T.K. Chin
    TI__Guru* 88905 points
    Greetings Guarav:

    You mentioned at 40-60MHz TCLK the deserializer locks and there is no issue. But at lower TCLK rate the deserializer does not lock.

    1). As part of synchronization, the serializer sends out 6 zeros followed by 6 ones at TCLK rate. The SYNC1 or SYNC2 should be asserted for a minimum of 1024 TCLK period. Could you please confirm at 25 to 35MHz TCLK rate you have SYNC1/2 asserted for at minimum for 1024 TCLK cycles?

    2). Using TCLK to trigger scope, please provide us scope shot of the serializer output when operating at TCLK rate of 25 to 35 MHz and when operating at TCLK rate of 40 to 60 MHz. This is when SYNC1/2 are active.

    3). Using TCLK to trigger scope, please provide us scope shot of the serializer output when operating at TCLK rate of 25 to 35 MHz and when operating at TCLK rate of 40 to 60 MHz. This is after synchronization(SYNC1/2 are not active).

    Regards,,nasser
  • 0 in reply to Nasser Mohammadi
    Intellectual 450 points
    It seems the problem is on power supply side. I bypassed ferrite bead of deserialiser by a short cable and SERDES was getting locked with data transmission (very low data error) . with ferrite bead power supply ripple was around 30mv P-P and without ferrite baed it reduced slightly to 25mv P-P. Any suggestion on this ???
  • 0 in reply to Dexter
    Intellectual 450 points
    MAy i know how this pll is correlated to power supply ripples??
  • 0 in reply to Dexter
    TI__Guru* 88905 points
    Hi Gaurav,

    Glad to hear you found the root cause of the problem. Based on your finding, it seems the ripple or power supply noise could be close to the loop bandwidth of the de-serializer clock and data recovery unit. At higher data rate the loop bandwidth is higher and thus it was not as much effected by the power supply noise. But at lower data rate this effected the device operation.

    Regards,,nasser
  • 0 in reply to Nasser Mohammadi
    Intellectual 450 points
    Hello,

    After removing ferrite bead, proper communication is taking place. But ferrite bead has to be placed to avoid high frequency to get coupled with source supply . How should i chose the ferrite bead or i should just left it.

    Regards
    Gaurav
  • 0 in reply to Dexter
    TI__Guru* 88905 points

    Hi Gaurav,

    The choice of ferrite bead is a function of power supply noise characteristics. The LC filter on power supply provides 3rd order low pass filter to attenuate noise on supply. Based on your earlier test, with ferrite bead you had higher noise level than when you were not using the ferrit bead. This tells us your LC filter is not doing a good job of attenuating the supply noise. This noise is related to power supply feeding DS92LV1021/12 devices. Normally the higher the L or C the lower the low pass filter 3dB cut off point and thus higher noise attenuation. Also, I think it would be best if you check power supply specification or vendor for best practices for suppressing noise.

    Regards,,nasser

  • 0 in reply to Nasser Mohammadi
    Intellectual 450 points

    hello,

    I am still unable to solve the problem with ferrote bead placed on PLL suppy side.

    Is it really necessary to put ferrite bead???

    what is the serdes pll loop bandwidth???

    any suggesstion.

  • 0 in reply to Dexter
    TI__Guru* 88905 points
    Hi Gaurav,

    1). From your earlier comments, it seems without ferrite bead you don't see a negative side effect and this meets your requirements. So I don't see a need for ferrite bead in your application.
    2). Ser/Des loop bandwidth is a function of the data rate. But for DS92LV1210 the loop bandwidth is less than 1 MHz.

    Regards,,nasser
  • 0 in reply to Nasser Mohammadi
    Intellectual 450 points

    hello,

    1) I have placed ferrite bead to avoid high frequency noise to enter in  remaining circuitry.

    2) I calculated resonance frequency of ferritebead and cap. circuit. It is around 750 KHz. If i make this frequency more than 1 MHz will it solve my problem ??

    Regards

    Gaurav