Рассинхронизация двух IP FIFO Xilinx Опции

[Kirill_Good]

По ошибке создал не в той ветке прошлое сообщение.

Здравствуйте!

У меня в работе прошивки возникают ошибки, мое предположение из за рассинхронизации двух одинаковых IP FIFO. Опишу принцип работы : 2 ФИФО шириной по 1024 бита, чтобы хранить 2048 битные значения. Сигналы на запись подаются одновременно, сигналы на чтение тоже. ФИФО со стороны записи тактируется 15 МГц, со стороны чтения 30 МГц. Чтение происходит в момент not_empty_fifo1 and not_empty_fifo2. Ошибка заключается в том, что данные в некоторые моменты времени приходят первая часть 1024 верные вторая 1024 неверные, эти моменты времени периодичностью не выделяются.

Верно ли мое предположение?

Спасибо!

[Kirill_Good]

Спасибо за советы!

Причина сбоев в проекте стала ещё загадочнее. Проект заключается в передачи потока данных с DSP Freescale по RapidIO на Spartan 6, в плис находятся два буфера( один на прием из SRIO, другой на передачу в SRIO). Для отладки был создан loopback между этим фифо, то что приходит с DSP отсылается обратно. На DSP реализован такой механизм посылается пакет, ждет прихода его же, и только потом посылается следующий. В течении трех дней , возникала ошибка при посылке: не приходил от ПЛИС пакет всё время со значениями 4A4A4A.. (254 байта) и несколько раз поток тормозился из за неприхода пакета с данными B3B3B3B3...(254 байта). После многочисленных переделок прошивки FPGA решили убрать из генерации данных эти значения, и поток заработал, т.е все приходящие пакеты возвращаются!

Как можно такое объяснить?

[Timmy]

Спасибо за советы!

Причина сбоев в проекте стала ещё загадочнее. Проект заключается в передачи потока данных с DSP Freescale по RapidIO на Spartan 6, в плис находятся два буфера( один на прием из SRIO, другой на передачу в SRIO). Для отладки был создан loopback между этим фифо, то что приходит с DSP отсылается обратно. На DSP реализован такой механизм посылается пакет, ждет прихода его же, и только потом посылается следующий. В течении трех дней , возникала ошибка при посылке: не приходил от ПЛИС пакет всё время со значениями 4A4A4A.. (254 байта) и несколько раз поток тормозился из за неприхода пакета с данными B3B3B3B3...(254 байта). После многочисленных переделок прошивки FPGA решили убрать из генерации данных эти значения, и поток заработал, т.е все приходящие пакеты возвращаются!

Как можно такое объяснить?

Из вышеописанного у меня возникает впечатление, что поток данных у вас значительно меньше, чем 4096*200mb/s, просто вы полностью распараллеливаете входные пакеты до FIFO. Может быть, можно распараллеливать их после FIFO, чтобы уменьшить его разрядность, и проблема решится сама собой? Для передачи признака конца пакета можно использовать, например, дополнительный бит.

Объяснить сбои можно тем, что при сигнале определённой формы возникает сбой при передаче символов разделения пакетов, от чего всё падает. Например, прошивка FPGA глючит, если входной пакет имеет не ту длину.
Особенность кода 4A в том, что в десятибитной форме он становится 0101010101.

[Kirill_Good]

Из вышеописанного у меня возникает впечатление, что поток данных у вас значительно меньше, чем 4096*200mb/s, просто вы полностью распараллеливаете входные пакеты до FIFO. Может быть, можно распараллеливать их после FIFO, чтобы уменьшить его разрядность, и проблема решится сама собой? Для передачи признака конца пакета можно использовать, например, дополнительный бит.

Объяснить сбои можно тем, что при сигнале определённой формы возникает сбой при передаче символов разделения пакетов, от чего всё падает. Например, прошивка FPGA глючит, если входной пакет имеет не ту длину.
Особенность кода 4A в том, что в десятибитной форме он становится 0101010101.

С рассинхронизацией вопрос решил, просто это уже был побочный эффект переделок прошивки. А на счет символов 0х4А я нашел упоминания об этом и других символах, а именно в 8/10 bit encoding. В протоколе SRIO это реализовано на PHY уровне. 4А это b'01001010, и это из специальных символов, там есть и другие. Я пока мало нашел, потому что из разных источников по копейке. В одном упоминалось что это последовательность генерируется для постоянной синхронизации между контроллерами в неактивном состоянии. Нашел ещё про d10.2 pattern. Никто про него не слышал?

Timmy, вы его как раз написали, я сейчас только заметил, да d10.2 это та последовательность которую вы написали. Там где она есть я ещё увидел такие слова как " Jitter Tolerance Test Pattern " и "critical phase shifts" в SerDes. Вы это и имели ввиду?

Сообщение отредактировал Kirill_Good - Jul 28 2011, 12:00