Добрый день!.
Мне в проекте потребовалось использовать модуль синхронного FIFO (т.е. у клок), вроде бы ничего сложно, но т.к. раньше такого не делал, возникла заминка.
Для начала сгенерировал в альдеке то что они предлагают использовать и использовав их код в качестве референсного немного его переписал. Т.к. они в качестве указателей пользуют integer range и обрабатывают его переполнение, я заменл это на std_logic_vector и убрал обработку(это дало код, который синтезатор исе лучше "понял", если судить по его отчету).
Но при симууляции возникили вопросы:
Флаги empty & full в коде регистровые, т.е. сигнал на выходе появляеься на такт позже управляющих сигналов (одновременно с записью/чтением РАМ).
поэтому в тестбенче, который моделирует синхронный модуль, с которого информация пишеться в фифо, и синхронный модуль который читает фифо, происходит "перегрузка".
Например при глубине в 8 чисел, делаеться попытка писать в фифо 9 (строб записи 9 тактов), А при чтении модуль читает 9 чисел, вместо 8.
Эту проблему можно решить если сделать флаги empty&full не регистровыми или ввести дополнительную асинхронную логику в синхронные блоки. Можно усложнить блок управление фифо - например ввести сигнал ошибки записи. (как в апноте от ксайлинкса).
И мой вопрос: Как лучше сделать ?? Просто не хочеться терять много времени на экспиременты.

ЗЫ. Сильно не пинайте если что

Почему не в CoreGen?

Core Cen пользует готовые макросы и примитивы , а я хочу научиться писать на языке так, что бы все синтезировалось в то, как было задумано, с помошью правильно написанного кода и атрибутов
И я хочу понять принцип, все таки флаги должны быть регистровыми, или асинхронными.

Можно посмотреть статейки о FIFO тут
http://www.sunburst-design.com/papers/

http://forum.electronix.ru/index.php?showtopic=3197 ?

Есть негласный стандарт при проектировании ASIC и FPGA: все, что касается памяти, делать на имеющихся на кристалле ресурсах (hardcore macroses). IBM ASIC Design Group проводила исследование по поводу эффективности применения регистровой памяти (а здесь именно этот тип и получится) при построении FIFO/LIFO. Так вот, до 256 байт - можно. Существенной деградации производительности и ресурсозатрат не проиходит. Все, что свыше этого - только с помощью ядер (аппаратаных примитивов типа BlockRAM у XILINX). Как-то очень давно, роясь в XILINX DataSheets, прочитал прямое указание использовать исключительно BlockRAM для генерации FIFO вместо HDL-inferred.

Нельзя ли уточнить, каковы причины использования Inferred RAM вместо применения готовых и оптимизированных ресурсов?

Причины как я уже указал, в том, что хочу научиться писать на хдл, без применения black box, там где это возможно, например с помощью констрейна RAM_STYLE можно уложить память описанную на хдл, туда куда нужно.
А насчет distributed ram если нужен фифо на 16 слов, зачем пользовать 2 килобайтный блок ? ?)



спасибо, знакомлюсь



Вопрос по пдф, xapp131, рисунок Figure 2: 511 x 8 Synchronous FIFO
у меня получаються точно такиеже осцилограммы, за одним исключением на рисунке 2 строб записи прерываеться одновременно с установлением сигнала full. У меня в в тест бенче процесс записи:


и строб записи перекрывается с full на такт (

Действительно, для указанного объема памяти использовать 2 Кб ресурсов не следует. До 256 байт - вполне подойдет регистровая память. Об этом я писал выше.

А какая вам разница? Если есть лишний блок памяти, почему бы его не использовать?

Про диаграммы: может, ошибка?

Да нет, похоже я начинаю немного "въезжать" после прочтения пдф и мои логические рассуждения оправдываються :

The Empty flag is set when either the fifocount is zero, or when the fifocount is one and only a
Read is being performed. This early decoding allows Empty to be set immediately after the last
Read. It is cleared after a Write operation (with no simultaneous Read). Similarly, the Full flag
is set when the fifocount is 255, or when the fifocount is 254 and only a write is being
performed. It is cleared after a Read operation (with no simultaneous Write).

т.е. похоже что флаги действительно имеют латентность в 1 такт и это нужно учитывать, либо более ранним выставлением флагов, либо дополнительной обработкой снаружи фифо.

У Xilinx'а есть несколько xapp'ов, посвященных реализации синхронных (один клок на чтение и на запись) и асинхронных (разные клоки) FIFO на блочной и распределенной памяти, смотрите на их сайте (там есть и исходники для разных вариантов).
Флаги лучше применять регистровые - положительно скажется на частоте.

Кстати, исходники там довольно корявые (если их творчески переработать с использованием generate и констант в разрядности шин - они получаются более компактными и их легче модифицировать для разных задач). К сожалению с глубиной (особенно для асинхронных FIFO) все не так просто, поскольку для генерации флагов там применяются счетчики Грея.

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

Задержку флагов не учтешь: событие, о котором сигнализирует флаг, увы, произошло на такт раньше. Но вообще ничего страшного здесь нет, этот флаг вполне можно использовать, например, если темп поступления входных данных, а именно строб WE идет со скважностю >= 2. В этом случае установка флага как раз соответсвует времени записи нового слова. Если же запись данных производится непрерывными блоками (сигнал WE установлен более чем на один такт), то в этом случае надо пользоваться флагами, соответствующими неполному заполнению FIFO.

Спасибо за короткий и понятный ответ.
Вы окончательно утвердили мои сомнения.