Пытаюсь сделать FIFO с двумя клоками.
Есть проект со своим тактовым сигналом и есть данные от АЦП, сопровождаемые одним клоком (формируемым из проектного клока). Пытаюсь ввести между ними FIFO данных (dual clock) для исключения возможных неоднозначностей при взаимном джиттере этих тактовых сигналов - FIFO, содержащее не менее двух и не более восьми слов. Клок от АЦП может пропадать, эта ситуация (мусор на выходе FIFO) просто игнорируется.
Кроме того, это будет необходимо при возможном переходе на мультиплексированную шину от АЦП, когда за один период тактового сигнала передается две выборки.

КОроче, не получается... Вот кусочек проекта.
Ещё... Кто знает, означает ли примечание (4) в описани ug_fifo.pdf, что сигналы wrempty и rdempty можно использовать только в конфигурациях с разной шириной шин входа и выхода?

Для контроля работоспособности проекта используется версия этого блока без FIFO, просто с синхронизатором.

Любые варианты комбинационной логики с соответствующих выходов (количество занятых слов FIFO) на входы дают неработоспособные варианты схемы. Если "зажать" wrreq и rdreq на VCC - только в этом случае нет помех (шума) - но это не то, что хотелось бы от этой схемы получить (состояние между совеесм пусто и совсем заполнено).

Попробуйте сделать следующее:
С одной стороны счетчик ситает количество записанных слов до определенного значения, при достижении выдается импульс-готовности
Этот импульс-готовности передается через кросдомен клоков и с другой стороный начинается вычитка записанных слов.
Далее запись уже производиться в другую половину памяти и чтение делается из той половины памяти куда ранее писали данные..

При этом двупортовая память организована по принципу видеобуфера, т.е. в одну половину памяти только пишем, с другой половины памяти только читаем...

Можно попробовать сделать на регистрах, вместо использования блочной памяти

А зачем городить счетчик и кроссдоменную синхронизацию, если в fifo_dc это уже предусмотрено? Или оно на самом деле не работает и надол всё руками?

я Вам предложил без фифо.
Двухпортовая память + обвязка

PS фифо рабочее

Насколько понимаю, FIFO (особенно двуклоковые) крайне не любят работать в режиме "пропадания" такта.
Поставьте формирователь, который будет генерить такты из тактов АЦП даже в том случае, когда сами такты пропадают.

Ну это не пропадание...
Уточню: есть всегда идущий системный клок. Он идет наружу как LVDS, тактирует АЦП. От АЦП может идти либо тот же сигнал (текущая ситуация) либо с половинной частотой (мультиплексированная шина) либо сигнала нет (АЦП с поламперным птореблением с режиме передачи отправили в sleep).
Не очень понял генерить такты из тактов АЦП даже в том случае, когда сами такты пропадают.

Если тактовый от АЦП является производным от системного, то зачем двухклоковое ФИФО? Что клоки от АЦП как-то сильно дрожат или сдвинуты?
Может быть действительно, входные данные захватить простым регистром под клоки АЦП, а уже потом их протолкнуть в обычную память с раздельными шинами на запись и на чтение... И работать она будет уже на системной частоте...
Вопрос в том, зачем именно ФИФО, если исходный клок берется от системного?

Ситуация с мультиплексированием данных - это не повод?
В общем случае и без этого есть (на мой взгляд) ситуация - в случае неизвестной природы внутренних преобразований клока в АЦП можно напороться на ситуацию, когда его клок может как опережать так и опаздывать от клока системного. Для чео мне и захотелось FIFO...

А как с времянками по предустановке wrreq и rdreq перед клоками? И откуда они берутся... Ну, при чтении - понятно. А вот для записи?

Берутся с выходов состояния (количества слов) своей же половины FIFO через логическую функцию. сейчас rdreq = 0, если < 2, wrreq = 0, если >= 4.

Но ведь wrreq - это разрешение записи, а оно должно прийти ДО фронта входного клока. А если Вы формируете wrreq из сигналов на выходе, то они могут и не попасть ДО... Видимо поэтому, когда даете "всегда готов" для записи, то оно и работает...

Я понимаю, что wrreq снявшееся после того как 4 слова окажется в FIFO - это уже состояние "заполнившейся совсем" очереди. ДО начала записи оно и так яформировано. Там (вне FIFO) просто логика, без триггеров.

Возможно, что есть гонка сигналов на стороне выхода в схеме проверки состояния счетчика. Это узкие импульсы могут попадать на первичку и гробить запись...

Эти все гонки закончатся к началу следующего импульса - там всго 122 с копейками мегагерца... Обычный синхронный счетчик тоже с этими гонкаи работает.

Так, а что это "Table 6: Output Latency of the Status Flag for the DCFIFO"
Не соображу пока - wrreq to wrusedw[]: 2 wrclk

О! читать доки надо оказывается... Сделаю больше очередь - проверю.
Проверил - теперь не портится поток данных.

Пока компилируется, дошло - в идее использовать FIFO есть изъян - нет условий для "расасывания" совсем заполненой очереди.
Разве что, формировать сброс при смене режимов работы после того, как adc_clka стабилизируется. Правда, в условиях всегда существующего системного тактового сигнала (который чтение тактирует) это невозможная ситуация. Надежно ли?
Но для случая мультиплексированных данных это самое то.