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