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.

TNETE2201B: Bit order

Part Number: TNETE2201B


Drew,

Sorry for the long delay in responding to your question.  We have been trying a lot of different things trying to get our setup working.

We also had doubts that our clock was meeting the jitter requirement based on the timing reports from our FPGA compile.  We went ahead a built a small PCB with a new clock source to drive the TNETE and the FPGA directly.  We should definitely be meeting jitter specs now as the new clock board is a high quality oscillator and clock driver with careful attention paid to impedance matching and signal delay.

The improved clock setup did make things more stable with our setup but we could still not get the part to properly sync with our data in loopback mode.  After extensive testing I think we may have stumbled onto the solution but we want to confirm.  The datasheet says:

"RD0 is the first bit received."
"TD0 sent as the first bit."
"The 8b/10b encoded data is transmitted sequentially bit 0 through 9. "
"This enables the function that examines and compares ten bits of serial input data to the K28.5 synchronization character."
My question is, which bit is the MSB of the serial data? D0 or D9?  I dont see that explicitly defined in the datasheet.
Thank you
Francisco
  • Hi Francisco,

    Apologies for the delay.  I'm going to link your other e2e here for future reference in case someone has a similar issue.

    https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1110958/tnete2201b-refclk-jitter-spec-and-generation

    It's good that you were able to resolve clocking issues.

    I would expect that D9 is the MSB.  Is this inconsistent with what you're observing in your system?

    Thanks,
    Drew

  • Drew,

    There are some nuances to the data that is being transmitted.  In the data sheet in the section talking about the comma character they say:

    The K28.5 character is defined in the fibre channel standard as a pattern consisting of 0011111010 (a negative number beginning disparity) with the 7 MSBs (0011111) referred to as the comma character.

    That led us to believe that the data we sent to the TNETE would from MSB to LSB 0011111010 for the K28.5 character.  We did not have much success getting the part to SYNC with that pattern and during testing reversed the order of the bits.  The part started to reliably produce SYNC pulses with this pattern. 

    Trying to understand our results we dug into the 802.3z protocol.  In the protocol the 10bit encoded value is actually written from LSB to MSB so when K28.5 is written as 0011111010 it is actually written LSB to MSB.  Hence when we reversed the order of the bits the part seems to work properly. 

    I had asked the question to try and confirm that D9 is the MSB of the encoded 10b code, which is actually written LSB to MSB when you write out the 10 bit sequence.

    Francisco

  • Hi Francisco,

    I'm glad you were able to figure this out!  The datasheet does seem to indicate that the K28.5 character is from MSB to LSB, so it's peculiar that it seems the sync character is actually written LSB to MSB.

    After identifying this issue, are you still having issues with the device?

    Thanks,
    Drew

  • Now that we are sending the bits in the order I described we have been able to get expected results in loopback testing.  Next we are testing our larger system that will have 2 TNETEs talking to each other across the board.

    F

  • Hi Francisco,

    Thanks for the update, it's good that the loopback testing is working as expected!  I will mark this as resolved for now, but feel free to re-open if you run into issues with system testing.

    Thanks,
    Drew