Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
13 years ago

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 :(

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.

20 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi Basstudio,

    Could you provide me what Altera offered as a solution?

    regards
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- 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 "[email protected]"

    Thanks in advance.

    Angad
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hello,

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

    Cheers
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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;