Cyclone V Transceiver Synchronised 32bit Word Alignment Problem

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;

Hello,

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

Cheers

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

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

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

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.

Hi Basstudio,

Could you provide me what Altera offered as a solution?

regards

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

--- 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.

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!