Loopback problem in Stratix V GX

[Altera_Forum]

In out project we have implemented a Custom PHY transceiver, running in duplex mode at 5120 MHz, and the loop-back is done externally with a fibre. Through the TX link we send 191 bits (6 lanes with 32 bits each) with the next pattern: 

• FFFF0000FFFF0000 from 191 downto 128  
• AAAAAAAAAAAAA from 127 downto 64  
• know pseudo-random pattern from 63 downto 0  

  The pseudo-random pattern is a 128b word, with a 4b header (0101), and starts with a counter so it is easily spotted in SignalTap (see attached screen-shots). In the RX side, we receive the next: 

• FFFF0000FFFF0000 from 191 downto 128  
• AAAAAAAAAAAAA from 127 downto 64  
• wrong pseudo-random pattern from 63 downto 0  

  By "wrong" I mean that the header it is now "1111" instead of "0101" and the counter instead of been 0-1-2-3-4-5-6 is 0-3-6-7-12-15-14. In addition, the counter's bits have been moved 1 clock cycle ahead. Where in the tx lanes the counter bits are 3 clock cycles after the header, in the rx side they are in the 2nd clock cycle. In the attached files it is more clear what I wanted to say.   More information about our setup: 

• Quartus 13.1  
• Stratix V 5SGXEA7N2F45C3  
• FPGA fabric transceiver interface width = 32  
• Number of lanes = 6  
• "Data rate" and "base data rate" = 5120 Mbps  
• Input clock frequency = 160 MHz  
• rx_signaldetected and rx_is_lockedtodata are asserted in all the lanes  
• The pseudo-random words are 128b wide, but are sent in packets of 32b, that's why after the header there are two clock cycles without data, and in the 3rd in where the counter bits are.  

  We already try: 

• Enable rx_coreclkin and tx_coreclkin and link them to a 160 MHz clk without any change in the behaviour.  
• Internal loop-back, but that option seems not to be present in the Megafunction window. Nevertheless we manually edited the .sv files to change the "ser_loopback" parameter to "true", but it did not worked.  

  Any suggestions?  And thanks in advance.

[Altera_Forum]

How are you synchronizing the lanes at the receiver? When the receiver is enabled it looks for a pattern to match. Unfortunately that pattern is hard-coded into the transceiver instance so when you change data, you would also need to change the match pattern. If you want to have an arbitrary match pattern, then you need to implement it in your fabric logic.  

 Without a match pattern, your serial bit stream will convert to bytes/words at an arbitrary bit offset. This does not explain why your sync pattern "0101" is detected as "1111", though perhaps you are seeing high bits from your final counter value, i.e., LSB-to-MSB the bits transmitted would be 1010-0000-1000-0100-1100-0010-1010-0110-1110-0001-1001-0101- ... I don't immediately see a 0-3-6-7 pattern in there ... but you get the idea.  You should simulate this before looking at hardware. Eg. see the Arria V GZ example here  https://www.ovro.caltech.edu/~dwh/correlator/cobra_docs.html  Cheers, Dave

[Altera_Forum]

Dear Dave, 

 thank you very much for your suggestions. I'm fixing some problems that I have in the code in order to run a simulation of the whole project. I will post the results.  Regarding the synchronization, we are not using any pattern because the transceiver mega-function allow us to run this way by setting the "Word alignment mode" as "Bit slipping". Surely the RX data is offset and we have to write our own code to search for the header, but this is something that we have to do in any case as the length of our words is greater (128b) than the width of the RX lanes (32b).   Cheers,  Pablo R.

[Altera_Forum]

--- Quote Start ---   Regarding the synchronization, we are not using any pattern because the transceiver mega-function allow us to run this way by setting the "Word alignment mode" as "Bit slipping". Surely the RX data is offset and we have to write our own code to search for the header, but this is something that we have to do in any case as the length of our words is greater (128b) than the width of the RX lanes (32b).    --- Quote End ---   Yes, you will have to write your own synchronization code. Even without synchronization, you should be able to write out the bits in bit-by-bit format and see the serialized bits you sent, it'll just be the parallel output that might be wrong. If you're using SignalTap, you could just pulse the bit-slip control and then trigger to capture a new trace until you see the pattern you were expecting.  Cheers, Dave