• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 31 subscribers
  • Views 864 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.

TLK10081: Encoding Questions

Richard Elmquist
Mastermind 45250 points
Part Number: TLK10081
Other Parts Discussed in Thread: TLK10022

I have a customer asking the following questions regarding the TLK10081:

In our case we would be taking 4 x 1.25 Gbps ethernet signals (8B/10B encoded) and transporting them optically, ideally at the rate of 10.3125 Gbps, because that is what it appears many of the SFP+ modules support (10 gigabit ethernet rate).  There would be a lot of unused bandwidth which could be used for what the data sheet calls a "reserved lane" (see page 13).  In our application, the networks being transported could contain sensitive information and thus we have to demonstrate to our customer that no "cross contamination" between lanes is possible.  In other words, we have to be absolutely certain that the signal input onto Lane 1 comes out on Lane 1, (same for lanes 2,3,4,etc.).  I am hopeful that the "reserved lane" measures indicated on page 13 of the data sheet would accomplish this.  I do understand that the traffic is being aggregated and carried together on the same 10 Gbps stream, however, in our application, the "lane ordering" has to be maintained.

There are a couple of questions that come to mind in this regard:
(1) In the case of link disruption, how quickly would the lane ordering be restored?
(2) In the case above, how much potential data could come out of the wrong lane prior to restoration of lane ordering?

I know it sounds kind of paranoid, but these are the things that our customer and the accreditors will want to know.

I was not sure how to answer this as I am not exactly sure how the data is aggregated in the lanes. Can you look at this question and let me know if the TLK10081 will work for them or if we have another device that will meet their need better.

Please let me know if you have any further questions for the customer.

Thanks for your help with this!

Richard Elmquist

  • 0
    TI__Genius 16150 points

    Hi Richard,

    Let's verify what the actual data rates will be. We can do 8x1.25=10.0Gbps. The 10.3125Gpbs rate is specific to 10G Ethernet and 64B/66B encoding which we do not support. But I assume they want 10.0Gbps.

    The lane ordering will be set by the K28.5 characters. Internally, we'll replace K28.5 (0x2BC) on Lane 0 (default) to K28.3 (0x27C). This K28.3 will be used by the RX device to set the lane ordering. So they have a restriction to never send K28.3 on any lane, so that lane ordering stays maintained. The question may arise, can bit errors alias to a K28.3 and cause a temporary lane re-alignment? Well, yes. The best way to guard against this is to also enable 20-bit scrambling. An aliased K28.3 would be detected as a descramble error and then would be changed to an error code, and thereby prevent the unwanted aliasing and rotation change.

    This would be TX_SCR_20_EN (8009.1) for the transmitter and RX_SCR_20_EN (8019.1) for the receiver. Then you set the polynomial at 800E/800F (transmitter) and 801E/801F (receiver). I did some tests with HDMI data and came up with a good polynomial but can't seem to find what it was. I will try to find it. They can also pick any polynomial they want, up to 32 bits, and then do a BER test. I just looked online and found a random example, x^16+x^15+x^13+x^4+1. You would set bits 16, 15, 13, and 4 to '1.' The downside to a multiplicative/20-bit scrambler is that one bit error results in multiple error codes on the RX, but at least it would guard against the lane mis-rotation.

    Unfortunately tlk10022/81 does not have hysteresis, so without scrambling, it's possible that bit errors could alias to the rotation character and cause instant rotation change, which would persist until the next K28.3 (from a K28.5) is found on Lane 0.

    I don't remember if a cable plug/re-plug scenario could cause a random bit shift and thus temporarily cause lane mis-rotation. They might have to check that to be sure.


    Best Regards,
    Luis Omar Moran
    High Speed Interface
    SWAT Team

  • 0 in reply to Luis Omar Moran
    TI__Mastermind 45250 points

    Luis,

    Thanks for your quick response!

    I will let you know if the customer has any further questions.

    Thanks again.

    Richard Elmquist

  • 0 in reply to Richard Elmquist
    TI__Mastermind 45250 points

    Luis,

    The customer has asked some further questions:

    First of all, you’re; we don't have to run the high speed side at 10.3125 Gbps, it could be 10.0 Gbps or any rate transportable by an SFP+ optical module.

    In our application, we don't need the full 8 lane capacity, so using your example, what if we injected constant K28.5's on Lane 0?

    Would that make the recovery time for lane mis-rotation to be extremely fast?  How fast would the part re-align?

    How many bits/words of mis-aligned data could possibly go through (worst case) with this technique? (I would imagine that in this case only a couple of 10 bit words could spill out of the wrong channel until the pattern is detected on lane 0).

    I would like to convince our customers that the recovery time would be very fast and that the amount of data that goes through would be insignificant and therefore this part would be able to meet our requirements because this makes our design a lot simpler and easier. We are dealing with some secure communications applications here, so we have to go to extremes to ensure that the lanes are properly aligned as much as possible (ideally 100%).

    Please let me know if you have any further questions for the customer.

    Thanks for your help with this!

    Richard Elmquist

  • 0 in reply to Richard Elmquist
    TI__Genius 16150 points

    Hi Richard,

    Yes, if they feed continuous K28.5 on Lane 0 then that would maximize lane recovery time. I would need to look at the design, but it's possible that would prevent it from ever mis-rotating, even if another lane had bit error aliasing to K28.3. Let me research it and I'll get back to you.

    Best Regards,

    Luis

  • 0 in reply to Richard Elmquist
    TI__Genius 16150 points
    If you send all K28.5 on Lane 0, then in 8:1 mode, the "worst case" scenario is that you receive a false K28.3 on Lane 2 (Lane 1 K28.3 would be ignored since Lane 0 was a valid K28.3). Then you would get a false rotation where Lane 2 now gets K28.5. Then the mapping would look like this

    Source -> Destination Lane
    -----------------------------------
    Lane 0 -> Lane 0 / K28.5
    Lane 1 -> Lane 1
    Lane 2 -> K28.5 (don't care). This is the bit error
    Lane 3 -> Lane 1 (this corrupts the correct Lane 1 data from above)
    Lane 4 -> Lane 2
    Lane 5 -> Lane 3
    Lane 6 -> Lane 4
    Lane 7 -> Lane 5
    Lane 0 -> Lane 0 (K28.5 / Re-alignment)

    So you get one crossed byte on Lanes 1, 3, 4 and 5. Lane 2 is a K28.5 so not data. Lanes 6 and 7 do not receive new data so they repeat the previous byte.

    I believe this would be sufficient to be considered no cross data, as one "crossed" byte in a stream cannot be distinguished from bit errors.

    Changing to a 20-bit error code would prevent a false K28.3 on HSRX from propagating and causing a false re-alignment. However, on the Transmitter device, a false LSRX input decode of a K28.3 would still propagate to the RX device for the above scenario. So there's not a 100% perfect solution, but reserving one lane for strictly K28.5 code would certainly minimize any cross-rotation corruption.

    Regards,
    Luis
  • 0 in reply to Luis Omar Moran
    TI__Mastermind 45250 points

    Luis,

    Thanks for your quick response!

    I will let you know if this answers the customer's questions.

    Thanks again.

    Richard Elmquist

  • 0 in reply to Luis Omar Moran
    TI__Genius 16150 points
    Actually Lane 2 did get corrupted with Lane 4 data as per the table. Still, the corrupted lanes only received one incorrect byte, which is the main point.
    Regards,
    Luis