Полная версия этой страницы: TLK2201BI кто-нибудь использовал без 8B/10B?
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > Fast Ethernet/Gigabit Ethernet/FibreChannel
TLK2201BI (это SerDes для Gigabit Ethernet) кто-нибудь использовал без 8B/10B? У меня нет возможности кодировать поток по 8B/10B, можно только скремблировать 31-разрядным скремблером. А в спецификации на микросхему не говорится о характеристиках её цепи востановления тактовой частоты, так что я потенциально рискую, что она потеряет синхронизацию. Может быть кто-то имеет опыт использования её без кодирования, а только со скремблированием? Сколько она "выдержит" подряд идущих одинаковых ноликов или единичек при условии, что на передающем конце тактовая частота удовлетворяет условию стабильности +/- 100ppm?
Могу только сказать, что с 11-разрядным скремблером - работает 
если кому интересно, вот такой ответ пришёл от разработчика:
The TLK2201 expects to see data that has been 8b/10b encoded, but strictly speaking it is not necessary that the data be 8b/10b coded. There may be other protocols that are suitable for the TLK2201.
The TLK2201 is at its core just a 10 bit serializer and deserializer. The serializer will simply take whatever is presented to the parallel bus and serialize it – no matter what.
The deserializer will simply take the incoming serial data stream and lock to it (if the rate of the data stream is within +/-200ppm of what the transmitter is transmitting) and then chop the data stream up into 10 bit words to output.
Even if the transmitter is not needed, there is no way to turn it of and the REFCLK must be present for the deserializer to work. And the +/-200ppm requirement on REFCLK still applies. (I say +/- 200 ppm rather than +/-100ppm because in a full duplex app the clocks should be spec’d to +/-100 ppm and thus the serial data coming into a receiver might be as much as +/-200ppm away from what the transmitter is transmitting. Think of the case where one clock source is +100ppm and the other clock source -100ppm for example.)
If the incoming serial data stream is scrambled, the SYNCEN pin must be used to turn off the comma detect, or else the deserialization boundary will jump every time there is a 0011111 pattern present in the serial data.
Also, the TLK2201 was characterized with 8b/10b coded data. So jitter performance is only guaranteed over 8b/10b coded data and different transition density and different run lengths of data may make for slightly different performance.
But consider this, the SLK2501 and related SLK devices from TI are designed to operate on SONET data streams and these are polynomial scrambled. These SLK devices are expected to handle run lengths of up to 72 bits, but the ref clock accuracy is expected to be much tighter. And these SLK devices have essentially the *same* internal architecture of the Clock/Data Recovery as the TLK2201 does.
Of course, with scrambled data into the TLK2201, there is no way to recover the byte boundary so you will have to be able to accept data that is chopped into 10bit words on any arbitrary boundary each time the link is powered up or restored after an interruption. But with SYNCEN off, the deserialization boundary will remain constant during the time the link is active. Oh, and there is also the possibility of using the device as a 5 bit deserializer of sorts, but with DDR clocking so it is still really a 10bit deserializer. This is one aspect of the statement that the receiver can’t sync to a scrambled pattern.
The CDR can, but the byte boundary logic can’t.
If I may, I would like to quibble about one thing. If the data is scrambled with a 2**31 – 1 scrambler, then there is no guarantee that the run length is limited to 31 bits. If the output of the scrambling polynomial is sent straight, then yes the run length is limited to 31 bits. But if this scrambling is applied to data, then there is no absolute limit on the run length of the data. If the data is uncorrelated to the scrambler then each bit may have a 50% chance of being the same as the previous bit. So the chance of a run length of 10 is 1/1024. The chance of a 20 bit run length is 1 in 2**20. There is a chance of a 100 bit run length, but very unlikely. The trade-off between the run length we can accept will depend on the accuracy of the REFCLK and the eye opening of the data pattern. The longer the run length and the looser the REFCLK the sooner one could expect the CDR sample point to drift off from center and result in a bit error. With a more wide open eye pattern then more drift could be tolerated than with a more closed eye opening.
One more thing, the TLK2201 architecture does not have an independent PLL and VCO just for the receiver. Looking at the block diagram in the data sheet, there is only one PLL in the chip. This PLL takes the reference clock and multiplies it up in frequency to the bit rate. This clock would be suitable to strobe the incoming serial data if there were some way to align the clock phase to the center of the eye opening – using some magic delay element. That is in essence what we do. We have a delay element that shifts the PLL clock to align to the incoming serial data eye opening. The CDR function is a digital state machine that monitors samples of the data stream and adjusts the setting of the delay. This constant monitoring and adjusting allows ppm frequency differences to be tracked out.
The TLK2201 expects to see data that has been 8b/10b encoded, but strictly speaking it is not necessary that the data be 8b/10b coded. There may be other protocols that are suitable for the TLK2201.
The TLK2201 is at its core just a 10 bit serializer and deserializer. The serializer will simply take whatever is presented to the parallel bus and serialize it – no matter what.
The deserializer will simply take the incoming serial data stream and lock to it (if the rate of the data stream is within +/-200ppm of what the transmitter is transmitting) and then chop the data stream up into 10 bit words to output.
Even if the transmitter is not needed, there is no way to turn it of and the REFCLK must be present for the deserializer to work. And the +/-200ppm requirement on REFCLK still applies. (I say +/- 200 ppm rather than +/-100ppm because in a full duplex app the clocks should be spec’d to +/-100 ppm and thus the serial data coming into a receiver might be as much as +/-200ppm away from what the transmitter is transmitting. Think of the case where one clock source is +100ppm and the other clock source -100ppm for example.)
If the incoming serial data stream is scrambled, the SYNCEN pin must be used to turn off the comma detect, or else the deserialization boundary will jump every time there is a 0011111 pattern present in the serial data.
Also, the TLK2201 was characterized with 8b/10b coded data. So jitter performance is only guaranteed over 8b/10b coded data and different transition density and different run lengths of data may make for slightly different performance.
But consider this, the SLK2501 and related SLK devices from TI are designed to operate on SONET data streams and these are polynomial scrambled. These SLK devices are expected to handle run lengths of up to 72 bits, but the ref clock accuracy is expected to be much tighter. And these SLK devices have essentially the *same* internal architecture of the Clock/Data Recovery as the TLK2201 does.
Of course, with scrambled data into the TLK2201, there is no way to recover the byte boundary so you will have to be able to accept data that is chopped into 10bit words on any arbitrary boundary each time the link is powered up or restored after an interruption. But with SYNCEN off, the deserialization boundary will remain constant during the time the link is active. Oh, and there is also the possibility of using the device as a 5 bit deserializer of sorts, but with DDR clocking so it is still really a 10bit deserializer. This is one aspect of the statement that the receiver can’t sync to a scrambled pattern.
The CDR can, but the byte boundary logic can’t.
If I may, I would like to quibble about one thing. If the data is scrambled with a 2**31 – 1 scrambler, then there is no guarantee that the run length is limited to 31 bits. If the output of the scrambling polynomial is sent straight, then yes the run length is limited to 31 bits. But if this scrambling is applied to data, then there is no absolute limit on the run length of the data. If the data is uncorrelated to the scrambler then each bit may have a 50% chance of being the same as the previous bit. So the chance of a run length of 10 is 1/1024. The chance of a 20 bit run length is 1 in 2**20. There is a chance of a 100 bit run length, but very unlikely. The trade-off between the run length we can accept will depend on the accuracy of the REFCLK and the eye opening of the data pattern. The longer the run length and the looser the REFCLK the sooner one could expect the CDR sample point to drift off from center and result in a bit error. With a more wide open eye pattern then more drift could be tolerated than with a more closed eye opening.
One more thing, the TLK2201 architecture does not have an independent PLL and VCO just for the receiver. Looking at the block diagram in the data sheet, there is only one PLL in the chip. This PLL takes the reference clock and multiplies it up in frequency to the bit rate. This clock would be suitable to strobe the incoming serial data if there were some way to align the clock phase to the center of the eye opening – using some magic delay element. That is in essence what we do. We have a delay element that shifts the PLL clock to align to the incoming serial data eye opening. The CDR function is a digital state machine that monitors samples of the data stream and adjusts the setting of the delay. This constant monitoring and adjusting allows ppm frequency differences to be tracked out.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.