Может я что-то не заметил, но - делаю пустой проект, MegaWizard'ом рожаю двух клоковое fifo, делаю vwf с повторением примера от Wizard и, с удивлением, вижу в симуляторе смещение q от фронта rdreq не на 2 клока, а на 4! Quartus 5.0 не web. Для меня эти два клока ой как не лишнии! Может кто с этим dcfifo боролся? Или надо забыть об использовании данной мега и все писать ручками?
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

Надо корректно формировать объем FIFO. Интервал записи больше объема.
при этом у Вас стоит опция писать данные при заполненном фифо.
Вы данные теряете.

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

Я досконально с этим фифо не разбирался, потому что использую только одноклоковое фифо.
Если у Вас раздельные клоки по записи и чтению и они не синхронны, без задержки по чтению не обойтись. Да и по ресурсам это больше, чем одноклоковое.
В одноклоковом фифо я использую структуру типа

module in_out (global_clk, in_clk, input_data, inout_clk, out_clk, out_data);

output [7:0] out_data;
output out_clk;

input global_clk;
input [7:0] input_data;
input in_clk;
input inout_clk;

reg [7:0] out_data;
reg [7:0] in_data;
reg [1:0] sdvig_in_rg;
reg [1:0] sdvig_out_rg;

wire e_wr_rg;
wire e_rd_rg;

assign out_clk = inout_clk;

always @ (posedge global_clk)
begin
sdvig_in_rg <= {sdvig_in_rg[0], in_clk};
sdvig_out_rg <= {sdvig_out_rg[0], inout_clk};
end

assign e_wr_rg = sdvig_in_rg[0] & ~sdvig_in_rg[1];
assign e_rd_rg = ~sdvig_out_rg[0] & sdvig_out_rg[1];

always @ (posedge global_clk)
begin
if (e_wr_rg == 1'b1)
in_data <= input_data;
if (e_rd_rg == 1'b1)
out_data <= in_data;
end

endmodule
И никаких задержек по чтению.

Все просто: вы подали сигнал rdreq во время того, как rdempty был '1'. FIFO игнорирует rdreq если rdempty='1'. Я обычно ползуюсь следующей логикой:

signal q_ready: boolean;

process(clk, resetN)
begin
if resetN='0' then
q_ready<= false;
elsif rising_edge(clk) then
if rdempty='0' and rdreq='1' then
q_ready <= true;
else
q_ready <= false;
end if;
end if;
end process;
.............................
Далее:

if q_ready then
sampled_q <= q;
end if;

Уважаемые ГУРУ!
Совсем еще зелен в этом деле, помогите советом, пжалста.
Имеется такая задача:
Есть CPLD, в которую снаружи последовательно вдвигаются/выдвигаются данные по клоку, формируемому устройством-хостом. С CPLD связан процессор, который забирает/подсовывает данные, клок формирует процессор, т.е. клоки чтения/записи совершенно асинхронны. Можно ли применить библиотечный dcfifo, чтобы обеспечить следующий алгоритм работы: устройство-хост формирует сигналы wrreq, wrclk и заполняет FIFO; при появлении сигнала wrfull процессор формирует сигналы rdreq и rdclk и вычитывает данные из FIFO. Можно ли победить задержки с появлением сигналов wrfull и rdempty? Можно ли формировать клок эпизодически, т.е. только на время вычитывания данных?

1. Частоту лучше держать постоянно.
2. Используя выход usedw можно контроллировать количество слов в фифо и в любой момоент иницировать или прекращать запись или чтение.
3. Реализация такого фифо в CPLD будет весьма проблематична по причине отсутствия там (в CPLD) встроенной ОЗУ.

1. Нужно формировть rdclk постоянно и оперировать лишь rdreq? Но ведь внешний процессор не знает скорости поступления данных! Разве что формировать rdclk из wrclk?
2. Я конечно еще поэкспериментирую и, возможно, эта проблема отпадет при замене эпизодической генерации rdclk постоянной генерацией, но ведь сигнал rdempty сбрасывается в ноль с задеркой в несколько тактов rdclk после появления wrfull, значение rdusedw тоже отстает от wrusedw. И, как указывал уважаемый Jenik, пока rdempty = '1' читать не полагается.
3. Большой глубины буфера не требуется, поэтому реально обойтись dff

А проблема то в чём ?

Fish,

Clocks уберать не советую. Может и работать будет, но не думаю что dcfifo на это расчитан. Я думаю что убирать клоки нужно толко в том случаи, если они создают помеху для других частей схемы. Для того, что бы не менять частоту, можно держать клоки всегда на максимально возможной частоте. Считывать из фифо надо не когда оно полностью заполнилось, а когда оно ДОСТАТОЧНО заполнолось. (ДОСТАТОЧНО - зависит от конкретной задачи). Что касавтся задержки между входом и выходом, то если клоки не синхринизированы, то ничего не поделаеш. Если же есть синхронизация, то можно использоват синхроный ФИФО.

Спасибо. Я почитал документацию на библиотечные FIFO и понял, что видимо dcfifo не удасться применить. Занялся прикручиванием scfifo.