How does the Stratix II GX Transceiver Deserializer work?

[Altera_Forum]

Hello, 

 I was wondering how the Stratix II GX Transceiver Deserializer works.   What happens in a signal lost condition? By signal loss condition I mean the link is broken where the lines are either pulled up or down, but are *NOT* floating. In my application I need access to the last bits sent before loss of signal even if it is a partial word. I have created a small table below trying to understand how the Deserializer (i.e. SIPO) might work. The table shows two transmissions. The first one succeeds in sending its 16-bits and the RX-SIPO matches what was sent. The second one succeeds at sending 5-bits before the signal is lost. The 2nd line in the table shows some options for what the RX-SIPO might look like after the second transmission.     Are any of the options I have listed in the table how the Deserializer works? If not how does it work? Does serial data (zero-bits or random-bits) continue to be clocked in even after the signal is lost?    TX# TX-PISO RX-SIPO 1 1011 0111 0110 0001 1011 0111 0110 0001 2 1010 1<Signal Loss> 1110 1100 0011 0101 (option A) 0000 0000 0001 0101 (option B) 1010 1000 0000 0000 (option C) Note: Here data shifted out of TX-PISO starting on left hand side  Thank you for your help,

[Altera_Forum]

I don't believe the problem is as simple as you would like. I'm sure some of the wiser forum users will override me on this but I see two issues. 

 1 - The physical layer. What does a loss of signal look like at the receiver? Does the signal drift to a logic high, low, or somewhere inbetween? The deserializer is just that. At a high level, it has no concept of signal levels other than 1 or 0. It will continue to deserialize data regardless of what is found on its input. At the physical layer you really have no concept of loss of signal. Now in reality, the transceiver does have a signal loss threshold determined by the amplitude of the input signal but I don't know how you can make use of this.  2 - Depending on your implementation, at some point the clock recovery unit is no longer going to be able to detect a clock on the input. However, there may be a significant delay between the actual loss of signal and the loss of recovered clock. This method will not give you  3 - Your encoding protocol is really the only method of signal detection you have. For example, if you are sending/receiving SDI data, the only way you know that a signal is present is by the consistent presence of a predetermined sequence of bits on the data stream. If that sequence of bits is not found in the stream, then you assume there is no signal. In this case, there is a huge time delay between the loss of signal and the awareness that the signal is lost.  Certain protocols may give you finer resolution on detecting when a signal was lost. But even then, you would have to define signal loss as a bit error in the data stream. Your resolution on determining where in the bitstream that error occurred would depend on your bit error detection resolution.  Jake

[Altera_Forum]

Thanks for the info 

 I plan to use an LFSR to send a known sequence of data across the link and compare it to what I expect on the receiving end. This seems like it should give me the ability to determine when I have lost my link. The real issue is that I need to know down to the bit when I lost the link. That is why my table shows 5-bits making it thru before the link is broken.   What I am trying to determine is what will the Deserializer look like when the link is broken. Based on what you have describe it sounds like it could be my "option C" where it just keeps deserializing the data even though it is zeros because my codes are no longer making it thru.    I could then use the partial value to compare against the code I expected to get and see that the link failed at bit-5 on code-X.   What do you think?