Forum Discussion
Cyclone V Transceiver Synchronised 32bit Word Alignment Problem
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 :(
- The PMA-PCS interface is configured as a 20bit data path.
- 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.
- The rate match FIFO is bypassed.
- I am using the 8b/10b decoder
- I am using the byte (16bit word) deserialiser to get a 32bit data path to the FPGA fabric.
- 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.
- I am using the phase compensation FIFO in the non-registered low-latency mode.
20 Replies
- Altera_Forum
Honored Contributor
How can I post a better signaltap view? It appears as a ridiculous tumbnail...
- Altera_Forum
Honored Contributor
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
Honored Contributor
--- 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
Honored Contributor
- Altera_Forum
Honored Contributor
--- 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
Honored Contributor
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
Honored Contributor
--- 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? [email protected] - Altera_Forum
Honored Contributor
--- 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)
--- Quote End --- Thanks lot for the sharing of the working function.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
Honored Contributor
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
Honored Contributor
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 [email protected]