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

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

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

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

Спасибо!

а частоты 15 и 30 МГц когерентны или независимы?

независимы

Тогда еще два вопроса:
1) Почему два FIFO, а не одно на 2048 бит?
2) Собственно выбран IP с явной поддержкой двух независимых доменов тактовой частоты, или нет?

1) диапазон у ip от 1 до 1024
2) да, два домена

Какова глубина FIFO?
Переполнение не происходит? Учтите, что у Xilinx FIFO получается глубиной на 1 меньше заявленной,
к примеру 1023 при ожидаемой глубине 1024.
Ещё есть фишка с флажками - они опаздывают на 1 такт. Поэтому в некоторых случаях приходится вставлять
принудительную задержку на 1 клок в стэйт машине обработки фифо.

Не надо ни чего вставлять, все уже придумано и сделано. При синтезе IP поставьте флажок на "Read Port Handshaking" и
данные у себя в проекте захватывайте по сигналу valid. Дальше, строб записи и "момент not_empty_fifo1 and not_empty_fifo2"
желательно (рекомендую) сделать синхронным относительно тактов записи и чтения соответственно.

Спасибо за подсказки! Сообщения про задержки FULL и сигналы VALID навели на мысль, я это забыл учесть.

Вы неправильно поняли вопрос. Речь тут идёт не о задержке данных на выходе относительно строба чтения, а совсем о другом.
Речь идёт о том, что флажки по уровню данных в фифо появляются с запозданием на 1 клок. И это необходимо учитывать.
А как вам приспичит формировать сигнал валидности - пользоваться сигналом valid либо сдвигать на 1 такт строб чтения - это к теме отношения не имеет.
Рекомендация привязать строб записи к клокам записи звучит весьма банально, без выполнения этого условия вообще ничего работать не будет.
Сигналы типа "not_empty_fifo1 and not_empty_fifo2" тоже привязывать к клокам чтения не нужно - они и так уже привязаны к этим клокам внутри блока фифо.
Лишняя привязка только добавляет задержку.

Не оспариваю очевидные вещи. Учитывать задержку можно самому, а можно воспользоваться готовым решением.
Рекомендация по привязке флажков к клокам предложена как вариант помощи, когда есть непонимание причины
происхождения сбоев. А вообще в подобных ситуациях ставлю тестовый поток имитации входных данных
(допустим счетчик), который включаю по команде извне.

Безусловно, симуляция (Modelsim,Questa или ActiveHDL) была бы крайне полезна автору для понимания логики работы ФИФО.
Как правило функциональная симуляция (без учёта задержек в кристалле) снимает 95% вопросов типа "почему не работает?" или "почему работает не так как надо?".

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

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

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

Из вышеописанного у меня возникает впечатление, что поток данных у вас значительно меньше, чем 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. Вы это и имели ввиду?

Я имел ввиду, что D10.2 это в своём роде уникальный код именно в десятибитной кодировке, что указывает на то, что проблема, наиболее вероятно, связана с SERDES и их обвязкой, а не с FIFO, и SERDES надо более детально протестировать, а потом можно будет делать выводы.

Спасибо большое!