• TI Thinks Resolved

SI test fail for the SFP+ Ports through the Retimer DS100DF410

Dear Sir,

I have a project which uses the SFI Retimer DS100DF410 to output 16x SFP+ Port.  But, with the initial retimer configuration, the SI test result of the 16x SFP+ Ports are all failed.  The fail phenomenon are descripled as blow:

A. The 8180 Pattern is wrong.

B. The PRBS9 Pattern is fail.

C. Just PRBS31 Pattern is pass. 

So, Is this SI fail caused by the initial retimer configuration ?  If yes, why the 8180 pattern is wrong ? Thank you very much !

  • In reply to Lee Sledjeski:

    Lee,

    We were having an issue unlocking the CDR due to certain types os 1G packets and the modification of Channel Register 0x0C value. Default = 08'h, Change to = 00'h. resolved the issue. Can you explain what is the consequence of using this bit change in final firmware ? Is it recommendable to use it in 10G system also ?
  • In reply to Sergio Eduardo Spader:

    Sergio,

    This register bit enables or disables the "single bit transition" check for declaring CDR lock.  When this bit is enabled, the internal state machine must record a certain number of "single bit transitions" for a valid lock condition.  The 8180 pattern would not meet this condition since there are no 101 or 010 pattern changes. 

    I would recommend keeping this bit enabled for normal operation.

    Regards,

    Lee

  • In reply to Lee Sledjeski:

    Lee,


    Our Design have SFP+ ports connected to the DS100DF410, this SFP+ ports can work either in 10.3125G (66/64) 10Gbase-X or 1.25G (8B10B) 1000Base-X, 10G works OK, what happens is that we findout using valid ethernet packets a certain sequence of packets that makes the CDR to unlock. I can wireshark the packets if you want. We tested in our system and with your development kit and both cenarios the CDR unlock after sending that packet sequence. But we figure out that modifying this register as you recommended to this 8180 issue makes the traffic pass normally.

    As we were having issues in 1.25G (8B10B) do you recommend to change the bit  or do you think it is better to send you the packets and work a little bit more to better evaluate what is happening ? Until now we do not observe no collateral problem after changing this bit for 1.25G traffic.


    Thanks


    Sérgio

  • In reply to Sergio Eduardo Spader:

    Hi Sergio,

    There is no problem with setting this bit.  You can try making the change below as well. 

    If you change the equalization value in channel register 0x3A from A5'h to 00'h does the retimer still lose lock?

    The value of A5'h is quite large and usually not needed for low speed applications.

    Regards,

    Lee