Доброго времени, коллеги!
Разрабатываю описание аппаратуры для системы сбора и передачи данных.
Есть КА сбора данных и формирования протокола (общая длина 250 Байт), время формирования протокола 60 мкс, в течение которого данные записываются в двухпортовую память.
По окончанию работы в цикле этот КА формирует сигнал "готовности данных" (PRcomplete, второй снизу на диаграмме), длительностью порядка 900 нс.
По переднему фронту "готовности данных" второй КА формирует сигналы адреса и чтения из двухпортовой памяти, а также сигналы wrreq и wrclk управления буфером FIFO (на времянке представлен только сигнал разрешения записи и обозначен lngfifowrreq). Собственно буфер представляет сгенерированную квартусом (9.0 web Edition) мегафункцию с двумя раздельными тактовыми сигналами синхронизации для записи и чтения (улучшенной защитой от метастабильности). Перезапись данных происходит примерно за 5 мкс.
Оба КА работают безупречно, на одном тактовом домене 200 МГц. Запись производится на чатоте 50 МГц (на один такт записи тратится 4 такта 200 МГц).
Странности начинаются при попытке чтения дынных из буфера FIFO.
Предполагалось, что по окончанию перезаписи протокола в буфер, задним фронтом сигнала lngfifowrreq, должен запуститься КА формирующий сигналы rdreq и rdclk. Сиганл rdclk должен во время генерации идти с частотой 60 МГц. КА работат в тактовом домене 240 МГц, поэтому lngfifowrreq, поступает на КА через три триггера (входной с доменом 200МГц, а два выходных с доменом 240 МГц). В КА так же заводится сигнал опустошения читаемого буфера lngfifordempty, по которому должно прекратиться чтение данных из буфера. Отладка в моделсим показала правильные начало и остановку чтения буфера.
В реальном железе (cyclon II) КА не запускается, т.к. после перезаписи данных в FIFO вместе с установкой lngfifowrreq=0, выставляется сигнал lngfifordempty=1, несмотря на то, что во время перезаписи этот сигнал обнулялся(см временную диаграмму).
Попробовал вместо rdclk подать постоянную частоту 60МГц, дополнительно принудительно подавая нуль вместо сигнала rdempty - КА заработал, но не останавливается и иногда в приемной программе появляются повторы байт, которых быть не должно.
Подскажите, в чем может быть причина установки признака "буфер чтения пуст" (rdempty) при снятии сигнала wrreq?

Похоже нашел ответ -> здесь

Ну вот теперь, самостоятельно пройдя по собственным граблям, вы убедились, что gated clock - абсолютное зло, которое надо уничтожать повсеместно.

З Ы (Немного не в тему) А вообще забавно читать подобного рода посты типа "у меня задумана вот такая вот хреновина, она должна работать вот так и так,
но не работает - ааааа, памажите люди добрые, сорцы не покажу ибо коммерческая (или даже не дай бог военная) тайна и вообще копирайт".
Далее обычно следует ответ "давай сорцы, телепаты в отпуске".
Ну а потом 2 варианта : 1 - сорцы дал, нашли косяк - помогли, исправили.
или 2 вариант : "таки залез в гугл, нашёл похожую траблу, исправил сам".
Пора уже видимо FAQ писать на тему "ааааа, памажите, у меня ничего не работает".

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

Да, убедился, что неправильно понимал работу FIFO и тактовые сигналы надо подавать постоянно, а не только во время операций чтения/записи.
Сожалею что ранее отнял Ваше время на чтение и ответ в виде крика души.

Боюсь, что вы не до конца поняли в чём изначально корень зла. То, что фифошка работает некорректно с "прореженными" клоками - это следствие того,
что никто и никогда клоки не прореживает, это явление называется в англоязычной литературе "gated clock" и является причиной многих неприятностей в синхронном
дизайне.
Если объяснить в двух словах, то рекомендация следующая : никогда не пропускайте клоки через логику, если надо управлять клоками - используйте спец. вход триггера clock enable.
Всё это очень широко описано в соответствующей литературе и неоднократно обсуждалось на форуме.