Запускаю GTP трансивер, и вот наткнулся на то что происходит рассинхронизация слов. для тестирования использую FRAME_GEN блок, который выдает поток данных с K28.5+, с интервалом в 32 слова. рассинхронизация происходит где то после 1 ms - байты меняются местами.
Как с этим бороться?

А как настроен-то GTP? Realign по K28.5 - отнюдь не есть его функция по умолчанию.

Вывел сигнал RX_BYTE_IS_ALIGN - он в "1". То есть, байты выравнены. Но внутри пакета LSB и MSB меняются местами.
Но вот что к этому приводит? Понятно что частоты плывут, но кварц не плохой +-25PPM, в предидущем проекте Arria GX без проблем работала с обычным Geyer-овским кварцем.



SATA II - 2.5 Ghz. Больше я ничего не менял, за базу брал сгенерированный example.
По умолчанию, К28.5. В Frame_Gen bp example - bc, то есть, как я понимаю К28.5+.
ALIGN_COMMA_WORD, по умолчанию - 2. Тоесть, выравнивание по LSB.
Переделал под ALIGN_COMMA_WORD - 1, все равно те же грабли. НаXilinx пишут что нужно снимать rxencommaalign - не помогает.

Сигнал ладно, внутри блок должен быть настроен понимать K28.5 как realign. K28.5+ что такое - я не понимаю. Что плюс означает?

А кварц все равно какой: там за секунду передается минимум миллиард бит. Даже если разбег кварцев 1ppb - за восемь секунд набежит байт.

Внутри, Comma detection - K28.5. Передается K28.5+ - comma plus - x"bc"(восемь бит), так же как в example. Непонятно почему в этом example разрешается выравнивание comma minus, но это нюансы.
Я так понимаю что в трансивере есть логика, которая должна компенсировать этот разбег. Иначе никак. Может я не совсем понимаю логику работы, может быть нельзя передавать непрерывный поток пакетов?

Дошло. Но тогда не понимаю, почему вы управляете 10b символами. У вас не включен 8b/10b внутри GTP? Я посылал 8b поток и он там сам разбирался, что ему сейчас надо послать: плюс или минус.

В любом случае, как я помню align делается по любому K28.5. И еще вспоминаю, что в SATA они вроде должны парами передаваться.

У меня 16 битный интерфейс, посылаю в младшем байте - 101 11100. На счет плюс,минус теперь понятно. 8b/10b включен.

В принципе, мне простой serdes нужен. Не думал, что нужно заморачиаться с комами, и т.д. У альтеры в визарде, выбираешь Basic, и не думаешь как там протокол реализуется.
Как в спартане6 реализовать serdes?

Можно не заморачиваться - тактируйте весь приемник частотой, извлеченой из потока и будет вам счастье. А если нужно иметь независимые частоты - увы, они всегда будут отличаться, и необходимо в протоколе предусматривать возможность синхронизации.

Что же до SATA - там примитивы состоят из четырех символов. ALIGNp - K28.5, D10.2, D10.2, D27.3. ALIGNp, как я правильно вспомнил ранее, должен посылаться два раза подряд. RTFM, короче.

Тоесть, для приемника, не использовать опрный генератор? А какой клок завести?

Первый бит GTPCLKOUT. Но вам еще остается найти в документации, каким сигналом при этом делать ресет схеме (пока PLL не увидела входной поток).

может вам сгенерить Xilinx AURORA интерфейс, там проблема разницы частот опорных генераторов решена с помощью Clock Correction алгоритма.
а сам протокол вроде несложный

Clock correction sequence в AURORA - идеологически то же самое, что ALIGNp в SATA.

Сгенерил Aurora интерфейс, тот же результат. Я вот что не понимаю, я ведь компилю "example design", и если отбросить возможность того что в плате проблемы, то он по сути должен работать.
В нем есть модуль FRAME_GEN, который и генерит данные.

MEM_00 => x"00000e0d00000c0b00000a09000008070000060500000403000002bc00000100",
MEM_01 => x"00001e1d00001c1b00001a19000018170000161500001413000012110000100f",
MEM_02 => x"00002e2d00002c2b00002a29000028270000262500002423000022210000201f",
MEM_03 => x"00003e3d00003c3b00003a39000038370000363500003433000032310000302f",
MEM_04 => x"00004e4d00004c4b00004a49000048470000464500004443000042410000403f",
MEM_05 => x"00005e5d00005c5b00005a59000058570000565500005453000052510000504f",
MEM_06 => x"00006e6d00006c6b00006a69000068670000666500006463000062610000605f",
MEM_07 => x"00007e7d00007c7b00007a79000078770000767500007473000072710000706f",

MEM_08 => x"00000e0d00000c0b00000a09000008070000060500000403000002bc00000100",
MEM_09 => x"00001e1d00001c1b00001a19000018170000161500001413000012110000100f",
MEM_0A => x"00002e2d00002c2b00002a29000028270000262500002423000022210000201f",
MEM_0B => x"00003e3d00003c3b00003a39000038370000363500003433000032310000302f",
MEM_0C => x"00004e4d00004c4b00004a49000048470000464500004443000042410000403f",
MEM_0D => x"00005e5d00005c5b00005a59000058570000565500005453000052510000504f",
MEM_0E => x"00006e6d00006c6b00006a69000068670000666500006463000062610000605f",
MEM_0F => x"00007e7d00007c7b00007a79000078770000767500007473000072710000706f",


На приемной стороне я получаю


02bc - comma aligment.


LSB - 67 69 6A 6C
MSB - 68 6A 6B 6D











Только что посмотрел, у меня еластик буфер underflow. Навеное в этом и проблема.

А где у вас в памяти данные, которые вы посылаете на вход TXCHARISK?