Cyclone V Transceiver Synchronised 32bit Word Alignment Problem

[Altera_Forum]

I am using the cyclone v gt (http://www.altera.co.uk/products/devkits/altera/kit-cyclone-v-gx.html) demo board in an attempt to get a transceiver channel that has a direct loopback (Tx->Rx) across the HSMC to verify a physical link running and synchronised correctly at the receiver from the transmitted data. 

 The loopback is as follows:-  

• The transceiver is constantly transmitting = K28.5, D10.2, D10.2 & D27.3 (SATA align primitive in transmission order) i.e. 7b4a4abch in the 8b-domain. 
• The transceiver is receiving = 7b4a4abch which is good :) OR 4abc7b4ah which is word swapped :( 

  After reading the documentation many times I can't work out why the word ordering isn't working, word alignment appears to work though; this is my configuration in the receiver:-  

1. The PMA-PCS interface is configured as a 20bit data path. 
2. The word aligner is in manual mode detecting x2 comma K28.5 (10bit) symbols which appears to be working because using SignalTap I can see the synchronisation being asserted after detecting the second word alignment pattern. 
3. The rate match FIFO is bypassed. 
4. I am using the 8b/10b decoder 
5. I am using the byte (16bit word) deserialiser to get a 32bit data path to the FPGA fabric. 
6. I have the byte ordering configured to auto looking for the comma K28.5 pattern in the 8b-domain i.e. 1BCh and padding with 000h. 
7. I am using the phase compensation FIFO in the non-registered low-latency mode. 

  But it would seem that the byte ordering block isn't working because if I have read the documentation correctly this would detect my word swapped scenario (4abc7b4ah) which would be replaced with the padding such that the word alignment is restored back to the original data alignment. Any help is much appreciated because I think I have exhausted all my ideas from reading the documentation many times now.

[Altera_Forum]

I still haven't managed to get this to work and I am waiting to here back from Altera through a service request on this. 

 I did try a similar method to this one (http://www.alteraforum.com/forum/showthread.php?t=21586&p=154036#post154036) identified on a Stratix IV using the following settings:- 

• Word Aligner Pattern Length = 20 (x2 10b symbols) 
• Word Aligner Pattern = AA97Ch (D10.2 & K28.5 negative disparity in LSbit serial order) 

 I could see the new word alignment working but I still couldn't get the byte (word) ordering to work looking for K28.5 (1BCh). I thought the word ordering might require an 18bit pattern (i.e. x2 data octets + x2 control symbol flags) but the megawizard insists that it requires a 9bit pattern.  To get around this issue I have written my own word ordering function, here is the simplified vhdl:-  architecture behaviour of RxBuffer is -- Word ordering (WO) signals signal WODetector : std_logic; signal WODataDelta : std_logic_vector(15 downto 0); signal WOData : std_logic_vector(31 downto 0); begin -- Re-Align detection register -- Note: when the dword is not synchronised this is asserted when the upper-word is synchronised and identifies the pattern -- detect (LSB) from the word aligner when the lower-word is not synchronised (prior to the pattern detector). process (SIMPLTP_RxClk) is begin if (rising_edge(SIMPLTP_RxClk)) then -- Check if the data word is not synchronised (one or more octets within the dword) = capture align detection if (SIMPLTP_RxData(58) = '0' or SIMPLTP_RxData(42) = '0' or SIMPLTP_RxData(26) = '0' or SIMPLTP_RxData(10) = '0') then WODetector <= -- Upper word synchronised and pattern detected SIMPLTP_RxData(58) and SIMPLTP_RxData(44) and SIMPLTP_RxData(42) and -- Lower word not synchronised not SIMPLTP_RxData(26) and not SIMPLTP_RxData(10); else WODetector <= WODetector; end if; end if; end process; -- Data/control delta registers process (SIMPLTP_RxClk) is begin if (rising_edge(SIMPLTP_RxClk)) then WODataDelta <= SIMPLTP_RxData(55 downto 48) & SIMPLTP_RxData(39 downto 32); end if; end process; -- Word (re)alignment output register -- Note: either re-aligned or straight depending on the re-alignment detector process (SIMCL_Reset, SIMPLTP_RxClk) is begin if (SIMCL_Reset = '1') then WOData <= x"00000000"; elsif (rising_edge(SIMPLTP_RxClk)) then -- Check if a re-alignment is detected and synchronisation established = use delta + current words if (WODetector = '1') then WOData <= SIMPLTP_RxData(23 downto 16) & SIMPLTP_RxData(7 downto 0) & WODataDelta; -- Re-Align not required = retain word order else WOData <= SIMPLTP_RxData(55 downto 48) & SIMPLTP_RxData(39 downto 32) & SIMPLTP_RxData(23 downto 16) & SIMPLTP_RxData(7 downto 0); end if; end if; end process; -- Physical layer receive buffer data path output SIMPLRB_Data <= WOData; end architecture;

[Altera_Forum]

Hello, 

 If you are still interested, I have a working project that I could send to you.  Cheers

[Altera_Forum]

--- Quote Start ---  Hello,  If you are still interested, I have a working project that I could send to you.  Cheers  --- Quote End ---    Hi,  I am facing a very similar issue with Cyclone V SX device. mbarrosm it would be a great help if you could share the project with me. you can share the same on "angadhs@iwavesystems.com"  Thanks in advance. Angad

[Altera_Forum]

Hi mbarrosm 

Yes I am definitely still interested in your transceiver word ordering settings if you are running it in double width mode. I spent hours trying to get this working including a service request with Altera and found it wouldn't work reliably in this configuration - I also captured it failing in the hardware too. I couldn't waste any more time on this so I ended up implementing my own word alignment in the user logic but it would always be best if I can get it to work properly in the transceiver to save resource.  Thanks

[Altera_Forum]

Anyone already found a solution for this issue? I am facing the same problems with the ALTGX transceivers in the Stratix IV GX device. I even tried to issue rx_enapatternalign when the wrong 16 bit boundary occurs but that does not seem to work... 

 Thanks in advance

[Altera_Forum]

I had to give up trying to resolve this issue as I had to delivery my solution and couldn't waste any more resource on the issue, therefore I implemented the dword alignment in user code - see post# 2 above. 

 I spent some time with Altera technical support on this which at the time I thought we resolved the issue in simulation but as soon as I started testing in hardware I saw the issue again.

[Altera_Forum]

Hi Basstudio, 

 Could you provide me what Altera offered as a solution?   regards

[Altera_Forum]

--- Quote Start ---  I had to give up trying to resolve this issue as I had to delivery my solution and couldn't waste any more resource on the issue, therefore I implemented the dword alignment in user code - see post# 2 above.  I spent some time with Altera technical support on this which at the time I thought we resolved the issue in simulation but as soon as I started testing in hardware I saw the issue again.  --- Quote End ---    Hi, I tried the following solution and it seems as if it works although I must admit that the documentation is difficult to interpret..  In the word alignment pattern length I used 20 bits and for the word alignment pattern I used the pattern 10101010100101111100 (AA97C , D10.2 and K28.5). Then I enabled the byte ordering block and checked based on the syncstatus signal from the word aligner. I checked the Use a two word byte ordering pattern with the two patterns 001001010 and 110111100 (first one represents hex 4A (D10.2) and the second one hex 1BC (equivalent to K28.5 char (9th bit 1 to indicate it is a control char)). For the byte ordering pad pattern I use the 000000000. This latter one still confuses me a bit...  Then after the SATA OOB signalling when the speed negotiation starts and the drive sends the ALIGN primitives I check for the syncstatus bits and when they appear to be all ones then I issue a rx_enapatternalign to the ALTGX.  I can then see that the block realigns and that I get the correct 7BA4A4BC alignment...  regards

[Altera_Forum]

--- Quote Start ---  Hi, I tried the following solution and it seems as if it works although I must admit that the documentation is difficult to interpret..  In the word alignment pattern length I used 20 bits and for the word alignment pattern I used the pattern 10101010100101111100 (AA97C , D10.2 and K28.5). Then I enabled the byte ordering block and checked based on the syncstatus signal from the word aligner. I checked the Use a two word byte ordering pattern with the two patterns 001001010 and 110111100 (first one represents hex 4A (D10.2) and the second one hex 1BC (equivalent to K28.5 char (9th bit 1 to indicate it is a control char)). For the byte ordering pad pattern I use the 000000000. This latter one still confuses me a bit...  Then after the SATA OOB signalling when the speed negotiation starts and the drive sends the ALIGN primitives I check for the syncstatus bits and when they appear to be all ones then I issue a rx_enapatternalign to the ALTGX.  I can then see that the block realigns and that I get the correct 7BA4A4BC alignment... regards  --- Quote End ---    Thanks, this is interesting as I never resolved this when I was working on it. Does your solution work consistently and do you need to toggle the optional rx_std_wa_patternalign input port to get it to align correctly and consistently?  I wasn't using the rx_std_wa_patternalign signal in my design because I interpreted the transceiver user guide as this was an optional signal therefore would only require it if I wanted to perform a re-alignment in the word aligner i.e. the first alignment would automatically occur.

[Altera_Forum]

Hi,  

 Yes it works consistently. Please find attached a power up signaltap analysis on the alignment. I am using 4 drives that I wake up. As you can see two of them appear to be misaligned and when I activate the rx_enapatternalign inputs then the stuff really realigns to the correct patterns. It works everytime....  Still wondering what Altera support suggested to you.  regards!

[Altera_Forum]

How can I post a better signaltap view? It appears as a ridiculous tumbnail...

[Altera_Forum]

Yeah the SignalTap capture is a little too small to read. 

 Can we conclude then from your testing and the work I did originally that to resolve this issue you have to toggle the rx_enapatternalign input after synchronisation to get the dword alignment to work correctly? If this is the case then the transceiver user guide is really weak in divulging this information.

[Altera_Forum]

--- Quote Start ---  Yeah the SignalTap capture is a little too small to read.  Can we conclude then from your testing and the work I did originally that to resolve this issue you have to toggle the rx_enapatternalign input after synchronisation to get the dword alignment to work correctly? If this is the case then the transceiver user guide is really weak in divulging this information.  --- Quote End ---    Yes, I agree with you.  The doc states:  in manual alignment mode, the word aligner starts looking for the programmed 8-bit, 16-bit, or 32-bit word alignment pattern in the received data stream as soon as rx_digitalreset is de-asserted low. it aligns to the first word alignment pattern received regardless of the logic level driven on the rx_enapatternalign signal. any word alignment pattern received thereafter in a different word boundary does not cause the word aligner to re-align to this new word boundary. after the initial word alignment following de-assertion of the rx_digitalreset signal, if a word re-alignment is required, you must use the rx_enapatternalign signal.   That suggests that after rx_digitalreset is asserted it would look for the first word allignment pattern.. However, my method works all the time...  I would like to know how to upload a better picture. The forum seems to resize it to an idiot thumbnail...  regards

[Altera_Forum]

tried to post signaltap attachment again. Hope this one is better..

[Altera_Forum]

--- Quote Start ---  tried to post signaltap attachment again. Hope this one is better..  --- Quote End ---   Hi, could you explain more clearly how to byte order pattern? You use two byte pattern 4a and 1bc. So the 18 byte pattern is hex 095BC. Should this pattern be in the "byte order patter (hex)" field of megawizard? Does it works in auto byte ordering mode? Or I must use manual mode with usign rx_std_byteorder_ena port?

[Altera_Forum]

Hi, could you explain more clearly how to use byte order pattern? You use two byte pattern 4a and 1bc. So the 18 byte pattern is hex 095BC. Should this pattern be in the "byte order patter (hex)" field of megawizard? Does it works in auto byte ordering mode? Or I must use manual mode with usign rx_std_byteorder_ena port?

[Altera_Forum]

--- Quote Start ---  Hello,  If you are still interested, I have a working project that I could send to you.  Cheers  --- Quote End ---   Hi! Could you send me a working project? kliuchevsky@mail.ru

[Altera_Forum]

--- Quote Start ---  I still haven't managed to get this to work and I am waiting to here back from Altera through a service request on this.  I did try a similar method to this one (http://www.alteraforum.com/forum/showthread.php?t=21586&p=154036#post154036) identified on a Stratix IV using the following settings:- 

• Word Aligner Pattern Length = 20 (x2 10b symbols) 
• Word Aligner Pattern = AA97Ch (D10.2 & K28.5 negative disparity in LSbit serial order) 

 I could see the new word alignment working but I still couldn't get the byte (word) ordering to work looking for K28.5 (1BCh). I thought the word ordering might require an 18bit pattern (i.e. x2 data octets + x2 control symbol flags) but the megawizard insists that it requires a 9bit pattern.  To get around this issue I have written my own word ordering function, here is the simplified vhdl:-  architecture behaviour of RxBuffer is -- Word ordering (WO) signals signal WODetector : std_logic; signal WODataDelta : std_logic_vector(15 downto 0); signal WOData : std_logic_vector(31 downto 0); begin -- Re-Align detection register -- Note: when the dword is not synchronised this is asserted when the upper-word is synchronised and identifies the pattern -- detect (LSB) from the word aligner when the lower-word is not synchronised (prior to the pattern detector). process (SIMPLTP_RxClk) is begin if (rising_edge(SIMPLTP_RxClk)) then -- Check if the data word is not synchronised (one or more octets within the dword) = capture align detection if (SIMPLTP_RxData(58) = '0' or SIMPLTP_RxData(42) = '0' or SIMPLTP_RxData(26) = '0' or SIMPLTP_RxData(10) = '0') then WODetector <= -- Upper word synchronised and pattern detected SIMPLTP_RxData(58) and SIMPLTP_RxData(44) and SIMPLTP_RxData(42) and -- Lower word not synchronised not SIMPLTP_RxData(26) and not SIMPLTP_RxData(10); else WODetector <= WODetector; end if; end if; end process; -- Data/control delta registers process (SIMPLTP_RxClk) is begin if (rising_edge(SIMPLTP_RxClk)) then WODataDelta <= SIMPLTP_RxData(55 downto 48) & SIMPLTP_RxData(39 downto 32); end if; end process; -- Word (re)alignment output register -- Note: either re-aligned or straight depending on the re-alignment detector process (SIMCL_Reset, SIMPLTP_RxClk) is begin if (SIMCL_Reset = '1') then WOData <= x"00000000"; elsif (rising_edge(SIMPLTP_RxClk)) then -- Check if a re-alignment is detected and synchronisation established = use delta + current words if (WODetector = '1') then WOData <= SIMPLTP_RxData(23 downto 16) & SIMPLTP_RxData(7 downto 0) & WODataDelta; -- Re-Align not required = retain word order else WOData <= SIMPLTP_RxData(55 downto 48) & SIMPLTP_RxData(39 downto 32) & SIMPLTP_RxData(23 downto 16) & SIMPLTP_RxData(7 downto 0); end if; end if; end process; -- Physical layer receive buffer data path output SIMPLRB_Data <= WOData; end architecture;   --- Quote End ---    Thanks lot for the sharing of the working function.

[Altera_Forum]

Hi, 

 I use the altgx with 20 bit word alignment pattern. The binary field is "10101010100101111100". The word aligner is set to manual word alignment mode. if the altgx has incorrectly aligned then you give a patternalign to the altgx. You can detect if the pattern is aligned by watching the rx_syncstatus bits being high.  regards

[Altera_Forum]

I am trying to use cyclone V GX transceiver. Would it possible to send a copy of the working project. This may help me to understand how it works clive.seguna@gmail.com